| cyphermox | teward: I think most packages instead ship the file using their install files | 01:39 |
|---|---|---|
| teward | cyphermox: infinity said dh_apport / dh_installapport so eh | 01:39 |
| teward | cyphermox: i'm trying to ship inside the .install files but apparently it's not included in the .deb | 01:39 |
| teward | unpacking the binaries yields the file not being present | 01:39 |
| cyphermox | ie. usb-creator ships source_usb-creator.py to usr/share/apport/package-hooks | 01:39 |
| cyphermox | my info may be outdated, or most packages may need to be updated :) | 01:40 |
| teward | cyphermox: would that be doable on a per-binary basis, i.e. if the source package produces 5 primary binaries, of which only 4 need the apport hooks, there's a package.py for each of those? | 01:40 |
| cyphermox | or you could ship just one for the source package | 01:41 |
| cyphermox | either way works, but having just one is probably better if it turns out to be the same file for each binary | 01:41 |
| teward | ... true... but then i run into the -dbg packages getting it, and the -common package getting it | 01:41 |
| teward | cyphermox: this is for the nginx package, and it contains hooks for Package class bugs/failures, because those bug reports currently suck to a level I can't safely say here, due to systemd hiding the 'error' output from the 'start' task | 01:42 |
| cyphermox | in this case what I've seen was the -common package shipping it for the source, and you probably don't need a -dbg since we create them | 01:42 |
| * teward shrugs | 01:43 | |
| cyphermox | how's your rules? | 01:45 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| infinity | teward: I never said anything about dh_apport, I only pointed you to the manpage when you asked how it worked. :P | 02:21 |
| teward | ahhh | 02:21 |
| teward | infinity: okay, then i misunderstood | 02:21 |
| infinity | teward: It's perfectly reasonable to install it by hand, either with dh_install or cp. :P | 02:21 |
| teward | heh | 02:21 |
| teward | infinity: then i misunderstood you, I apologize | 02:22 |
| infinity | teward: And I'd agree with the crowd that having one hook for the source package and installing it to (only) -common makes the most sense. | 02:22 |
| teward | infinity: and apport will understand source_nginx.py applies for nginx*? | 02:22 |
| teward | or rather, automatically know it refers to all binaries? | 02:22 |
| teward | or am I gonna have to postinst script it for -common? | 02:22 |
| teward | (for symlinks anyways) | 02:23 |
| infinity | teward: apport knows to map binary->source in some fashion. I forget what that fashion is. :P | 02:27 |
| teward | heh | 02:27 |
| teward | i know i have it working for Vivid to cp the .py into where it needs to go... | 02:27 |
| infinity | Oh, it's just source_$package.py ... That's simple enough. | 02:27 |
| teward | ... but I'm having a hard time figuring out why the same codechanges don't work in WIly | 02:28 |
| teward | and it's one of those headscratcher moments | 02:28 |
| teward | 'cause i've been beating it all day | 02:28 |
| infinity | teward: Yeah, just source_nginx.py should do it. Apport will do the dpkg lookup for the binary->source mapping, then run the source hook (if there's no binary hook, which there shouldn't be in this scheme) | 02:28 |
| teward | infinity: any special consideration with regards to debian/rules and the package itself, other than the install of the .py ? | 02:29 |
| infinity | teward: I'm not an apport expert, but I'm pretty sure you just drop the hook in the right directory, and you're done. | 02:30 |
| infinity | teward: So, just put it in nginx-common.install or whatever. | 02:30 |
| teward | ack | 02:30 |
| teward | i'll poke at this tomorrow | 02:32 |
| teward | i'm waaay too tired to test things xD | 02:32 |
| teward | but thanks for clarification and more insights :) | 02:32 |
| teward | cyphermox: FWIW, the rules here're from Debian, the last time they were revised was for enabling PIE and other hardening flags, and even then this channel was more than helpful in fixing a failure somewhere along the lines :) | 02:32 |
| teward | actually... was that you, infinity, who helped solve that, or was it someone else? | 02:33 |
| teward | I forget, i interact with so many people xD | 02:33 |
| infinity | Sounds like something I'd do. | 02:35 |
| teward | well, in either case, those changes made their way into debian | 02:35 |
| cyphermox | good | 02:35 |
| teward | so the SRU and direct upload for... I think it was trusty/utopic/vivid at the time... had the PIE and other missing hardening flags put in | 02:35 |
| teward | i forget... DAMN now I want to dig into the changelogs | 02:36 |
| teward | hmm, maybe it was just Vivid... | 02:37 |
| teward | yep, SRU'd to vivid... *shrugs* | 02:37 |
| teward | anyways, thanks for the direction points to look at, infinity and cyphermox. | 02:38 |
| cyphermox | no worries | 02:38 |
| teward | and as always, thanks again to all who help out with these things :) | 02:38 |
| teward | because i think i'd have thrown the nginx package into oblivion by now xD | 02:38 |
| cyphermox | teward: we all eventually break things, trick is to know, accept it, and fix it :) | 02:39 |
| teward | cyphermox: and acknowledge that when you aren't sure how to fix, you and and likely should ask for help XD | 02:40 |
| teward | cyphermox: at least i'm not some newbie who uploads to a PPA 50 times and taxes canonical's infrastructure with all their fails | 02:40 |
| teward | i try and stick to my local sbuild for that xD | 02:40 |
| teward | although I sure remember when I was one of those newbies xD | 02:40 |
| cyphermox | some things are really hard to properly stage without a PPA | 02:40 |
| teward | or sbuild and a local VM | 02:41 |
| teward | which is what i've been doing all day XD | 02:41 |
| cyphermox | (or, I should say, without a PPA if you don't want to spend hours setting up infra) | 02:41 |
| cyphermox | yeah, I noticed | 02:41 |
| teward | building, testing, building, testing, shredding, building, testing xD | 02:41 |
| cyphermox | fwiw, sbuild-launchpad-chroot is pretty cool to get you nice up-to-date chroots quickly | 02:41 |
| teward | cyphermox: FWIW this is the one thign I hate about systemd: job start errors aren't grabbed by apport anymore during a postinst fail | 02:41 |
| teward | it just says "Job failed, refer to [two other commands] for details." | 02:42 |
| teward | for service failed to start problems | 02:42 |
| teward | and with nginx Vivid, we had... *pulls list* | 02:42 |
| teward | ... at least six or seven... bugs that are ambiguous as all hell since there's no usable debug info | 02:43 |
| teward | hence my getting up off my butt, deprioritizing the nginx Wily merge prep, and working on this apport hook stuff :/ | 02:44 |
| teward | which in turn as soon as I get working and provably so with test cases i'm going to upload... cause i'm tired of ambiguous nginx postinstallation failed bugs. So's sarnold and rbasak. | 02:45 |
| teward | anyways, i'm off, good night | 02:45 |
| === salem_ is now known as _salem | ||
| pitti | Good morning | 03:39 |
| pitti | teward: it's dh_apport, but yes | 03:40 |
| pitti | teward: man dh_apport | 03:40 |
| pitti | teward: either ship a source_<srcpkgname>.py which applies to all binaries, or a <binarypkg>.py and perhaps symlinks for the other packages | 03:41 |
| pitti | teward: it's all in /usr/share/doc/apport/package-hooks.txt.gz | 03:41 |
| pitti | teward: we never grabbed job start errors in apport | 03:42 |
| pitti | only indirectly via package install failures, but their logs didn't contain syslog or upstart logs by default either | 03:42 |
| pitti | makes sense for a package to include theirs, of course | 03:42 |
| pitti | that's why we have apport hooks | 03:43 |
| tjaalton | why aren't packages like libuid-wrapper synced from debian to wily? | 06:14 |
| tjaalton | hmm nevermind | 06:14 |
| tjaalton | realized that it's probably in universe instead | 06:14 |
| tjaalton | and in vivid too :) | 06:14 |
| tjaalton | so sssd needs it in main | 06:15 |
| tjaalton | libnss-wrapper too | 06:16 |
| tjaalton | when are we going to get rid of main/universe split again? | 06:17 |
| Noskcaj | tjaalton, once we MIR every package? | 06:19 |
| tjaalton | no | 06:20 |
| tjaalton | there's an old blueprint about it | 06:20 |
| Noskcaj | huh | 06:21 |
| tjaalton | https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-finish-archive-reorg | 06:23 |
| tjaalton | cjwatson: is this ^ again in the horizon now that lp is getting more love these days? | 06:25 |
| dholbach | good morning | 06:35 |
| sil2100 | pitti: piiing | 09:02 |
| pitti | hey sil2100 | 09:02 |
| sil2100 | pitti: hey, again me and again regarding translations (as I'm assuming you have more knowledge than I do here) ;) | 09:03 |
| sil2100 | pitti: a strange thing happened | 09:03 |
| sil2100 | Around the beginning of the week we had an ubuntu-system-settings released to vivid and wily with a string change | 09:03 |
| sil2100 | It changed "Install & Restart" to "Restart & Install" | 09:03 |
| sil2100 | https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/347/+translate <- but the LP template still has the old one | 09:04 |
| sil2100 | Didn't we import all the new strings to templates yesterday? | 09:04 |
| seb128 | https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-system-settings/+imports indicates there are not be template import for the recent builds | 09:06 |
| pitti | oh right, latest from May | 09:08 |
| seb128 | pitti, ? | 09:08 |
| seb128 | " Uploaded by Steve Langasek on 2015-07-02 19:35:20 CEST " | 09:08 |
| seb128 | pitti, weird thing is that the most recent package build | 09:09 |
| seb128 | https://launchpadlibrarian.net/210643779/buildlog_ubuntu-wily-amd64.ubuntu-system-settings_0.3%2B15.10.20150703-0ubuntu1_BUILDING.txt.gz | 09:09 |
| seb128 | has | 09:09 |
| seb128 | " 69979f587d60fac3711adab7320a0700ceac2ac7 1655913 ubuntu-system-settings_0.3+15.10.20150703-0ubuntu1_amd64_translations.tar.gz" | 09:09 |
| seb128 | sorry, https://launchpadlibrarian.net/211136452/buildlog_ubuntu-wily-amd64.ubuntu-system-settings_0.3%2B15.10.20150708-0ubuntu1_BUILDING.txt.gz | 09:10 |
| seb128 | but launchpad doesn't have it | 09:11 |
| seb128 | pitti, http://paste.ubuntu.com/11854869/ | 09:12 |
| pitti | hmm | 09:12 |
| seb128 | works on 0.3+15.10.20150622-0ubuntu2 though | 09:12 |
| pitti | wgrant: do these imports only happen from the time on when these magic check boxes get unchecked? | 09:12 |
| seb128 | so it's like launchpad didn't get the translations tarball | 09:12 |
| pitti | yesterday I got asked to fiddle with https://translations.launchpad.net/ubuntu/wily/+translations-admin , maybe that did the trick? | 09:13 |
| wgrant | pitti: No, those checkboxes only delay Approved entries from being imported. | 09:22 |
| === vrruiz_ is now known as rvr | ||
| sil2100 | hmmm | 09:26 |
| cjwatson | tjaalton: not currently scheduled | 09:27 |
| tjaalton | cjwatson: ok | 09:27 |
| seb128 | wgrant, any idea why the most recent ubuntu-system-settings builds don't have their translations tarball in launchpad? | 09:28 |
| seb128 | wgrant, cf what I just copied in backlog, the pastebin a small lp-shell log showing the data seems to not be there | 09:28 |
| seb128 | where it's there for the older uploads | 09:28 |
| cjwatson | tjaalton: (and it's Hard, so would need a significant slot of time) | 09:30 |
| cjwatson | seb128: perhaps related to it being in universe? | 09:30 |
| seb128 | cjwatson, it always was in universe | 09:31 |
| cjwatson | this may be irrelevant, it's hot and I'm really not very awake | 09:31 |
| wgrant | universe hasn't been relevant since oneiric. | 09:31 |
| seb128 | https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-system-settings/+imports has recent imports | 09:31 |
| seb128 | since it stopped importing for a week or so | 09:31 |
| tjaalton | cjwatson: understood | 09:32 |
| wgrant | seb128, pitti: Ah, got it. | 09:37 |
| wgrant | seb128, pitti: The new tarball ended up in the 2015-06-25 queue item | 09:37 |
| seb128 | ? | 09:38 |
| wgrant | That's correct. | 09:38 |
| seb128 | how come | 09:38 |
| wgrant | Also correct. | 09:38 |
| wgrant | For reasons I've never been able to fathom, Translations will attempt to update an existing import queue entry if it can, rather than creating a new one. | 09:39 |
| wgrant | In this case, it apparently decided that updating the third newest one was a grand idea. | 09:39 |
| wgrant | So the newest one, which wasn't updated, got imported over the top of the actual new template. | 09:39 |
| wgrant | Copying the package back in may fix it, but I forget in which scenarios the custom copier hack applies. | 09:44 |
| cjwatson | All copies, pretty much. | 09:45 |
| wgrant | Even a copy that actually does nothing because it already exists? | 09:45 |
| cjwatson | Think so, let me check | 09:45 |
| wgrant | Good lord. | 09:45 |
| cjwatson | Yeah, the copier doesn't bail out early or anything, that would be clever. | 09:47 |
| wgrant | Perhaps this is a good time to dig through history to discover why somebody thought it would be a good idea to update an existing queue item rather than adding a new one. | 09:47 |
| wgrant | sigh | 09:47 |
| cjwatson | But handy in this case :) | 09:47 |
| wgrant | Oh yes, certainly. | 09:47 |
| cjwatson | Batshit *and* useful. | 09:47 |
| wgrant | The best kind of batshit insanity. | 09:47 |
| cjwatson | (I can say that since I'm reasonably sure it was my fault.) | 09:47 |
| wgrant | I've actively ignored the custom upload copier since long before you came onto the scene. | 09:48 |
| wgrant | But indeed the packagecopier integration was at your hand. | 09:48 |
| wgrant | seb128: So indeed it seems that copying the package over itself will fix it. | 09:51 |
| wgrant | Ohhhhh | 09:53 |
| wgrant | It chose that entry because it matches on the importer. | 09:53 |
| wgrant | That is the second most stupid thing I've seen today. | 09:53 |
| wgrant | After the custom upload copier :) | 09:53 |
| wgrant | cjwatson: Do you have any idea why Translations attempts to update existing entries? | 09:55 |
| wgrant | It goes back more than nine and a half years, so I doubt it, but you have the benefit of a heat-addled brain. | 09:55 |
| cjwatson | wgrant: None whatsoever, I tried as hard as I could to ignore Translations for many years | 10:04 |
| wgrant | Heh, yes... | 10:04 |
| cjwatson | (Which often wasn't very well, but the extent to which I touched it was entirely client-side) | 10:04 |
| cjwatson | Speaking of Translations, I think I can turn on ubuntu-rtm/15.04 imports now, if that's OK with you. | 10:05 |
| wgrant | I let in a big batch of wily imports just before this incident came to light, so they won't process for at least several hours. | 10:06 |
| wgrant | Given that that would push the first hacked import well into Saturday morning, I'm tempted to reblock those wily imports. | 10:06 |
| JuNuKN_ | Can someone point me in a direction how to prevent from a black screen, while ubuntu switches from plymouth to the unity desktop? | 10:24 |
| cjwatson | wgrant: Are you suggesting that I'd be better off not unblocking ubuntu-rtm/15.04 just yet to avoid slowing down wily too much? | 10:25 |
| JuNuKN_ | On our system it needs 12 seconds, till the desktop is up and our fullscreen app is visible. | 10:25 |
| wgrant | cjwatson: No, I just don't want the first import to happen as the US sysadmins disappear for the week. | 10:27 |
| wgrant | cjwatson: For that reason I'm half way through reblocking the wily templates that I had unblocked. | 10:27 |
| cjwatson | wgrant: Oh, right. 15.04 should be much quicker, so I might go ahead with at least one of those. | 10:30 |
| cjwatson | Actually, there are only nine templates here, how bad can it be. | 10:30 |
| wgrant | cjwatson: Yep, but they wouldn't have processed until tomorrow morning wile whily had translations approved. | 10:31 |
| cjwatson | Yeah | 10:31 |
| wgrant | My only concern is that the first overlay import not occur while we have nobody around to fix any explosions. | 10:32 |
| JuNuKN_ | Can someone point me in a direction how to prevent from a black screen, while ubuntu switches from plymouth to the unity desktop? On our system it needs 12 seconds, till the desktop is up and our fullscreen app is visible. I wan't to prevent the user sit in front of a black screen,- better would be to still let the splash screen up, till I quit plymouth my self with our app | 10:32 |
| Laney | doko: looks like pcre3 needs some work, std::basic_string in exported symbols | 11:05 |
| doko | Laney, you mean, in the ppa? | 11:05 |
| Laney | I did a test build against the ppa | 11:06 |
| doko | Laney, just upload it then in the ppa, I'll leave a comment in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791236 | 11:07 |
| ubottu | Debian bug 791236 in src:pcre3 "pcre3: library transition may be needed when GCC 5 is the default" [Important,Open] | 11:07 |
| Laney | sure | 11:08 |
| Laney | I will use a non archive version then though | 11:08 |
| doko | no, we will copy it to the archive | 11:08 |
| Laney | not if it fails to build | 11:09 |
| Laney | ?!?! | 11:09 |
| doko | well, upload a version to the ppa that does build =) | 11:09 |
| Laney | you probably want the maintainer to decide what to do | 11:09 |
| Laney | http://paste.debian.net/281022 | 11:10 |
| Laney | they don't have the symbols file in debian btw | 11:11 |
| doko | can you leave a comment in the report? | 11:12 |
| Laney | ok | 11:16 |
| Mirv | if anyone is interested, there's a hung armhf builder that failed to finish and also failing to cancel at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+build/7638685 | 11:20 |
| cjwatson | Mirv: Curious. Will look once I get logs extracted via webops. | 11:25 |
| cjwatson | Looks like it failed to build but then hung when trying to retrieve files. No sign of a cancel actually being processed at the buildd-manager level. | 11:27 |
| Mirv | cjwatson: hmm, this amd64 build is also hung, and I'd want to cancel and rebuild it properly (without reuploading) | 11:40 |
| Mirv | this = https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7638376 | 11:41 |
| cjwatson | Mirv: there's lots of firewall-level trouble at the moment. | 11:41 |
| cjwatson | Mirv: but you can try a cancel there and cross your fingers | 11:41 |
| infinity | Mirv: I see no indication that build is hung. | 11:45 |
| infinity | However, if there are network issues, buildd-manager might have "lost" the buildd, and might need a restart. | 11:46 |
| === _salem is now known as salem_ | ||
| === MacSlow is now known as MacSlow|lunch | ||
| Mirv | cjwatson: ok. well I can also see if it at some point finishes by itself | 11:55 |
| Mirv | infinity: it usually takes 2h for that to build so I assume it has stayed at that point for the last 4 hours. | 11:55 |
| infinity | Mirv: Yeah, I'm fairly sure the build itself is complete (on the buildd), it's that LP is failing to care. | 11:56 |
| infinity | Mirv: And it seems there are larger issues afoot relating to that, so I'll let wgrant/cjwatson put out their fires. | 11:57 |
| cjwatson | Right, I would suggest leaving things well alone at the moment. | 11:57 |
| cjwatson | Our slave DB server is rather suspiciously doing nothing at all. | 11:57 |
| infinity | Mirv: The reason I immediately called "nah, it's not hung", is because the last bit in the log tail is the part where sbuild lists all the contents of the debs... After a successful build. | 11:57 |
| infinity | Mirv: So, all that's left to do is for the master to suck up the results and do things with them. | 11:58 |
| cjwatson | And at least some connections to it are crashing. | 11:58 |
| Mirv | infinity: yeah, leaving it alone seems right in case LP then gets back to business of getting the results | 12:02 |
| rbasak | pitti: just one catch with that [trusted=yes]. I wonder if it is available in Precise? | 12:18 |
| infinity | rbasak: trusted=yes works in precise (just tested) | 12:41 |
| rbasak | infinity: oh, great. Should be no issue then. Thanks. | 13:01 |
| rbasak | pitti: could you please take a look at bug 1455097? Alleged potential issues since systemd no longer uses /etc/pm/sleep.d/ but packages put stuff in there. Do we have the functionality we need provided for the systemd mechanisms also? | 13:02 |
| ubottu | bug 1455097 in pm-utils (Ubuntu) "pm-suspend no longer run since upgrade to vivid" [Medium,Confirmed] https://launchpad.net/bugs/1455097 | 13:02 |
| pitti | rbasak: yes, I checked precise's apt-sources manpage, seems to be there | 13:10 |
| pitti | rbasak: there is, one can put stuff into /lib/systemd/system-sleep/, but we don't actually want all the old pm-suspend quirks any more | 13:11 |
| pitti | rbasak: so we could check which of the bits are really still needed, and link them from there | 13:12 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| cjwatson | wgrant: How does one set import_into using the translations import queue API? https://translations.launchpad.net/ubuntu-rtm/15.04/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=all is all "No import target selected yet", so setStatus(new_status="Approved") doesn't work | 14:50 |
| cjwatson | Or is this suspicious on the grounds that it should have been preselected? | 14:50 |
| teward | pitti: hate to ask, but in a source_package.py apport hook, is there a way to evaluate which package was filed against, so that i can exclude certain packages from the hook? | 14:51 |
| teward | (the case of nginx-common failing its postinstall is different than nginx-* binary installs and doesn't need the same data) | 14:51 |
| wgrant | cjwatson: Oh, hm, I guess auto-approval won't work without the templates already existing. | 14:51 |
| pitti | teward: report['Package'].split()[0] (to cut off the version number) | 14:51 |
| teward | thank you kindly :) | 14:51 |
| pitti | teward: note that it's mostly just a dictionary, so you can do stuff like print(report) in your hook (or print(report.keys()) or so) | 14:52 |
| cjwatson | I manually approved the unity-scope-click template to see if it would import, and it did,. | 14:52 |
| wgrant | Yeah, that won't be a problem. | 14:52 |
| wgrant | I forget if the POs will be automatically approved into the right place once the template is. | 14:53 |
| teward | pitti: ack | 14:53 |
| wgrant | cjwatson: There may be few enough (interesting?) templates in the overlay that it's reasonable to manually approve them. It's not currently possible to do so using the API, as potemplate etc. aren't exported. | 14:55 |
| * pitti waves bye and good weekend! | 15:00 | |
| Laney | bye pitti! | 15:01 |
| teward | see ya pitty! | 15:02 |
| teward | pitti* | 15:03 |
| teward | i hate autocorrect | 15:03 |
| cjwatson | wgrant: Not too bad if it's just templates, although as yet nothing has auto-approved the POs. | 15:04 |
| wgrant | cjwatson: They may not be autoapproved, though the gardener is slow and runs infrequently. | 15:05 |
| wgrant | If it ends up being a problem, trivial exports of IPOFile and IPOTemplate are not intractable. | 15:06 |
| cjwatson | Yeah. I'll approve the templates and see what happens. | 15:08 |
| cjwatson | Just opening the import form and hitting save DTRT, annoyingly | 15:08 |
| wgrant | cjwatson: fsvo trt | 15:19 |
| wgrant | cjwatson: Templates only share if the name is the same on both ends, but hopefully nobody's done anything weird in Ubuntu. | 15:19 |
| cjwatson | Perish the thought. | 15:19 |
| cjwatson | wgrant: With only POTs imported, a few spot checks are at least showing a respectable amount of green. | 15:24 |
| cjwatson | I'll check in tomorrow or something to see if the gardener did anything. | 15:25 |
| hjd | Hi all. The two packages https://launchpad.net/ubuntu/+source/modello-maven-plugin and https://launchpad.net/ubuntu/+source/sisu-plexus failed to build in Wily. Though it looks like they were simply synced before their dependencies had time to build. I've built both successfully on my Wily vm, so I believe that if anyone could poke them for a rerun that should resolve the build failures. | 15:50 |
| cjwatson | hjd: Yes, those should have been dependency waits but were bitten by a known launchpad-buildd bug. Both retried. | 15:57 |
| hjd | cjwatson: Thanks :) | 16:03 |
| Ionic | I think I just accendentally uploaded a package to upload.ubuntu.com (although I'm not sure how that even succeeded anonymously) | 16:35 |
| Ionic | how can I remove that again? | 16:35 |
| cjwatson | Ionic: What package name? | 16:37 |
| cjwatson | Ionic: It will almost certainly just be harmlessly rejected, but let's check. | 16:37 |
| cjwatson | dput anonymous uploads are fine; it's the signature that matters, and that's checked later. | 16:38 |
| Ionic | cjwatson: cups-x2go | 16:39 |
| Ionic | trusty | 16:39 |
| Ionic | the signature is probably known | 16:39 |
| cjwatson | Known to Launchpad doesn't necessarily mean it'll be accepted for an Ubuntu upload :) | 16:40 |
| Ionic | I hope so | 16:40 |
| cjwatson | 2015-07-10 16:30:11 INFO Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150710-162910-014065/cups-x2go_3.0.1.3-0~135~ubuntu14.04.1_ppc64el.changes': Signing key 1AD23D1B8F087A35AB74BDE9F4A7678C9C6B0B | 16:41 |
| cjwatson | 2B not registered in launchpad. | 16:41 |
| cjwatson | And a binaryful upload would have been rejected later anyway. | 16:41 |
| cjwatson | So you're fine | 16:42 |
| Ionic | great! thanks | 16:43 |
| Ionic | although it's weird that the key wasn't accepted | 16:43 |
| cjwatson | Doesn't seem to be on keyserver.ubuntu.com | 16:44 |
| cjwatson | And it would have to be specifically associated with a Launchpad user as well | 16:44 |
| Ionic | not sure what the project has as a key | 16:46 |
| Ionic | normally Ubuntu packages are being built in launchpad anyway, but maybe with a special key | 16:46 |
| cjwatson | OK, but that's presumably for a PPA or something anyway | 16:47 |
| Ionic | yep | 16:48 |
| teward | where should I drop a wily udev naming algorithms question (for network interfaces) | 17:41 |
| teward | here or -quality? | 17:41 |
| teward | or #ubuntu+1 | 17:41 |
| === josepht` is now known as josepht | ||
| melodie | hello | 18:08 |
| melodie | xnox are you here? | 18:13 |
| melodie | xnox I have posted a comment on bug #1326412 to your attention: | 18:13 |
| ubottu | bug 1326412 in ubuntu-release-upgrader (Ubuntu) "can't do dist-upgrade due to systemd" [Undecided,Fix released] https://launchpad.net/bugs/1326412 | 18:13 |
| melodie | https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1326412/comments/5 | 18:13 |
| melodie | as this bug was at that moment considered not important to fix in Trusty and I just hit it now in 14.04.2: Trusty is a LTS ... | 18:14 |
| melodie | no solution here except maybe lock the packages, which is what I am now testing. | 18:15 |
| xnox | melodie: let me just check to make sure everything. | 18:16 |
| xnox | melodie: in trusty, this works correctly when booted with upstart. | 18:16 |
| xnox | melodie: are you booted with upstart or systemd? | 18:16 |
| xnox | (e.g. systemctl is-system-running vs initctl version) will tell you. | 18:17 |
| xnox | initctl --system version; to be more correct. | 18:17 |
| melodie | xnox I don't know how I can boot to upstart, and even worse, in a chrooted environment | 18:17 |
| xnox | melodie: if you have a bug with | 18:18 |
| xnox | melodie: if you see a bug in a chroot, this is a different bug then! | 18:18 |
| xnox | melodie: although probably looks like this one =) | 18:18 |
| melodie | xnox I can understand the "upgrade to next version" thing, idea, but with a LTS? seriously? | 18:19 |
| xnox | pelase file a new bug with $ ubuntu-bug against well i guess ubuntu-release-upgrader and describe what you are seeing. | 18:19 |
| melodie | wait | 18:19 |
| xnox | melodie: all upgrades must work from Trusty, when trusty is booted with upstart. | 18:19 |
| xnox | melodie: and we believe they do. | 18:19 |
| melodie | I don't do upgrade I do dist-upgrade | 18:19 |
| melodie | how do we get it to boot with upstart? | 18:20 |
| xnox | melodie: if your host is trusty, and booted with systemd, that is entirely unsupported. | 18:20 |
| xnox | melodie: first check what you are booted with. | 18:20 |
| xnox | melodie: on the host, do $ initctl --system version | 18:20 |
| xnox | if that says upstart, you are booted with upstart. | 18:20 |
| melodie | I'll do | 18:20 |
| xnox | melodie: to boot with upstart, you need to specify init=/sbin/upstart or remove systemd-sysv package. | 18:21 |
| melodie | as soon as the actual update ends (I redid the environment) | 18:21 |
| melodie | remove systemd-sysv ? that's all it takes? | 18:21 |
| xnox | melodie: on upgrade to 15.10 or later, e.g. next lts. We upgrade systems to supported systemd config and reboot after upgrade gets one systemd. | 18:21 |
| xnox | melodie: yes. and do note systemd is not supported on 14.04 LTS, the first LTS with systemd support will be 16.04 LTS | 18:22 |
| melodie | xnox how is the setup done in the officiel Trusty versions? | 18:22 |
| xnox | melodie: if you install trusty, you get upstart as pid 1, yet there are pieces of systemd daemons running. | 18:22 |
| melodie | it seems that the systemd packages are installed there, aren't they? | 18:22 |
| xnox | e.g. udev & logind are daemons provided by systemd package. | 18:23 |
| melodie | yes they are :) | 18:23 |
| xnox | melodie: systemd is a lot of daemons. In trusty, only udev & logind are used by default. | 18:23 |
| melodie | I'll check to remove systemd-sysv once synaptic (chrooted synaptic) will have finished. | 18:23 |
| xnox | the bug #1326412 is specifically about somebody changing trusty into a non-supportable configuration, or e.g. booting with init=/lib/systemd/systemd kernel command line. | 18:24 |
| ubottu | bug 1326412 in ubuntu-release-upgrader (Ubuntu) "can't do dist-upgrade due to systemd" [Undecided,Fix released] https://launchpad.net/bugs/1326412 | 18:24 |
| xnox | and then doing upgrades with systemd as pid 1. | 18:24 |
| melodie | well here there is systemd-services installed and if I try to remove it, half of the system is going away | 18:24 |
| melodie | with it | 18:24 |
| xnox | melodie: anyway $ initctl --system version -> will definately tell you pid1 is upstart. Then we can talk / file bugs troubleshoot more whatever you are seeing odd happening. | 18:24 |
| xnox | melodie: do not remove systemd-services. | 18:24 |
| melodie | I'll do initctl --system version as soon as synaptic finishes | 18:25 |
| xnox | melodie: yeap. if that says upstart open a new bug report. If that errors out like so: | 18:26 |
| xnox | $ initctl --system version | 18:26 |
| xnox | initctl: Name "com.ubuntu.Upstart" does not exist | 18:26 |
| xnox | then you are booted with systemd as pid1, and you really want to get off that on 14.04 LTS. | 18:26 |
| melodie | initctl: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory | 18:27 |
| melodie | this is what it says | 18:27 |
| xnox | your dbus seems to be dead.... | 18:27 |
| melodie | I'll try to start it manually | 18:27 |
| xnox | melodie: you can check unix domain sockets with e.g.: | 18:28 |
| xnox | $ netstat -n | grep upstart | 18:28 |
| xnox | there should be one for system upstart. | 18:28 |
| melodie | prompts comes back silent | 18:28 |
| melodie | # service dbus start | 18:28 |
| melodie | initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused | 18:28 |
| melodie | also | 18:28 |
| xnox | =( | 18:28 |
| xnox | do you have $ ls /run/systemd/system ? | 18:29 |
| xnox | if that folder exists, you have pid1 as systemd. and should get off it. | 18:29 |
| xnox | cat /proc/cmdline might be a clue as well. | 18:29 |
| melodie | looking | 18:29 |
| xnox | (not having system dbus sounds like a really broken system, FYI) | 18:30 |
| melodie | # ls /run/systemd/system | 18:30 |
| melodie | ls: cannot access /run/systemd/system: No such file or directory | 18:30 |
| xnox | i'd be tempted to say your machine is hosed. | 18:30 |
| xnox | and i wonder if it will reboot. | 18:30 |
| melodie | # cat /proc/cmdline | 18:30 |
| melodie | root=/dev/sda3 resume=/dev/sda5 vga=775 ro | 18:30 |
| melodie | well this is a chroot | 18:31 |
| melodie | it won't reboot, it's not meant to reboot | 18:31 |
| xnox | .... | 18:31 |
| xnox | melodie: then please open a new bug against a package that failed to upgrade with your dist-upgrade log. | 18:32 |
| xnox | melodie: bug you commented on, has nothing to do with a chroot upgrade problem. | 18:32 |
| melodie | ah | 18:32 |
| xnox | melodie: but if your host is running systemd, the chroot is unsupportable. | 18:32 |
| xnox | melodie: i need to make sure the host is not running systemd. | 18:32 |
| xnox | as pid 1 that is. | 18:33 |
| melodie | I think I can check for systemd-sysv and remove it if it exists | 18:33 |
| xnox | it doesn't matter what is installed in the chroot... | 18:33 |
| melodie | how is that? | 18:33 |
| melodie | I mean, I'll make eventually an iso | 18:33 |
| melodie | then, if systemd-sysv is not installed it's better for the further use? | 18:34 |
| xnox | you lost me. | 18:34 |
| infinity | melodie: If you're having problems upgrading a chroot, systemd-sysv is irrelevant. | 18:34 |
| infinity | melodie: But, sure, if that chroot is meant to become a live filesystem later, it shouldn't have systemd-sysv installed. | 18:34 |
| infinity | melodie: But I doubt it does. | 18:34 |
| melodie | hi infinity | 18:35 |
| melodie | I just checked, not only it's not installed but it's not even in the packages list in Synaptic | 18:35 |
| infinity | melodie: Okay, so I saw your comment on the end of LP: #1325142 | 18:35 |
| ubottu | Launchpad bug 1325142 in systemd (Ubuntu Trusty) "failure to update libpam-systemd in 14.04 due to missing logind init script" [Undecided,Triaged] https://launchpad.net/bugs/1325142 | 18:35 |
| infinity | melodie: That has nothing to do with any packaging bug, it's that you're in a chroot environment. | 18:36 |
| xnox | melodie: bug 1326412 only affects upgrades of certain packages, when pid 1 is unsupported systemd on unsupported releases (e.g. 14.04 LTS) in that case invoke-rc.d and friends fail to detect when stuff is in chroots and whether stuff should be started or stopped and fails to execute those things, hence making all sorts of problems............... | 18:36 |
| ubottu | bug 1326412 in ubuntu-release-upgrader (Ubuntu) "can't do dist-upgrade due to systemd" [Undecided,Fix released] https://launchpad.net/bugs/1326412 | 18:36 |
| infinity | melodie: And your chroot should have a policy-rc.d to prevent invoke-rc.d from running at all. | 18:36 |
| xnox | melodie: why are you in a chroot? and why don't you start out with a good chroot e.g. $ mk-sbuild trusty; schroot -u root -c source:trusty-amd64 | 18:37 |
| xnox | (or whatever arch you are on) | 18:37 |
| * xnox got to run. melodie feel free to drop email to my irc nickname @ubuntu.com | 18:37 | |
| infinity | xnox: It's a chroot because they're building a new root filesystem. | 18:37 |
| infinity | melodie: http://paste.ubuntu.com/11857389/ | 18:38 |
| melodie | xnox infinity I tell you everything about it : I am running my custom version in Vivid, and building a new custom version of that recipe based on Trusty. up to now it was working. | 18:38 |
| infinity | melodie: (stolen from mk-sbuild) | 18:38 |
| melodie | infinity thanks! | 18:38 |
| infinity | melodie: Toss that in your chroot at the beginning of your build process. Delete it at the end. | 18:38 |
| infinity | melodie: Any installs/upgrades during your build will then be no-ops. | 18:38 |
| melodie | infinity I see the content, that's nice! | 18:39 |
| melodie | I might put it in the chroot/tmp directory | 18:39 |
| infinity | melodie: As a general rule, you want something like that in all chroots where you'll be installing/removing daemons that you don't actually want running. | 18:39 |
| xnox | didn't think of vivid host, trusty chroot. | 18:40 |
| melodie | so I don't need to remove it at the end (or I might forget) | 18:40 |
| infinity | melodie: Err, it needs to be /usr/sbin/policy-rc.d or it won't work. | 18:40 |
| infinity | melodie: And it needs to be removed before you ship, or your final system won't work. :P | 18:40 |
| infinity | melodie: Note what that snippet actually does (writes a new file to /usr/sbin/policy-rc.d) | 18:41 |
| melodie | I use Ubuntu Builder which has some cleanser started prior to launching the build process | 18:41 |
| melodie | yes: "sudo bash -c "cat >> $MNT/usr/sbin/policy-rc.d" <<EOM" | 18:41 |
| infinity | xnox: host and chroot don't really matter anyway. Expecting invoke-rc.d to work in a chroot is almost always a failing prospect. | 18:41 |
| TJ- | Wily server amd64 ISO, in UEFI mode, fails base-installer/kernel due to a missing pool/main/l/linux/linux-headers-signed-generic* - is this known? | 18:43 |
| xnox | infinity: wouldn't a world be a better place if policy-rc.d by default would do nothing inside a chroot, unless something magic is specified to force do stuff?! | 18:44 |
| melodie | I don't know if anyone can be interested, but I have pulled out to light what Ubuntu Builder does and how (transcripted from the original tutorial). I hope some day someone adopts this project. | 18:44 |
| infinity | xnox: No. | 18:44 |
| xnox | meh | 18:45 |
| melodie | http://linuxvillage.org/en/2015/07/ubuntu-builder-original-tutorial/ | 18:45 |
| infinity | xnox: People use chroots for lots of different reasons. They just fail miserably in the "install a full OS that I intend to boot later" mode. Sometimes. But not always. | 18:45 |
| infinity | TJ-: That's not a package that should exist... | 18:46 |
| infinity | TJ-: So, err... Fun. I'll look when I get back from lunch. | 18:46 |
| TJ- | infinity: I thought that too... but that's what I'm seeing right now (KVM+UEFI boot) | 18:46 |
| infinity | TJ-: Yeah, I know what would cause that, but I want to diagnose a bit first, so I'll give it a spin. | 18:47 |
| infinity | TJ-: (basically, is the kernel guessing bit somehow stupidly decides the flavour you want is called "signed", that's what the result would be, but I need to debug a bit to see why it got that stupid idea. :P) | 18:48 |
| infinity | s/is the/if the/ | 18:48 |
| TJ- | infinity: I wonder if it was caused because d-i asked me if I wished to 'force' the installation to be UEFI? | 18:49 |
| TJ- | infinity: apologies for the screenshot but its in a VM http://imgur.com/bQyRfq1 | 18:50 |
| melodie | infinity after I used your script: | 18:54 |
| melodie | http://pastebin.fr/40427 | 18:54 |
| melodie | seems to work! | 18:54 |
| TJ- | infinity: the syslog: https://iam.tj/projects/misc/syslog | 18:55 |
| infinity | TJ-: so... It's also not helpful that you ENOSPCed during that install. | 18:58 |
| infinity | TJ-: Can you try again with a larger disk? :P | 18:58 |
| TJ- | infinity: it did? it didn't tell me that! | 18:59 |
| infinity | Jul 10 18:38:44 in-target: dpkg: error processing archive /media/cdrom//pool/main/l/linux/linux-image-extra-4.0.0-4-generic_4.0.0-4.6_amd64.deb (--unpack):^M | 18:59 |
| infinity | Jul 10 18:38:44 in-target: cannot copy extracted data for './lib/modules/4.0.0-4-generic/kernel/drivers/bcma/bcma.ko' to '/lib/modules/4.0.0-4-generic/kernel/drivers/bcma/bcma.ko.dpkg-new': failed to write (No space left on device)^M | 18:59 |
| infinity | Jul 10 18:38:44 in-target: dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) | 18:59 |
| TJ- | infinity: shouldn't the install pre-warn about that, I'm sure I've seen it do so before | 19:00 |
| infinity | TJ-: The headers bug may still happen anyway and, like I said, I'll look after lunch, but yeah. Might not hurt to also have enough disk to test. | 19:00 |
| TJ- | 2GB should be enough for a base install ! | 19:00 |
| smoser | pitti, you still around ? | 19:01 |
| smoser | anyone have ideas on | 19:01 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1473527 | 19:01 |
| ubottu | Ubuntu bug 1473527 in cloud-init (Ubuntu) "module ssh-authkey-fingerprints fails Input/output error: /dev/console" [Undecided,New] | 19:01 |
| infinity | TJ-: Except that if that disk was 2G, your / was less than 1.2G. | 19:01 |
| infinity | TJ-: At least, based on the 831484k swap ... | 19:02 |
| smoser | cloud-init writes to /dev/console directly, and sometimes that just fails. when it is functional. it feels to me like systemd is involved. | 19:02 |
| TJ- | infinity: I let it do guided LVM and choose everything itself, I didn't even look (since I was doing this to test another bug) | 19:03 |
| TJ- | infinity: "Partition disks" ==> "This machine's firmware has started the installer in UEFI mode... continue to install Debian..." <<<<< | 19:08 |
| TJ- | infinity: the updated syslog: https://iam.tj/projects/misc/syslog.1 | 19:11 |
| infinity | TJ-: Still ENOSPC... | 19:12 |
| TJ- | infinity: grrr, same issue, with 4GB | 19:12 |
| TJ- | is it using some artificially low LVM LV size ? | 19:13 |
| teward | during the install what generates /etc/network/interfaces and installs it to disk? | 19:13 |
| TJ- | I just noticed : PV /dev/vda3 VG ubuntu-vg lvm2 [1.26 GiB / 0 free] | 19:13 |
| infinity | teward: "The installer", which could be any number of packages, depending on how you installed. | 19:13 |
| teward | infinity: i should stop crossposting... balloons just gave me the answer in -quality (I install via the daily ISO in VMware, so Ubiquity) | 19:14 |
| cyphermox | teward: ubiquity when you install in graphical, netcfg otherwise. | 19:28 |
| teward | cyphermox: ack, i'll repoint the bug | 19:28 |
| infinity | teward: What's the bug? | 19:29 |
| teward | infinity: upon install, systemd uses the systemd naming algo. but the interfaces file is built for the kernel style eth##, not systemd naming algo, so networking fails to come up after reboot/install | 19:30 |
| teward | https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1473542 | 19:30 |
| ubottu | Ubuntu bug 1473542 in ubiquity (Ubuntu) "ubuntu-server daily iso - Upon installation, /etc/network/interfaces not populated with correct network interface names, so networking fails to start" [High,New] | 19:30 |
| teward | and balloons guided the bug | 19:30 |
| infinity | teward: Ahh. pitti was meant to be on top of that when he decided to switch. :P | 19:30 |
| teward | balloons suggested ubiquity and systemd | 19:30 |
| teward | infinity: so we can blame pitti | 19:30 |
| teward | and I can throw fire at pitti now? | 19:30 |
| infinity | teward: Pretty much | 19:30 |
| teward | infinity: note i'm using the 9th's iso and i'm going to double confirm with the 10ths as soon as i can zsync it down | 19:31 |
| balloons | he'll probably have it fixed before infinity starts on Monday ;p | 19:31 |
| teward | infinity: balloons: and this is the ubuntu-server iso | 19:31 |
| infinity | teward: If it's the server ISO, it's netcfg. | 19:31 |
| teward | ack | 19:31 |
| infinity | Ubiquity won't have the same bug pretty much by accident | 19:31 |
| balloons | teward, ohh.. then yea, that was my question about using the debian installer or not | 19:31 |
| teward | done | 19:32 |
| infinity | Cause it boots with systemd, so it'll have the systemd names. | 19:32 |
| teward | balloons: you confused me :P | 19:32 |
| teward | infinity: so not a systemd bug (Invalid against that), but Confirmed Known against netcfg? | 19:32 |
| infinity | COuld be a systemd bug too. | 19:32 |
| infinity | In that it might need to ship things for d-i to mangle in netcfg. | 19:32 |
| infinity | So, keep both tasks. | 19:32 |
| teward | ack | 19:32 |
| teward | infinity: should it be left at "New" or "Confirmed" | 19:33 |
| teward | since you said this was supposed to be done | 19:33 |
| infinity | Don't care. | 19:33 |
| teward | ok | 19:33 |
| cyphermox | I'm leaning towards a systemd bug | 19:33 |
| infinity | cyphermox: Well, both. | 19:33 |
| cyphermox | I'm wondering if it's not a file missing in a udeb | 19:33 |
| infinity | cyphermox: netcfg is going to need to invoke the systemd interface renaming magic before it presents the selector UI. | 19:34 |
| infinity | cyphermox: So we get the mangled names. | 19:34 |
| cyphermox | yes | 19:34 |
| infinity | cyphermox: Then everything after that will be smooth. | 19:34 |
| cyphermox | indeed | 19:34 |
| cyphermox | isn't the renaming done by systemd itself in udev somewhere? | 19:34 |
| infinity | cyphermox: But fair point, if it's just a udev hook or something, it could just be a missing file. | 19:34 |
| cyphermox | we shouldn't have to call something | 19:34 |
| cyphermox | pitti: how does the interface naming logic work? | 19:35 |
| teward | FWIW there was no udev | 19:35 |
| teward | and i had to write an override with my template rules to force it to eth0,eth1 temporarily | 19:35 |
| sarnold | cyphermox: maybe a udevadm settle to make sure that systems with a few thousand drives have finished handling their nics before starting? | 19:35 |
| teward | (to get net up) | 19:36 |
| infinity | teward: Of course there was a udev... | 19:36 |
| cyphermox | I'm pretty sure there was :) | 19:36 |
| teward | infinity: i meant a persistent rul | 19:36 |
| teward | rule* | 19:36 |
| teward | my apologies :) | 19:36 |
| cyphermox | no, that's what's been changed | 19:36 |
| infinity | teward: Right, the installer doesn't write the persistent rule, it's written on first boot. And this new scheme doesn't use it anymore. | 19:36 |
| cyphermox | (AIUI) | 19:36 |
| teward | ok | 19:36 |
| infinity | (Though, if you have one, it wins) | 19:36 |
| teward | infinity: yeah, i wrote one temporarily | 19:37 |
| teward | because i needed networking to come up :P | 19:37 |
| cyphermox | on the installed system you mean? | 19:37 |
| infinity | cyphermox: According to pitti's mail, it's /lib/udev/rules.d/80-net-setup-link.rules | 19:37 |
| infinity | cyphermox: So maybe that's missing from the udeb. | 19:38 |
| infinity | cyphermox: And, looking at the .install file, it sure seems to be missing. | 19:38 |
| teward | cyphermox: correct. | 19:39 |
| cyphermox | teward: ok | 19:39 |
| teward | cyphermox: networking worked fine on the installer | 19:39 |
| teward | it's the generated /etc/network/interfaces where it fails | 19:39 |
| teward | and i either have to rename the interfaces or edit the file | 19:39 |
| teward | and i needed consistency for testing, so i just copied in the template i have on my wily VM too | 19:40 |
| cyphermox | yup | 19:40 |
| teward | s/wily VM/vivid VM/ | 19:40 |
| cyphermox | teward: so you got the newest images from pending? | 19:40 |
| teward | infinity: so it's a missing udev rules? | 19:40 |
| teward | cyphermox: zsyncing now | 19:40 |
| teward | (slowwwwwwwww) | 19:40 |
| infinity | Yeah, looks like it's missing in the udeb. | 19:41 |
| cyphermox | well, I don't think it's going to be fixed right now now | 19:41 |
| cyphermox | infinity: you do the magic? | 19:41 |
| infinity | (And even if it wasn't, it would be missing in d-i) | 19:41 |
| infinity | cyphermox: I can do the fixing, but testing beforehand would be smart. | 19:42 |
| cyphermox | yes | 19:42 |
| teward | cyphermox: infinity: as long as it's on the radar and scheduled to be fixed "soon" i can just edit things to make it work | 19:42 |
| * infinity tears apart a d-i initrd to add the rule. | 19:42 | |
| teward | rather than pester you all for an instant fix | 19:42 |
| cyphermox | infinity: or i'll do the systemd fix and upload to my magical d-i testing PPA | 19:42 |
| infinity | cyphermox: That's way longer tunraround. :P | 19:43 |
| cyphermox | pfff | 19:43 |
| cyphermox | infinity: but it's magic | 19:43 |
| infinity | cyphermox: How is it any more magic than my PPA? :P | 19:44 |
| cyphermox | fwiw, I'm starting to like that overlay trick :) | 19:44 |
| teward | also, is there a reason i can do `shutdown -h now` without sudo now in wily? | 19:44 |
| teward | that seems like a DoS vector IMO | 19:44 |
| cyphermox | were you root? | 19:44 |
| teward | (if someone gains access to an unprivileged account) | 19:45 |
| teward | cyphermox: no, the user that the installer prompted me for the username for | 19:45 |
| teward | let me reinstall and test again | 19:45 |
| infinity | teward: Were you logged in on the console? | 19:45 |
| teward | infinity: yeah, tty1, is that why? | 19:45 |
| infinity | teward: Yeah. | 19:45 |
| infinity | teward: That's no more of an attack vector than you being able to shut down from X locally. | 19:45 |
| teward | i'm going to install openssh on here, SSH locally, and then test again... | 19:45 |
| teward | ack | 19:46 |
| teward | i'm curious if it spills over to SSH at all (and i'mma test) | 19:46 |
| teward | and if it does then THAT'S a bad thing | 19:46 |
| cyphermox | ah, policykit | 19:46 |
| teward | infinity: i do know that it's immediately going to require me to dhclient the thing | 19:46 |
| teward | since the pending iso has the same mismatch in netcfg stuff | 19:46 |
| teward | but that's an easy to test/fix thing | 19:47 |
| teward | now that i know to look for it xD | 19:47 |
| cyphermox | teward: guess you didn't need to pick things from pending, the isos for properly promoted (finally) | 19:49 |
| teward | heh | 19:49 |
| infinity | Hrm. Still eth0 | 19:56 |
| teward | infinity: at least, with 20150710 | 20:03 |
| teward | but meh | 20:03 |
| teward | infinity: remind me again since it's been a while - when uploading something to the repositories (including devel release) it's RELEASE-proposed right? | 20:16 |
| teward | been a while since i've made a merge/upload xD | 20:16 |
| teward | (I should really NOT forget things >.<) | 20:16 |
| infinity | teward: Just $release | 20:16 |
| cjwatson | teRELEASE is fine, it gets automatically redirected. | 20:16 |
| cjwatson | (sigh, lag) | 20:16 |
| teward | heheh two responses | 20:19 |
| teward | infinity: cjwatson: ack, i wasn't sure, last one i have appeared to have -proposed :/ | 20:19 |
| infinity | teward: -proposed will go to the right place, it's just unnecessary. | 20:19 |
| infinity | teward: As a bare SERIES will always be rewritten to SERIES-proposed | 20:20 |
| teward | right, i'll be glad to chop it off when i do uploads and such xD | 20:20 |
| teward | ack | 20:20 |
| yofel | cjwatson: could you please refresh the kubuntu packageset? thanks! | 20:30 |
| cjwatson | yofel: I haven't had permission to do that in quite some time | 20:32 |
| infinity | cyphermox: Hrm. So, adding that udev rule isn't enough to make it happy. | 20:32 |
| yofel | oh ok, who should I ask? | 20:32 |
| cjwatson | yofel: ask somebody in IIRC ~developer-membership-board | 20:32 |
| yofel | ok, thanks | 20:32 |
| cyphermox | really? | 20:36 |
| * cyphermox pulls the relevant stuff | 20:37 | |
| * infinity experiments. | 20:37 | |
| cyphermox | yofel: I can learn to do it now, will have to eventually | 20:38 |
| === Ionic is now known as Guest64021 | ||
| teward | infinity: if an SRU upload is solely adding apport hooks, does it need a corresponding SRU bug? | 20:40 |
| cyphermox | infinity: 99-systemd ? | 20:42 |
| infinity | cyphermox: Yeah, probably, but I doubt we want the whole thing... | 20:43 |
| cyphermox | I don't know | 20:43 |
| yofel | cjwatson: that would be great if you have time :) | 20:44 |
| yofel | erm | 20:44 |
| yofel | cyphermox: ^ | 20:44 |
| cyphermox | yofel: I'm reading the README and apt-getting germinate | 20:44 |
| * infinity tries: | 20:45 | |
| infinity | grep 'SUBSYSTEM=="net"' /lib/udev/rules.d/99-systemd.rules > lib/udev/rules.d/99-systemd.rules | 20:45 |
| infinity | Nope. | 20:46 |
| infinity | teward: Yes, it needs a bug. | 20:46 |
| teward | OK cause there already is one on this | 20:46 |
| infinity | Oh, might need the binary that calls... | 20:47 |
| cyphermox | systemd-sysctl? | 20:49 |
| infinity | Yeah. That didn't solve it for me either. La la. | 20:49 |
| cyphermox | I don't think that's what renames the devices? | 20:49 |
| cyphermox | net.ifnames | 20:52 |
| infinity | Yeah, that's enabled by default in the new systemd (which I'm using). | 20:52 |
| infinity | If it wasn't, we wouldn't have a bug report. :P | 20:52 |
| cyphermox | is it? | 20:53 |
| infinity | Yes. | 20:53 |
| infinity | The patch disabling it was reverted. | 20:53 |
| cyphermox | ok. | 20:53 |
| cyphermox | I'm grepping and not finding anything that seems to set it to 1 | 20:54 |
| infinity | Because 1 is the default... | 20:54 |
| cyphermox | but grep also doesn't return much | 20:54 |
| cyphermox | infinity: do you have a /etc/udev/rules.d/80-net-setup-link.rules on the filesystem? | 20:56 |
| infinity | cyphermox: Yes. | 20:56 |
| cyphermox | hmm | 20:56 |
| infinity | cyphermox: Bingo. | 21:10 |
| infinity | cyphermox: Got it working, now I need to figure out how much of this I can delete again. :P | 21:10 |
| cyphermox | cool | 21:12 |
| cyphermox | what was it? | 21:12 |
| infinity | 75-net-description for sure | 21:12 |
| infinity | And maybe other bits. | 21:12 |
| infinity | Deleting one by one until I break it. | 21:12 |
| infinity | 99-systemd was useless, thankfully. | 21:13 |
| infinity | cyphermox: http://paste.ubuntu.com/11858147/ is my final initrd diff. Running through a full install now to make sure the installed system has the same names as d-i. | 21:18 |
| infinity | cyphermox: Then I'll upload systemd and then d-i. | 21:18 |
| cyphermox | looks about right | 21:19 |
| cyphermox | I didn't know we had files there for systemd | 21:19 |
| infinity | We didn't until just now. :P | 21:19 |
| cyphermox | well, I mean on the installed system :) | 21:20 |
| cyphermox | didn't remember about the links | 21:20 |
| infinity | cyphermox: The systemd/network stuff defines the naming policy. | 21:21 |
| cyphermox | yeah | 21:21 |
| infinity | Why it's in lib/systemd instead of lib/udev, I don't know. | 21:21 |
| infinity | But yay for merging the projects. :( | 21:22 |
| === Guest64021 is now known as Ionic | ||
| cyphermox | ah, that's because it's some magical systemd config rather than magical udev config | 21:26 |
| cyphermox | :) | 21:26 |
| infinity | cyphermox: Sure, the syntax is systemdish, but it's read by udevd. | 21:27 |
| infinity | (Clearly, since we don't have systemd in the initrd) | 21:27 |
| infinity | Oh, hrm, probably want to fix this for the initramfs hook too. | 21:29 |
| infinity | cyphermox: http://paste.ubuntu.com/11858246/ <-- Look sane? | 21:37 |
| cyphermox | yeah, looks sane | 21:38 |
| infinity | smoser: Is cloud-init a systemd service? | 21:43 |
| infinity | smoser: If so, it's probably missing some magic to let it attach to a console. | 21:43 |
| smoser | infinity, yes, it is a service. | 21:47 |
| smoser | and has | 21:47 |
| smoser | StandardOutput=journal+console | 21:47 |
| infinity | smoser: Are you opening /dev/console to read or write? | 21:48 |
| smoser | that is in cloud-final.service . and that service runs, and then explicitly opens /dev/console and writes to it. | 21:48 |
| infinity | (And why not just use stdio?) | 21:48 |
| sarnold | why /dev/console instead of e.g. /dev/tty? | 21:48 |
| smoser | well | 21:49 |
| infinity | Not /dev/anything, ideally, just trusty that stdout is the right place. | 21:49 |
| smoser | a.) thats not a bad argument | 21:49 |
| smoser | b.) but it doesn't explain "sometimes" | 21:49 |
| infinity | If you're telling system to redirect your stdout to console, then... | 21:49 |
| infinity | s/trusty/trust/ | 21:49 |
| infinity | That release ruined me. | 21:49 |
| smoser | c.) writes to stdout of a service like that get prefixed with systemd job status | 21:49 |
| smoser | which is undesireable | 21:49 |
| smoser | if it failed everytime, then i'd absolutely agree with you | 21:50 |
| teward | cyphermox: infinity: thank you both for looking at it :) | 22:16 |
| teward | (the systemd, network interface naming algorithms not matching thing) | 22:16 |
| === salem_ is now known as _salem | ||
| infinity | teward: https://launchpad.net/ubuntu/+source/systemd/222-1ubuntu2 | 22:23 |
| teward | i saw the fix committed messages go out :) | 22:24 |
| teward | *looks* | 22:24 |
| infinity | Oh, FFS. FTBFS. Maybe I should have tested. | 22:24 |
| teward | failed on arm64 | 22:24 |
| cyphermox | there will be more explosions. | 22:25 |
| teward | infinity: cyphermox: And this, my friends, is why I don't mess with the core packages much xD | 22:25 |
| cyphermox | teward: it's not just going to fail on arm64 | 22:25 |
| teward | cyphermox: indeed | 22:25 |
| teward | cyphermox: it was loading the other images was all | 22:25 |
| teward | you're right though | 22:25 |
| teward | even so, thank you, cyphermox and infinity, for taking a look at it so rapidly | 22:25 |
| cyphermox | ah. it's from debian/extra | 22:29 |
| teward | infinity: unrelated: how long does it take for an SRU to show up in the sponsoring list | 22:37 |
| teward | or rather on any lists | 22:37 |
| teward | (i forgot since i have upload it goes right past 'sponsorship' xD) | 22:38 |
| infinity | teward: You get an email. But <= 5 minutes. | 22:38 |
| teward | infinity: no, i meant once it lands in the uploads queue | 22:40 |
| teward | i already got the "awaiting accept" | 22:41 |
| infinity | teward: Well, that is "the list". | 22:41 |
| teward | (in other news, the wily package with the nginx apport hooks is there, so now I can relax with regards to Wily coming forward) | 22:41 |
| infinity | teward: From there, a human needs to get around to reviewing it. | 22:41 |
| teward | infinity: right, i was curious what average wait was on that, if only to stop getting crap vivid 'postinstall failed' bugs | 22:41 |
| teward | but that's not as big an issue, i can wait :) | 22:42 |
| cyphermox | teward: isn't it good already? | 22:42 |
| cyphermox | https://launchpad.net/ubuntu/+source/nginx/1.6.2-5ubuntu4 | 22:42 |
| teward | cyphermox: -5ubuntu4 is wily | 22:42 |
| infinity | cyphermox: He SRUed it too. | 22:42 |
| teward | cyphermox: switch to Vivid - -5ubuntu3.1 | 22:42 |
| cyphermox | sorry, I misread | 22:42 |
| teward | cyphermox: that's why i said it's there for wily. it's awaiting review for Vivid | 22:42 |
| teward | no problem :) | 22:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!