| aeoril | 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:33 |
|---|---|---|
| aeoril | darkxst I am installing to Ubuntu-Gnome vivid live-cd "Try Ubuntu" | 02:34 |
| aeoril | (In a virtual machine) | 02:36 |
| sarnold | aeoril: gir1.2-gdm-1.0 appears to be built from the gdm source package: Y | 02:40 |
| sarnold | aeoril: https://launchpad.net/ubuntu/+source/gdm | 02:40 |
| sarnold | aeoril: did you copy over those binaries too when testing? | 02:40 |
| aeoril | sarnold no | 02:40 |
| sarnold | you'll need to include it onthe same dpkg -i command.. | 02:41 |
| aeoril | 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:42 |
| sarnold | 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 |
| sarnold | aeoril: but it's surprisingly easy to miss other binary packages that don't match source*deb glob :) | 02:44 |
| aeoril | 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:45 |
| darkxst | you only need the first 3 | 02:47 |
| sarnold | aeoril: you can skip the -dev package unless you want to compile code on the test machine that links against libgdm.. | 02:48 |
| aeoril | sarnold ok, thanks | 02:48 |
| aeoril | sarnold cool! That worked, and thanks again! Tested, and now I can attach the debdiff to the bug and claim victory! :) | 02:50 |
| sarnold | :D | 02:51 |
| sarnold | aeoril: very nice :) | 02:51 |
| aeoril | 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:51 |
| aeoril | sarnold should I just make a new comment - "Fixed - see attached debdiff" and let others take care of all that? | 02:52 |
| aeoril | sarnold (I will add proper info to the comment of course) | 02:52 |
| sarnold | aeoril: be sure to detail what testing you've done in the comment.. | 02:52 |
| sarnold | aha good ;) | 02:52 |
| aeoril | sarnold this is my third! | 02:53 |
| sarnold | aeoril: the actual bugstate is probably less important than getting the fix attached and describe the testing done, etc | 02:53 |
| sarnold | aeoril: dude! | 02:53 |
| sarnold | aeoril: that's awesome :) you've been busy | 02:53 |
| aeoril | 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 |
| sarnold | aeoril: wow, was that really so long ago? | 02:54 |
| sarnold | I have no idea how it became april so quickly. or march.. | 02:54 |
| aeoril | sarnold yah, a month and a day since March 1! | 02:55 |
| sarnold | aeoril: well I'm glad to see you're back, then :) | 02:55 |
| aeoril | stuff happens :) | 02:55 |
| aeoril | 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:56 |
| sarnold | after the firstone, most bugs will feel more trivial .. :) | 02:57 |
| aeoril | 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 |
| aeoril | learning how to build and test and all that | 02:58 |
| sarnold | aeoril: yeah, quite often each one requires something slightly different | 03:03 |
| sarnold | it's a fun way to stay flexible :) | 03:03 |
| aeoril | sarnold you want to look over my patch/comment? https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1315442 | 03:17 |
| ubottu | Launchpad bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] | 03:17 |
| aeoril | 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 |
| sarnold | 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 |
| sarnold | aeoril: exactly that :) | 03:21 |
| aeoril | sarnold yes, I specifically elided the correct 'fi' to leave indenting correct :) | 03:22 |
| sarnold | 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 |
| sarnold | aeoril: yay :) | 03:22 |
| aeoril | sarnold ok, I'll do that tomorrow | 03:22 |
| sarnold | 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 |
| sarnold | (for simple fixes it almost always will make sense :) | 03:23 |
| aeoril | sarnold I carefully checked the debdiff manually | 03:24 |
| sarnold | :D | 03:24 |
| === gusnan is now known as Guest79913 | ||
| infinity | slangasek: Around? | 05:10 |
| slangasek | infinity: hi | 05:20 |
| infinity | slangasek: Sanity check on http://paste.ubuntu.com/10728501/ before I upload and self-accept? | 05:24 |
| infinity | 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 |
| slangasek | infinity: is there a bug report for this? | 05:25 |
| infinity | 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 |
| infinity | slangasek: Dunno. Maybe. I was cleaning up test failures. | 05:25 |
| infinity | slangasek: Anyhow, tested and does what I expect for both old and new triggers. | 05:27 |
| slangasek | 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 |
| infinity | slangasek: It's blocking one other package, and now that I know the root cause, I could let that package pass. *shrug* | 05:27 |
| slangasek | infinity: I'd highly prefer to have pitti review this before upload, I don't want folks working at cross-purposes | 05:28 |
| infinity | 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 |
| slangasek | not necessarily; maybe update-rc.d should be doing it? | 05:28 |
| infinity | And if you install an init script without rc.d links? | 05:29 |
| infinity | Which isn't a terribly normal thing to do, granted, but... | 05:30 |
| slangasek | then you're in violation of policy, go directly to policyjail do not collect 200 policydollars | 05:30 |
| infinity | 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:33 |
| infinity | slangasek: Still, a weird thing to do, and yes, update-rc.d would cover the places I've run into the bug. | 05:34 |
| infinity | slangasek: Though it would actually run more often than the trigger. | 05:34 |
| infinity | slangasek: So, not exactly an optimisation. :P | 05:34 |
| * slangasek nods | 05:34 | |
| infinity | 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:35 |
| slangasek | 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:37 |
| infinity | 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 |
| infinity | slangasek: But yeah, I wouldn't doubt it's come up before. | 05:38 |
| darkxst | aeoril, trusty would need a seperate debdiff , although I not entirely sure it warrants an SRU, it is only a warning isnt it? | 06:13 |
| mbiebl | slangasek, infinity: we discussed that on #debian-systemd a while ago when another DD ran into this issue | 07:23 |
| mbiebl | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774799 | 07:23 |
| ubottu | 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:23 |
| mbiebl | I think I slightly prefer that update-rc.d calls daemon reload | 07:24 |
| mbiebl | let's see what pitti thinks | 07:26 |
| infinity | mbiebl: Any reason for the preference? It's more performant as a trigger. | 07:49 |
| mbiebl | infinity: someone might install a non-deb package, still using update-rc.d to register the init script | 07:50 |
| mbiebl | I also vaguely remember, dpkg-triggers were somewhat problematic with conffiles | 07:50 |
| mbiebl | (although that might be outdated nowadays) | 07:50 |
| infinity | 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:51 |
| infinity | 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 |
| mbiebl | infinity: have you seen the bug report? | 07:52 |
| mbiebl | it was about git cloning fusionforge | 07:52 |
| infinity | mbiebl: Yeah, I read the report just now. | 07:52 |
| mbiebl | running make post-instlal | 07:52 |
| mbiebl | i.e., no dpkg involved here | 07:52 |
| infinity | mbiebl: Right, fair point. | 07:52 |
| mbiebl | infinity: I agree about the RC-ness of the bug though | 07:53 |
| infinity | 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:53 |
| infinity | 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:54 |
| infinity | 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 |
| mbiebl | inotify is not without problems | 07:55 |
| mbiebl | and yes, upstream, rejected that so far | 07:55 |
| infinity | The only real inotify problem I run into is overlayfs not implementing it. | 07:56 |
| infinity | But it still beats "you must know this magic invocation if you install an init script". | 07:56 |
| infinity | Whether the magic is update-rc.d or sysctectl daemon-reload or whatever. | 07:56 |
| infinity | THough, I suppose most would just get frustrated and reboot, and it would magically work. :P | 07:57 |
| mbiebl | iirc, for native services, systemd will implicitly check if you start a service which is not loaded yet | 07:58 |
| infinity | mbiebl: But I take the point about github-style deployments that think package managers suck. | 07:58 |
| mbiebl | and do a reload then | 07:58 |
| mbiebl | we could maybe do the same for sysv init scripts | 07:58 |
| mbiebl | that wouldn't catch changed init scripts though | 07:58 |
| mbiebl | only new ones | 07:58 |
| infinity | 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:58 |
| infinity | 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 |
| infinity | mbiebl: So, changing them should work fine. | 07:59 |
| infinity | mbiebl: I could be wrong, but the idea that it's caching /etc/init.d/* seems insane. | 07:59 |
| mbiebl | for /etc/init.d, it runs a generator | 08:00 |
| mbiebl | see /run/systemd/generator.late/ | 08:00 |
| aeoril | darkxst it is a "Syntax Error" | 08:00 |
| infinity | mbiebl: Right. Ahh, sure, it wouldn't catch changes to LSB headers, I guess. | 08:01 |
| darkxst | aeoril, does it break the sysv init script? | 08:01 |
| infinity | mbiebl: But that's a small and unfortunate corner case that doesn't matter much at runtime anyway, only at boot. | 08:01 |
| infinity | mbiebl: And at boot, it'll re-run the generator. | 08:02 |
| mbiebl | 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 | |
| aeoril | darkxst not sure - how would I check that? | 08:03 |
| LocutusOfBorg1 | infinity, so the kernel module will be available on debian too? | 08:04 |
| darkxst | aeoril, you'd need to boot with sysv instead of upstart or systemd | 08:04 |
| aeoril | darkxst (googling - no idea how to do that) | 08:05 |
| infinity | mbiebl: Yeah, I'm all for minimally invasive so close to both releases. | 08:05 |
| infinity | 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:06 |
| infinity | mbiebl: Obviously natively in C where it's doing the native unit check. | 08:07 |
| mbiebl | infinity: btw, do you know dpkg file triggers and conffiles can you used safely nowdays? | 08:07 |
| mbiebl | the doc still contains: http://paste.debian.net/164615/ | 08:07 |
| infinity | mbiebl: Define safely. I think there's still a chance overtriggering, but I've not noticed under-triggering. | 08:07 |
| infinity | 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:08 |
| infinity | 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 |
| mbiebl | infinity: I agree, it would be nice if systemd would pick up the (new) sysv init script automatically | 08:09 |
| mbiebl | that would mean though, pulling sysv specific code into the core | 08:09 |
| mbiebl | so it's unlikely, that this would be accepted upstream | 08:10 |
| mbiebl | where it was moved into a generator a few releases ago | 08:10 |
| infinity | 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 |
| infinity | Anyhow, I agree that a non-C approach is likely best for now. | 08:10 |
| infinity | Just worth thinking about a better way. | 08:11 |
| infinity | LocutusOfBorg1: No, which is why vbox-guest-dkms should also provide that virtual package. | 08:11 |
| infinity | LocutusOfBorg1: I'll work up a nice Debian-and-Ubuntu-friendly diff when I'm done testing how this all fits together. | 08:12 |
| infinity | LocutusOfBorg1: Which is waiting on the current kernel to be built and published. And maybe me having a nap. :P | 08:12 |
| infinity | darkxst: An unmatched fi is going to be more than just a warning, it'll halt parsing. | 08:13 |
| infinity | darkxst: Likely the only reason it was never noticed was because everyone was booting with upstart and never used the init script. | 08:14 |
| didrocks | 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:15 |
| infinity | 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 |
| darkxst | infinity, yes agreed on both points, I'm exhausted from painting all day, clearly not thinking straight! | 08:16 |
| infinity | 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:17 |
| infinity | 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 |
| didrocks | 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 |
| didrocks | right | 08:18 |
| infinity | didrocks: Anyhow, I'm not a fan of inotify because of the "some filesystems suck" argument, it was just a talking point. | 08:19 |
| infinity | 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 |
| didrocks | 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 |
| infinity | mbiebl: ^-- Sound about right? | 08:20 |
| didrocks | the trigger is in addition to the generated postinst daemon-reload, right? | 08:21 |
| didrocks | (as we start/restart units there) | 08:21 |
| infinity | 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 |
| infinity | didrocks: There is no postinst reload if you install with --no-start, that's the bug. | 08:21 |
| infinity | didrocks: Because there is no postinst reload at all, it's actually in invoke-rc.d | 08:21 |
| didrocks | oh right, I just played with this for cloud-init this morning | 08:22 |
| didrocks | yeah | 08:22 |
| infinity | 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 |
| infinity | So, not going down that road. | 08:22 |
| didrocks | I guess the trigger is fine, at least conceptually | 08:22 |
| infinity | But a trigger fix or update-rc.d fix will paper over just fine. | 08:23 |
| didrocks | yeah, not the time to request a mass rebuild of everything using dh_systemd :p | 08:23 |
| infinity | And both solve different corner cases that the other misses, which is why I'm slightly inclined toward both. | 08:23 |
| infinity | Neither catches every case, but I don't think we can afford to hold out for perfection and avoid progress. | 08:24 |
| didrocks | infinity: do we really care about git installation using systemd when someone doesn't know how to use it properly? | 08:25 |
| didrocks | I guess there is the arg of backward compat with update-rc/invoke-rc | 08:25 |
| infinity | 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 |
| infinity | didrocks: So, that seems like it should DTRT. | 08:25 |
| didrocks | fair enough | 08:25 |
| infinity | 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 |
| infinity | 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:26 |
| didrocks | indeed, the solution sounds sane enough to me | 08:27 |
| infinity | 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:27 |
| infinity | I know I have a few of those lying around. :P | 08:28 |
| infinity | Like... All my firewalls. | 08:28 |
| mbiebl | infinity: yeah, sounds about right and please keep me posted | 08:28 |
| infinity | 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:29 |
| mbiebl | within the pkg-systemd team, no | 08:30 |
| mbiebl | slangasek is the closest to an official sysvinit maintainer aside from roger, petter and hmh | 08:30 |
| mbiebl | the latter 3 being very busy/occupied otherwise afaics | 08:31 |
| infinity | 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 |
| infinity | mbiebl: Or talk to Steve, if he's happy pushing it. | 08:31 |
| LocutusOfBorg1 | infinity, thanks a lot :) | 08:32 |
| mbiebl | it's in collab-maint, so we might consider pushing the changes directly | 08:32 |
| infinity | 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 |
| infinity | mbiebl: And, usually with good reason. | 08:34 |
| mbiebl | nod | 08:34 |
| mbiebl | looks like Petter is the most active one just looking at the recent history | 08:34 |
| mbiebl | getting an ack from Steve or Petter looks like the most promising approach | 08:36 |
| infinity | Right. I'll chase that up tomorrow before I lose context on all of it. | 08:38 |
| infinity | mbiebl: And thanks for the input, the Debian bug lent insight. | 08:38 |
| mbiebl | np | 08:38 |
| aeoril | darkxst How do I start using sysv? | 08:40 |
| darkxst | aeoril, I don't know | 08:40 |
| aeoril | darkxst neither did my googld search ... :( | 08:40 |
| infinity | aeoril: You don't in Ubuntu. We only support upstart and systemd. | 08:41 |
| infinity | aeoril: But running the init script seems to be enough to trigger the bug, doesn't it? | 08:41 |
| aeoril | infinity I can trigger the bug by just running /etc/init.d/gdm | 08:42 |
| infinity | 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:42 |
| aeoril | 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 |
| infinity | aeoril: Yeah. Should probably be fixed in utopic too, FWIW. | 08:45 |
| aeoril | infinity ok, will do. Thanks | 08:46 |
| aeoril | (tomorrow) | 08:47 |
| seb128 | @sponsor on | 08:57 |
| udevbot | Error: "sponsor" is not a valid command. | 08:57 |
| seb128 | @pilot on | 08:57 |
| udevbot | (pilot (in|out)) -- Set yourself an in or out of patch pilot. | 08:57 |
| seb128 | @pilot in | 08:57 |
| === 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 | ||
| infinity | seb128: Heh. That's what you get for trying to operate IRC on a holiday. | 09:01 |
| seb128 | lol | 09:02 |
| seb128 | yeah, I was off yesterday afternoon so doing some sponsoring today in exchange :-) | 09:02 |
| infinity | seb128: Yeah, I'm in a similar "I slacked a bit, and making up for it" boat. | 09:03 |
| seb128 | 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:25 |
| Riddell | tseliot: am I right in thinking your sddm patch is still a work in progress and not ready for upload? | 09:28 |
| tseliot | Riddell: yes, I'm still waiting for a reply from David Edmunson | 09:29 |
| tseliot | especially about the two leaks that I fixed | 09:29 |
| tseliot | (one was already there) | 09:30 |
| Riddell | tseliot: thanks, I've pinged him :) | 09:30 |
| tseliot | Riddell: thanks | 09:30 |
| aeoril | 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:32 |
| darkxst | aeoril, it will already be 14.04.2 if you do the regular updates | 09:34 |
| aeoril | oh, ok - will do then | 09:34 |
| darkxst | (minus the HWE stack) which is opt-in and probably not much use if X is working fine for you | 09:35 |
| infinity | aeoril: "lsb_release -a" should say 14.04.2 already, unless you never upgrade. | 09:36 |
| aeoril | infinity yes, I just did that already - it is indeed 14.04.2 ... | 09:36 |
| aeoril | thanks, guys! | 09:36 |
| Riddell | tseliot: have you actually tested sddm with nvidia-prime? does it work for you? | 09:38 |
| seb128 | 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:39 |
| darkxst | infinity, Ive seen crash reports on errors.u.c of people that have never upgraded once since trusty was realeased!' | 09:41 |
| tseliot | 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:41 |
| Riddell | ooh thanks seb128 | 09:42 |
| seb128 | Riddell, yw! | 09:42 |
| dz0ny | ok why is this triaged as invalid https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1432176 | 09:43 |
| ubottu | Error: malone bug 1432176 not found | 09:43 |
| aeoril | 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:44 |
| infinity | aeoril: You want "apt-get dist-upgrade" | 09:45 |
| infinity | aeoril: "upgrade" refuses to add/remove packages. | 09:45 |
| aeoril | ok, thanks - should I always use "dist-upgrade" instead of "upgrade" then? | 09:46 |
| infinity | 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 |
| aeoril | ok, will do ... :) | 09:47 |
| infinity | 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:48 |
| infinity | 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:49 |
| dz0ny | infinity: mhm, I realized that last bit now. I have gnome staging ppa and that seems to be the cause | 09:50 |
| aeoril | infinity thanks, that worked! | 09:52 |
| LocutusOfBorg1 | 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 |
| LocutusOfBorg1 | I hope you understand, if not possible, feel free to filter that part :) | 09:53 |
| seb128 | LocutusOfBorg1, hey, ok, wfm | 09:53 |
| LocutusOfBorg1 | thanks! | 09:54 |
| seb128 | LocutusOfBorg1, can you make the bug SRU compliant? (impact/test case/regression potential in the description)? | 10:02 |
| LocutusOfBorg1 | in a few minutes | 10:05 |
| LocutusOfBorg1 | done! | 10:16 |
| seb128 | LocutusOfBorg1, thanks | 10:26 |
| aeoril | 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 |
| ubottu | bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442 | 10:27 |
| seb128 | 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 |
| seb128 | aeoril, I don't think you can edit commit, just add a new one? | 10:27 |
| aeoril | seb128 ok, will do - thanks - I cannot find anyway to edit the comment | 10:27 |
| seb128 | aeoril, right, you can't | 10:28 |
| aeoril | ok, thanks seb128 | 10:28 |
| LocutusOfBorg1 | thanks to you seb128 :) | 10:43 |
| LocutusOfBorg1 | I'm wondering if dholbach is on VAC :) | 10:43 |
| LocutusOfBorg1 | seb128, BTW I would like to have a feedback for https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1424769 | 10:44 |
| ubottu | Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Undecided,Confirmed] | 10:44 |
| LocutusOfBorg1 | if possible :) | 10:44 |
| aeoril | 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 |
| seb128 | LocutusOfBorg1, today is an holiday in Germany (good friday) | 10:44 |
| ubottu | Launchpad bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] | 10:44 |
| darkxst | aeoril, probably ok from a quick glance, will sponsor over the weekend when I find time | 10:46 |
| aeoril | darkxst ok, thanks - this is starting to get easier! :) | 10:47 |
| aeoril | darkxst I still need to do the utopic fix - will do soon | 10:47 |
| darkxst | aeoril, time to find your own bug to fix ;) | 10:47 |
| aeoril | darkxst this is a lot of fun! :D | 10:48 |
| aeoril | darkxst I need to do a fix with some good coding in it! | 10:48 |
| seb128 | 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 |
| aeoril | s/good/real/ | 10:48 |
| LocutusOfBorg1 | seb128, thanks, but he wasn't there also yesterday maybe :) | 10:49 |
| seb128 | LocutusOfBorg1, yeah, maybe it's taking some extra days for a long easter w.e | 10:49 |
| LocutusOfBorg1 | I hope he is having a good time then ;) | 10:49 |
| aeoril | 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:50 |
| seb128 | @pilot out | 10:53 |
| === 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: | ||
| darkxst | aeoril I meant for you to find a bug you can fix | 10:56 |
| aeoril | darkxst as opposed to you finding them for me? | 10:56 |
| darkxst | yes | 10:58 |
| aeoril | darkxst will do, thanks for all your help :) | 11:01 |
| darkxst | aeoril, np, Im off to bed now | 11:03 |
| aeoril | darkxst night! | 11:03 |
| aeoril | darkxst I am going to look for a fix that has some c code in it | 11:04 |
| aeoril | (I have not coded in C for a while) | 11:05 |
| didrocks | @pilot in | 11:05 |
| === 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 | ||
| aeoril | didrocks I see you are my patch pilot! Just looked up what that was! | 11:07 |
| aeoril | s/my/our/ | 11:08 |
| didrocks | 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:10 |
| aeoril | didrocks not sure, actually - I am new | 11:11 |
| aeoril | didrocks I was just commenting that I noticed you were the patch pilot - I did not know there was such a thing | 11:12 |
| didrocks | 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 |
| aeoril | didrocks if they wanted to manually use /etc/init.d/gdm to start/stop/whatever the service, it would affect them though | 11:13 |
| didrocks | 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 | 11:15 |
| === dkessel_ is now known as dkessel | ||
| aeoril | 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:15 |
| didrocks | 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 |
| darkxst | aeoril, you don't, there is a massive delta on gdm between debian and ubuntu | 11:16 |
| aeoril | didrocks I might as well! If I never do it, I won't learn! | 11:16 |
| aeoril | darkxst oh, ok | 11:16 |
| didrocks | darkxst: you think the gdm init script is different? | 11:16 |
| darkxst | didrocks, I need to finish my gdm3 merge first ! before that is possible | 11:16 |
| didrocks | let me look at the init script, one sec | 11:17 |
| didrocks | 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:17 |
| didrocks | aeoril: attaching a patch to the forwarded bug report | 11:18 |
| aeoril | didrocks ok, thanks for the link :) | 11:19 |
| didrocks | aeoril: yeah, they don't have that bug | 11:19 |
| aeoril | didrocks ok, thanks anyway :) | 11:20 |
| didrocks | (their init script is different, which is normal, as they support sysv) | 11:20 |
| didrocks | aeoril: yw! | 11:20 |
| aeoril | didrocks yah, I would figure if they support it, it probably works better already! | 11:20 |
| didrocks | yeah ;) | 11:21 |
| aeoril | 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:21 |
| didrocks | aeoril: debian supports multiple init system, ubuntu always supported one (upstart until now, and systemd but on some flavors) | 11:22 |
| didrocks | we removed most of the init scripts in the past | 11:22 |
| didrocks | but TBH, that was more a burden than anything in the end, to keep a delta with debian just for this | 11:22 |
| didrocks | and under systemd, sysv init scripts are ignored if there is a systemd unit | 11:22 |
| aeoril | didrocks why did we not remove all the sysv scripts if we cannot even use them? | 11:23 |
| didrocks | 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 |
| didrocks | so we couldn't sync automatically | 11:23 |
| didrocks | and it introduces uncessary diff | 11:23 |
| didrocks | noting that the size on disk is really negligeable | 11:24 |
| aeoril | didrocks oh, sorry - I misunderstood. I think I understand now. | 11:24 |
| didrocks | (472K for instance on my machine, which has a lot more packages than the standard installation) | 11:24 |
| darkxst | didrocks, gdm is way out of sync, but I was trying to go to bed half an hour a go | 11:25 |
| darkxst | really going now | 11:25 |
| didrocks | darkxst: enjoy your long week-end :) | 11:25 |
| aeoril | didrocks so, we removed them in the past, but now we just leave them in because they come from debian? | 11:25 |
| didrocks | right | 11:25 |
| darkxst | didrocks, it already started and I am exhausted after day 1! | 11:26 |
| aeoril | didrocks ok, gotcha. Thanks for the explanation | 11:26 |
| didrocks | darkxst: 3 more days for you to rest! | 11:26 |
| didrocks | aeoril: yw, do not hesitate if you have any other questions :) | 11:26 |
| aeoril | darkxst thanks for all your support! Good night! I hope you have a nice holiday! | 11:26 |
| aeoril | 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:28 |
| didrocks | 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 |
| didrocks | (especially when fixing older releases, where the process is way more involved) | 11:29 |
| aeoril | 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:30 |
| didrocks | sure :) | 11:33 |
| aeoril | didrocks caffeine is amazing ... I can do the utopic patch now ... lol | 11:44 |
| aeoril | (until I crash) | 11:44 |
| didrocks | ahah ;) | 11:45 |
| seb128 | 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:49 |
| seb128 | 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 |
| seb128 | 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:51 |
| seb128 | 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 |
| ubottu | Launchpad bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New] | 11:58 |
| === adam_g is now known as adam_g_out | ||
| cyphermox | seb128: I'm off today but since I've looked, I might as well review this :) | 12:28 |
| cyphermox | ah, that one | 12:28 |
| seb128 | 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:28 |
| cyphermox | no, rejecting; I had applied it in vivid and it broke things | 12:29 |
| seb128 | k | 12:29 |
| seb128 | thanks | 12:29 |
| seb128 | cyphermox, btw, did you do something about the nm-applet issue from the other day? | 12:29 |
| cyphermox | seb128: which? | 12:29 |
| cyphermox | the crash, yes | 12:29 |
| seb128 | cyphermox, the segfault | 12:29 |
| seb128 | right | 12:29 |
| seb128 | great | 12:29 |
| cyphermox | should be in archive now | 12:29 |
| seb128 | cyphermox, oh, I somewhat didn't notice the upload on vivid-changes, great, thanks ;-) | 12:31 |
| seb128 | 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:33 |
| cyphermox | oh, no | 12:34 |
| cyphermox | but it really looks like something broken by indicator, not by upstream | 12:34 |
| === Guest79913 is now known as gusnan | ||
| cyphermox | ie. fails because of hows things get started when you initialize the indicators | 12:35 |
| cyphermox | I'll get back to this on Monday | 12:35 |
| seb128 | cyphermox, weird, https://retrace.fedoraproject.org/faf/reports/352711/ seems similar | 12:37 |
| cyphermox | hmm, it really does | 12:42 |
| cyphermox | in any case, I think this should help a whole lot, but it's indicator-specific anyway | 12:42 |
| seb128 | cyphermox, that's why I suggested upstreaming it the other day :-) | 12:42 |
| cyphermox | I'll discuss the details with dcbw on monday | 12:42 |
| seb128 | thanks | 12:42 |
| seb128 | isn't monday off for you? | 12:42 |
| cyphermox | maybe there is a something else to do | 12:43 |
| cyphermox | nope | 12:43 |
| seb128 | k | 12:43 |
| cyphermox | maybe it's off for him though | 12:43 |
| cyphermox | most things already assert that devinfo is there (it being null causes the crash) | 12:43 |
| seb128 | tuesday is fine a well :-) | 12:43 |
| cyphermox | and it's expected to be set when devices are initially discovered | 12:43 |
| cyphermox | but I can't assert in this case, maybe just ignoring the device if it doesn't have the devinfo struct | 12:44 |
| seb128 | k | 12:45 |
| seb128 | 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 |
| ubottu | Launchpad bug 1411630 in openjdk-8 (Ubuntu) "Build-Depends cannot be fulfilled in precise" [Undecided,New] | 12:49 |
| doko_ | seb128, sure, next free work day, which is Thu or Mon in a week | 13:04 |
| doko_ | and I'm not keen on mitya57's patches ... there are still syncs initiated by mitya57 which ftbfs in -proposed | 13:05 |
| seb128 | doko_, no hurry, should I just unsubscribe sponsors and assign to you? | 13:06 |
| doko_ | seb128, sure, I can have a look | 13:08 |
| seb128 | doko_, thanks | 13:08 |
| seb128 | doko_, enjoy the easter days ;-) | 13:08 |
| smoser | seb128, that was on my list fl things to do today. | 13:11 |
| seb128 | smoser, great, thanks :-) | 13:11 |
| smoser | infinity, didrocks took a look at bug 1438520 and got a fix going forward, but we are wondering if there is a way to skip old prerm. | 13:21 |
| ubottu | bug 1438520 in cloud-init (Ubuntu) "cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution" [High,Confirmed] https://launchpad.net/bugs/1438520 | 13:21 |
| smoser | so that we could allow an upgrade to actually fix a system right now, rather than only future systems that don't have broken cloud-init. | 13:22 |
| smoser | anyone else is welcome to suggest fix also, it doesn't have to be ∞ | 13:22 |
| strikov | smoser: okay, so cloud-init gets restarted during upgrade, but maybe we can simply re-run initialization if (a) cloud-init start and (b) doesn't see 'init was successful' marker in /var/lib/<don't remember>? | 13:38 |
| smoser | strikov, so the problem is that cloud-init is in the image, and running 'upgrade'. | 13:40 |
| smoser | that upgrade triggers cloud-init upgrade. | 13:40 |
| smoser | which causes the series of maintainer scripts described at https://wiki.debian.org/MaintainerScripts | 13:40 |
| smoser | (upgrade) to run. | 13:40 |
| strikov | smoser: yep; cloud-init gets stopped (restarted) | 13:40 |
| smoser | and the pre-rm script there says "stop" | 13:40 |
| strikov | smoser: but why it doesn't finish initialization next time it runs? | 13:41 |
| smoser | so didrocks fix, which is right is to tell packaging "you dont want to stop or start or restart" (which is actually the behavior we want). | 13:41 |
| strikov | smoser: i.e. stop/start, oops i didn't finish init last time, let's do it now | 13:41 |
| smoser | but we have to deliver that configuration and have no way other thna packaging to do it. | 13:41 |
| smoser | strikov, it does finish next time. | 13:41 |
| smoser | but "next time" is on reboot | 13:41 |
| smoser | the problem will go away when we have images with cloud-init at this next (non-broken) version inside them. | 13:42 |
| strikov | smoser: yeah, that's the point; maybe we need to re-init not on reboot but every time with *start* cloud init but 'init finished' marked doesn't exist | 13:43 |
| strikov | smoser: then, it does everything needed when upgrade starts it after upgrade | 13:43 |
| smoser | hm.., yeah, so why didn't that happen.... | 13:44 |
| smoser | oh i thikn maybe because its a "one shot" service (Type=oneshot) | 13:45 |
| smoser | that the 'restart' only did a 'stop'. | 13:45 |
| smoser | effectively. | 13:45 |
| strikov | smoser: if we fix this (somehow) i think that upgrade will work fine; it stops during prerm, then starts on postint, cloud-init re-inits and we're done | 13:45 |
| smoser | i think i'm just going to upload the fix, an then we'll try to get "beta3" images made . so that only people that run the beta2 (out of date) image will see the issue. | 13:46 |
| smoser | it seems the least invasive, and i can think of further problems by it (basically it will then be behaving like upstart did) | 13:47 |
| smoser | strikov, your solution could definitely work though. | 13:51 |
| strikov | smoser: by uploading the fix you mean didrock's one or oneshot? | 13:51 |
| smoser | didrocks solution. | 13:51 |
| smoser | right now it *is* oneshot. (which it should be, its essentially a task not to be restarted when it exits) | 13:51 |
| didrocks | yeah, it should be oneshot | 13:52 |
| smoser | and i think that is why it doesn't get started on 'restart' | 13:52 |
| smoser | it just gets stopped | 13:52 |
| strikov | smoser: yeah, it should work i think; hope we don't meet oneshot issue later | 13:52 |
| strikov | smoser: ah, btw, does it mean that cloud-init is not upgradable? | 13:53 |
| strikov | smoser: because we basically use the old one even if we have upgrade available? | 13:54 |
| aeoril | didrocks Lintian questions: http://paste.ubuntu.com/10730634/ should I worry about this error and warning? | 13:54 |
| strikov | smoser: can we meet some issues if 'data' gets unpacked from new cloud-init but 'code' is from the previous one | 13:54 |
| smoser | strikov, well, it could . its just the 'cloud-config' portion that upgrades itself. so those modules. you're right though. | 13:55 |
| smoser | if there was a data format change, new versions would have to find they were using the old version's data and support it. | 13:55 |
| aeoril | didrocks also, the debdiff had a change in it I did not make - it appears the .dsc included with the utopic gdm package has an out-of-date .dsc in it??? | 13:56 |
| smoser | we have done some thing slike that before. when modules change names, it will rename the marker files. | 13:56 |
| didrocks | aeoril: no, that's fine (the utopic is due to your version of some packages not backported) and the standard-versions is not updated to latest, but you don't want to do that in a released version | 13:56 |
| didrocks | aeoril: you can use lintian-info --tags <the tag shown> to get more info btw | 13:56 |
| aeoril | didrocks what about the debdiff having an extra change in it that I did not make? | 13:57 |
| didrocks | aeoril: that's weird, do you have it handy? | 13:58 |
| didrocks | like pastebin it | 13:58 |
| aeoril | didrocks sure: http://paste.ubuntu.com/10730665/ lines 15-26 should not be there ... it looks like the .dsc included in the package is out of date ... | 14:01 |
| didrocks | ah that | 14:01 |
| didrocks | aeoril: don't worry, the uploaders lines are autoupdated (this is for debian) | 14:01 |
| didrocks | no incidence in ubuntu in practice :) | 14:01 |
| aeoril | didrocks not sure what you mean ... do you mean that this fix will only be used by debian? | 14:02 |
| aeoril | (per our previous discussion) | 14:02 |
| didrocks | aeoril: it's not really a "fix", it's a field used in debian to determine who can upload a package when some of the packages are co-maintained | 14:02 |
| didrocks | aeoril: after a while if someone didn't upload that package, he/she will be stripped out of the Uploaders: list | 14:03 |
| didrocks | but this is really just used in debian, not ubuntu | 14:03 |
| aeoril | oh, ok - thanks - I understand now | 14:03 |
| didrocks | aeoril: more information on https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Uploaders | 14:03 |
| smoser | didrocks, i've updated that bug with 2 comments, one describing what we decided to do and why, and the other showing how i tested that the solution fixes this problem. | 14:15 |
| * didrocks looks | 14:15 | |
| didrocks | smoser: looking good, thanks for summarizing :) | 14:17 |
| smoser | ugh | 14:17 |
| smoser | except for i didn't actually test it. | 14:17 |
| smoser | the ppa build failed | 14:17 |
| smoser | https://launchpadlibrarian.net/201943285/buildlog_ubuntu-vivid-amd64.cloud-init_0.7.7%7Ebzr1088-0ubuntu2%7Esm1_BUILDING.txt.gz | 14:17 |
| smoser | the build environment doesn't have /sbin/ip i guess. :-( | 14:18 |
| smoser | that recently changed | 14:18 |
| didrocks | argh | 14:18 |
| didrocks | @pilot out | 14:23 |
| === 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: | ||
| === mako_ is now known as mako | ||
| aeoril | didrocks thanks for all your help. I got the final patch attached for bug 1315442. It is up to darkxst now. | 15:05 |
| ubottu | bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442 | 15:05 |
| seb128 | hallyn, tyhicks, do you think https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264 is likely to be fixed for vivid? | 15:30 |
| ubottu | Launchpad bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged] | 15:30 |
| hallyn | seb128: no idea, i wasn't looking at it | 15:34 |
| hallyn | i thought tyhicks was working on it | 15:35 |
| hallyn | infinity: http://paste.ubuntu.com/10731209/ have you ever seen this? | 15:35 |
| hallyn | my program just does a fork() and seems to hit an assert inside fork inside libc and get hung | 15:35 |
| hallyn | i'll do some extra bookkeeping so i can kill that task if/when that happens, but it'd be nicer if that didn't happen :) | 15:35 |
| * hallyn tried to peek inside libc's fork but got lost somewhere on the minotaur level | 15:36 | |
| hallyn | it's libnih-dbus so maybe it's an at_fork handler i didn't know was being registered | 15:37 |
| hallyn | jinkeys, looks like | 15:42 |
| hallyn | assert (THREAD_GETMEM (self, tid) != ppid); | 15:42 |
| hallyn | may be failing, bc pid is 0 | 15:42 |
| hallyn | no, ppid is listed as 605. but that's wrong bc we had just done a setns(/proc/pid/ns/pid) before the fork, so pid is iddferent | 15:46 |
| hallyn | so presumably that's why this is racy - fork happens to have given me in the new pidns the pid of the parent in th eparent pidns | 15:47 |
| tyhicks | seb128: that fix stalled while I was investigating other issues that smoser reported to me which were similar symptoms but different causes | 15:50 |
| hallyn | yup that's what's going on. is there a way to force libc to update it's cached values i wonder | 15:50 |
| tyhicks | seb128: I hope to circle back to all the systemd/schroot/sbuild/ecryptfs bugs next week and prepare fixes | 15:50 |
| seb128 | tyhicks, ok, great, thanks | 15:51 |
| kirkland | tyhicks: did you happen to track down that boot/login critical problem? | 15:51 |
| seb128 | tyhicks, sorry for being naggy about that, but vivid release is soon, and that issue is quite annoying for dev who want to write apps for the phone | 15:51 |
| tyhicks | kirkland: no, I'm about to start debugging it again | 15:51 |
| hallyn | arguably libc's setns should just do that for us | 15:51 |
| tyhicks | seb128: I understand - sbuild/schroot internals are outside of my comfort zone | 15:52 |
| tyhicks | kirkland: I created bug #1439849 for that issue | 15:53 |
| ubottu | bug 1439849 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 0000000000000010" [Critical,Confirmed] https://launchpad.net/bugs/1439849 | 15:53 |
| smoser | seb128, sorry i took tyhicks off on a wild goose chase. | 15:53 |
| smoser | (well, not entirely wild) | 15:53 |
| seb128 | tyhicks, yeah, seems it's difficult to find somebody who has those in their confort zone though :-/ | 15:53 |
| * tyhicks nods | 15:53 | |
| seb128 | smoser, no worry, I'm sure you have good reasons :-) | 15:53 |
| tyhicks | kirkland: will you be able to https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940 ? There's no chance that I'll get to it before release. | 15:54 |
| ubottu | Launchpad bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New] | 15:54 |
| tyhicks | s/will you be able to/will you be able to review/ | 15:55 |
| mitya57 | doko: Which of my syncs FTBFS? It seems to me that I am not aware of that. | 16:29 |
| doko | mitya57, https://launchpad.net/ubuntu/+source/webkit2gtk/2.6.2+dfsg1-4 | 16:30 |
| doko | also a good idea to watch http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 16:30 |
| mitya57 | doko: I will look ASAP (maybe tomorrow). And I am watching that page, but it has a lot of entries so it's easy to miss something. | 16:32 |
| doko | heh, sure, but don't you get emails for build failures too? | 16:33 |
| mitya57 | No, I don't see any mails about webkit2gtk in my inbox, except the "accepted into proposed" one. | 16:35 |
| mitya57 | I think they are not sent to the sync sponsor. | 16:36 |
| tseliot | Riddell: apparently I also need to check (in gpu-manager) that sddm is the default. How do I do that? There's no /etc/X11/default-display-manager | 16:40 |
| tseliot | or gpu-manager will refuse to configure the system | 16:41 |
| Riddell | um, I don't know | 16:42 |
| Riddell | tseliot: I guess there should be /etc/X11/default-display-manager ? | 16:42 |
| tseliot | Riddell: I've just installed today's image and it's not there | 16:43 |
| tseliot | Kubuntu 15.04 daily | 16:43 |
| Riddell | tseliot: yes I confirm there's not, I guess it's a bug in the sddm packaging | 16:43 |
| tseliot | Riddell: ok, I hope this can be fixed soon. I'll write the file manually for now | 16:44 |
| tseliot | Riddell: does sddm have a log that I can use for debugging? | 16:55 |
| tseliot | Riddell: as it seems to ignore my settings in /etc/sddm.conf | 16:56 |
| Riddell | tseliot: /var/log/sddm.log ? | 16:59 |
| tseliot | Riddell: oh, I see the problem now. Thanks | 17:00 |
| sarnold | aeoril: there's a debian/control change in your utopic debdiff that I don't understand but the fix and changelog look good in both | 17:32 |
| aeoril | sarnold thanks for looking at it - I figure the .dsc must have been out of date on that "pull-lp-source" package. I did not make that debian/control file change | 17:33 |
| aeoril | sarnold I think it was didrocks that told me it was ok - just a debian thing, doesn't matter in Ubuntu??? | 17:34 |
| aeoril | sarnold three down, thousands to go! | 17:34 |
| sarnold | aeoril: yeah it probably doesn't actually matter; it just seemed out of place | 17:34 |
| sarnold | aeoril woo :) | 17:34 |
| aeoril | lol fun fun! | 17:34 |
| aeoril | darkxst informed me it is time to find a new bug on my own :) I want to find one with a non-trivial code change, preferably in C | 17:35 |
| aeoril | sarnold well, off to lunch ... thanks again ... :) | 17:38 |
| tseliot | Riddell: I had to make DisplayCommand blocking too (being a qprocess), or the script would get killed too soon. At least I'm not getting a black screen now (it all works on login). Something goes wrong on log out. I'll have another look at it next week | 17:39 |
| sarnold | aeoril: bon apetite :) | 17:40 |
| Riddell | tseliot++ thanks so much | 17:40 |
| tseliot | np | 17:40 |
| sarnold | aeoril: a pal ran into this bug yesterday.. lshw crashes when reading his uefi FAT filesystem.. https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/1437681 | 17:40 |
| ubottu | Launchpad bug 1437681 in lshw (Ubuntu) "lshw-gtk assert failure: *** stack smashing detected ***: lshw-gtk terminated" [Medium,Confirmed] | 17:40 |
| aeoril | sarnold ok, thanks - I'll look into it after I get back from lunch ... I'm hungry for food and bugs to kill! | 17:41 |
| aeoril | sarnold sweet - stack smashing! | 17:42 |
| sarnold | :) | 17:43 |
| mitya57 | doko: webkit2gtk fix is in archive, already built on one architecture | 18:40 |
| mdeslaur | cyphermox: so network manager no longer shows the dumb bridge devices, but I still got a notify osd "You are now connected to virbr0" | 18:41 |
| doko | mitya57, \o/ | 18:45 |
| mdeslaur | cyphermox: bug 1440166 | 18:49 |
| ubottu | bug 1440166 in network-manager-applet (Ubuntu) "network indicator displays notifications for virtual devices" [Undecided,New] https://launchpad.net/bugs/1440166 | 18:49 |
| aeoril | sarnold is this the "correct" place to get the source files for lshw-gtk? http://packages.ubuntu.com/source/vivid/lshw | 19:05 |
| sarnold | aeoril: I've found cases when packages.ubuntu.com data wasn't up to date; I prefer looking in launchpad.net/ubuntu/+source/<sourcepackagename> | 19:07 |
| sarnold | aeoril: so in this case, https://launchpad.net/ubuntu/+source/lshw | 19:07 |
| sarnold | aeoril: pull-lp-source should dtrt though | 19:07 |
| aeoril | sarnold pull-lp-source said "pull-lp-source: Error: The source package 'lshw-gtk' does not exist in the Ubuntu primary archive in vivid, vivid-security, vivid-updates or vivid-proposed" - is there any way to configure it so it finds the right source for lshw? | 19:09 |
| aeoril | sarnold oh, I know - "pull-lp-source lshw" ... right? | 19:09 |
| sarnold | aeoril: no, the best way I know to find the source package is to use apt-cache show lshw-gtk | grep ^Source | 19:10 |
| sarnold | yeah, exactly | 19:10 |
| sarnold | aeoril: if there's no Source: line, then its source package is named the same.. | 19:10 |
| aeoril | sarnold I just found out lshw and lshw-gtk were the same source package | 19:10 |
| aeoril | sarnold I do not understand your last comment | 19:11 |
| aeoril | sarnold Source: line where? | 19:11 |
| sarnold | aeoril: it's difficult to find the correct source package for a given binary package; the apt-cache show ... | grep ^Source: trick willtell you the source package name unless the name of the binary package matches the name of the source package, in which case the Source: line is absent | 19:12 |
| aeoril | oh, ok - I see now | 19:13 |
| aeoril | sarnold I'll tuck that away | 19:13 |
| aeoril | sarnold when I use pull-lp-source, it won't work unless I sudo it. This leaves all the entire contents with root as owner/group. I always have to do chown and chgrp so I can use them as myself. Is this normal? | 19:18 |
| sarnold | aeoril: probably you're running it from a root-owned directory; if you run it in a directory you already own it ought to work unprivileged | 19:21 |
| aeoril | sarnold no, I am running it from my home directory - I just checked, and the directory in which I just ran it is owned by me | 19:22 |
| sarnold | aeoril: well, the next step is to figure out why :) "strace -o /tmp/pull -f pull-lp-source lshw" and then look through /tmp/pull to find the permission denied messages that indicate you needed to use privileges to run it.. | 19:24 |
| kirkland | barry: howdy! still around? | 19:57 |
| kirkland | barry: wanna help me snapify ssh-import-id? | 19:57 |
| kirkland | barry: doesn't that sound like the perfect day to end the week? :-) | 19:57 |
| barry | kirkland: hi. i need to leave a little early today, but i have a few minutes | 19:57 |
| kirkland | barry: sweet | 19:57 |
| barry | :) | 19:58 |
| kirkland | barry: is this the best channel to hold this conversation? | 19:58 |
| barry | kirkland: maybe #snappy-devel | 19:58 |
| barry | er, #snappy | 19:58 |
| mdeslaur | cyphermox: I've attached a debdiff to bug 1440166 for your approval | 20:01 |
| ubottu | bug 1440166 in network-manager-applet (Ubuntu) "network indicator displays notifications for virtual devices" [Undecided,New] https://launchpad.net/bugs/1440166 | 20:01 |
| aeoril | sarnold I had root owner/group on ~/.launchpadlib - not sure why - I am guessing the first time I ran pull-lp-source, I ran it as root and it created that directory structure as root??? | 20:02 |
| aeoril | sarnold anyway, everything working now | 20:02 |
| aeoril | sarnold thanks :) | 20:02 |
| Unit193 | kirkland: Oooh, speaking of such, did you get the paste? | 20:03 |
| aeoril | Unit193 hey, I have fixed three bugs now! Long time no chat! | 20:03 |
| Unit193 | Howdy. | 20:03 |
| aeoril | Unit193 you remember me from #ubuntu-beginners-team? | 20:04 |
| Unit193 | Of course. Congrats. | 20:04 |
| aeoril | Unit193 yes, I am actually doing some meaningful work and have finally started contributing after all these years. Hope all is well with you. | 20:04 |
| aeoril | Unit193 I took a detour for 3 years into Javascript/Web development, but am back now | 20:05 |
| Unit193 | Heh, you were playing with websockets back then too. | 20:06 |
| aeoril | Unit193 yes, I started getting into a little node stuff even back then. Had a great time doing Javascript - fascinating stuff! It was amazing to see the technology unfolding rapidly in just the three years I was involved - simply amazing, actually! | 20:07 |
| aeoril | Unit193 the development tools and pretty much everything in browsers was just changing so fast and really good stuff | 20:08 |
| kirkland | Unit193: hiya -- the bitbucket stuff -- yeah, I need to create a bitbucket account so I can test it myself | 20:08 |
| kirkland | Unit193: it's on my list, haven't gotten to it yet | 20:08 |
| Unit193 | kirkland: Ah, sorry about that. In case you didn't have it https://bitbucket.org/snippets/unit193/q8My I left the copyright stuff there since it was minimal changes. | 20:09 |
| kirkland | Unit193: very good, I'll get it | 20:09 |
| Unit193 | Sure, no rush at all. | 20:09 |
| Unit193 | kirkland: And, poked them about being able to retrive keys not owned by you. | 20:10 |
| kirkland | Unit193: yeah, no kidding -- they really should remove the auth requirement on that | 20:12 |
| kirkland | Unit193: it's a friggin PUBLIC key! | 20:13 |
| infinity | smoser: Sure you sorted this out while I was asleep, but old-prerm is the very first thing called in an upgrade, you can't override it. | 20:57 |
| infinity | hallyn: I've never seen lll explode on a simple fork, no. I assume it's not actually all that simple, once the entire thing is unwound. | 21:00 |
| hallyn | yeah it's not "that" simple - but surprisingly easy to make happen | 21:02 |
| hallyn | part of hte problem is containers start with lowe rpids so it's almost guaranteed to eventually happen if you keep trying | 21:02 |
| sarnold | aeoril: aha! nice :) | 21:06 |
| aeoril | sarnold yes, I saw that on the stack trace dumped immediately to the screen, but misread the line and thought that that file was in the directory I was pulling hte source into. Once I looked at it again and saw it was in the root of my home directory, it became obvious after checking permissions. | 21:07 |
| darkxst | aeoril, you deleted the vivid patch from the bug? | 21:08 |
| aeoril | darkxst no - I deleted a misbegotten utopic patch (wrong debdiff) then reuploaded the correct utopic patch - there should be three now - vivid, trusty and utopic ... let me check ... | 21:08 |
| aeoril | darkxst apparently, I somehow deleted the vivid patch. Not sure how that could have happened. I will upload it again. Sorry. | 21:10 |
| aeoril | darkxst sorry about that - you can check it again now. I have re-uploaded it: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1315442 | 21:19 |
| ubottu | Launchpad bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] | 21:19 |
| aeoril | darkxst I am just trying to up my karma, or at least my subconscious is ... | 21:21 |
| psusi | so with the release of vivid getting so close now I am growing concerned that this critical bug that prevents installation on uefi systems is going to go unfixed... is anyone looking at https://bugs.launchpad.net/bugs/1418706 | 21:27 |
| ubottu | Launchpad bug 1418706 in ubiquity (Ubuntu) "Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install" [Critical,Triaged] | 21:27 |
| psusi | it looks like there is a severe underlying breakage in ubiquity and how it is running the partman scripts int he wrong order or in parallel | 21:27 |
| infinity | hallyn: Ahh, the upstream bug is an enlightening read. | 21:28 |
| infinity | hallyn: And also clear that it's not a regression from trusty, at least, so that's nice. | 21:28 |
| psusi | it will be *really* bad if vivid is released with this bug unfixed | 21:29 |
| infinity | cyphermox: Can you put investigating LP: #1418706 on your post-holiday TODO? | 21:34 |
| ubottu | Launchpad bug 1418706 in ubiquity (Ubuntu) "Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install" [Critical,Triaged] https://launchpad.net/bugs/1418706 | 21:34 |
| infinity | hallyn: I'm not sure I'd go so far as calling that a glibc bug, so much as a missing feature. The assertion seems entirely sane in a world where our parents' PID doesn't magically go away. :P | 21:36 |
| infinity | hallyn: But yeah. Icky. Would be nice to see patches from the container crowd with an implementation they feel would be both historically correct and also deal with the brave new world. | 21:37 |
| darkxst | aeoril, can you add the SRU paperwork to the bug also (https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template) | 21:43 |
| aeoril | darkxst ok, will try | 21:43 |
| aeoril | darkxst do you mean just adding a comment with the SRU Bug Template filled out? | 21:45 |
| darkxst | aeoril, edit the bug description | 21:45 |
| aeoril | darkxst ok, will do my best | 21:46 |
| hallyn | infinity: eh, what you say is probably more fair than what i say, but i guess i'd be more charitable if the end-result wasn't a mysterious hung task hung in assert() | 21:48 |
| hallyn | it wasn't a bug befor epid namesapces, but it's been a bug for a long time now | 21:48 |
| infinity | hallyn: I'm entirely on board with the behaviour being suboptimal. :P | 21:49 |
| hallyn | i'd still like to know whether anyone is working on the pthread mutex fixup to allow us to fix this | 21:49 |
| infinity | hallyn: The bug log doesn't imply a great deal of care-factor, but I can poke around and see if anyone's working on it internally. | 21:49 |
| infinity | hallyn: I wouldn't object to the "skip the assert if PPID == 0" bandaid, I don't think, but if it's already been worked around in software hitting the bug, I'd rather take some time and think about implications of a "correct" fix, whatever correct looks like. | 21:50 |
| hallyn | infinity: the ppid isn't registered as 0 though, unfortunately | 21:58 |
| aeoril | darkxst do you mind if I create the SRU paperwork and bpaste it for you to look at first then paste it into the bug description once it looks ok? Also, when did you need this? I have been working on bugs since 2:30 am my time and it is now 5:00 pm | 21:59 |
| aeoril | (getting played out) | 21:59 |
| darkxst | aeoril, just write it straight into the bug, you can always change it later if really needed | 22:01 |
| darkxst | I'm going to upload it soon, so should be done as soon as you can | 22:01 |
| infinity | hallyn: Oh, there was an imlpication of such in the bug. Definitely needs a bit more unwinding to understand, I guess. | 22:01 |
| aeoril | darkxst I have to cook right now for dinner, but I can do it after that - maybe a couple of hours max? | 22:02 |
| Unit193 | And in case you missed it, lot of backlog in #debian-devel about ddebs. | 22:03 |
| darkxst | aeoril, sure, even tomorrow would be fine | 22:04 |
| aeoril | darkxst oh, good - I'll plan on tomorrow afternoon then, if that is ok - maybe later this evening if I get a nap in | 22:06 |
| darkxst | aeoril, ok | 22:13 |
| infinity | darkxst: Did you sponsor that gdm upload I just rejected? :P | 22:54 |
| infinity | darkxst: You had some patch cruft in debian/-p2 which was obviously an oops. | 22:54 |
| darkxst | infinity, yes, hmm | 22:54 |
| darkxst | how did that get there! | 22:55 |
| darkxst | fixed now | 23:02 |
| aeoril | darkxst infinity was that bug 1315442 ? | 23:30 |
| ubottu | bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442 | 23:30 |
| darkxst | yes | 23:31 |
| aeoril | I guess I am not the only one who "oppsed" on it, although I did it several times ... | 23:31 |
| aeoril | "oopsed" ... | 23:31 |
| darkxst | seems I oopsed not you | 23:32 |
| aeoril | darkxst yes, I understand, but I had several "oopses" of my own on that silly thing | 23:33 |
| aeoril | My Gosh! Release is the 23rd of this month for vivid? | 23:42 |
| ClevrPwn | anyone know why UCK is having problems with GFXBOOT? (this seemed like the best room from the list to ask. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!