[01:39] teward: I think most packages instead ship the file using their install files [01:39] cyphermox: infinity said dh_apport / dh_installapport so eh [01:39] cyphermox: i'm trying to ship inside the .install files but apparently it's not included in the .deb [01:39] unpacking the binaries yields the file not being present [01:39] ie. usb-creator ships source_usb-creator.py to usr/share/apport/package-hooks [01:40] my info may be outdated, or most packages may need to be updated :) [01:40] 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:41] or you could ship just one for the source package [01:41] either way works, but having just one is probably better if it turns out to be the same file for each binary [01:41] ... true... but then i run into the -dbg packages getting it, and the -common package getting it [01:42] 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] 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:43] * teward shrugs [01:45] how's your rules? === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ [02:21] teward: I never said anything about dh_apport, I only pointed you to the manpage when you asked how it worked. :P [02:21] ahhh [02:21] infinity: okay, then i misunderstood [02:21] teward: It's perfectly reasonable to install it by hand, either with dh_install or cp. :P [02:21] heh [02:22] infinity: then i misunderstood you, I apologize [02:22] 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] infinity: and apport will understand source_nginx.py applies for nginx*? [02:22] or rather, automatically know it refers to all binaries? [02:22] or am I gonna have to postinst script it for -common? [02:23] (for symlinks anyways) [02:27] teward: apport knows to map binary->source in some fashion. I forget what that fashion is. :P [02:27] heh [02:27] i know i have it working for Vivid to cp the .py into where it needs to go... [02:27] Oh, it's just source_$package.py ... That's simple enough. [02:28] ... but I'm having a hard time figuring out why the same codechanges don't work in WIly [02:28] and it's one of those headscratcher moments [02:28] 'cause i've been beating it all day [02:28] 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:29] infinity: any special consideration with regards to debian/rules and the package itself, other than the install of the .py ? [02:30] 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] teward: So, just put it in nginx-common.install or whatever. [02:30] ack [02:32] i'll poke at this tomorrow [02:32] i'm waaay too tired to test things xD [02:32] but thanks for clarification and more insights :) [02:32] 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:33] actually... was that you, infinity, who helped solve that, or was it someone else? [02:33] I forget, i interact with so many people xD [02:35] Sounds like something I'd do. [02:35] well, in either case, those changes made their way into debian [02:35] good [02:35] 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:36] i forget... DAMN now I want to dig into the changelogs [02:37] hmm, maybe it was just Vivid... [02:37] yep, SRU'd to vivid... *shrugs* [02:38] anyways, thanks for the direction points to look at, infinity and cyphermox. [02:38] no worries [02:38] and as always, thanks again to all who help out with these things :) [02:38] because i think i'd have thrown the nginx package into oblivion by now xD [02:39] teward: we all eventually break things, trick is to know, accept it, and fix it :) [02:40] cyphermox: and acknowledge that when you aren't sure how to fix, you and and likely should ask for help XD [02:40] 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] i try and stick to my local sbuild for that xD [02:40] although I sure remember when I was one of those newbies xD [02:40] some things are really hard to properly stage without a PPA [02:41] or sbuild and a local VM [02:41] which is what i've been doing all day XD [02:41] (or, I should say, without a PPA if you don't want to spend hours setting up infra) [02:41] yeah, I noticed [02:41] building, testing, building, testing, shredding, building, testing xD [02:41] fwiw, sbuild-launchpad-chroot is pretty cool to get you nice up-to-date chroots quickly [02:41] 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:42] it just says "Job failed, refer to [two other commands] for details." [02:42] for service failed to start problems [02:42] and with nginx Vivid, we had... *pulls list* [02:43] ... at least six or seven... bugs that are ambiguous as all hell since there's no usable debug info [02:44] hence my getting up off my butt, deprioritizing the nginx Wily merge prep, and working on this apport hook stuff :/ [02:45] 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] anyways, i'm off, good night === salem_ is now known as _salem [03:39] Good morning [03:40] teward: it's dh_apport, but yes [03:40] teward: man dh_apport [03:41] teward: either ship a source_.py which applies to all binaries, or a .py and perhaps symlinks for the other packages [03:41] teward: it's all in /usr/share/doc/apport/package-hooks.txt.gz [03:42] teward: we never grabbed job start errors in apport [03:42] only indirectly via package install failures, but their logs didn't contain syslog or upstart logs by default either [03:42] makes sense for a package to include theirs, of course [03:43] that's why we have apport hooks [06:14] why aren't packages like libuid-wrapper synced from debian to wily? [06:14] hmm nevermind [06:14] realized that it's probably in universe instead [06:14] and in vivid too :) [06:15] so sssd needs it in main [06:16] libnss-wrapper too [06:17] when are we going to get rid of main/universe split again? [06:19] tjaalton, once we MIR every package? [06:20] no [06:20] there's an old blueprint about it [06:21] huh [06:23] https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-finish-archive-reorg [06:25] cjwatson: is this ^ again in the horizon now that lp is getting more love these days? [06:35] good morning [09:02] pitti: piiing [09:02] hey sil2100 [09:03] pitti: hey, again me and again regarding translations (as I'm assuming you have more knowledge than I do here) ;) [09:03] pitti: a strange thing happened [09:03] Around the beginning of the week we had an ubuntu-system-settings released to vivid and wily with a string change [09:03] It changed "Install & Restart" to "Restart & Install" [09:04] 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] Didn't we import all the new strings to templates yesterday? [09:06] https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-system-settings/+imports indicates there are not be template import for the recent builds [09:08] oh right, latest from May [09:08] pitti, ? [09:08] " Uploaded by Steve Langasek on 2015-07-02 19:35:20 CEST " [09:09] pitti, weird thing is that the most recent package build [09:09] https://launchpadlibrarian.net/210643779/buildlog_ubuntu-wily-amd64.ubuntu-system-settings_0.3%2B15.10.20150703-0ubuntu1_BUILDING.txt.gz [09:09] has [09:09] " 69979f587d60fac3711adab7320a0700ceac2ac7 1655913 ubuntu-system-settings_0.3+15.10.20150703-0ubuntu1_amd64_translations.tar.gz" [09:10] sorry, https://launchpadlibrarian.net/211136452/buildlog_ubuntu-wily-amd64.ubuntu-system-settings_0.3%2B15.10.20150708-0ubuntu1_BUILDING.txt.gz [09:11] but launchpad doesn't have it [09:12] pitti, http://paste.ubuntu.com/11854869/ [09:12] hmm [09:12] works on 0.3+15.10.20150622-0ubuntu2 though [09:12] wgrant: do these imports only happen from the time on when these magic check boxes get unchecked? [09:12] so it's like launchpad didn't get the translations tarball [09:13] yesterday I got asked to fiddle with https://translations.launchpad.net/ubuntu/wily/+translations-admin , maybe that did the trick? [09:22] pitti: No, those checkboxes only delay Approved entries from being imported. === vrruiz_ is now known as rvr [09:26] hmmm [09:27] tjaalton: not currently scheduled [09:27] cjwatson: ok [09:28] wgrant, any idea why the most recent ubuntu-system-settings builds don't have their translations tarball in launchpad? [09:28] 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] where it's there for the older uploads [09:30] tjaalton: (and it's Hard, so would need a significant slot of time) [09:30] seb128: perhaps related to it being in universe? [09:31] cjwatson, it always was in universe [09:31] this may be irrelevant, it's hot and I'm really not very awake [09:31] universe hasn't been relevant since oneiric. [09:31] https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-system-settings/+imports has recent imports [09:31] since it stopped importing for a week or so [09:32] cjwatson: understood [09:37] seb128, pitti: Ah, got it. [09:37] seb128, pitti: The new tarball ended up in the 2015-06-25 queue item [09:38] ? [09:38] That's correct. [09:38] how come [09:38] Also correct. [09:39] 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] In this case, it apparently decided that updating the third newest one was a grand idea. [09:39] So the newest one, which wasn't updated, got imported over the top of the actual new template. [09:44] Copying the package back in may fix it, but I forget in which scenarios the custom copier hack applies. [09:45] All copies, pretty much. [09:45] Even a copy that actually does nothing because it already exists? [09:45] Think so, let me check [09:45] Good lord. [09:47] Yeah, the copier doesn't bail out early or anything, that would be clever. [09:47] 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] sigh [09:47] But handy in this case :) [09:47] Oh yes, certainly. [09:47] Batshit *and* useful. [09:47] The best kind of batshit insanity. [09:47] (I can say that since I'm reasonably sure it was my fault.) [09:48] I've actively ignored the custom upload copier since long before you came onto the scene. [09:48] But indeed the packagecopier integration was at your hand. [09:51] seb128: So indeed it seems that copying the package over itself will fix it. [09:53] Ohhhhh [09:53] It chose that entry because it matches on the importer. [09:53] That is the second most stupid thing I've seen today. [09:53] After the custom upload copier :) [09:55] cjwatson: Do you have any idea why Translations attempts to update existing entries? [09:55] It goes back more than nine and a half years, so I doubt it, but you have the benefit of a heat-addled brain. [10:04] wgrant: None whatsoever, I tried as hard as I could to ignore Translations for many years [10:04] Heh, yes... [10:04] (Which often wasn't very well, but the extent to which I touched it was entirely client-side) [10:05] Speaking of Translations, I think I can turn on ubuntu-rtm/15.04 imports now, if that's OK with you. [10:06] 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] Given that that would push the first hacked import well into Saturday morning, I'm tempted to reblock those wily imports. [10:24] Can someone point me in a direction how to prevent from a black screen, while ubuntu switches from plymouth to the unity desktop? [10:25] 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] On our system it needs 12 seconds, till the desktop is up and our fullscreen app is visible. [10:27] cjwatson: No, I just don't want the first import to happen as the US sysadmins disappear for the week. [10:27] cjwatson: For that reason I'm half way through reblocking the wily templates that I had unblocked. [10:30] wgrant: Oh, right. 15.04 should be much quicker, so I might go ahead with at least one of those. [10:30] Actually, there are only nine templates here, how bad can it be. [10:31] cjwatson: Yep, but they wouldn't have processed until tomorrow morning wile whily had translations approved. [10:31] Yeah [10:32] My only concern is that the first overlay import not occur while we have nobody around to fix any explosions. [10:32] 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 [11:05] doko: looks like pcre3 needs some work, std::basic_string in exported symbols [11:05] Laney, you mean, in the ppa? [11:06] I did a test build against the ppa [11:07] 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] Debian bug 791236 in src:pcre3 "pcre3: library transition may be needed when GCC 5 is the default" [Important,Open] [11:08] sure [11:08] I will use a non archive version then though [11:08] no, we will copy it to the archive [11:09] not if it fails to build [11:09] ?!?! [11:09] well, upload a version to the ppa that does build =) [11:09] you probably want the maintainer to decide what to do [11:10] http://paste.debian.net/281022 [11:11] they don't have the symbols file in debian btw [11:12] can you leave a comment in the report? [11:16] ok [11:20] 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:25] Mirv: Curious. Will look once I get logs extracted via webops. [11:27] 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:40] cjwatson: hmm, this amd64 build is also hung, and I'd want to cancel and rebuild it properly (without reuploading) [11:41] this = https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7638376 [11:41] Mirv: there's lots of firewall-level trouble at the moment. [11:41] Mirv: but you can try a cancel there and cross your fingers [11:45] Mirv: I see no indication that build is hung. [11:46] However, if there are network issues, buildd-manager might have "lost" the buildd, and might need a restart. === _salem is now known as salem_ === MacSlow is now known as MacSlow|lunch [11:55] cjwatson: ok. well I can also see if it at some point finishes by itself [11:55] infinity: it usually takes 2h for that to build so I assume it has stayed at that point for the last 4 hours. [11:56] Mirv: Yeah, I'm fairly sure the build itself is complete (on the buildd), it's that LP is failing to care. [11:57] Mirv: And it seems there are larger issues afoot relating to that, so I'll let wgrant/cjwatson put out their fires. [11:57] Right, I would suggest leaving things well alone at the moment. [11:57] Our slave DB server is rather suspiciously doing nothing at all. [11:57] 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:58] Mirv: So, all that's left to do is for the master to suck up the results and do things with them. [11:58] And at least some connections to it are crashing. [12:02] infinity: yeah, leaving it alone seems right in case LP then gets back to business of getting the results [12:18] pitti: just one catch with that [trusted=yes]. I wonder if it is available in Precise? [12:41] rbasak: trusted=yes works in precise (just tested) [13:01] infinity: oh, great. Should be no issue then. Thanks. [13:02] 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] bug 1455097 in pm-utils (Ubuntu) "pm-suspend no longer run since upgrade to vivid" [Medium,Confirmed] https://launchpad.net/bugs/1455097 [13:10] rbasak: yes, I checked precise's apt-sources manpage, seems to be there [13:11] 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:12] rbasak: so we could check which of the bits are really still needed, and link them from there === salem_ is now known as _salem === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [14:50] 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] Or is this suspicious on the grounds that it should have been preselected? [14:51] 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] (the case of nginx-common failing its postinstall is different than nginx-* binary installs and doesn't need the same data) [14:51] cjwatson: Oh, hm, I guess auto-approval won't work without the templates already existing. [14:51] teward: report['Package'].split()[0] (to cut off the version number) [14:51] thank you kindly :) [14:52] 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] I manually approved the unity-scope-click template to see if it would import, and it did,. [14:52] Yeah, that won't be a problem. [14:53] I forget if the POs will be automatically approved into the right place once the template is. [14:53] pitti: ack [14:55] 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. [15:00] * pitti waves bye and good weekend! [15:01] bye pitti! [15:02] see ya pitty! [15:03] pitti* [15:03] i hate autocorrect [15:04] wgrant: Not too bad if it's just templates, although as yet nothing has auto-approved the POs. [15:05] cjwatson: They may not be autoapproved, though the gardener is slow and runs infrequently. [15:06] If it ends up being a problem, trivial exports of IPOFile and IPOTemplate are not intractable. [15:08] Yeah. I'll approve the templates and see what happens. [15:08] Just opening the import form and hitting save DTRT, annoyingly [15:19] cjwatson: fsvo trt [15:19] cjwatson: Templates only share if the name is the same on both ends, but hopefully nobody's done anything weird in Ubuntu. [15:19] Perish the thought. [15:24] wgrant: With only POTs imported, a few spot checks are at least showing a respectable amount of green. [15:25] I'll check in tomorrow or something to see if the gardener did anything. [15:50] 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:57] hjd: Yes, those should have been dependency waits but were bitten by a known launchpad-buildd bug. Both retried. [16:03] cjwatson: Thanks :) [16:35] I think I just accendentally uploaded a package to upload.ubuntu.com (although I'm not sure how that even succeeded anonymously) [16:35] how can I remove that again? [16:37] Ionic: What package name? [16:37] Ionic: It will almost certainly just be harmlessly rejected, but let's check. [16:38] dput anonymous uploads are fine; it's the signature that matters, and that's checked later. [16:39] cjwatson: cups-x2go [16:39] trusty [16:39] the signature is probably known [16:40] Known to Launchpad doesn't necessarily mean it'll be accepted for an Ubuntu upload :) [16:40] I hope so [16:41] 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] 2B not registered in launchpad. [16:41] And a binaryful upload would have been rejected later anyway. [16:42] So you're fine [16:43] great! thanks [16:43] although it's weird that the key wasn't accepted [16:44] Doesn't seem to be on keyserver.ubuntu.com [16:44] And it would have to be specifically associated with a Launchpad user as well [16:46] not sure what the project has as a key [16:46] normally Ubuntu packages are being built in launchpad anyway, but maybe with a special key [16:47] OK, but that's presumably for a PPA or something anyway [16:48] yep [17:41] where should I drop a wily udev naming algorithms question (for network interfaces) [17:41] here or -quality? [17:41] or #ubuntu+1 === josepht` is now known as josepht [18:08] hello [18:13] xnox are you here? [18:13] xnox I have posted a comment on bug #1326412 to your attention: [18:13] 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] https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1326412/comments/5 [18:14] 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:15] no solution here except maybe lock the packages, which is what I am now testing. [18:16] melodie: let me just check to make sure everything. [18:16] melodie: in trusty, this works correctly when booted with upstart. [18:16] melodie: are you booted with upstart or systemd? [18:17] (e.g. systemctl is-system-running vs initctl version) will tell you. [18:17] initctl --system version; to be more correct. [18:17] xnox I don't know how I can boot to upstart, and even worse, in a chrooted environment [18:18] melodie: if you have a bug with [18:18] melodie: if you see a bug in a chroot, this is a different bug then! [18:18] melodie: although probably looks like this one =) [18:19] xnox I can understand the "upgrade to next version" thing, idea, but with a LTS? seriously? [18:19] pelase file a new bug with $ ubuntu-bug against well i guess ubuntu-release-upgrader and describe what you are seeing. [18:19] wait [18:19] melodie: all upgrades must work from Trusty, when trusty is booted with upstart. [18:19] melodie: and we believe they do. [18:19] I don't do upgrade I do dist-upgrade [18:20] how do we get it to boot with upstart? [18:20] melodie: if your host is trusty, and booted with systemd, that is entirely unsupported. [18:20] melodie: first check what you are booted with. [18:20] melodie: on the host, do $ initctl --system version [18:20] if that says upstart, you are booted with upstart. [18:20] I'll do [18:21] melodie: to boot with upstart, you need to specify init=/sbin/upstart or remove systemd-sysv package. [18:21] as soon as the actual update ends (I redid the environment) [18:21] remove systemd-sysv ? that's all it takes? [18:21] 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:22] 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] xnox how is the setup done in the officiel Trusty versions? [18:22] melodie: if you install trusty, you get upstart as pid 1, yet there are pieces of systemd daemons running. [18:22] it seems that the systemd packages are installed there, aren't they? [18:23] e.g. udev & logind are daemons provided by systemd package. [18:23] yes they are :) [18:23] melodie: systemd is a lot of daemons. In trusty, only udev & logind are used by default. [18:23] I'll check to remove systemd-sysv once synaptic (chrooted synaptic) will have finished. [18:24] 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] 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] and then doing upgrades with systemd as pid 1. [18:24] well here there is systemd-services installed and if I try to remove it, half of the system is going away [18:24] with it [18:24] 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] melodie: do not remove systemd-services. [18:25] I'll do initctl --system version as soon as synaptic finishes [18:26] melodie: yeap. if that says upstart open a new bug report. If that errors out like so: [18:26] $ initctl --system version [18:26] initctl: Name "com.ubuntu.Upstart" does not exist [18:26] then you are booted with systemd as pid1, and you really want to get off that on 14.04 LTS. [18:27] 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] this is what it says [18:27] your dbus seems to be dead.... [18:27] I'll try to start it manually [18:28] melodie: you can check unix domain sockets with e.g.: [18:28] $ netstat -n | grep upstart [18:28] there should be one for system upstart. [18:28] prompts comes back silent [18:28] # service dbus start [18:28] initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused [18:28] also [18:28] =( [18:29] do you have $ ls /run/systemd/system ? [18:29] if that folder exists, you have pid1 as systemd. and should get off it. [18:29] cat /proc/cmdline might be a clue as well. [18:29] looking [18:30] (not having system dbus sounds like a really broken system, FYI) [18:30] # ls /run/systemd/system [18:30] ls: cannot access /run/systemd/system: No such file or directory [18:30] i'd be tempted to say your machine is hosed. [18:30] and i wonder if it will reboot. [18:30] # cat /proc/cmdline [18:30] root=/dev/sda3 resume=/dev/sda5 vga=775 ro [18:31] well this is a chroot [18:31] it won't reboot, it's not meant to reboot [18:31] .... [18:32] melodie: then please open a new bug against a package that failed to upgrade with your dist-upgrade log. [18:32] melodie: bug you commented on, has nothing to do with a chroot upgrade problem. [18:32] ah [18:32] melodie: but if your host is running systemd, the chroot is unsupportable. [18:32] melodie: i need to make sure the host is not running systemd. [18:33] as pid 1 that is. [18:33] I think I can check for systemd-sysv and remove it if it exists [18:33] it doesn't matter what is installed in the chroot... [18:33] how is that? [18:33] I mean, I'll make eventually an iso [18:34] then, if systemd-sysv is not installed it's better for the further use? [18:34] you lost me. [18:34] melodie: If you're having problems upgrading a chroot, systemd-sysv is irrelevant. [18:34] melodie: But, sure, if that chroot is meant to become a live filesystem later, it shouldn't have systemd-sysv installed. [18:34] melodie: But I doubt it does. [18:35] hi infinity [18:35] I just checked, not only it's not installed but it's not even in the packages list in Synaptic [18:35] melodie: Okay, so I saw your comment on the end of LP: #1325142 [18:35] 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:36] melodie: That has nothing to do with any packaging bug, it's that you're in a chroot environment. [18:36] 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] 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] melodie: And your chroot should have a policy-rc.d to prevent invoke-rc.d from running at all. [18:37] 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] (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] xnox: It's a chroot because they're building a new root filesystem. [18:38] melodie: http://paste.ubuntu.com/11857389/ [18:38] 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] melodie: (stolen from mk-sbuild) [18:38] infinity thanks! [18:38] melodie: Toss that in your chroot at the beginning of your build process. Delete it at the end. [18:38] melodie: Any installs/upgrades during your build will then be no-ops. [18:39] infinity I see the content, that's nice! [18:39] I might put it in the chroot/tmp directory [18:39] 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:40] didn't think of vivid host, trusty chroot. [18:40] so I don't need to remove it at the end (or I might forget) [18:40] melodie: Err, it needs to be /usr/sbin/policy-rc.d or it won't work. [18:40] melodie: And it needs to be removed before you ship, or your final system won't work. :P [18:41]