**** BEGIN LOGGING AT Sun Sep 03 03:00:02 2017 Sep 03 06:47:34 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) Sep 03 06:47:34 /usr/share/hildon-application-manager/domains/variant-domains.xexp. Then open Ham. Catalogues ok. Go for updates. Result: one update available (Maemo5 security update). Log empty. Then refresh. Result: same update available. Log: http://paste.ubuntu.com/25456351/. Anybody who may explain to me what's going on? Sep 03 07:48:41 DocScrutinizer05: Use eSATA to avoid SATA↔USB conversion overhead? Sep 03 07:52:13 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? ☺ Sep 03 07:52:43 isa is already burned down. that witch. Sep 03 07:58:05 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. Sep 03 08:03:34 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. Sep 03 08:03:34 I was curious how to replace the “non-removable” battery of the BlackBerry KEYone. Sep 03 08:03:34 https://www.ifixit.com/Guide/BlackBerry+KEYone+Motherboard+Disassembly/92149 Sep 03 08:03:34 That looks like a lot of work only to remove an internal battery. I do not have an electric blow dryer. Sep 03 08:03:34 https://www.phonedog.com/2013/09/26/i-don-t-think-i-ll-ever-understand-the-point-of-non-removable-batteries Sep 03 08:04:45 tbh i do not know how is any samsung phone related to #maemo Sep 03 08:04:48 :P Sep 03 08:59:12 did anyone try to use the 0xFFFF flasher recently? It complains about my libusb version, even though it seems correct Sep 03 09:02:13 rhn_mk1 It needs libusb0.1, not libusb1.0, nor libusb1.0 + compatibility layer to libusb0.1 (I don't remember its name). Sep 03 09:03:04 Enrico_Menotti: hm, maybe I have both versions installed... Sep 03 09:04:36 rhn_mk1 ...and it sees the wrong one. May be. Sep 03 09:05:21 Enrico_Menotti: libusb-devel-0.1.5-7.fc24.x86_64 looks good, doesn't it? Sep 03 09:05:39 do you know what happens if the wrong one is used? Sep 03 09:07:27 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. Sep 03 09:07:56 What is your OS? Sep 03 09:08:34 Enrico_Menotti: Fedora 25 Sep 03 09:09:21 the source of the libusb-devel package is hard to understand... Sep 03 09:09:58 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. Sep 03 09:10:37 Enrico_Menotti: worst case there's local installation or Docker :) Sep 03 09:11:07 but I want to improve something, I guess, or I'd just flash with the closed flasher already Sep 03 09:11:52 libusb1.0 is slow Sep 03 09:12:11 so when you combine libusb1.0 + compat layer for 0.1 then it would be slow too Sep 03 09:12:26 you need to use libusb0.1 for 0xFFFF Sep 03 09:13:01 Pali: what are the consequences of the slowness? no detection? fails in the middle? Sep 03 09:13:22 no detection or sometimes no detection Sep 03 09:13:38 fail in the middle can happen, if "middle" means to reconnect Sep 03 09:14:37 Pali: why are delays critical? will the device timeout somehow? Sep 03 09:14:59 yes, you need to start communication with device in time window Sep 03 09:15:00 On Debian the package is libusb-0.1-4. I believe the libusb-devel is not the correct one (but I may be wrong). Sep 03 09:15:29 I just found that Fedora uses libusb-compat Sep 03 09:15:55 Yes, that's the compatibility layer. So you're using libusb1.0 + compat layer. Sep 03 09:16:26 or actually I'm using libusbx + compar layer Sep 03 09:16:51 thanks for the hints Sep 03 09:16:57 Yw. Sep 03 09:18:20 Pali: hello. Could you please have a look at what I asked earlier (08:47 CEST)? Maybe you can help. Sep 03 09:23:25 is there some reputable source hosting N900 flash images? Sep 03 09:24:07 ~lf Sep 03 09:24:07 i guess #maemo lazyflashing is http://wiki.maemo.org/Updating_the_tablet_firmware#The_Lazy_Approach Sep 03 09:24:28 thanks Sep 03 09:24:50 Or also a mirror I found on archive.org, up to PR1.3. Sep 03 09:25:42 http://web.archive.org/web/20131117073524/http://skeiron.org/tablets-dev/nokia_N900/ Sep 03 09:26:25 oh, that's quite good Sep 03 09:28:04 ~flashing Sep 03 09:28:05 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 Sep 03 09:28:20 get the script, run it, forget about downloading anything else Sep 03 09:28:40 all you need is already in the script Sep 03 09:28:56 I don't like running random scripts as root :P Sep 03 09:29:10 i assume you have the ability to read? Sep 03 09:31:16 oh, I just did that Sep 03 10:07:53 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 Sep 03 10:08:06 and then we need more glue to automatically build packages and such, but that's OK Sep 03 10:08:09 at least then the basics work Sep 03 10:08:34 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 Sep 03 10:53:56 Wizzup: we can ask if/how it works in the devuan setup Sep 03 10:54:05 we could Sep 03 10:54:13 I want to understand how the plugins want it work :p Sep 03 10:54:16 great! Sep 03 10:54:38 in the meanwhile, I am finishing codelockui REing Sep 03 10:54:40 :) Sep 03 10:54:46 sweet! Sep 03 10:54:59 :) Sep 03 10:55:20 BTW, anybody knows what it is used for? Sep 03 10:55:27 I mean - is that devicelock? Sep 03 10:55:57 haha, finishing REing something without knowing where it is used, I like it Sep 03 10:56:01 (and no, I can only guess) :D Sep 03 10:56:21 REing was started by jonwil Sep 03 10:56:42 also, this is the lib used when you choose "remove operator lock" in control panel Sep 03 10:56:55 but I am not sure what it is supposed to do actually Sep 03 11:00:42 freemangordon: I dont exactly remember which is which, but one is used to unlock device Sep 03 11:00:49 and the other is used in control panel Sep 03 11:01:05 yep, this is the one used in cpl Sep 03 11:01:06 iirc codelockui is basically the code dialog Sep 03 11:01:16 yes, it is, but what it is used for? Sep 03 11:01:27 what code is that one? Sep 03 11:01:33 "operator lock"? Sep 03 11:01:42 hmm no, the phone lock Sep 03 11:01:42 WTF is that in terms of n900? Sep 03 11:01:52 no, phonelock is libdevicelock Sep 03 11:01:56 or devicelock Sep 03 11:02:07 ah, you mean this is the ui? Sep 03 11:02:10 exactly Sep 03 11:02:28 make some changes and see where they show up? Sep 03 11:02:34 well, from what I remember, at least Sep 03 11:02:51 haven't fiddled with those for quite a while (1.5y or something) Sep 03 11:03:16 hmm Sep 03 11:03:52 back then I wanted to fix it when in portrait mode... then I realized it was closed-source Sep 03 11:03:59 no more :) Sep 03 11:04:12 yay :) Sep 03 11:04:22 fixing it should be possible soon then :) Sep 03 11:04:48 hm btw, while you're here ... would it be possible to make hildon/mb2 a non-compositing wm? Sep 03 11:04:58 no idea :D Sep 03 11:05:21 and how well would it perform with llvmpipe on arm (has anyone tested it)? Sep 03 11:05:33 (assuming we have to keep it compositing) Sep 03 11:06:16 ok, I managed to lock my dev device and there seems to be a bug in codelockui so I can't unlock it :D Sep 03 11:06:27 haha Sep 03 11:06:33 lol Sep 03 11:06:36 iirc there is some dbus call to unlock it Sep 03 11:07:01 well, I keep the original .so, so I will revert to it, but still, it is funny Sep 03 11:16:11 https://wizzup.org/first-build.png Sep 03 11:17:10 Wizzup: BTW, you clone from github to another repo, right? Sep 03 11:17:23 right now from the maemo gitlab, yeah Sep 03 11:17:30 but we target any git URI Sep 03 11:17:33 s/maemo/devuan/ Sep 03 11:17:51 I think we'll have problems with branches, right? or not Sep 03 11:18:03 yes Sep 03 11:18:11 https://git.devuan.org/maemo/libcal Sep 03 11:18:15 you always build master? Sep 03 11:18:17 parazyd already made some branches/files/tags Sep 03 11:18:26 and we need to fix most of the control files Sep 03 11:18:36 the maemo/ascii branch Sep 03 11:18:37 but we'll get there, I don't have all the anwsers yet Sep 03 11:18:51 ah, ok Sep 03 11:19:09 jonwil: cheers https://github.com/community-ssu/codelockui Sep 03 11:19:32 congratz! :) Sep 03 11:20:54 Good to see that's finished Sep 03 11:21:19 And that hildon-plugins-notify-sv and libplayback also seem to be finished Sep 03 11:21:40 mhm Sep 03 11:22:06 though there are still problems in codelockui, but I am chasing them Sep 03 11:24:51 Great :) Sep 03 11:26:14 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?) Sep 03 11:28:03 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) Sep 03 11:31:01 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. Sep 03 11:32:20 that's no question Sep 03 11:32:32 bencoh So what are those keys in variant-domains.xexp? Sep 03 11:32:38 (This is the question.) Sep 03 11:33:48 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" Sep 03 11:34:43 Its good that we are getting more and more of the interesting stuff for the N900 (hildon-plugins-notify-sv for example) cloned :) Sep 03 11:36:09 hmm, no idea what variant-domains.xexp is, I've never had to bother Sep 03 11:36:26 (not that I use HAM much, but ... it does work here) Sep 03 11:36:36 DocScrutinizer05 Sorry, why man apt? Is not this related to HAM? Sep 03 11:36:48 ham is apt based Sep 03 11:36:59 DocScrutinizer05: this is still HAM-specific Sep 03 11:37:23 and I doubt he'll find information regarding the HAM-apt glue in the apt manual :) Sep 03 11:37:27 then b) already is off the table :-D Sep 03 11:37:38 remains a) Sep 03 11:38:19 but how are certs HAM specific? I thought that's a genuine apt thing Sep 03 11:38:43 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? Sep 03 11:39:30 I wouldn't be surprised if the answer is "yes" or "click an install file" Sep 03 11:40:00 I for one never edited sourcelist files Sep 03 11:40:42 I copy them however, in enable-catalogs Sep 03 11:41:00 Ok. When you click the install file, does that also install new keys? Or keys are not needed for the muarf.org mirror? Sep 03 11:41:19 there are no keys for muarf Sep 03 11:41:55 muarf is a mirror that doesn't build&sign stuff itself, so the original nokia keys apply Sep 03 11:42:07 what is stopping maemo team from repacking nokia debs with maemo.org keys? Sep 03 11:42:08 makes you wonder why we can't just resign it. Sep 03 11:42:11 ^^ Sep 03 11:42:22 not that there would be any new package in those repos Sep 03 11:42:25 missing sources? Sep 03 11:42:35 you don't need sources to sign it Sep 03 11:42:40 +1 Sep 03 11:42:49 bfc Sep 03 11:42:59 nfc even. ask the experts Sep 03 11:43:06 define 'experts' Sep 03 11:43:41 I think we looked into that for quite a few months, even Nokia dides did though they had no clue at all Sep 03 11:44:11 devuan does this on a daily basis Sep 03 11:44:15 afaik Sep 03 11:44:30 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). Sep 03 11:44:32 I think the issue is that there is no key in the stock firmware that is still valid (not expired) Sep 03 11:44:57 jonwil: right, so cssu can add it Sep 03 11:45:06 but since packages would barf on keyexpireds, does it change anything? Sep 03 11:45:23 this way one can change the repo url and add a key and be done Sep 03 11:45:55 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. Sep 03 11:46:30 would apt break if pkg key changes? Sep 03 11:47:15 (Brb.) Sep 03 11:47:39 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) Sep 03 11:47:46 s/any/anything/ Sep 03 11:47:46 bencoh meant: 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 anything) Sep 03 11:49:11 Wizzup: no CSSU can't add it since we have no valid key to sign the new key Sep 03 11:49:39 well, technically CSSU has its own key Sep 03 11:49:41 we would need to instruct users to add the new key manually Sep 03 11:49:43 the one used to sign CSSU Sep 03 11:49:56 that is installed when upgrading (migrating) to CSSU Sep 03 11:50:01 couldnt cssu installer do that? Sep 03 11:50:02 DocScrutinizer05: then people click a link in the browser and add the key Sep 03 11:50:06 whatever, same thing Sep 03 11:51:41 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" Sep 03 11:51:50 I still have the emails Sep 03 11:52:23 My understanding is that there was no valid key in the stock ROMs that could be used to re-sign the Nokia repos Sep 03 11:52:26 because they were thinking about proper fix Sep 03 11:52:34 jonwil: yep Sep 03 11:52:42 i propose just resigning the debs with cssu key Sep 03 11:52:47 there was, but Nokia refused to use it Sep 03 11:53:14 well, another way would be breaking the key Sep 03 11:53:29 or just ignore it Sep 03 11:53:33 breaking onto nokia servers Sep 03 11:53:34 jonwil: but a key can be added via the browser easily Sep 03 11:53:55 *shrug* requiring some user interactions seems fine Sep 03 11:54:12 Wizzup: that been exactly the point Sep 03 11:54:18 it's just that not fixing the re-signing is lame, but I can understand it if the issue is time constraints Sep 03 11:54:25 DocScrutinizer05: is it? people already have to jump through several hoops for cssu Sep 03 11:54:27 prolly yes, with user interaction it's feasible Sep 03 11:54:49 Are CSSU debs currently signed? Sep 03 11:55:05 the concern back when was for doofus users who don't have a clue Sep 03 11:55:19 jonwil: nfc Sep 03 11:55:27 prolly not Sep 03 11:55:53 given they are built and packaged offline Sep 03 11:56:09 so who would be the key owner? Sep 03 11:56:09 they are Sep 03 11:56:27 So they get signed when they get pushed to cssu-testing/cssu-stable/whatever? Sep 03 11:56:29 maemo infra signs then Sep 03 11:56:34 yes Sep 03 11:56:44 ooh fine :-) Sep 03 11:57:07 Ok so is the key that is used to sign those installed by CSSU (or as part of the CSSU process) or what? Sep 03 11:58:30 jonwil: sorry, can't parse, please rephrase Sep 03 11:58:41 took me a while too :-) Sep 03 11:58:49 Ok so CSSU packages are signed by someone Sep 03 11:58:52 your english is better Sep 03 11:59:00 jonwil: in the repo, yes Sep 03 11:59:06 is the pubkey used to verify CSSU signature a part of the CSSU installation process? Sep 03 11:59:09 yes Sep 03 12:00:00 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. Sep 03 12:00:20 I will be busy for a couple of hours (F1 race). See you later. Thanks for the discussion so far. Sep 03 12:00:40 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 Sep 03 12:00:49 The third is someone running CSSU Sep 03 12:01:23 IMO we should do this: Sep 03 12:01:24 jonwil: no CSSU????? o,O shame on you! ;-P Sep 03 12:01:54 mhm Sep 03 12:02:07 I am running a mix of various cloned/updated packages (some I cloned, others cloned or upgraded by someone else) Sep 03 12:02:12 WAAH Pali has a terrible timing Sep 03 12:02:13 anyway, codelockui seems to work :) Sep 03 12:02:53 I'm pretty sure he investigated the whole issue in epic depth back when Sep 03 12:03:49 IMO we should do this: Sep 03 12:03:50 1.We re-sign all the Nokia packages with the CSSU key Sep 03 12:04:03 in general I agree we finally should reclaim contrpol over *all* signature keys, particularly since original Nokia repos are no more Sep 03 12:05:04 so not a single user can run updates without having CSSU installed and repo sourcelists fixed Sep 03 12:05:33 ergo we need to take action about that, finally Sep 03 12:06:24 Wizzup: which branch should I use so it is easier for you? Sep 03 12:06:33 freemangordon: I don't know yet, once I do, I'll let you know Sep 03 12:06:39 I think just a tag is fine Sep 03 12:06:46 ok, I'll use gtk2 sisnce then Sep 03 12:06:47 right now we're making it auto generate and sign a repo :) Sep 03 12:07:01 is that ok? Sep 03 12:07:06 gtk2? sure Sep 03 12:07:08 ok Sep 03 12:09:25 IMO we should do this: Sep 03 12:09:27 1.We re-sign all the Nokia packages with the CSSU key Sep 03 12:09:28 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. Sep 03 12:09:30 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 Sep 03 12:09:31 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. Sep 03 12:10:07 that should fix all those cssu installs that require manual package installations? Sep 03 12:13:21 Anyone got any comments on whether my idea is good or not? Sep 03 12:15:57 jonwil: I guess the idea is good, but I don;t see who is going to release it Sep 03 12:16:54 jonwil seems to have run out of things to RE, so.. ;) Sep 03 12:17:11 ah, right :) Sep 03 12:17:28 and he is keys expert too Sep 03 12:17:59 jonwil: that is exactly what I thought/meant Sep 03 12:20:37 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) Sep 03 12:21:11 jonwil: iirc we are not allowed to host closed source packages Sep 03 12:21:35 jonwil, would you be able to write a script for someone to run oh his server? (ie. bencoh) Sep 03 12:21:36 no idea how relevent is this in 2017, but still Sep 03 12:22:35 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. Sep 03 12:23:03 I dont know enough about writing shell scripts or signing packages to write such a script :) Sep 03 12:23:48 eager to learn pkg signing then? ;) Sep 03 12:24:25 Actually, I need to stop procrastinating and talking on here and watching crap on YouTube Sep 03 12:25:15 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... Sep 03 12:25:25 So I gotta stop messing about and actually start building :) Sep 03 12:26:37 note that re-signed packages can be host by 3rd parties Sep 03 12:26:54 hosted* Sep 03 12:29:39 (( jonwil: iirc we are not allowed to host closed source packages)) yes exactly Sep 03 12:30:23 we are not even allowed to publish tablets-dev though in fact we always been the ones to host it, on maemo infra Sep 03 12:31:22 are we allowed to RE packages? Sep 03 12:31:24 why are you not allowed? Sep 03 12:31:34 and if you host it anyway, might as well just sign it Sep 03 12:31:37 and to publish/create debs out of the results? Sep 03 12:31:40 Wizzup: because Nokia tells us so Sep 03 12:31:56 but I'm not maemo Sep 03 12:33:13 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 Sep 03 12:33:44 :) Sep 03 12:33:51 problem solved Sep 03 12:37:48 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. Sep 03 12:38:45 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. Sep 03 12:40:20 So we just need someone to come up with a way for whoever has a repo already to re-sign things. Sep 03 12:40:36 Then we make CSSU point to that 3rd party repo Sep 03 12:40:41 and we are in business :) Sep 03 12:41:17 except that we don't want a 3rd-party to resign Sep 03 12:41:56 s/resign/re-sign/ Sep 03 12:41:57 bencoh meant: except that we don't want a 3rd-party to re-sign Sep 03 12:42:11 well "community" (i.e. official infra) can't host a repo. Sep 03 12:42:15 so you'd need maemo to re-sign packages at some point Sep 03 12:42:19 yeah I know :) Sep 03 12:42:36 reprepro can do this in a breeze Sep 03 12:44:18 Ok so then we need someone who has the CSSU key to re-sign an existing (or new not-hosted-by-community) mirror somehow. Sep 03 12:45:00 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. Sep 03 12:45:01 "somehow" yeah :) Sep 03 12:47:13 well, if maemo does not want to be associated, they should not sign it Sep 03 12:47:36 who would you trust then? Sep 03 12:47:37 http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2013-01-24.log.html#t2013-01-24T13:13:24 Sep 03 12:49:01 Anyhow, this isn't something I can do anything to help with really Sep 03 12:50:11 ohwell, that link has some info regarding the .xexp file as well Sep 03 12:50:20 Enrico_Menotti: ^ Sep 03 12:50:48 (( Then we make CSSU point to that 3rd party repo)) is arguable, but I *think* of manageable risk nowadays Sep 03 12:52:02 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. Sep 03 12:52:27 *somehow* skeiron was exactly that Sep 03 12:52:52 some folks inside maemo went nuts about it Sep 03 12:55:43 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) Sep 03 12:58:06 hail hildon foundation >:-( Sep 03 13:00:03 woody been one of that guerrilla crew, but later blamed me for lying at him. I mean, how insidious can it get? Sep 03 13:00:56 I don't think going through this helps anymore ;) Sep 03 13:01:05 I don't know anything about this, and I do not know what good this does bringing it up again here and now Sep 03 13:01:22 you're right, sorry Sep 03 13:01:33 I just felt deep anger and frustration Sep 03 13:01:44 had to vent Sep 03 13:03:14 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? Sep 03 13:04:35 I *think* we could create a maemo-hosted mirror with restricted access to host the new-signed stuff Sep 03 13:05:11 as long as "nobody" (but those with the credentials) has access, we're fine with hosting on maemo Sep 03 13:05:46 too bad when the credentials "leak" Sep 03 13:06:01 ;-) Sep 03 13:06:05 DocScrutinizer05: you can actually re-use existing credentials ;) Sep 03 13:06:22 (that's what I did for ovi) Sep 03 13:06:48 bencoh: it must not be too obvious Sep 03 13:07:08 Anyhow, this is 100% out of my hands, I have nothing to do with it :) Sep 03 13:07:21 same here :) Sep 03 13:07:29 e.g. re-implementing that old "please enter your IMEI" thing won't fly Sep 03 13:09:19 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 Sep 03 13:10:21 or similar to tablets-dev which is also still there, just nobody knows about it ;-) Sep 03 13:12:48 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 Sep 03 13:14:05 by the way ... https://github.com/postmarketOS/pmbootstrap/issues/438 :) Sep 03 13:14:29 (tl;dr: pavelmachek detailing n900 mainline status as a daily driver) Sep 03 13:18:52 nice Sep 03 13:25:10 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 Sep 03 13:25:35 :-D Sep 03 13:26:26 would make more than just some sense when such CSSU "private" mirror had been re-signed by CSSU keys Sep 03 13:27:52 when some "ev17 h4x0r5" crack and mirror that private Nokia CSSU mirror, what could we possibly do? Sep 03 13:29:02 this is a public chan with public logs :p anyway Sep 03 13:29:49 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 Sep 03 13:30:05 -_- Sep 03 13:31:31 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 ;-) Sep 03 13:41:44 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 ;-) Sep 03 13:43:27 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. Sep 03 13:45:23 keyholder of CSSU keys: merlin1991 Sep 03 13:45:34 afaik Sep 03 13:45:48 ~mirrors Sep 03 13:45:48 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 Sep 03 13:46:09 hmm, no not those Sep 03 13:48:00 jonwil: why would we need "to figure out who is going to run this 3rd party mirror"? Sep 03 13:48:21 I mean we need to figure out which mirror is going to be the one that hosts this re-signed repo. Sep 03 13:48:47 we will see which mirror is it that picks up Sep 03 13:48:49 ;-) Sep 03 13:49:48 I suggest to consider indirection: point to a place with an .install file and only that .install file points to the recently valid mirrors Sep 03 13:51:17 ~jrrepos Sep 03 13:51:17 well, jrrepos is http://maemo.cloud-7.de/maemo5/et_al/HAM-catalogs/ Sep 03 13:52:16 for a really longterm stable URL I'd change this to sth not including cloud-7 though Sep 03 13:52:35 might even be histed on maemo infra Sep 03 13:52:39 hosted* Sep 03 13:53:30 maybe a bootjob could download the .install file and edit the sources.list or /etc/hosts Sep 03 13:55:57 echo "nokiareposymbolic `wget http://maemo.cloud-7.de/maemo5/et_al/HAM-catalogs/ | grep 'URI = '|cut -f 3`" >>/etc/hosts Sep 03 13:56:01 sth like that Sep 03 13:56:32 (obviously buggy, but you get the idea) Sep 03 14:06:47 freemangordon: http://sprunge.us/RANT Sep 03 14:09:51 RANT ? ;-P Sep 03 14:10:17 ;=P Sep 03 14:10:21 yep, lol Sep 03 14:10:25 lol Sep 03 14:10:35 new flavor of bullshit bingo ala sprunge? Sep 03 14:13:33 anyway: this is libcal built from a devuan ascii VM running jenkins Sep 03 14:13:38 it auto generates a repo and signs it with a testing key Sep 03 14:13:58 this could essentially be rsynced to a public http server and we could play with it on a real device Sep 03 14:14:09 we'll add the arm arch once we've figured out the other parts Sep 03 14:14:23 automatically adding new packages, auto fetching new builds, documenting the branches / files required for git builds, and such Sep 03 14:57:53 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. Sep 03 14:57:53 Recap: I understand the keys for the original Nokia repos are expired, nothing to do about that. So that issues a warning in the HAM log, but nothing else. Still, I didn't understand why apt-worker refuses to use packages from mirrored (on muarf.org) Nokia repos (says "wrong domain"). Next, by removing the domain and key files in /usr/share/hildon-application-manager/ apt-worker doesn't complain anymore. As far as I Sep 03 14:57:53 understand at the moment, in this situation apt-worker has no keys to verify the signatures (is this correct?), so it should complain even louder! Also, I removed the keys for repository.maemo.org together with the others, and neither this repository causes apt-worker to complain! Sorry, I don't understand what's going on. Sep 03 14:58:01 May anybody help me to clarify the situation? Sep 03 14:59:20 how did you add the repositories to your device? Sep 03 14:59:49 ((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 Sep 03 15:01:07 ~redpill Sep 03 15:01:08 extra, extra, read all about it, redpill is http://wiki.maemo.org/Red_Pill_mode Sep 03 15:04:11 HAM "settings"-> "[ ] Ignore packages from wrong domains", "[x] ignore the third party packages policy for SSU" Sep 03 15:04:44 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. Sep 03 15:04:51 not sure which setting they'd need, but... usually your problem doesn't occur here Sep 03 15:06:19 what happens when just using the .install files? Sep 03 15:06:30 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 Sep 03 15:06:33 (I've never tried those, so ...) Sep 03 15:07:42 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 Sep 03 15:08:28 well, actually for *user* the canonical way is to use HAM "catalogs" interface, or click an .install file in microB Sep 03 15:09:24 /60/60 Sep 03 15:10:09 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 Sep 03 15:12:17 when copying files into /etc/apt/* works, then editing same files must work too, right? Sep 03 15:12:40 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 Sep 03 15:12:40 their catalogues and install others: it makes more sense to me to correct the original catalogues. Anyhow, at this point I'd like to understand how the .xexp files work. Sep 03 15:13:15 DocScrutinizer05 /etc/apt/sources.list.d/ you mean? Sep 03 15:13:38 whatever files are there under /etc/apt Sep 03 15:14:16 I can't help with .xexp files, never heard of them before you came up with them Sep 03 15:14:59 I guess THAT is a very HAM specific thing Sep 03 15:15:26 only used once during initial config Sep 03 15:16:44 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 Sep 03 15:17:44 you probably have to dig deep into HAM sources to get an answer to "how does .xexp work?" Sep 03 15:18:22 all I know is: nobody sugested to mess with .xexp so far Sep 03 15:18:54 the canoical way is via /etc/apt and /etc/hildon-app*ger Sep 03 15:19:26 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 Sep 03 15:19:27 /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. Sep 03 15:19:45 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 Sep 03 15:19:53