[02:33] darkxst ugggh. I've been fighting this for a while. Google finds lots of stuff, but not what I need. I cannot install my gdm package: http://paste.ubuntu.com/10727964/ [02:34] darkxst I am installing to Ubuntu-Gnome vivid live-cd "Try Ubuntu" [02:36] (In a virtual machine) [02:40] aeoril: gir1.2-gdm-1.0 appears to be built from the gdm source package: Y [02:40] aeoril: https://launchpad.net/ubuntu/+source/gdm [02:40] aeoril: did you copy over those binaries too when testing? [02:40] sarnold no [02:41] you'll need to include it onthe same dpkg -i command.. [02:42] sarnold omg I see now - there are several .deb files created from sbuild - I guess I need to install all of them, not just he one for gdm? [02:44] aeoril: in this case, yes; sometimes they'll spit out cohnflicting packages, like nginx-full vs nginx-tiny, etc. and picking just the ones you want to test is the right answer.. [02:44] aeoril: but it's surprisingly easy to miss other binary packages that don't match source*deb glob :) [02:45] sarnold there are 4 of them - gdm_3.14.1-0ubuntu3_amd64.deb libgdm1_3.14.1-0ubuntu3_amd64.deb gir1.2-gdm-1.0_3.14.1-0ubuntu3_amd64.deb libgdm-dev_3.14.1-0ubuntu3_amd64.deb - do I instal all four of those? [02:47] you only need the first 3 [02:48] aeoril: you can skip the -dev package unless you want to compile code on the test machine that links against libgdm.. [02:48] sarnold ok, thanks [02:50] sarnold cool! That worked, and thanks again! Tested, and now I can attach the debdiff to the bug and claim victory! :) [02:51] :D [02:51] aeoril: very nice :) [02:51] sarnold the bug has not been set to "triaged" - it is still confirmed, undecided, unassigned. Does someone need to set it to triaged? I don't think I can [02:52] sarnold should I just make a new comment - "Fixed - see attached debdiff" and let others take care of all that? [02:52] sarnold (I will add proper info to the comment of course) [02:52] aeoril: be sure to detail what testing you've done in the comment.. [02:52] aha good ;) [02:53] sarnold this is my third! [02:53] aeoril: the actual bugstate is probably less important than getting the fix attached and describe the testing done, etc [02:53] aeoril: dude! [02:53] aeoril: that's awesome :) you've been busy [02:54] sarnold no, not at all - I had to stop from March 1 until today, but am back at it as of this afternoon [02:54] aeoril: wow, was that really so long ago? [02:54] I have no idea how it became april so quickly. or march.. [02:55] sarnold yah, a month and a day since March 1! [02:55] aeoril: well I'm glad to see you're back, then :) [02:55] stuff happens :) [02:56] I just took up exactly where I left off - kind of amazing how it all fell into place on this bug today. But darkxst has been giving me "trivial" bugs so I can get myself aquainted with packaging and stuff like that, so they really have not been too bad [02:57] after the firstone, most bugs will feel more trivial .. :) [02:58] sarnold I have really learned a lot, but it takes some time. I have had to test each bug differently and that has been probably the biggest challenge [02:58] learning how to build and test and all that [03:03] aeoril: yeah, quite often each one requires something slightly different [03:03] it's a fun way to stay flexible :) [03:17] sarnold you want to look over my patch/comment? https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1315442 [03:17] Launchpad bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] [03:21] sarnold darkxst I may not be done with this - it needs to be fixed in trusty too - however, the line number is different that needs removing - line 78 in trusty, not line 73. How would I go about doing that? Just make the fix and debdiff for trusty, then add another comment/patch to the bug and indicate it is for trusty? [03:21] aeoril: the patch is nice and short.. I do wonder if the 'right' fi was removed, so the indenting is left nice and pretty.. I don't see a similar gdm.init on sources.debian.net though, hehe [03:21] aeoril: exactly that :) [03:22] sarnold yes, I specifically elided the correct 'fi' to leave indenting correct :) [03:22] aeoril: sometimes you can get a patch to apply "with fuzz" to different versions, but since this patches a file in debian/ there isn't a standalone patch to work with.. and for one line, it isn't a big deal to recreate it.. [03:22] aeoril: yay :) [03:22] sarnold ok, I'll do that tomorrow [03:23] aeoril: I always like to hand-inspect the debdiff.. sometimes it includes a lot of unrelated stuff. it's a good habit to get into to skim the raw debdiff, when it makes sense to do so.. [03:23] (for simple fixes it almost always will make sense :) [03:24] sarnold I carefully checked the debdiff manually [03:24] :D === gusnan is now known as Guest79913 [05:10] slangasek: Around? [05:20] infinity: hi [05:24] slangasek: Sanity check on http://paste.ubuntu.com/10728501/ before I upload and self-accept? [05:25] slangasek: Context, swift (and other packages, I'm sure, but swift is where I noticed) installs init.d scripts with --no-start, and systemd isn't aware of them existing as "services" until either a reboot or a daemon-reload, which then causes swift's autopkgtests to fail. [05:25] infinity: is there a bug report for this? [05:25] slangasek: Originally, I was going to fix this in the autopkgtests as a hack, but then it just seemed obvious to me that an init.d script that systemd isn't aware of is a bug in systemd, hence the trigger. [05:25] slangasek: Dunno. Maybe. I was cleaning up test failures. [05:27] slangasek: Anyhow, tested and does what I expect for both old and new triggers. [05:27] infinity: I'd rather not be hasty with changes here; it's quite possible that pitti or someone is already planning to fix this somewhere else. Is the test failure currently blocking? [05:27] slangasek: It's blocking one other package, and now that I know the root cause, I could let that package pass. *shrug* [05:28] infinity: I'd highly prefer to have pitti review this before upload, I don't want folks working at cross-purposes [05:28] slangasek: But the only other place this could be fixed is dh_installinit, which would require a rebuild of every --no-start init-script-shipping package, which seems silly. [05:28] not necessarily; maybe update-rc.d should be doing it? [05:29] And if you install an init script without rc.d links? [05:30] Which isn't a terribly normal thing to do, granted, but... [05:30] then you're in violation of policy, go directly to policyjail do not collect 200 policydollars [05:33] slangasek: To be fair, I just skimmed, but I don't actually see anythign that says I must have links, only that I must control them with update-rc.d if I do. [05:34] slangasek: Still, a weird thing to do, and yes, update-rc.d would cover the places I've run into the bug. [05:34] slangasek: Though it would actually run more often than the trigger. [05:34] slangasek: So, not exactly an optimisation. :P [05:34] * slangasek nods [05:35] slangasek: Anyhow, I'll give pitti a poke for a review and his thoughts on the matter, maybe with some copy and paste from this conversation. [05:37] infinity: ok, cheers. fwiw I feel like I did hear something about this exact issue recently, but can't pin down the context of it [05:38] slangasek: I'd been chalking the swift failure up to "the tests don't systemd correctly" until I got annoyed enough to investigate today, and instead came to the conclusion that systemd (as implemented in Debian/Ubuntu) doesn't sysv correctly. [05:38] slangasek: But yeah, I wouldn't doubt it's come up before. [06:13] aeoril, trusty would need a seperate debdiff , although I not entirely sure it warrants an SRU, it is only a warning isnt it? [07:23] slangasek, infinity: we discussed that on #debian-systemd a while ago when another DD ran into this issue [07:23] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774799 [07:23] Debian bug 774799 in sysv-rc "sysv-rc: Unit my-service.service failed to load: No such file or directory, using install from source + update-rc.d" [Important,Open] [07:24] I think I slightly prefer that update-rc.d calls daemon reload [07:26] let's see what pitti thinks [07:49] mbiebl: Any reason for the preference? It's more performant as a trigger. [07:50] infinity: someone might install a non-deb package, still using update-rc.d to register the init script [07:50] I also vaguely remember, dpkg-triggers were somewhat problematic with conffiles [07:50] (although that might be outdated nowadays) [07:51] mbiebl: The trigger worked fine in my testing, but I guess the non-deb thing maybe applies. I figure that's about as likely as a crappy in-house deb that installs an init script and doesn't use update-rc.d, though. ie: both are somewhat likely, neither are worth catering to. [07:52] mbiebl: I'm not super picky about the solution, mind you, but I do think it's RC for both vivid and jessie. [07:52] infinity: have you seen the bug report? [07:52] it was about git cloning fusionforge [07:52] mbiebl: Yeah, I read the report just now. [07:52] running make post-instlal [07:52] i.e., no dpkg involved here [07:52] mbiebl: Right, fair point. [07:53] infinity: I agree about the RC-ness of the bug though [07:53] mbiebl: One could perhaps argue for both the trigger and update-rc.d involvement, to catch both not-normal-package cases, but there's always the corner case of unpackaged-and-also-not-using-our-tools. [07:54] mbiebl: The RCness, IMO, is only for it misbehaving with Debian packages, mind you, I think it's just Very Unfortunate if we can't fix a few non-archive cases at the same time. [07:55] mbiebl: The only way to catch them all would be an inotify watch in systemd itself, which I assume you'd object to, or upstream would, or both. [07:55] inotify is not without problems [07:55] and yes, upstream, rejected that so far [07:56] The only real inotify problem I run into is overlayfs not implementing it. [07:56] But it still beats "you must know this magic invocation if you install an init script". [07:56] Whether the magic is update-rc.d or sysctectl daemon-reload or whatever. [07:57] THough, I suppose most would just get frustrated and reboot, and it would magically work. :P [07:58] iirc, for native services, systemd will implicitly check if you start a service which is not loaded yet [07:58] mbiebl: But I take the point about github-style deployments that think package managers suck. [07:58] and do a reload then [07:58] we could maybe do the same for sysv init scripts [07:58] that wouldn't catch changed init scripts though [07:58] only new ones [07:58] mbiebl: Yeah, for native units, it checks for the file. I suppose one could extend that to "if the native file isn't found, see about an init script, you doofus". [07:59] mbiebl: Does it actually cache init scripts? That would be insane. I assume it just maps an internal service to the path on disk, and still forks them. [07:59] mbiebl: So, changing them should work fine. [07:59] mbiebl: I could be wrong, but the idea that it's caching /etc/init.d/* seems insane. [08:00] for /etc/init.d, it runs a generator [08:00] see /run/systemd/generator.late/ [08:00] darkxst it is a "Syntax Error" [08:01] mbiebl: Right. Ahh, sure, it wouldn't catch changes to LSB headers, I guess. [08:01] aeoril, does it break the sysv init script? [08:01] mbiebl: But that's a small and unfortunate corner case that doesn't matter much at runtime anyway, only at boot. [08:02] mbiebl: And at boot, it'll re-run the generator. [08:03] infinity: at this point, I'd prefer a least invasive change. running daemon-reload in update-rc.d would fit that bill imho and be good enough [08:03] * LocutusOfBorg1 hugs infinity [08:03] darkxst not sure - how would I check that? [08:04] infinity, so the kernel module will be available on debian too? [08:04] aeoril, you'd need to boot with sysv instead of upstart or systemd [08:05] darkxst (googling - no idea how to do that) [08:05] mbiebl: Yeah, I'm all for minimally invasive so close to both releases. [08:06] mbiebl: But I think the "right" solution would be for systemd itself to do the moral equivalent of "if no native unit; then if [ -x /etc/init.d/service ]; systemctl daemon-reload; service action" [08:07] mbiebl: Obviously natively in C where it's doing the native unit check. [08:07] infinity: btw, do you know dpkg file triggers and conffiles can you used safely nowdays? [08:07] the doc still contains: http://paste.debian.net/164615/ [08:07] mbiebl: Define safely. I think there's still a chance overtriggering, but I've not noticed under-triggering. [08:08] mbiebl: That's basically saying "a modified conffile won't get twiddled on upgrade, so won't generate a trigger, and if you were hoping for that, sucks to be you". [08:09] mbiebl: But that's not the case I'm triggering for. If the init script is already there, I don't need to trigger again on package upgrade. [08:09] infinity: I agree, it would be nice if systemd would pick up the (new) sysv init script automatically [08:09] that would mean though, pulling sysv specific code into the core [08:10] so it's unlikely, that this would be accepted upstream [08:10] where it was moved into a generator a few releases ago [08:10] Fairly unlikely, yeah, but also not a heavy patch to carry. I imagine it's all of a few lines to do it well. [08:10] Anyhow, I agree that a non-C approach is likely best for now. [08:11] Just worth thinking about a better way. [08:11] LocutusOfBorg1: No, which is why vbox-guest-dkms should also provide that virtual package. [08:12] LocutusOfBorg1: I'll work up a nice Debian-and-Ubuntu-friendly diff when I'm done testing how this all fits together. [08:12] LocutusOfBorg1: Which is waiting on the current kernel to be built and published. And maybe me having a nap. :P [08:13] darkxst: An unmatched fi is going to be more than just a warning, it'll halt parsing. [08:14] darkxst: Likely the only reason it was never noticed was because everyone was booting with upstart and never used the init script. [08:15] infinity: (catching up), on the inotify point, one of the issue was that "you may want to install a set of units, and only then commit their existence" (as you are unsure in which order they are unpack, and so, deps are maybe not present yet) [08:16] mbiebl: Anyhow, if pitti gets back to me over the weekend, I'll CC you in on it, but I'm inclined to take this discussion to a JFDI conclusion in both distros if he's off having a proper vacation and ignoring email. :) [08:16] infinity, yes agreed on both points, I'm exhausted from painting all day, clearly not thinking straight! [08:17] didrocks: But registering a unit's existence doesn't imply immediately starting it, does it? It certainly doesn't in the case I'm dealing with anyway. [08:18] didrocks: I guess there's a race there where the sysadmin could try to start a service while apt is still running, but that seems like a "he gets to keep both pieces" situation. [08:18] infinity: right, as long as you don't start them, it's fine, but upstream doesn't want to create gap for race if something else on the system pulls that new unit which doesn't have its deps [08:18] right [08:19] didrocks: Anyhow, I'm not a fan of inotify because of the "some filesystems suck" argument, it was just a talking point. [08:20] didrocks: I think we've settled on update-rc.d and/or trigger to paper over things for now (we just need to settle on the and/or), and then examining maybe a clever fallback in systemd itself later, if we don't mind carrying the patch. [08:20] infinity: sure, just giving you more context that the "inotify on some fs doesn't work" isn't the only blocker in upstream's POV [08:20] mbiebl: ^-- Sound about right? [08:21] the trigger is in addition to the generated postinst daemon-reload, right? [08:21] (as we start/restart units there) [08:21] didrocks: I wouldn't consider my inotify argument a blocker upstream at all, they seem pretty keen on positions like "if your system doesn't have feature X, it's not proper Linux" statements. [08:21] didrocks: There is no postinst reload if you install with --no-start, that's the bug. [08:21] didrocks: Because there is no postinst reload at all, it's actually in invoke-rc.d [08:22] oh right, I just played with this for cloud-init this morning [08:22] yeah [08:22] And while I could make an argument that that's wrong too, it's WAY too late to rebuild literally everything that uses dh_installinit. [08:22] So, not going down that road. [08:22] I guess the trigger is fine, at least conceptually [08:23] But a trigger fix or update-rc.d fix will paper over just fine. [08:23] yeah, not the time to request a mass rebuild of everything using dh_systemd :p [08:23] And both solve different corner cases that the other misses, which is why I'm slightly inclined toward both. [08:24] Neither catches every case, but I don't think we can afford to hold out for perfection and avoid progress. [08:25] infinity: do we really care about git installation using systemd when someone doesn't know how to use it properly? [08:25] I guess there is the arg of backward compat with update-rc/invoke-rc [08:25] didrocks: Well, the git installation method in the bug report was using update-rc.d, which is the Debian-approved way of doing things. [08:25] didrocks: So, that seems like it should DTRT. [08:25] fair enough [08:26] didrocks: And, conversely, I think a simple/crappy/non-policy-compliant in-house deb that ships an init script and doesn't use update-rc.d should probably also work. [08:26] didrocks: We can cover both of those, and then we just miss the "non-packaged and non-update-rc.d" case, which isn't an insiginificant case, but also more invasive to solve. :/ [08:27] indeed, the solution sounds sane enough to me [08:27] Although, the non-packaged/non-update-rc.d init script is also less likely to source LSB functions, which then doesn't land it in systemd land. [08:28] I know I have a few of those lying around. :P [08:28] Like... All my firewalls. [08:28] infinity: yeah, sounds about right and please keep me posted [08:29] mbiebl: Do any of your team have carte blanche (within reason) to upload sysvinit in Debian for the update-rc.d fix, or do we need to coordinate with Roger too? [08:30] within the pkg-systemd team, no [08:30] slangasek is the closest to an official sysvinit maintainer aside from roger, petter and hmh [08:31] the latter 3 being very busy/occupied otherwise afaics [08:31] mbiebl: Alright. I'll wait on pitti for a day or two, and if he has no input on the matter, I'll consider concensus between you, me, and didrocks good 'nuff, and talk to Roger about the update-rc.d bits. [08:31] mbiebl: Or talk to Steve, if he's happy pushing it. [08:32] infinity, thanks a lot :) [08:32] it's in collab-maint, so we might consider pushing the changes directly [08:34] mbiebl: Yeah, I'd be happy to push the changes, just less happy about uploading without someone's approval. People tend to be twitchy about ownership of base packages still here and there. [08:34] mbiebl: And, usually with good reason. [08:34] nod [08:34] looks like Petter is the most active one just looking at the recent history [08:36] getting an ack from Steve or Petter looks like the most promising approach [08:38] Right. I'll chase that up tomorrow before I lose context on all of it. [08:38] mbiebl: And thanks for the input, the Debian bug lent insight. [08:38] np [08:40] darkxst How do I start using sysv? [08:40] aeoril, I don't know [08:40] darkxst neither did my googld search ... :( [08:41] aeoril: You don't in Ubuntu. We only support upstart and systemd. [08:41] aeoril: But running the init script seems to be enough to trigger the bug, doesn't it? [08:42] infinity I can trigger the bug by just running /etc/init.d/gdm [08:42] aeoril: Right, then no need to do a whole sysv boot, really. Between running the script and a visual confirmation by someone who can count opens versus closures, it should suffice. [08:45] infinity good. The current debdiff works for vivid. I will add a new debdiff after doing the fix for trusty and attach it to the bug as well, indicating it is for trusty. Then, we will have a debdiff for vivid and another for trusty. The bug is the same, the difference is that in trusty I need to remove the "fi" line 78 while on vivid it is line 73. Does that all seem reasonable? [08:45] aeoril: Yeah. Should probably be fixed in utopic too, FWIW. [08:46] infinity ok, will do. Thanks [08:47] (tomorrow) [08:57] @sponsor on [08:57] Error: "sponsor" is not a valid command. [08:57] @pilot on [08:57] (pilot (in|out)) -- Set yourself an in or out of patch pilot. [08:57] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 [09:01] seb128: Heh. That's what you get for trying to operate IRC on a holiday. [09:02] lol [09:02] yeah, I was off yesterday afternoon so doing some sponsoring today in exchange :-) [09:03] seb128: Yeah, I'm in a similar "I slacked a bit, and making up for it" boat. [09:25] infinity, ogra_, cyphermox, can one of you merge/upload https://code.launchpad.net/~darkxst/ubiquity-slideshow-ubuntu/vivid/+merge/254490 ? it looks fine but coredev seems to not have access to that vcs... [09:28] tseliot: am I right in thinking your sddm patch is still a work in progress and not ready for upload? [09:29] Riddell: yes, I'm still waiting for a reply from David Edmunson [09:29] especially about the two leaks that I fixed [09:30] (one was already there) [09:30] tseliot: thanks, I've pinged him :) [09:30] Riddell: thanks [09:32] I have a machine I am running trusty 14.04.1 LTS on. I use it to do builds using sbuild when doing bug fixes. Should I upgrade this to 14.04.2 for any reason? [09:34] aeoril, it will already be 14.04.2 if you do the regular updates [09:34] oh, ok - will do then [09:35] (minus the HWE stack) which is opt-in and probably not much use if X is working fine for you [09:36] aeoril: "lsb_release -a" should say 14.04.2 already, unless you never upgrade. [09:36] infinity yes, I just did that already - it is indeed 14.04.2 ... [09:36] thanks, guys! [09:38] tseliot: have you actually tested sddm with nvidia-prime? does it work for you? [09:39] Riddell, hey, speaking of sddm, there is https://code.launchpad.net/~dan-mcgregor/ubuntu/vivid/sddm/fix-zsh/+merge/255127 in the sponsoring queue ;-) [09:41] infinity, Ive seen crash reports on errors.u.c of people that have never upgraded once since trusty was realeased!' [09:41] Riddell: I haven't had the chance to test it yet (but I will). My work is based on what I did for lightdm though, and it reuses code that was already there in sddm (for the DisplayCommand parameter), so, in addition to building fine, it should also work. [09:42] ooh thanks seb128 [09:42] Riddell, yw! [09:43] ok why is this triaged as invalid https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1432176 [09:43] Error: malone bug 1432176 not found [09:44] Is this OK with apt-get upgrade on 14.04.2? "The following packages have been kept back: liboxideqt-qmlplugin linux-generic linux-headers-generic linux-image-generic" [09:45] aeoril: You want "apt-get dist-upgrade" [09:45] aeoril: "upgrade" refuses to add/remove packages. [09:46] ok, thanks - should I always use "dist-upgrade" instead of "upgrade" then? [09:47] aeoril: Generally, yes, just pay attention to what it wants to do. If it's asking to remove a bunch of things, something may have gone wrong and you might want to say "no". :) [09:47] ok, will do ... :) [09:48] dz0ny: Because, due to outdated packages, it was impossible to generate a useful stack trace, so it's not particularly debuggable. If you can provide exact reproduction steps to make the crash happen on a current version, reopening it would be fine. [09:49] dz0ny: Oh, and you also have non-Ubuntu packages installed, which is almost certainly the source of the bug, based on the limited stacktrace we did get. [09:50] infinity: mhm, I realized that last bit now. I have gnome staging ppa and that seems to be the cause [09:52] infinity thanks, that worked! [09:53] seb128, hi, since the trusty release is an LTS and I did a mistake in non using the standard patch notation in the previous upload I would like to rename it if possible [09:53] I hope you understand, if not possible, feel free to filter that part :) [09:53] LocutusOfBorg1, hey, ok, wfm [09:54] thanks! [10:02] LocutusOfBorg1, can you make the bug SRU compliant? (impact/test case/regression potential in the description)? [10:05] in a few minutes [10:16] done! [10:26] LocutusOfBorg1, thanks [10:27] I seem to be unable to edit my comment on bug 1315442 - #7 - I want to change it to mention the fix is for the vivid version specifically [10:27] bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442 [10:27] smoser, hey, could you review https://code.launchpad.net/~niedbalski/ubuntu/vivid/curtin/fix-1263181/+merge/250163 it's in the sponsoring queue for a while (and the reported seems a bit grumpy on the bug by the lack of feedback, he states that things are just not working at the moment) [10:27] aeoril, I don't think you can edit commit, just add a new one? [10:27] seb128 ok, will do - thanks - I cannot find anyway to edit the comment [10:28] aeoril, right, you can't [10:28] ok, thanks seb128 [10:43] thanks to you seb128 :) [10:43] I'm wondering if dholbach is on VAC :) [10:44] seb128, BTW I would like to have a feedback for https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1424769 [10:44] Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Undecided,Confirmed] [10:44] if possible :) [10:44] sarnold or infinity or darkxst would you mind looking here? I added the patch for trusty: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1315442 (comment #9) [10:44] LocutusOfBorg1, today is an holiday in Germany (good friday) [10:44] Launchpad bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] [10:46] aeoril, probably ok from a quick glance, will sponsor over the weekend when I find time [10:47] darkxst ok, thanks - this is starting to get easier! :) [10:47] darkxst I still need to do the utopic fix - will do soon [10:47] aeoril, time to find your own bug to fix ;) [10:48] darkxst this is a lot of fun! :D [10:48] darkxst I need to do a fix with some good coding in it! [10:48] LocutusOfBorg1, I don't know the package much but I think added -lts variants makes sense in the context of the renamed xorg stacks [10:48] s/good/real/ [10:49] seb128, thanks, but he wasn't there also yesterday maybe :) [10:49] LocutusOfBorg1, yeah, maybe it's taking some extra days for a long easter w.e [10:49] I hope he is having a good time then ;) [10:50] darkxst I have my own bug to fix! I just don't have the ability to fix it! (that one I worked on forever about vim/gnome-terminal) [10:53] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [10:56] aeoril I meant for you to find a bug you can fix [10:56] darkxst as opposed to you finding them for me? [10:58] yes [11:01] darkxst will do, thanks for all your help :) [11:03] aeoril, np, Im off to bed now [11:03] darkxst night! [11:04] darkxst I am going to look for a fix that has some c code in it [11:05] (I have not coded in C for a while) [11:05] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks [11:07] didrocks I see you are my patch pilot! Just looked up what that was! [11:08] s/my/our/ [11:10] aeoril: the gdm thing? I'm unsure to understand how that impacts the ubuntu gnome guys as there is an upstart job (gdm.conf) for it, right? [11:11] didrocks not sure, actually - I am new [11:12] didrocks I was just commenting that I noticed you were the patch pilot - I did not know there was such a thing [11:13] aeoril: ah ok, no worry! I saw you were discussing about the gdm bug, I'll let the ubuntu gnome team deciding on it, but it's a bug fix that debian may benefit from, not ubuntu as we only support upstart and systemd [11:13] didrocks if they wanted to manually use /etc/init.d/gdm to start/stop/whatever the service, it would affect them though [11:15] aeoril: not something that they should do (because a lot of other things will be broken, even if it works), and not something that we support at all === dkessel_ is now known as dkessel [11:15] didrocks oh, ok - what do I do to make the patch available to debian, if anything, or will the ubuntu-gnome people do that? [11:16] aeoril: if you want to handle it and push to debian, that would be rocking, there is a wiki page about it, one sec [11:16] aeoril, you don't, there is a massive delta on gdm between debian and ubuntu [11:16] didrocks I might as well! If I never do it, I won't learn! [11:16] darkxst oh, ok [11:16] darkxst: you think the gdm init script is different? [11:16] didrocks, I need to finish my gdm3 merge first ! before that is possible [11:17] let me look at the init script, one sec [11:17] aeoril: for reference (I'll tell you here if the bug applies to them in a sec): https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers#Forwarding_bug_reports [11:18] aeoril: attaching a patch to the forwarded bug report [11:19] didrocks ok, thanks for the link :) [11:19] aeoril: yeah, they don't have that bug [11:20] didrocks ok, thanks anyway :) [11:20] (their init script is different, which is normal, as they support sysv) [11:20] aeoril: yw! [11:20] didrocks yah, I would figure if they support it, it probably works better already! [11:21] yeah ;) [11:21] didrocks why do we have the sysv stuff at all if we don't support it? I mean, if you cannot even use it manually even, what is the point? [11:22] aeoril: debian supports multiple init system, ubuntu always supported one (upstart until now, and systemd but on some flavors) [11:22] we removed most of the init scripts in the past [11:22] but TBH, that was more a burden than anything in the end, to keep a delta with debian just for this [11:22] and under systemd, sysv init scripts are ignored if there is a systemd unit [11:23] didrocks why did we not remove all the sysv scripts if we cannot even use them? [11:23] aeoril: as told, we did it in the past, but as we merge regularly from debian, a lot of packages only had those removals as a delta [11:23] so we couldn't sync automatically [11:23] and it introduces uncessary diff [11:24] noting that the size on disk is really negligeable [11:24] didrocks oh, sorry - I misunderstood. I think I understand now. [11:24] (472K for instance on my machine, which has a lot more packages than the standard installation) [11:25] didrocks, gdm is way out of sync, but I was trying to go to bed half an hour a go [11:25] really going now [11:25] darkxst: enjoy your long week-end :) [11:25] didrocks so, we removed them in the past, but now we just leave them in because they come from debian? [11:25] right [11:26] didrocks, it already started and I am exhausted after day 1! [11:26] didrocks ok, gotcha. Thanks for the explanation [11:26] darkxst: 3 more days for you to rest! [11:26] aeoril: yw, do not hesitate if you have any other questions :) [11:26] darkxst thanks for all your support! Good night! I hope you have a nice holiday! [11:28] didrocks I do have one question - you mentioned this earlier, but I want to clarify - this whole fix may be pointless, because we cannot use the scripts, but you leave it to the ubuntu gnome people to decide? [11:29] aeoril: exactly, they are the ones touching the most of those packages, so if they want to add that fix to other changes in an upload, that's fine. I just don't think it worthes an upload on its own [11:29] (especially when fixing older releases, where the process is way more involved) [11:30] didrocks ok. I have put the patches for vivid and trusty into the bug report. I will go ahead and do utopic as well for completeness - it is easy at this point and does not take much time [11:33] sure :) [11:44] didrocks caffeine is amazing ... I can do the utopic patch now ... lol [11:44] (until I crash) [11:45] ahah ;) [11:49] barry, hey, could you look at https://code.launchpad.net/~brunonova/oneconf/lp1165104/+merge/198429 ? it's waiting for feedback from you since 2013, the contributor seems a bit disappointed since :-/ [11:51] cyphermox, (or somebody else looking at foundation things, maybe infinity?) could be get https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222 merged or rejected? [11:51] it's a one liner, it feels like we should be able to do the tweak Colin suggested and merge in if the change is right [11:58] tyhicks, kirkland, hey, could you review https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940 ?it's in the sponsoring queue waiting since january 1st [11:58] Launchpad bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New] === adam_g is now known as adam_g_out [12:28] seb128: I'm off today but since I've looked, I might as well review this :) [12:28] ah, that one [12:28] cyphermox, thanks, and that can wait next week, sorry for the ping on a day off, I assumed you would just get the backlog when you are back next week, I didn't meant to nag you on a vac day [12:29] no, rejecting; I had applied it in vivid and it broke things [12:29] k [12:29] thanks [12:29] cyphermox, btw, did you do something about the nm-applet issue from the other day? [12:29] seb128: which? [12:29] the crash, yes [12:29] cyphermox, the segfault [12:29] right [12:29] great [12:29] should be in archive now [12:31] cyphermox, oh, I somewhat didn't notice the upload on vivid-changes, great, thanks ;-) [12:33] cyphermox, did you upstream the fix? the patch has no header, but I think it impacts upstream as well since fedora had similar reports [12:34] oh, no [12:34] but it really looks like something broken by indicator, not by upstream === Guest79913 is now known as gusnan [12:35] ie. fails because of hows things get started when you initialize the indicators [12:35] I'll get back to this on Monday [12:37] cyphermox, weird, https://retrace.fedoraproject.org/faf/reports/352711/ seems similar [12:42] hmm, it really does [12:42] in any case, I think this should help a whole lot, but it's indicator-specific anyway [12:42] cyphermox, that's why I suggested upstreaming it the other day :-) [12:42] I'll discuss the details with dcbw on monday [12:42] thanks [12:42] isn't monday off for you? [12:43] maybe there is a something else to do [12:43] nope [12:43] k [12:43] maybe it's off for him though [12:43] most things already assert that devinfo is there (it being null causes the crash) [12:43] tuesday is fine a well :-) [12:43] and it's expected to be set when devices are initially discovered [12:44] but I can't assert in this case, maybe just ignoring the device if it doesn't have the devinfo struct [12:45] k [12:49] doko_, hey, could you review https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1411630 ? mitya57 pointed on the bug that the change should probably be including in Debian as well, it's waiting in the sponsoring queue since january [12:49] Launchpad bug 1411630 in openjdk-8 (Ubuntu) "Build-Depends cannot be fulfilled in precise" [Undecided,New] [13:04] seb128, sure, next free work day, which is Thu or Mon in a week [13:05] and I'm not keen on mitya57's patches ... there are still syncs initiated by mitya57 which ftbfs in -proposed [13:06] doko_, no hurry, should I just unsubscribe sponsors and assign to you? [13:08] seb128, sure, I can have a look [13:08] doko_, thanks [13:08] doko_, enjoy the easter days ;-) [13:11] seb128, that was on my list fl things to do today. [13:11]