| 00:54.42 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 01:23.57 | DocScrutinizer05 | ext4lazyinit my ass |
| 01:27.13 | *** join/#maemo err0r3o3 (~err0r3o3@178-191-18-83.adsl.highway.telekom.at) |
| 01:39.31 | *** join/#maemo drathir (~kamiljk8@unaffiliated/drathir) |
| 01:53.09 | *** join/#maemo DarioAlejandro (~root@198.199.119.90) |
| 04:38.54 | *** join/#maemo APic (~apic@apic.name) |
| 06:10.12 | *** join/#maemo rhn_mk1 (~rhn@unaffiliated/rhn) |
| 06:41.04 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 06:47.34 | Enrico_Menotti | So. I changed /usr/share/hildon-application-manager/catalogues/variant-catalogues.xexp for the catalogues to point to muarf.org. Next I open HAM. The catalogues are ok. I go for updates. Result: no updates available. Log: http://paste.ubuntu.com/25456343/ (lines 2 and 3 are repeated many times, with many different package names. I just reported them one time in the pastebin). Now I close HAM. I remove (or rename) |
| 06:47.34 | Enrico_Menotti | <PROTECTED> |
| 07:37.58 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 07:48.41 | brolin_empey | DocScrutinizer05: Use eSATA to avoid SATAâUSB conversion overhead? |
| 07:52.13 | brolin_empey | Has anyone else noticed the conceptual similarity between having an SSD on a PCI Express card and the HDDs on an ISA card used in the 1980s? ⺠|
| 07:52.43 | KotCzarny | isa is already burned down. that witch. |
| 07:58.05 | brolin_empey | KotCzarny: There are Socket T AKA LGA775 (Intel Core 2 era) motherboards with at least 1 ISA slot but, if I recall correctly, Socket 478 (Pentium 4) is the last generation of motherboard with an ISA slot with working DMA for an ISA card. |
| 08:01.38 | *** join/#maemo dmth|intevation (~dmth|inte@5.147.144.77) |
| 08:03.34 | brolin_empey | Incidentally: After having a bulging battery in two models of smartphone with a removable battery (Samsung Galaxy Note 3 and Geeksphone Revolution), I do not think I want a mobile computer with a non-removable battery. |
| 08:03.34 | brolin_empey | I was curious how to replace the ânon-removableâ battery of the BlackBerry KEYone. |
| 08:03.34 | brolin_empey | https://www.ifixit.com/Guide/BlackBerry+KEYone+Motherboard+Disassembly/92149 |
| 08:03.34 | brolin_empey | That looks like a lot of work only to remove an internal battery. I do not have an electric blow dryer. |
| 08:03.34 | brolin_empey | https://www.phonedog.com/2013/09/26/i-don-t-think-i-ll-ever-understand-the-point-of-non-removable-batteries |
| 08:04.45 | KotCzarny | tbh i do not know how is any samsung phone related to #maemo |
| 08:04.48 | KotCzarny | :P |
| 08:21.51 | *** join/#maemo florian (~fuchs@x4d094406.dyn.telefonica.de) |
| 08:27.10 | *** join/#maemo jkepler (~Thunderbi@2a01:e35:2f37:400:224:d7ff:feaa:82a8) |
| 08:31.45 | *** join/#maemo florian_ (~fuchs@x4d094406.dyn.telefonica.de) |
| 08:59.12 | rhn_mk1 | did anyone try to use the 0xFFFF flasher recently? It complains about my libusb version, even though it seems correct |
| 09:02.13 | Enrico_Menotti | rhn_mk1 It needs libusb0.1, not libusb1.0, nor libusb1.0 + compatibility layer to libusb0.1 (I don't remember its name). |
| 09:03.04 | rhn_mk1 | Enrico_Menotti: hm, maybe I have both versions installed... |
| 09:04.36 | Enrico_Menotti | rhn_mk1 ...and it sees the wrong one. May be. |
| 09:05.21 | rhn_mk1 | Enrico_Menotti: libusb-devel-0.1.5-7.fc24.x86_64 looks good, doesn't it? |
| 09:05.39 | rhn_mk1 | do you know what happens if the wrong one is used? |
| 09:07.27 | Enrico_Menotti | Well, as far as I know, libusb1.0 has a different interface from libusb0.1, or something of the kind. They are different packages. And if you use libusb1.0 + compatibility layer, it's too slow, or something of the kind. For further details, better ask Pali, I think. |
| 09:07.56 | Enrico_Menotti | What is your OS? |
| 09:08.34 | rhn_mk1 | Enrico_Menotti: Fedora 25 |
| 09:09.21 | rhn_mk1 | the source of the libusb-devel package is hard to understand... |
| 09:09.58 | Enrico_Menotti | I'm not used to it in any way. I managed to get 0xFFFF working on a Mac (yes, made some adjustments and recompiled). And had to install libusb0.1. I may look at the Debian available packages, but don't know whether that would help with Fedora. |
| 09:10.37 | rhn_mk1 | Enrico_Menotti: worst case there's local installation or Docker :) |
| 09:11.07 | rhn_mk1 | but I want to improve something, I guess, or I'd just flash with the closed flasher already |
| 09:11.52 | Pali | libusb1.0 is slow |
| 09:12.11 | Pali | so when you combine libusb1.0 + compat layer for 0.1 then it would be slow too |
| 09:12.26 | Pali | you need to use libusb0.1 for 0xFFFF |
| 09:13.01 | rhn_mk1 | Pali: what are the consequences of the slowness? no detection? fails in the middle? |
| 09:13.22 | Pali | no detection or sometimes no detection |
| 09:13.38 | Pali | fail in the middle can happen, if "middle" means to reconnect |
| 09:14.37 | rhn_mk1 | Pali: why are delays critical? will the device timeout somehow? |
| 09:14.59 | Pali | yes, you need to start communication with device in time window |
| 09:15.00 | Enrico_Menotti | On Debian the package is libusb-0.1-4. I believe the libusb-devel is not the correct one (but I may be wrong). |
| 09:15.29 | rhn_mk1 | I just found that Fedora uses libusb-compat |
| 09:15.55 | Enrico_Menotti | Yes, that's the compatibility layer. So you're using libusb1.0 + compat layer. |
| 09:16.26 | rhn_mk1 | or actually I'm using libusbx + compar layer |
| 09:16.51 | rhn_mk1 | thanks for the hints |
| 09:16.57 | Enrico_Menotti | Yw. |
| 09:18.20 | Enrico_Menotti | Pali: hello. Could you please have a look at what I asked earlier (08:47 CEST)? Maybe you can help. |
| 09:23.25 | rhn_mk1 | is there some reputable source hosting N900 flash images? |
| 09:24.07 | Enrico_Menotti | ~lf |
| 09:24.07 | infobot | i guess #maemo lazyflashing is http://wiki.maemo.org/Updating_the_tablet_firmware#The_Lazy_Approach |
| 09:24.24 | *** join/#maemo sodadosa (~bonggie@180.253.133.246) |
| 09:24.28 | rhn_mk1 | thanks |
| 09:24.50 | Enrico_Menotti | Or also a mirror I found on archive.org, up to PR1.3. |
| 09:25.42 | Enrico_Menotti | http://web.archive.org/web/20131117073524/http://skeiron.org/tablets-dev/nokia_N900/ |
| 09:26.25 | rhn_mk1 | oh, that's quite good |
| 09:28.04 | KotCzarny | ~flashing |
| 09:28.04 | infobot | hmm... maemo-flashing is http://wiki.maemo.org/Updating_the_tablet_firmware, or - on linux PC - download&extract http://maemo.cloud-7.de/maemo5/patches_n_tools/maemo-my-private-workdir.tgz, cd into it, do sudo ./flash-it-all.sh; or see ~flashing-cmdline, or see ~lazyflashing |
| 09:28.20 | KotCzarny | get the script, run it, forget about downloading anything else |
| 09:28.40 | KotCzarny | all you need is already in the script |
| 09:28.56 | rhn_mk1 | I don't like running random scripts as root :P |
| 09:29.10 | KotCzarny | i assume you have the ability to read? |
| 09:31.16 | rhn_mk1 | oh, I just did that |
| 09:39.21 | *** join/#maemo Wikiwide (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 09:57.20 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 10:07.53 | Wizzup | freemangordon: jenkins is now up, almost building the first package. we need to change one or two things on the git side to get it to build. then we can look at pushing it to a reprepro repo |
| 10:08.06 | Wizzup | and then we need more glue to automatically build packages and such, but that's OK |
| 10:08.09 | Wizzup | at least then the basics work |
| 10:08.34 | Wizzup | the more complex thing will be to build fremantle packages that depends on other fremantle packages - then we need to ensure it also fetched those build deps ... from its own previously built repo |
| 10:19.02 | *** join/#maemo florian_ (~fuchs@x4d094406.dyn.telefonica.de) |
| 10:19.11 | *** join/#maemo TheKit (~nekit@85-95-189-161.saransk.ru) |
| 10:21.28 | *** join/#maemo hurrian (~textual@unaffiliated/rikanee) |
| 10:28.15 | *** join/#maemo xy2_ (~xy2_@94.239.253.5) |
| 10:53.56 | parazyd | Wizzup: we can ask if/how it works in the devuan setup |
| 10:54.05 | Wizzup | we could |
| 10:54.13 | Wizzup | I want to understand how the plugins want it work :p |
| 10:54.16 | freemangordon | great! |
| 10:54.38 | freemangordon | in the meanwhile, I am finishing codelockui REing |
| 10:54.40 | freemangordon | :) |
| 10:54.46 | Wizzup | sweet! |
| 10:55.00 | parazyd | :) |
| 10:55.20 | freemangordon | BTW, anybody knows what it is used for? |
| 10:55.27 | freemangordon | I mean - is that devicelock? |
| 10:55.57 | Wizzup | haha, finishing REing something without knowing where it is used, I like it |
| 10:56.01 | Wizzup | (and no, I can only guess) :D |
| 10:56.21 | freemangordon | REing was started by jonwil |
| 10:56.42 | freemangordon | also, this is the lib used when you choose "remove operator lock" in control panel |
| 10:56.55 | freemangordon | but I am not sure what it is supposed to do actually |
| 11:00.42 | bencoh | freemangordon: I dont exactly remember which is which, but one is used to unlock device |
| 11:00.49 | bencoh | and the other is used in control panel |
| 11:01.05 | freemangordon | yep, this is the one used in cpl |
| 11:01.06 | bencoh | iirc codelockui is basically the code dialog |
| 11:01.16 | freemangordon | yes, it is, but what it is used for? |
| 11:01.27 | freemangordon | what code is that one? |
| 11:01.33 | freemangordon | "operator lock"? |
| 11:01.42 | bencoh | hmm no, the phone lock |
| 11:01.42 | freemangordon | WTF is that in terms of n900? |
| 11:01.52 | freemangordon | no, phonelock is libdevicelock |
| 11:01.56 | freemangordon | or devicelock |
| 11:02.07 | freemangordon | ah, you mean this is the ui? |
| 11:02.10 | bencoh | exactly |
| 11:02.28 | KotCzarny | make some changes and see where they show up? |
| 11:02.34 | bencoh | well, from what I remember, at least |
| 11:02.51 | bencoh | haven't fiddled with those for quite a while (1.5y or something) |
| 11:03.16 | freemangordon | hmm |
| 11:03.52 | bencoh | back then I wanted to fix it when in portrait mode... then I realized it was closed-source |
| 11:03.59 | freemangordon | no more :) |
| 11:04.12 | bencoh | yay :) |
| 11:04.22 | bencoh | fixing it should be possible soon then :) |
| 11:04.48 | bencoh | hm btw, while you're here ... would it be possible to make hildon/mb2 a non-compositing wm? |
| 11:04.58 | freemangordon | no idea :D |
| 11:05.21 | bencoh | and how well would it perform with llvmpipe on arm (has anyone tested it)? |
| 11:05.33 | bencoh | (assuming we have to keep it compositing) |
| 11:06.16 | freemangordon | ok, I managed to lock my dev device and there seems to be a bug in codelockui so I can't unlock it :D |
| 11:06.27 | bencoh | haha |
| 11:06.33 | KotCzarny | lol |
| 11:06.36 | bencoh | iirc there is some dbus call to unlock it |
| 11:07.01 | freemangordon | well, I keep the original .so, so I will revert to it, but still, it is funny |
| 11:16.11 | Wizzup | https://wizzup.org/first-build.png |
| 11:17.10 | freemangordon | Wizzup: BTW, you clone from github to another repo, right? |
| 11:17.23 | Wizzup | right now from the maemo gitlab, yeah |
| 11:17.30 | Wizzup | but we target any git URI |
| 11:17.33 | Wizzup | s/maemo/devuan/ |
| 11:17.51 | freemangordon | I think we'll have problems with branches, right? or not |
| 11:18.03 | Wizzup | yes |
| 11:18.11 | Wizzup | https://git.devuan.org/maemo/libcal |
| 11:18.15 | freemangordon | you always build master? |
| 11:18.17 | Wizzup | parazyd already made some branches/files/tags |
| 11:18.26 | Wizzup | and we need to fix most of the control files |
| 11:18.36 | parazyd | the maemo/ascii branch |
| 11:18.37 | Wizzup | but we'll get there, I don't have all the anwsers yet |
| 11:18.49 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 11:18.51 | freemangordon | ah, ok |
| 11:19.09 | freemangordon | jonwil: cheers https://github.com/community-ssu/codelockui |
| 11:19.32 | bencoh | congratz! :) |
| 11:20.54 | jonwil | Good to see that's finished |
| 11:21.19 | jonwil | And that hildon-plugins-notify-sv and libplayback also seem to be finished |
| 11:21.40 | freemangordon | mhm |
| 11:22.06 | freemangordon | though there are still problems in codelockui, but I am chasing them |
| 11:24.51 | jonwil | Great :) |
| 11:26.14 | Enrico_Menotti | Hello everybody. Could you please have a look at the question I asked earlier, around 8.47 CEST? In particular bencoh (muarf.org is your mirror, right?) |
| 11:26.22 | *** join/#maemo Vajb (~Vajb@85-76-12-27-nat.elisa-mobile.fi) |
| 11:28.03 | bencoh | Enrico_Menotti: hey! the KEYEXPIRED warning isn't related to the mirror. it just means that nokia signing keys have expired (quite a long time ago, actually - even before they closed their mirror) |
| 11:31.01 | Enrico_Menotti | Ah ok, so it's an unavoidable warning which I should live with. But one question: HAM was not working until I removed (renamed, actually) the /usr/share/hildon-application-manager/domains/variant-domains.xexp file. That contains some keys, which I don't know what are needed for. And a key is included also for repository.maemo.org - so I removed that as well, but this doesn't seem to affect that particular repository. |
| 11:32.20 | DocScrutinizer05 | that's no question |
| 11:32.32 | Enrico_Menotti | bencoh So what are those keys in variant-domains.xexp? |
| 11:32.38 | Enrico_Menotti | (This is the question.) |
| 11:33.48 | DocScrutinizer05 | very interesting if somebody finds an answer that's a) not 15 times the max postlen of freenode, and b) not just "RTFM man apt" |
| 11:34.20 | *** join/#maemo NeKit (~nekit@95-83-47-108.saransk.ru) |
| 11:34.43 | jonwil | Its good that we are getting more and more of the interesting stuff for the N900 (hildon-plugins-notify-sv for example) cloned :) |
| 11:36.09 | bencoh | hmm, no idea what variant-domains.xexp is, I've never had to bother |
| 11:36.26 | bencoh | (not that I use HAM much, but ... it does work here) |
| 11:36.36 | Enrico_Menotti | DocScrutinizer05 Sorry, why man apt? Is not this related to HAM? |
| 11:36.48 | DocScrutinizer05 | ham is apt based |
| 11:36.59 | bencoh | DocScrutinizer05: this is still HAM-specific |
| 11:37.23 | bencoh | and I doubt he'll find information regarding the HAM-apt glue in the apt manual :) |
| 11:37.27 | DocScrutinizer05 | then b) already is off the table :-D |
| 11:37.38 | DocScrutinizer05 | remains a) |
| 11:38.19 | DocScrutinizer05 | but how are certs HAM specific? I thought that's a genuine apt thing |
| 11:38.43 | Enrico_Menotti | bencoh How did you proceed to update the catalogues to muarf.org? Just disabled the original Nokia catalogues from the HAM GUI and installed the new catalogues? |
| 11:39.30 | DocScrutinizer05 | I wouldn't be surprised if the answer is "yes" or "click an install file" |
| 11:40.00 | DocScrutinizer05 | I for one never edited sourcelist files |
| 11:40.42 | DocScrutinizer05 | I copy them however, in enable-catalogs |
| 11:41.00 | Enrico_Menotti | Ok. When you click the install file, does that also install new keys? Or keys are not needed for the muarf.org mirror? |
| 11:41.19 | DocScrutinizer05 | there are no keys for muarf |
| 11:41.55 | DocScrutinizer05 | muarf is a mirror that doesn't build&sign stuff itself, so the original nokia keys apply |
| 11:42.07 | KotCzarny | what is stopping maemo team from repacking nokia debs with maemo.org keys? |
| 11:42.08 | Wizzup | makes you wonder why we can't just resign it. |
| 11:42.11 | Wizzup | ^^ |
| 11:42.15 | *** join/#maemo Kabouik (~kabouik@2a01:e35:2fd3:5030:e142:c406:c878:1d89) |
| 11:42.22 | KotCzarny | not that there would be any new package in those repos |
| 11:42.25 | DocScrutinizer05 | missing sources? |
| 11:42.35 | Wizzup | you don't need sources to sign it |
| 11:42.40 | KotCzarny | +1 |
| 11:42.49 | DocScrutinizer05 | bfc |
| 11:42.59 | DocScrutinizer05 | nfc even. ask the experts |
| 11:43.06 | KotCzarny | define 'experts' |
| 11:43.41 | DocScrutinizer05 | I think we looked into that for quite a few months, even Nokia dides did though they had no clue at all |
| 11:44.11 | Wizzup | devuan does this on a daily basis |
| 11:44.15 | Wizzup | afaik |
| 11:44.30 | Enrico_Menotti | Ok. So it's correct to "remove" the variant-domains.xexp, I guess. And what about repository.maemo.org? Does not produce any error nor warning without the key. And ehm, the original Nokia keys do not seem to apply to muarf: if I leave them there, I get the log I reported above (wrong domain). |
| 11:44.32 | jonwil | I think the issue is that there is no key in the stock firmware that is still valid (not expired) |
| 11:44.57 | Wizzup | jonwil: right, so cssu can add it |
| 11:45.06 | KotCzarny | but since packages would barf on keyexpireds, does it change anything? |
| 11:45.23 | Wizzup | this way one can change the repo url and add a key and be done |
| 11:45.55 | jonwil | Yeah resigning all the Nokia things with another key belonging to CSSU (and signing all the CSSU packages as well) seems like a good idea. |
| 11:46.30 | KotCzarny | would apt break if pkg key changes? |
| 11:47.15 | Enrico_Menotti | (Brb.) |
| 11:47.39 | bencoh | Enrico_Menotti: I'm not a good example, since I added the mirror urls to apt conf. and I don't really remember what I had to do for HAM to work (if any) |
| 11:47.46 | bencoh | s/any/anything/ |
| 11:49.11 | DocScrutinizer05 | Wizzup: no CSSU can't add it since we have no valid key to sign the new key |
| 11:49.39 | bencoh | well, technically CSSU has its own key |
| 11:49.41 | DocScrutinizer05 | we would need to instruct users to add the new key manually |
| 11:49.43 | bencoh | the one used to sign CSSU |
| 11:49.56 | bencoh | that is installed when upgrading (migrating) to CSSU |
| 11:50.01 | KotCzarny | couldnt cssu installer do that? |
| 11:50.02 | Wizzup | DocScrutinizer05: then people click a link in the browser and add the key |
| 11:50.06 | Wizzup | whatever, same thing |
| 11:51.41 | DocScrutinizer05 | sorry, I really have only a foggy idea about that stuff. Not much more than "Pali, freemangordon, and/or jonwil and others looked into it back when Nokia asked us how to fix their fuckup, and there was no feasible way for CSSU to accomplish that without help from Nokia that never came" |
| 11:51.50 | DocScrutinizer05 | I still have the emails |
| 11:52.23 | jonwil | My understanding is that there was no valid key in the stock ROMs that could be used to re-sign the Nokia repos |
| 11:52.26 | KotCzarny | because they were thinking about proper fix |
| 11:52.34 | DocScrutinizer05 | jonwil: yep |
| 11:52.42 | KotCzarny | i propose just resigning the debs with cssu key |
| 11:52.47 | DocScrutinizer05 | there was, but Nokia refused to use it |
| 11:53.14 | KotCzarny | well, another way would be breaking the key |
| 11:53.29 | DocScrutinizer05 | or just ignore it |
| 11:53.33 | KotCzarny | breaking onto nokia servers |
| 11:53.34 | Wizzup | jonwil: but a key can be added via the browser easily |
| 11:53.55 | Wizzup | *shrug* requiring some user interactions seems fine |
| 11:54.12 | DocScrutinizer05 | Wizzup: that been exactly the point |
| 11:54.18 | Wizzup | it's just that not fixing the re-signing is lame, but I can understand it if the issue is time constraints |
| 11:54.25 | Wizzup | DocScrutinizer05: is it? people already have to jump through several hoops for cssu |
| 11:54.27 | DocScrutinizer05 | prolly yes, with user interaction it's feasible |
| 11:54.49 | jonwil | Are CSSU debs currently signed? |
| 11:55.05 | DocScrutinizer05 | the concern back when was for doofus users who don't have a clue |
| 11:55.19 | DocScrutinizer05 | jonwil: nfc |
| 11:55.27 | DocScrutinizer05 | prolly not |
| 11:55.53 | DocScrutinizer05 | given they are built and packaged offline |
| 11:56.09 | DocScrutinizer05 | so who would be the key owner? |
| 11:56.09 | freemangordon | they are |
| 11:56.27 | jonwil | So they get signed when they get pushed to cssu-testing/cssu-stable/whatever? |
| 11:56.29 | freemangordon | maemo infra signs then |
| 11:56.34 | freemangordon | yes |
| 11:56.44 | DocScrutinizer05 | ooh fine :-) |
| 11:57.07 | jonwil | Ok so is the key that is used to sign those installed by CSSU (or as part of the CSSU process) or what? |
| 11:58.10 | *** join/#maemo NeKit (~nekit@85-95-189-140.saransk.ru) |
| 11:58.30 | freemangordon | jonwil: sorry, can't parse, please rephrase |
| 11:58.41 | DocScrutinizer05 | took me a while too :-) |
| 11:58.49 | jonwil | Ok so CSSU packages are signed by someone |
| 11:58.52 | freemangordon | your english is better |
| 11:59.00 | freemangordon | jonwil: in the repo, yes |
| 11:59.06 | DocScrutinizer05 | is the pubkey used to verify CSSU signature a part of the CSSU installation process? |
| 11:59.09 | freemangordon | yes |
| 11:59.41 | *** join/#maemo err0r3o3 (~err0r3o3@178-191-18-83.adsl.highway.telekom.at) |
| 12:00.00 | jonwil | Ok so right now there are 3 possibilities. First is someone running a stock firmware in which case it doesn't matter since they will be pointing at the stock Nokia repos that no longer exist. |
| 12:00.20 | Enrico_Menotti | I will be busy for a couple of hours (F1 race). See you later. Thanks for the discussion so far. |
| 12:00.40 | jonwil | The second possibility is someone who is running stock (or like me, stock with various replaced packages) but has changed their repos to point to a mirror |
| 12:00.49 | jonwil | The third is someone running CSSU |
| 12:01.23 | jonwil | IMO we should do this: |
| 12:01.24 | DocScrutinizer05 | jonwil: no CSSU????? o,O shame on you! ;-P |
| 12:01.54 | freemangordon | mhm |
| 12:02.07 | jonwil | I am running a mix of various cloned/updated packages (some I cloned, others cloned or upgraded by someone else) |
| 12:02.12 | DocScrutinizer05 | WAAH Pali has a terrible timing |
| 12:02.13 | freemangordon | anyway, codelockui seems to work :) |
| 12:02.24 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 12:02.53 | DocScrutinizer05 | I'm pretty sure he investigated the whole issue in epic depth back when |
| 12:03.48 | jonwil | IMO we should do this: |
| 12:03.50 | jonwil | 1.We re-sign all the Nokia packages with the CSSU key |
| 12:04.03 | DocScrutinizer05 | in general I agree we finally should reclaim contrpol over *all* signature keys, particularly since original Nokia repos are no more |
| 12:05.04 | DocScrutinizer05 | so not a single user can run updates without having CSSU installed and repo sourcelists fixed |
| 12:05.33 | DocScrutinizer05 | ergo we need to take action about that, finally |
| 12:06.24 | freemangordon | Wizzup: which branch should I use so it is easier for you? |
| 12:06.33 | Wizzup | freemangordon: I don't know yet, once I do, I'll let you know |
| 12:06.39 | Wizzup | I think just a tag is fine |
| 12:06.46 | freemangordon | ok, I'll use gtk2 sisnce then |
| 12:06.47 | Wizzup | right now we're making it auto generate and sign a repo :) |
| 12:07.01 | freemangordon | is that ok? |
| 12:07.06 | Wizzup | gtk2? sure |
| 12:07.08 | freemangordon | ok |
| 12:09.25 | jonwil | IMO we should do this: |
| 12:09.27 | jonwil | 1.We re-sign all the Nokia packages with the CSSU key |
| 12:09.28 | jonwil | 2.We put the re-signed packages in a mirror repo and make the CSSU installer update things to point there instead of the stock repo locations so anyone with CSSU gets all the stock packages properly signed and working again with no user interaction beyond installing or updating CSSU. |
| 12:09.30 | jonwil | 3.For people who are running a device but dont want to run CSSU, we have the appropriate "click here to add the new key" and "click here to add the new repo" links available somewhere |
| 12:09.31 | jonwil | That way anyone who just wants a stock device but wants to be able to pull Nokia packages without key errors can update their repos easily and those who want CSSU get CSSU and get it all done automatically. |
| 12:10.07 | KotCzarny | that should fix all those cssu installs that require manual package installations? |
| 12:13.21 | jonwil | Anyone got any comments on whether my idea is good or not? |
| 12:15.57 | freemangordon | jonwil: I guess the idea is good, but I don;t see who is going to release it |
| 12:16.54 | KotCzarny | jonwil seems to have run out of things to RE, so.. ;) |
| 12:17.11 | freemangordon | ah, right :) |
| 12:17.28 | KotCzarny | and he is keys expert too |
| 12:17.59 | Wizzup | jonwil: that is exactly what I thought/meant |
| 12:20.37 | jonwil | My idea requires somewhere we can host a nokia repo mirror and someone who has the relavent CSSU key and the ability to download the nokia repo from an existing mirror, sign it all and then upload it to new space. None of which I can help with (I dont have space to put it or keys to sign it with or the bandwidth/speed to do a full repo download and re-upload) |
| 12:21.11 | freemangordon | jonwil: iirc we are not allowed to host closed source packages |
| 12:21.35 | KotCzarny | jonwil, would you be able to write a script for someone to run oh his server? (ie. bencoh) |
| 12:21.36 | freemangordon | no idea how relevent is this in 2017, but still |
| 12:22.35 | jonwil | I dont think whatever remains of Nokia (either the Microsoft Nokia who was releasing Windows based crap or the other Nokia that is now releasing crap running some different OS) actually cares anymore about what happens to the N900 and its software. |
| 12:23.03 | jonwil | I dont know enough about writing shell scripts or signing packages to write such a script :) |
| 12:23.48 | KotCzarny | eager to learn pkg signing then? ;) |
| 12:24.25 | jonwil | Actually, I need to stop procrastinating and talking on here and watching crap on YouTube |
| 12:25.15 | jonwil | I am exhibiting at https://www.facebook.com/events/259797684501353/ and I have a billion things I need to build and change and prepare before I am ready... |
| 12:25.25 | jonwil | So I gotta stop messing about and actually start building :) |
| 12:26.37 | bencoh | note that re-signed packages can be host by 3rd parties |
| 12:26.54 | bencoh | hosted* |
| 12:29.39 | DocScrutinizer05 | ((<freemangordon> jonwil: iirc we are not allowed to host closed source packages)) yes exactly |
| 12:30.23 | DocScrutinizer05 | we are not even allowed to publish tablets-dev though in fact we always been the ones to host it, on maemo infra |
| 12:31.22 | KotCzarny | are we allowed to RE packages? |
| 12:31.24 | Wizzup | why are you not allowed? |
| 12:31.34 | Wizzup | and if you host it anyway, might as well just sign it |
| 12:31.37 | KotCzarny | and to publish/create debs out of the results? |
| 12:31.40 | DocScrutinizer05 | Wizzup: because Nokia tells us so |
| 12:31.56 | Wizzup | but I'm not maemo |
| 12:33.13 | DocScrutinizer05 | you may do whatever you want, you are also the one to suffer any consequences. "We" (maemo 'official') do not discourage anybody hosting Nokia proprietary stuff, but Maemo is not allowed to do it |
| 12:33.44 | bencoh | :) |
| 12:33.51 | Wizzup | problem solved |
| 12:37.48 | jonwil | I believe the deal that transferred maemo infra to community specified that community doesn't get any of the secret stuff (i.e. anything related to projects.maemo.org) and community isn't allowed to distribute the Nokia device repos. |
| 12:38.45 | jonwil | But there is nothing (other than the very very low risk of being sued by the ghost of Nokia) stopping someone that isn't "community" from redistributing the Nokia repos. |
| 12:40.20 | jonwil | So we just need someone to come up with a way for whoever has a repo already to re-sign things. |
| 12:40.36 | jonwil | Then we make CSSU point to that 3rd party repo |
| 12:40.41 | jonwil | and we are in business :) |
| 12:41.17 | bencoh | except that we don't want a 3rd-party to resign |
| 12:41.18 | *** join/#maemo florian_ (~fuchs@x4d094406.dyn.telefonica.de) |
| 12:41.56 | bencoh | s/resign/re-sign/ |
| 12:42.11 | jonwil | well "community" (i.e. official infra) can't host a repo. |
| 12:42.15 | bencoh | so you'd need maemo to re-sign packages at some point |
| 12:42.19 | bencoh | yeah I know :) |
| 12:42.36 | Wizzup | reprepro can do this in a breeze |
| 12:44.18 | jonwil | Ok so then we need someone who has the CSSU key to re-sign an existing (or new not-hosted-by-community) mirror somehow. |
| 12:45.00 | jonwil | Then we have a mirror signed by the CSSU key (which is what we want) but not hosted by community in a way that violates any nokia deals. |
| 12:45.01 | bencoh | "somehow" yeah :) |
| 12:47.13 | Wizzup | well, if maemo does not want to be associated, they should not sign it |
| 12:47.36 | bencoh | who would you trust then? |
| 12:47.37 | DocScrutinizer05 | http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2013-01-24.log.html#t2013-01-24T13:13:24 |
| 12:49.01 | jonwil | Anyhow, this isn't something I can do anything to help with really |
| 12:50.11 | bencoh | ohwell, that link has some info regarding the .xexp file as well |
| 12:50.20 | bencoh | Enrico_Menotti: ^ |
| 12:50.48 | DocScrutinizer05 | ((<jonwil> Then we make CSSU point to that 3rd party repo)) is arguable, but I *think* of manageable risk nowadays |
| 12:52.02 | jonwil | So we need to figure out whether we have the repo signed by the CSSU key or by someone else and then make that happen. |
| 12:52.27 | DocScrutinizer05 | *somehow* skeiron was exactly that |
| 12:52.52 | DocScrutinizer05 | some folks inside maemo went nuts about it |
| 12:55.43 | DocScrutinizer05 | a secret guerrilla crew did an awesome job setting up skeiron and mirror *everything* there, and in turn the only "support" by maemo council needed would have been that they finance a totally unrelated backup server as compensation for the infra provided by skeiron team. We all know where that ended (fro those who don't: see my signature in tmo) |
| 12:55.56 | *** join/#maemo NeKit (~nekit@85-95-188-221.saransk.ru) |
| 12:58.06 | DocScrutinizer05 | hail hildon foundation >:-( |
| 13:00.03 | DocScrutinizer05 | woody been one of that guerrilla crew, but later blamed me for lying at him. I mean, how insidious can it get? |
| 13:00.56 | bencoh | I don't think going through this helps anymore ;) |
| 13:01.05 | Wizzup | I don't know anything about this, and I do not know what good this does bringing it up again here and now |
| 13:01.22 | DocScrutinizer05 | you're right, sorry |
| 13:01.33 | DocScrutinizer05 | I just felt deep anger and frustration |
| 13:01.44 | DocScrutinizer05 | had to vent |
| 13:03.14 | jonwil | We need to stop talking about the past and look at the future. Do we intend to re-sign the repos or not? What mirror do we want to re-sign? And which key do we want to use to re-sign it? |
| 13:04.35 | DocScrutinizer05 | I *think* we could create a maemo-hosted mirror with restricted access to host the new-signed stuff |
| 13:05.11 | DocScrutinizer05 | as long as "nobody" (but those with the credentials) has access, we're fine with hosting on maemo |
| 13:05.46 | DocScrutinizer05 | too bad when the credentials "leak" |
| 13:06.01 | DocScrutinizer05 | ;-) |
| 13:06.05 | bencoh | DocScrutinizer05: you can actually re-use existing credentials ;) |
| 13:06.22 | bencoh | (that's what I did for ovi) |
| 13:06.48 | DocScrutinizer05 | bencoh: it must not be too obvious |
| 13:07.08 | jonwil | Anyhow, this is 100% out of my hands, I have nothing to do with it :) |
| 13:07.21 | bencoh | same here :) |
| 13:07.29 | DocScrutinizer05 | e.g. re-implementing that old "please enter your IMEI" thing won't fly |
| 13:08.58 | *** join/#maemo NeKit (~nekit@85-95-178-99.saransk.ru) |
| 13:09.19 | DocScrutinizer05 | I think of really installong a regular .htaccess with user/password, and some folks running a real non-affiliated mirror will find out about those credentials by social engineering, hacking or whatever |
| 13:10.21 | DocScrutinizer05 | or similar to tablets-dev which is also still there, just nobody knows about it ;-) |
| 13:12.48 | DocScrutinizer05 | NB I do _not_ suggest to use the "upstream secret" URL for sources.list in devices. They should use unaffilated mirrors. Those mirrors should sync to that hidden master |
| 13:14.05 | bencoh | by the way ... https://github.com/postmarketOS/pmbootstrap/issues/438 :) |
| 13:14.29 | bencoh | (tl;dr: pavelmachek detailing n900 mainline status as a daily driver) |
| 13:18.30 | *** join/#maemo TheKit (~nekit@178.45.238.122) |
| 13:18.52 | DocScrutinizer05 | nice |
| 13:25.10 | DocScrutinizer05 | HMMMMM. about re-signing Nokia mirror: CSSU could validly claim they need a working Nokia mirror for their own building process, so they could host such mirror which is "only available to them" via above mentioned credentials |
| 13:25.35 | DocScrutinizer05 | :-D |
| 13:26.26 | DocScrutinizer05 | would make more than just some sense when such CSSU "private" mirror had been re-signed by CSSU keys |
| 13:27.52 | DocScrutinizer05 | when some "ev17 h4x0r5" crack and mirror that private Nokia CSSU mirror, what could we possibly do? |
| 13:29.02 | bencoh | this is a public chan with public logs :p anyway |
| 13:29.29 | *** join/#maemo N-Mi (~nicolas@calvix/staff/N-Mi) |
| 13:29.49 | DocScrutinizer05 | we will diligently change the credentials once a month and run fail2ban and everything against the mirror to protect it. NFC how those evil hax0rs manage to always copy it |
| 13:30.05 | bencoh | -_- |
| 13:31.31 | DocScrutinizer05 | bencoh: the idea is we don't do anything evil. So we better discuss this publicly to make sure we didn't miss any aspect ;-) |
| 13:41.44 | DocScrutinizer05 | meh, the Nokia repos are as static as it can get, we don't need to keep this "infra" dynamically working. It's a one-shot action, just take care the signatures expire no earlier than 2099 ;-) |
| 13:43.27 | jonwil | Ok so the first thing we need to do is to figure out who is going to run this 3rd party mirror (either someone running an existing mirror if they are interested or someone with the ability to run a new 3rd party mirror). Once that happens I have a plan to make this all work with minimal risk to maemo infra/community people. |
| 13:45.23 | DocScrutinizer05 | keyholder of CSSU keys: merlin1991 |
| 13:45.34 | DocScrutinizer05 | afaik |
| 13:45.48 | DocScrutinizer05 | ~mirrors |
| 13:45.48 | infobot | i guess mirror is http://maemo-archive.wedrop.it/ http://talk.maemo.org/showthread.php?p=1315143#post1315143 or extras-devel.merlin1991.at - for fighting hashsum error, or see ~rmo-new |
| 13:46.09 | DocScrutinizer05 | hmm, no not those |
| 13:48.00 | DocScrutinizer05 | jonwil: why would we need "to figure out who is going to run this 3rd party mirror"? |
| 13:48.21 | jonwil | I mean we need to figure out which mirror is going to be the one that hosts this re-signed repo. |
| 13:48.47 | DocScrutinizer05 | we will see which mirror is it that picks up |
| 13:48.49 | DocScrutinizer05 | ;-) |
| 13:49.48 | DocScrutinizer05 | I suggest to consider indirection: point to a place with an .install file and only that .install file points to the recently valid mirrors |
| 13:50.14 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 13:51.17 | DocScrutinizer05 | ~jrrepos |
| 13:51.17 | infobot | well, jrrepos is http://maemo.cloud-7.de/maemo5/et_al/HAM-catalogs/ |
| 13:52.16 | DocScrutinizer05 | for a really longterm stable URL I'd change this to sth not including cloud-7 though |
| 13:52.35 | DocScrutinizer05 | might even be histed on maemo infra |
| 13:52.39 | DocScrutinizer05 | hosted* |
| 13:53.30 | DocScrutinizer05 | maybe a bootjob could download the .install file and edit the sources.list or /etc/hosts |
| 13:55.08 | *** join/#maemo N-Mi (~nicolas@calvix/staff/N-Mi) |
| 13:55.57 | DocScrutinizer05 | echo "nokiareposymbolic `wget http://maemo.cloud-7.de/maemo5/et_al/HAM-catalogs/ | grep 'URI = '|cut -f 3`" >>/etc/hosts |
| 13:56.01 | DocScrutinizer05 | sth like that |
| 13:56.32 | DocScrutinizer05 | (obviously buggy, but you get the idea) |
| 14:06.47 | Wizzup | freemangordon: http://sprunge.us/RANT |
| 14:09.51 | DocScrutinizer05 | RANT ? ;-P |
| 14:10.17 | APic | ;=P |
| 14:10.21 | Wizzup | yep, lol |
| 14:10.25 | APic | lol |
| 14:10.35 | DocScrutinizer05 | new flavor of bullshit bingo ala sprunge? |
| 14:13.32 | Wizzup | anyway: this is libcal built from a devuan ascii VM running jenkins |
| 14:13.38 | Wizzup | it auto generates a repo and signs it with a testing key |
| 14:13.58 | Wizzup | this could essentially be rsynced to a public http server and we could play with it on a real device |
| 14:14.09 | Wizzup | we'll add the arm arch once we've figured out the other parts |
| 14:14.23 | Wizzup | automatically adding new packages, auto fetching new builds, documenting the branches / files required for git builds, and such |
| 14:57.53 | Enrico_Menotti | Wow, I see my original question about HAM generated a lot of discussion. bencoh, I have read the log DocScrutinizer05 linked to. I admit openly that my present knowledge about keys, signatures and so on is null. So although I tried to read all, I didn't understand that much. That log gives some hints about the .xexp files, yes. But I haven't been able to learn substantially anything more than what I had already seen. |
| 14:57.53 | Enrico_Menotti | <PROTECTED> |
| 14:57.53 | Enrico_Menotti | <PROTECTED> |
| 14:58.01 | Enrico_Menotti | May anybody help me to clarify the situation? |
| 14:59.20 | bencoh | how did you add the repositories to your device? |
| 14:59.49 | DocScrutinizer05 | ((apt-worker refuses to use packages from mirrored (on muarf.org) Nokia repos)) there's a setting in HAM red-pill mode to allow "3ed party sources" or somesuch, iirc |
| 15:01.07 | DocScrutinizer05 | ~redpill |
| 15:01.07 | infobot | extra, extra, read all about it, redpill is http://wiki.maemo.org/Red_Pill_mode |
| 15:04.11 | DocScrutinizer05 | HAM "settings"-> "[ ] Ignore packages from wrong domains", "[x] ignore the third party packages policy for SSU" |
| 15:04.44 | Enrico_Menotti | bencoh I edited /usr/share/hildon-application-manager/catalogues/vairant-catalogues.xexp and added to the uri's indicated there the path to muarf.org's mirror: http://maemo.muarf.org/apt-mirror/mirror/. This fixes the standard catalogues by pointing them to muarf.org. HAM is not complaining it can't find the catalogues. Problems arise with apt-worker refusing the domain. |
| 15:04.51 | DocScrutinizer05 | not sure which setting they'd need, but... usually your problem doesn't occur here |
| 15:06.19 | bencoh | what happens when just using the .install files? |
| 15:06.30 | DocScrutinizer05 | generally messing around with config preset files that are not meant to get altered by user and only will install from a verified repo is for sure not the best method to avoid unexpected probelms |
| 15:06.33 | bencoh | (I've never tried those, so ...) |
| 15:07.42 | DocScrutinizer05 | editing /etc/* is the way to go for *user*, just make sure e.g. HAM is not running concurrently as otherwise it might overwrite your edits when terminating |
| 15:08.28 | DocScrutinizer05 | well, actually for *user* the canonical way is to use HAM "catalogs" interface, or click an .install file in microB |
| 15:09.24 | bencoh | /60/60 |
| 15:10.09 | DocScrutinizer05 | again, I point to my enable-catalogs script that just works to switch different catalog settings, so whatever it does it does it the right way |
| 15:12.17 | DocScrutinizer05 | when copying files into /etc/apt/* works, then editing same files must work too, right? |
| 15:12.40 | Enrico_Menotti | Ok, I didn't try the .install files. I was first trying to correct the original Nokia links, so to avoid having disabled catalogues and side by side new ones. Yes, I can use the .install files and see what happens. I agree with the procedure suggested by DocScrutinizer05 , in the sense that this should not be done by the end user. But the original repos are no more, so in my opinion it does not make sense to disable |
| 15:12.40 | Enrico_Menotti | <PROTECTED> |
| 15:13.15 | Enrico_Menotti | DocScrutinizer05 /etc/apt/sources.list.d/ you mean? |
| 15:13.38 | DocScrutinizer05 | whatever files are there under /etc/apt |
| 15:14.16 | DocScrutinizer05 | I can't help with .xexp files, never heard of them before you came up with them |
| 15:14.59 | DocScrutinizer05 | I guess THAT is a very HAM specific thing |
| 15:15.26 | DocScrutinizer05 | only used once during initial config |
| 15:16.44 | DocScrutinizer05 | maybe HAM checks if the .xexp is newer than the files under /etc/apt and /etc/hildon-applicationmanager and if so, it re-initializes the latter files according to the .xexp... Or whatever |
| 15:17.44 | DocScrutinizer05 | you probably have to dig deep into HAM sources to get an answer to "how does .xexp work?" |
| 15:18.22 | DocScrutinizer05 | all I know is: nobody sugested to mess with .xexp so far |
| 15:18.54 | DocScrutinizer05 | the canoical way is via /etc/apt and /etc/hildon-app*ger |
| 15:19.26 | Enrico_Menotti | About /etc/apt: I am asking because I first tried to change the file inside /etc/apt/sources.list.d, but I found out that the HAM modifies this file according to the catalogues indicated in the .xexp files (and the "enabled/disabled" setting, which I have seen is stored in /etc/hildon-application-manager/catalogues: if a catalogue is disabled, its url doesn't appear in /etc/apt/sources.list.d). If one only modifies |
| 15:19.27 | Enrico_Menotti | <PROTECTED> |
| 15:19.45 | DocScrutinizer05 | see http://maemo.cloud-7.de/maemo5/session-log_enable-catalogs_README.txt and http://maemo.cloud-7.de/maemo5/usr/local/sbin/enable-catalogs |
| 15:19.53 | DocScrutinizer05 | and http://paste.ubuntu.com/25454201 |
| 15:20.08 | DocScrutinizer05 | and particularly the modification dates in there |
| 15:20.33 | Enrico_Menotti | Ok, let me have a look. |
| 15:21.24 | DocScrutinizer05 | >>If one only modifies /etc/apt/sources.list.d, then upon calling HAM GUI again and doing some actions, the sources.list.d files go back to their original content.<< no, evidently not, unless maybe you have HAM running concurrently to your edits |
| 15:22.58 | Enrico_Menotti | Well, I didn't remove the OVI catalogue from the /etc/apt/sources.list.d. I disabled it in the HAM GUI. But afterwards it disappeared from the /etc/apt/sources.list.d file as well. |
| 15:23.44 | Enrico_Menotti | The file is /etc/apt/sources.list.d/hildon-application-manager.list. |
| 15:24.28 | DocScrutinizer05 | http://paste.ubuntu.com/25458596 |
| 15:28.23 | Enrico_Menotti | Let me do a test. |
| 15:29.26 | DocScrutinizer05 | ((I disabled it in the HAM GUI. But afterwards it disappeared from the /etc/apt/sources.list.d file as well.)) yes, that's how HAM manages stuff, it has "enabled"/"disabled" in /etc/hildon-application-manager/catalogues and adjusts the sources.list files accordingly, so apt also *should* use same repos |
| 15:29.52 | DocScrutinizer05 | AIUI |
| 15:30.22 | freemangordon | Wizzup: cool!!! |
| 15:30.43 | Wizzup | :) |
| 15:30.48 | DocScrutinizer05 | that's why you shouldn't just edit sources.list since HAM will interfere. Use HAM "catalogs" GUI instead. Or edit *all* files that need an edit |
| 15:30.52 | Wizzup | now I have a headache though |
| 15:30.57 | Wizzup | enough jenkins for today |
| 15:31.06 | freemangordon | where is the repo? |
| 15:31.25 | Wizzup | it's not yet online. I can rsync it somewhere if you want to look at it |
| 15:31.29 | Wizzup | It's on the vm only |
| 15:31.32 | freemangordon | ah, no, no hurry |
| 15:31.40 | DocScrutinizer05 | it's not just any wiskey, it's Jenkins whatthefuck |
| 15:31.54 | freemangordon | :) |
| 15:32.10 | Wizzup | so yeah, what's left is what I wrote above |
| 15:32.18 | Wizzup | should be a bit more work, but doable |
| 15:32.46 | freemangordon | in the meanwhile I managed to build and run hildon-control-panel in devuan VM :) |
| 15:33.52 | Wizzup | sweet |
| 15:34.04 | Wizzup | I'm really looking forward to getting a first devuan up and running with the repos |
| 15:34.15 | Wizzup | just add the repo; apt-get install hildon-desktop and done |
| 15:34.20 | Enrico_Menotti | DocScrutinizer05 I checked. Yes, if I edit /etc/apt/sources.list.d/hildon-application-manager.list, then open HAM GUI and trigger an action (I went to catalogues, opened the apps one and saved it without any modification), afterwards the /etc/apt/sources.list.d/... file is recreated. So it is enough to edit the .xexp file (/usr/share/hildon-application-manager/catalogues/variant-catalogues.xexp). HAM automatically |
| 15:34.21 | Enrico_Menotti | <PROTECTED> |
| 15:34.24 | freemangordon | do we have any known FOSS cpl applet? |
| 15:34.24 | *** join/#maemo ecc3g (~eccerr0r@2602:46:3913:b400:5054:ff:fe37:7e04) |
| 15:34.29 | Wizzup | cpl? |
| 15:34.33 | freemangordon | control panel |
| 15:34.38 | freemangordon | aka settings |
| 15:35.10 | DocScrutinizer05 | Enrico_Menotti: no, we don't edit .xexp |
| 15:35.33 | DocScrutinizer05 | /usr/* is read-only for all that matters |
| 15:36.08 | Wizzup | freemangordon: I don't know. I would assume so. external keyboard? |
| 15:36.13 | Wizzup | or operator name? |
| 15:36.34 | freemangordon | extkbd is mine, but it is qt |
| 15:36.46 | Wizzup | is that a problem? |
| 15:36.48 | *** join/#maemo florian_ (~fuchs@x4d094406.dyn.telefonica.de) |
| 15:37.04 | freemangordon | still no qt |
| 15:37.07 | Wizzup | ack |
| 15:37.25 | Wizzup | btw, if anyone knows how to connect to a bluetooth keyboard that seems to do 'auto pair', that would be nice (e.g. you never get to fill in a pin code) |
| 15:37.35 | Wizzup | it works on android, but the n900 gets stuck in a weird way and wants to fill in a pin |
| 15:37.38 | Wizzup | (windows has the same problem) |
| 15:38.32 | DocScrutinizer05 | Enrico_Menotti: honestly, I have a very simplistic approach to that: make a copy of /etc, then use HAM GUI to add or remove a catalog, then see what it did to /etc (usinf diff tool or whatever you like). So you see what's the correct way to do stuff, then implement that in your script or whatever you are about to create |
| 15:39.10 | DocScrutinizer05 | for advanced tasks, use strace to watch what exactly it is HAM is doing |
| 15:39.42 | DocScrutinizer05 | when using strace, watch out not to miss forks |
| 15:39.56 | Wizzup | strace -f follows forks |
| 15:40.01 | DocScrutinizer05 | yep |
| 15:40.15 | DocScrutinizer05 | that's what I leaft to the reader to figure out ;-) |
| 15:41.03 | Enrico_Menotti | DocScrutinizer05 Ok, I understand your position. However, one can play with his system in the way he likes to. It depends on what one wants to achieve. I'd like to correct the original catalogues instead of creating new ones. By editing the .xexp files this can be done, it seems, with all the risks this implies. |
| 15:41.34 | Enrico_Menotti | About tracing HAM actions: yes, I was thinking about something of the kind. Thanks for the hints. Never used strace. Will investigate. |
| 15:41.44 | DocScrutinizer05 | well, what can be done and what will work in the end are two segregate things |
| 15:42.28 | DocScrutinizer05 | editing files in /usr is a *very* poor idea since apt itself will override them next time you install/update stuff |
| 15:42.33 | Enrico_Menotti | Segregate? You mean separate? |
| 15:42.46 | Enrico_Menotti | Oh yes I got it. |
| 15:43.23 | Enrico_Menotti | That's absolutely correct. I realise it. One should modify packages on the repository they are fetched from by apt. |
| 15:43.29 | Enrico_Menotti | Right? |
| 15:43.32 | DocScrutinizer05 | yes |
| 15:43.52 | Enrico_Menotti | Yeah, I am conscious of this downside. |
| 15:46.51 | DocScrutinizer05 | and there's no point in musing about the signing keys in (or next to) /usr/share/hildon-application-manager/catalogues/ for you, since you don't have any alternative keys to provide there anyway |
| 15:47.56 | DocScrutinizer05 | how to correctly turn a signed into an unsigned repo for HAM is an entirely different and pretty complicated topic |
| 15:49.37 | DocScrutinizer05 | stuff n /etc/apt/trustdb.gpg. And whatnot else |
| 15:51.18 | DocScrutinizer05 | probably HAM takes care about that too. So I really suggest using HAM for editing HAM catalogs |
| 15:51.52 | Enrico_Menotti | Right. Is the mirror at muarf.org signed or not? If yes, is the signature the same as for the original Nokia repos? When you use the .install files, do they install any key for verifying the signature, besides creating new catalogues? All questions that arise in my mind. I don't want to annoy you by pretending an answer. It's just what I am thinking about. |
| 15:52.20 | rhn_mk1 | is there a way to use .install files from command line? |
| 15:52.25 | Enrico_Menotti | And yes, I'd use HAM to edit catalogues, but the default ones cannot be edited that way, as far as I know. They can only be disabled. |
| 15:52.36 | DocScrutinizer05 | it's a mirror, so the signatures are original nokia signatures and they don't match the mirror's URL |
| 15:53.26 | DocScrutinizer05 | when you use .install they don't explicitly create a new signature key |
| 15:53.43 | Enrico_Menotti | Yeah, that's what I was suspecting! |
| 15:55.12 | DocScrutinizer05 | it feels a little pointless to discuss this stuff in epic width without knowing what's the goal of that exercise |
| 15:56.07 | Enrico_Menotti | So if one removes the keys in the .xexp files, or put in another way creates another catalogue without signature by using the .install files, why does that work? Since there are no keys to verify the signature of the repos, should not HAM (or apt-worker) complain? |
| 15:56.22 | Enrico_Menotti | Ok, yes, this is pure speculation (almost pure). |
| 15:56.58 | Enrico_Menotti | The practical goal would be to have the original catalogues working by pointing to a mirror. |
| 15:57.23 | DocScrutinizer05 | that's an oxymoron |
| 15:57.42 | DocScrutinizer05 | original catalogues != mirror |
| 15:58.16 | Enrico_Menotti | Well, the catalogues are the info on the local system, pointing to a repo, is that right? |
| 15:58.21 | DocScrutinizer05 | unless you add a indirection to /etc/hosts |
| 15:58.48 | Enrico_Menotti | I mean I want to modify this info to point to the mirror, instead of disabling it and creating a new one. |
| 15:59.02 | DocScrutinizer05 | why? |
| 16:00.28 | DocScrutinizer05 | not that it'd be impossible (CSSU done similar), but the purpose is unclear |
| 16:01.26 | Enrico_Menotti | Well, it's a matter of taste, let's say. Since the original repos are down and forever will be, there's no sense in keeping the original catalogues as they are and creating others. This is what I thought initially. |
| 16:01.46 | Enrico_Menotti | Right, the other way in the end produces the same result. |
| 16:02.41 | DocScrutinizer05 | why would you want an immutable catalog entry pointing to an arbitrary mirror? |
| 16:03.10 | DocScrutinizer05 | would complicate matters to no end for users, once that mirror changes |
| 16:03.47 | Enrico_Menotti | Yes, true. |
| 16:04.21 | Enrico_Menotti | I was not thinking about other users - it's just for my personal use. If the mirror changes, I know how to correct again the catalogue entry. |
| 16:04.33 | DocScrutinizer05 | it's arguable if we should remove the original Nokia repos since they are and always will be dead. But replacing them by a random mirror doesn't feel like it's the right thing to do |
| 16:05.29 | DocScrutinizer05 | anyway, good luck, I'm afk for today |
| 16:05.32 | DocScrutinizer05 | o/ |
| 16:06.18 | Enrico_Menotti | Bye DocScrutinizer05 . I will stop here for now - will investigate later. |
| 16:06.21 | Enrico_Menotti | Thanks. |
| 16:31.03 | rhn_mk1 | is it possible to use the mirrored repositories with plain apt-get? `apt-get update` complains about old signatures for me |
| 16:31.20 | KotCzarny | complains doesnt equal 'not worky' |
| 16:31.28 | rhn_mk1 | errors out actually |
| 16:31.36 | KotCzarny | pastebin the error |
| 16:36.24 | rhn_mk1 | KotCzarny: http://pasted.co/f5a366a5 |
| 16:38.45 | rhn_mk1 | sources.list: http://pasted.co/d581e5db |
| 16:47.33 | *** join/#maemo jja2000 (jja2000mat@gateway/shell/matrix.org/x-tcoxplzjpkgigjau) |
| 16:50.48 | *** join/#maemo arcean (~arcean@nat2-6.finemedia.pl) |
| 17:08.20 | KotCzarny | ~maemo-repos |
| 17:08.20 | infobot | it has been said that maemo-repos is http://wiki.maemo.org/Repository#List_of_Maemo_repositories |
| 17:08.38 | KotCzarny | are you sure those linenoise mirrors match? |
| 17:09.08 | KotCzarny | they do, hmm |
| 17:09.32 | rhn_mk1 | copied from there |
| 17:09.43 | KotCzarny | but what about: |
| 17:09.49 | KotCzarny | # This is another mirror for the same thing as those above. Temporarily OFFLINE |
| 17:10.01 | rhn_mk1 | KotCzarny: I tried with muarf with the same error |
| 17:10.06 | KotCzarny | uhum |
| 17:10.15 | KotCzarny | was long time since i last updated |
| 17:10.57 | KotCzarny | but if apt dies on keyexpired it's another reason to resign packages in the mirrors |
| 17:11.02 | rhn_mk1 | that *does* work with FAM and HAM, but those seem to be using different source lists |
| 17:11.11 | rhn_mk1 | same URLs, nevertheless |
| 17:13.04 | DocScrutinizer05 | rhn_mk1: "W: " is *warning* |
| 17:13.24 | KotCzarny | Err http://maemo.linenoise.info ./ Release |
| 17:13.34 | KotCzarny | shouldnt it be wrn then? |
| 17:14.12 | DocScrutinizer05 | look at http://maemo.linenoise.info/, it's not any repo structure |
| 17:14.47 | DocScrutinizer05 | there's none of "Release" or any of the module dirs |
| 17:15.40 | DocScrutinizer05 | http://maemo.linenoise.info/downloads.maemo.nokia.com/fremantle/ssu/mr0 404, right? |
| 17:16.00 | DocScrutinizer05 | hmm actually not |
| 17:16.03 | KotCzarny | nope, loaded |
| 17:17.20 | KotCzarny | rhn_mk1: can you install any pkg from those mirrors via apt? |
| 17:17.21 | DocScrutinizer05 | anyway, I guess the error is about Release file not found in one of the places apt looks for them |
| 17:17.53 | rhn_mk1 | KotCzarny: can you give me an example? |
| 17:17.57 | DocScrutinizer05 | it's obviously _not_ a gpg error |
| 17:18.35 | KotCzarny | tutorial-home-applet ? |
| 17:18.49 | KotCzarny | seems safe enough to try |
| 17:19.32 | KotCzarny | if it's already installed you might add --reinstall to force reinstall |
| 17:20.27 | rhn_mk1 | http://paste.debian.net/984271/ |
| 17:20.32 | rhn_mk1 | it worked |
| 17:20.44 | KotCzarny | then i guess you can ignore those warnings |
| 17:21.05 | rhn_mk1 | KotCzarny: can you give me a random package from CSSU? |
| 17:21.11 | DocScrutinizer05 | anyway "W: GPG error: http://maemo.linenoise.info ./ Release: The following signatures were invalid: KEYEXPIRED 1349249546 KEYEXPIRED 1349249546 KEYEXPIRED 1349249546" is a *W*arning |
| 17:21.24 | rhn_mk1 | I'd like to figure out if these work |
| 17:21.32 | KotCzarny | which cssu flavour do you have? |
| 17:21.48 | rhn_mk1 | stable, if that's what you mean |
| 17:22.30 | KotCzarny | cssu server seems slow |
| 17:23.02 | KotCzarny | status-area-orientationlock-applet |
| 17:23.10 | rhn_mk1 | thanks |
| 17:23.43 | rhn_mk1 | also works! |
| 17:23.57 | KotCzarny | did you install cssu via installer ? |
| 17:24.15 | rhn_mk1 | KotCzarny: yes, and I added the line manually later |
| 17:24.40 | rhn_mk1 | the point of this exercise was to install CSSU from command line to save myself from typing |
| 17:24.49 | KotCzarny | um |
| 17:24.56 | DocScrutinizer05 | not recommended |
| 17:25.02 | KotCzarny | cssu installer does more than just changing repos |
| 17:25.08 | DocScrutinizer05 | indeed |
| 17:25.14 | KotCzarny | it should always be installed via recommended method |
| 17:25.17 | rhn_mk1 | it does, but does it need GUI for that? |
| 17:25.22 | DocScrutinizer05 | yes |
| 17:25.44 | rhn_mk1 | is baffled but okay |
| 17:26.06 | KotCzarny | if you played around and run into troubles remember what you did |
| 17:26.07 | DocScrutinizer05 | long answer: not if you know *exactly* what and how to start, in which sequence, from cmdline. and even then a GUI will open |
| 17:26.16 | KotCzarny | easier to debug for cssu folks |
| 17:26.54 | rhn_mk1 | ack |
| 17:27.31 | KotCzarny | you can try dissecting installer to check if you missed any steps |
| 17:27.41 | rhn_mk1 | KotCzarny: I'm not concerned about that actually |
| 17:28.31 | rhn_mk1 | only about making a "simple" script to bring a system up to date, and publishing that if I can |
| 17:29.08 | KotCzarny | i would refrain from publishing, unless it gets blessed by cssu folks |
| 17:29.19 | KotCzarny | otherwise you will create more troubles than help |
| 17:29.22 | rhn_mk1 | that's why I'm here, asking questions :) |
| 17:29.24 | DocScrutinizer05 | rhn_mk1: if that had been any feasible, CSSU would have done it |
| 17:30.51 | DocScrutinizer05 | the point (among others) is about CSSU installer changing repos, and for that HAM needs to be inactive. Later on you need HAM again to run the CSSU update |
| 17:31.15 | rhn_mk1 | CSSU is one piece of the mess, mirrors are another, dead repositories and useless apps are one more |
| 17:31.30 | KotCzarny | thank nokia for that situation |
| 17:31.32 | KotCzarny | :) |
| 17:32.14 | rhn_mk1 | I thank CSSU people for trying to fix that, but if I can make improvements, why not try? |
| 17:32.27 | KotCzarny | in perfect world we would have already patched firmware update |
| 17:32.37 | KotCzarny | but for various reasons it's not going to happen |
| 17:32.48 | KotCzarny | do you know good lawyer? |
| 17:32.49 | DocScrutinizer05 | lazyflashing, click recommended.install, one-click install CSSU and follow the instructions (it actually needs more than one click, which is the point) |
| 17:33.07 | DocScrutinizer05 | this is the canonical method to bring a device up-to-date |
| 17:33.12 | KotCzarny | especially one that tackled big corpo issues |
| 17:33.21 | rhn_mk1 | I figured that's the case |
| 17:33.28 | KotCzarny | if you manage to clear the way, we are golden |
| 17:35.16 | DocScrutinizer05 | rhn_mk1: quite a few people looked into CSSU to improve the procedure. If you nevertheless can come up with improvements, don't hesitate to suggest them. However it takes quite some study to avoid the pitfalls in that process CSSU needs to use to switch standard SSU to CSSU |
| 17:36.59 | rhn_mk1 | DocScrutinizer05: the necessary step to updating (and then to customizing) installation is to get the command line to work. but if you're saying it's impossible to update CSSU this way, then I guess there's nothing to be done |
| 17:37.10 | rhn_mk1 | s/update/install/ |
| 17:37.20 | rhn_mk1 | huh, neat |
| 17:39.37 | DocScrutinizer05 | it's a two-step process where HAM installs CSSU-enabler and then quits. And CSSU-enabler changes the repos (while HAM being inactive) and then starts HAM (and apt) again to do the real update |
| 17:39.45 | DocScrutinizer05 | iirc |
| 17:40.20 | rhn_mk1 | sounds simple enough, thanks |
| 17:40.53 | rhn_mk1 | does CSSU-enabler use the system-wide sources.list or the HAM one? |
| 17:40.57 | DocScrutinizer05 | you can't automate that process in a simple manner, unless you exploit alarmd or whatever to restart stuff after everything terminated |
| 17:41.13 | KotCzarny | cssu enabler uses ham in the process |
| 17:41.22 | *** join/#maemo err0r3o3_ (~err0r3o3@178-191-22-156.adsl.highway.telekom.at) |
| 17:41.24 | DocScrutinizer05 | ^^^ |
| 17:41.31 | rhn_mk1 | I see |
| 17:41.40 | rhn_mk1 | if I get anywhere, I'll let you know |
| 17:41.51 | KotCzarny | and most tricky part is ham failing quietly for some users with weird repos/packages |
| 17:41.57 | KotCzarny | without reporting it |
| 17:42.33 | rhn_mk1 | why does it use HAM instead of just apt-get? |
| 17:42.35 | DocScrutinizer05 | there's a possible way to schedule a timed execution of CSSU-enabler from CSSU-enabler's post-install script |
| 17:42.46 | DocScrutinizer05 | but that's... icky |
| 17:43.00 | DocScrutinizer05 | because HAM does more than apt-get |
| 17:43.41 | DocScrutinizer05 | that's why you never install core system stuff via apt |
| 17:43.49 | DocScrutinizer05 | always use HAM for that |
| 17:43.58 | rhn_mk1 | that's important advice, I didn't know |
| 17:44.04 | rhn_mk1 | what is the extra stuff then? |
| 17:44.23 | DocScrutinizer05 | stuff like stoping/starting services etc iirc |
| 17:44.36 | DocScrutinizer05 | priorities, whatnot else |
| 17:44.55 | DocScrutinizer05 | requesters the user needs to nod off |
| 17:46.05 | DocScrutinizer05 | when you e.g install sshd from apt, you nevertheless get a GUI requester you need to nod off, or in this case even enter new password iirc |
| 17:47.15 | DocScrutinizer05 | there's quite some HAM specisic stuff in some packages, and system updates cause HAM dto take care about needed reboots and service restarts and whatnot |
| 17:47.36 | DocScrutinizer05 | I don't know details |
| 17:48.15 | DocScrutinizer05 | I just know "NEVER EVER do a apt-get upgrade|dist-upgrade" |
| 17:48.43 | DocScrutinizer05 | which is what it basically boils down to |
| 17:50.49 | DocScrutinizer05 | ((if I get anywhere, I'll let you know)) the problem with this approach usually is: others been there, done that, and found about the hidden issues during weeks of research and bugfixing |
| 17:51.17 | DocScrutinizer05 | it's not as simple as "seems to work for me" |
| 17:51.37 | rhn_mk1 | indeed |
| 17:51.50 | rhn_mk1 | now I agree that it's not something I can do in a weekend |
| 17:52.24 | rhn_mk1 | which is a shame anyway :( scriptability rules |
| 17:53.07 | *** join/#maemo ecc3g (blc@r.jajcs.net) |
| 17:54.11 | DocScrutinizer05 | we all agree on that, and it's a sticky topic on CSSU. You may consider CSSU as a "as good as it gets" probably |
| 17:54.41 | DocScrutinizer05 | if there had been a way to streamline it further, *for sure* it had been implemented |
| 17:55.35 | DocScrutinizer05 | the above mentioned alarmd (sort of atd alike cronjob thing) "improvement" has usability / UX issues |
| 17:57.17 | DocScrutinizer05 | the device acts weird, starting stuff without clear plan that would be obvious to the user. Also involves timing isses aka race conditions etc |
| 17:58.14 | DocScrutinizer05 | I *think* "recently" Pali looked into exactly that |
| 17:58.21 | rhn_mk1 | I imagine there's also backwards compatibility issue with all the packages which were written assuming they are installed by HAM too |
| 17:58.33 | DocScrutinizer05 | yes, of course |
| 17:59.05 | DocScrutinizer05 | not in CSSU installation context maybe |
| 17:59.11 | DocScrutinizer05 | but generally of course |
| 18:07.05 | DocScrutinizer05 | looking at http://wiki.maemo.org/Red_Pill_mode gives an idea what HAM does "behind the scenes" |
| 18:07.10 | *** join/#maemo drcode (~drcode@5.29.192.15) |
| 18:07.29 | DocScrutinizer05 | note that red pill got re-activated by CSSU |
| 18:10.41 | *** join/#maemo ecc3g (~eccerr0r@2602:46:3913:b400:5054:ff:fe37:7e04) |
| 18:10.48 | rhn_mk1 | it's similar to what dnf is doing |
| 18:11.13 | DocScrutinizer05 | age old stuff but maybe still interesting: http://wiki.maemo.org/Task:Improving_the_Application_manager |
| 18:14.05 | DocScrutinizer05 | also note: |
| 18:14.09 | DocScrutinizer05 | ~speedyham |
| 18:14.09 | infobot | extra, extra, read all about it, speedyham is 30 times faster than HAM https://github.com/community-ssu/hildon-application-manager, now included in CSSU. |
| 18:15.39 | rhn_mk1 | is this stable? |
| 18:16.20 | Pali | I'm using it without any known error |
| 18:16.56 | Pali | freemangordon optimized parsing apt list/cache so it is really 30 times faster |
| 18:17.58 | DocScrutinizer05 | yes, actually like 32 times |
| 18:18.16 | DocScrutinizer05 | it's in CSSU, that says all about being stable |
| 18:19.50 | DocScrutinizer05 | https://github.com/community-ssu/hildon-application-manager has a nice readme |
| 18:20.00 | DocScrutinizer05 | plus more docs |
| 18:20.52 | DocScrutinizer05 | https://github.com/community-ssu/hildon-application-manager/tree/master/doc |
| 18:22.19 | DocScrutinizer05 | Enrico_Menotti: https://github.com/community-ssu/hildon-application-manager/blob/master/doc/scripting.txt - for xexp which actually are X-expressions |
| 18:24.22 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 18:25.34 | DocScrutinizer05 | >> - `essential` :: When present, marks the catalogue as essential. Essential catalogues can not be removed or edited by the user.<< |
| 18:32.56 | DocScrutinizer05 | >> If you want to test a multi-package installation script, put the Application Manager into red-pill mode; then it will use the multi-package confirmation dialog when there is more than one package to install.<< gives me some ideas :-D Particularly re ~jrtools etc |
| 18:37.54 | DocScrutinizer05 | Pali: how about creating a multi-package install file to get a "recommended set of tested and found useful packages" installed by one click? Sounds like a convenient thing for (particularly new) users |
| 18:39.00 | DocScrutinizer05 | the multi-package confirmation dialog (known from hildon restore) still allows user to choose which packages to actually get and which to reject |
| 18:42.01 | DocScrutinizer05 | glares at http://maemo.cloud-7.de/maemo5/et_al/HAM-catalogs/BM.install in light of `with-temporary-catalogues` instruction. Prolly I should fix that |
| 18:44.30 | DocScrutinizer05 | hmm wait, that's scripting, not installfiles# |
| 18:49.32 | DocScrutinizer05 | LOL! >> Whenever a memory card is inserted that contains a file called `.auto.install`, that file is processed by the Application Manager. Usually, the `.auto.install` file contains a `card\_install` group, of course.<< |
| 18:53.51 | DocScrutinizer05 | meh! no `with-temporary-catalogues` in .install files |
| 19:01.07 | DocScrutinizer05 | hmm, https://github.com/community-ssu/hildon-application-manager/blob/master/doc/temporary.txt |
| 19:15.53 | *** join/#maemo drcode (~drcode@5.29.192.15) |
| 19:16.25 | freemangordon | Pali: how am I supposed to install gconf chema file? |
| 19:26.34 | DocScrutinizer05 | https://projects.gnome.org/gconf/ >>Schema files Application developers create files called schema files, traditionally ending in the .schemas extension. These are in a nice human-readable format. These files are not used by GConf directly. Instead, when you "make install" or install an RPM/deb package, gconftool can be invoked to take the schemas in the schema file for an application and install them into one of the configuration |
| 19:26.35 | DocScrutinizer05 | sources. The schema install process also associates schema names with keys, so GConf can find the right schema for a given key. ...<< |
| 19:26.52 | freemangordon | I found something called gconf-schema |
| 19:28.06 | bencoh | "something"? |
| 19:29.07 | Pali | freemangordon: see some postinst debian script of some package |
| 19:29.36 | Pali | they are installed by postinst scripts |
| 19:30.04 | Wizzup | freemangordon: so any package on github needs to be packaged, aye? |
| 19:30.43 | Wizzup | from https://github.com/fremantle-gtk2 |
| 19:30.49 | freemangordon | Wizzup: excluding one or 2, yes |
| 19:31.23 | freemangordon | Wizzup: and most (if not all) need debian/changelg fixed, by the autobuilder script or dunno |
| 19:31.40 | Wizzup | they probably also need control file fixes and such |
| 19:31.53 | Wizzup | Source-Version has to become $source:Version, and other things |
| 19:32.12 | Wizzup | I'd probably aim for all deps of hildon-desktop + hildon-desktop itself first |
| 19:32.15 | Wizzup | should be plenty of fun |
| 19:32.21 | Wizzup | we have forked gtk2, right? |
| 19:34.05 | Wizzup | should we call it gtk2 on disk, or perhaps call it mgtk? (yes, we'd have to change everything that depends on it) |
| 19:34.08 | Wizzup | just wondering |
| 19:38.44 | freemangordon | no, keep it gtk |
| 19:38.53 | Wizzup | ok |
| 19:39.02 | Wizzup | so it won't break 'normal' applications? |
| 19:39.02 | freemangordon | iirc I changed debian/changelog |
| 19:39.05 | freemangordon | yes |
| 19:39.08 | Wizzup | sweet |
| 19:39.22 | Wizzup | we will have to keep it at a higher version than devuan's, or otherwise lock it somehow |
| 19:39.26 | freemangordon | so hildon-desktop (or some other package) should depend on that modified version |
| 19:39.31 | Wizzup | my idea was to add our maemo-devuan things as extra repo |
| 19:39.32 | Wizzup | ok |
| 19:39.39 | Wizzup | instead of one 'merged' repo |
| 19:39.45 | Wizzup | seems easier for us |
| 19:39.47 | freemangordon | right |
| 19:47.53 | parazyd | Wizzup: if you go that way, i'd recommend investigating apt pinning a bit more |
| 19:48.22 | parazyd | depending on it, you could have the repo push its priority through a specific (meta)package |
| 19:48.55 | parazyd | this of course applies only for packages existing in devuan |
| 19:54.43 | Wizzup | shouldn't be too hard |
| 19:54.48 | Wizzup | I've done pinning before I think |
| 19:55.09 | Wizzup | and to be honest, I don't care if things break in the start, a fix is probably a simple apt-command away |
| 19:55.18 | Wizzup | Let's just get her going, and then we'll figure out what breaks |
| 19:57.15 | parazyd | agree |
| 19:59.11 | *** join/#maemo jkepler (~Thunderbi@78.3e.32a9.ip4.static.sl-reverse.com) |
| 20:13.16 | *** part/#maemo jja2000 (jja2000mat@gateway/shell/matrix.org/x-tcoxplzjpkgigjau) |
| 20:15.45 | Enrico_Menotti | DocScrutinizer05 https://github.com/community-ssu/hildon-application-manager/blob/master/doc/repository.txt explains extensively what I wanted to know about package domains and the domain file. Thanks for pointing me there. What I miss now is: where is the info stored about the domain a package was originally installed from? |
| 20:17.07 | DocScrutinizer05 | with a ton of salt: I think it's never stored anywhere. with all the puzzling consequences |
| 20:18.41 | DocScrutinizer05 | hildon backup stores a list of package names to re-install, plus a list of cirrently activated repos. If the packages are not mathing the repo list, just too bad |
| 20:18.49 | freemangordon | it is stored |
| 20:18.56 | freemangordon | but I can;t remember where |
| 20:19.08 | freemangordon | I would guess somewhere in /var/ |
| 20:19.20 | freemangordon | checks |
| 20:19.24 | DocScrutinizer05 | maybe inside the .deb cache somewhere |
| 20:20.08 | DocScrutinizer05 | I'm pretty sure hildon backup doesn't backup that info, though they rather should |
| 20:20.38 | Enrico_Menotti | It should be stored: >>The AM classifies the package repositories into 'domains' and upgrades |
| 20:20.39 | Enrico_Menotti | to already installed packages must (usually) come from the same domain |
| 20:20.40 | Enrico_Menotti | that the package was originally installed from.<< |
| 20:20.50 | freemangordon | yes, it is stored |
| 20:21.31 | DocScrutinizer05 | hmm, ok. Take that salt for the soups you eat the rest of your life, then :-D |
| 20:23.29 | Enrico_Menotti | :) |
| 20:25.16 | freemangordon | Enrico_Menotti: /var/lib/hildon-application-manager |
| 20:27.12 | Enrico_Menotti | Thanks. I'm investigating. |
| 20:41.15 | Enrico_Menotti | Maybe I got the whole process. (Or maybe I'm still missing some detail.) I try to recap. |
| 20:41.21 | Enrico_Menotti | >>Repositories are associated with domains based on the key that they |
| 20:41.21 | Enrico_Menotti | have been signed with.<< |
| 20:42.15 | Enrico_Menotti | The association is in /usr/share/hildon-application-manager/domains/variant-domains.xexp. |
| 20:42.38 | Enrico_Menotti | When a package is installed, the domain it is installed from is recorded. |
| 20:44.19 | Enrico_Menotti | In /var/lib/hildon-application-manager there are files beginning with domain. and ending with the domain name, one for each domain defined above. When a package is installed, its name is recorded in the file corresponding to the domain it has been installed from. (Well, I think so.) |
| 20:45.12 | Enrico_Menotti | Now HAM finds, from the catalogues, a new version available for some package, stored in a certain repo, signed with a certain key. |
| 20:45.30 | Enrico_Menotti | From the key, the repo is associated to a domain. |
| 20:45.58 | freemangordon | also, there are domain priorities :) |
| 20:46.17 | Enrico_Menotti | If the domain the new version comes from is different from the domain the original package had been installed from, HAM issues the "wrong domain" error. |
| 20:46.37 | freemangordon | you can;t install a package from a domain with a lower priority over a one from a domain with a higher |
| 20:46.57 | freemangordon | no, wrong domain is only where the priority is lower, iirc |
| 20:47.02 | freemangordon | *when |
| 20:47.22 | Enrico_Menotti | With the exception that there is the "trust level" (rather than priority): a package may move from a domain to another with higher trust level. |
| 20:47.31 | Enrico_Menotti | freemangordon A min, I'm still writing. |
| 20:49.47 | Enrico_Menotti | Now what I think happens here: the key used for signing the version of the original Nokia repos which is mirrored in muarf.org is not inside my variant-domains.xexp file. As a consequence, the domain associated to the mr0 repo becomes "signed" (it's a fallback of HAM, defined by default). This has trust level 1. |
| 20:50.40 | Enrico_Menotti | The original domain of packages contained in mr0 is nokia-system, which has trust level 600. |
| 20:51.07 | Enrico_Menotti | So a package having a new version in mr0 may not be installed since it would be moved to a domain with lower trust level. |
| 20:52.10 | Enrico_Menotti | If I remove the variant-domains.xexp file, all repos become "signed", but most important the trust levels of all domains are lost. So the nokia-system domain gets trust level 0. |
| 20:53.03 | Enrico_Menotti | At this point all updates may be installed, since packages move to a domain identical to the original one, or to signed, which has trust level 1, higher than the trust level of the original domain. |
| 20:53.19 | Enrico_Menotti | Ok, it's just an hypothesis. Does this make sense? |
| 20:53.27 | Enrico_Menotti | freemangordon Finished, thanks. |
| 20:54.49 | Enrico_Menotti | A check would be by finding out the fingerprint of the key used to sign the original Nokia repos mirrored in muarf.org, and see whether or not it is stored in my variant-domains.xexp. |
| 20:55.40 | Enrico_Menotti | Please let me know your opinion about this reconstruction. |
| 20:58.03 | freemangordon | sounds about right |
| 21:00.11 | *** join/#maemo l_bratch (~l_bratch@serenity.bratch.co.uk) |
| 21:00.38 | Enrico_Menotti | If things are this way, problem solved: I just need to add the fingerprint of the key used to sign the mr0 repo on muarf.org. How to find it? |
| 21:02.11 | Enrico_Menotti | (Or maybe I get all right when I install the cssu. That should be up to date with keys and so on.) |
| 21:33.10 | Enrico_Menotti | Well, may also be I have the fingerprint, but since the key is expired, the repos are not assigned the corresponding domain. |
| 21:53.00 | Enrico_Menotti | Oh. I changed the year in my N900 clock, by setting it to 2010. At this point the keys are valid. Domains are recognised properly. I get other few "wrong domain" errors, now for repository.maemo.org. I guess the key is newer than 2010. |
| 21:58.49 | Enrico_Menotti | So no way - the repos should be signed with a valid key. I will do a workaround by setting the trust level of nokia-system and nokia-certified to 1, so when the original Nokia repos mirrored at muarf.org are recognised as domain "signed" (since the key has expired), thus with trust level 1, packages may be moved to that domain. The downfall is that packages will be registered as having been installed from domain |
| 21:58.49 | Enrico_Menotti | <PROTECTED> |
| 22:10.15 | Enrico_Menotti | Just one correction: I have set the trust level to 0, not 1. This because, in order to switch a package to a different domain, the new domain trust level must be higher (not equal) than the trust level of the old domain. |
| 22:10.25 | DocScrutinizer05 | ((If things are this way, problem solved: I just need to add the fingerprint of the key used to sign the mr0 repo on muarf.org)) no, muarf is still signed with original nokia key, but the URL stored in that key doesn't match *muarf* |
| 22:11.40 | Enrico_Menotti | DocScrutinizer05 Well, the error in the log says "expired". In fact if I set the year in the clock to 2010, no more errors. |
| 22:13.17 | DocScrutinizer05 | this is no error, it's a warning |
| 22:14.41 | Enrico_Menotti | Yeah but seems the key is not considered valid to identify the domain. If I set the clock to 2010, the domain is correctly identified. |
| 22:16.16 | Enrico_Menotti | Actually it is W: GPG error. |
| 22:19.25 | Enrico_Menotti | Bed time. G'night. |
| 22:20.30 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 22:23.19 | DocScrutinizer05 | whatever, W is Warning, and the Nokia key is expired and can't get updated, and mirrors so far don't use new signing keys but simply copy the original Nokia signature |
| 22:26.48 | DocScrutinizer05 | and I really don't get what exactly is the problem. I don't see stuff failing from the expired keys, but maybe that's just me |
| 22:29.10 | DocScrutinizer05 | probably when you flash a PR1.2 or PR1.1 repo and then try to upgrade to PR1.3 level via SSU, you actually could run into errors from that. When you flash PR1.3 then I don't see any packages that could get updated from Nokia's repos and thus would fail because of lack of trust |
| 22:29.36 | DocScrutinizer05 | s/repo/fiasco image/ |
| 22:30.53 | DocScrutinizer05 | installing "new" packages should still work since there's no previous packahe on your system from a source with higher trust level |
| 23:21.17 | *** join/#maemo pagurus` (~user@i59F7C026.versanet.de) |
| 23:28.00 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 23:43.48 | *** join/#maemo jon_y_ (~enforcer@2001:e68:4075:f6de:f64d:30ff:fe63:5a5a) |
