[05:43] <dodeluser> I create a remastered ubuntu iso with this genisoimage syntax:  http://pastebin.com/WR8kJxbN             but the iso is not "hybrid" as I cannot write it to usb with "dd" and boot (does not boot) . what am I doing wrong?
[05:55] <pitti> arges: hey! would you mind looking at systemd in unapproved? https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1437375/comments/19 has the explanations
[05:56] <pitti> arges: what was uploaded yesterday was not meant to go into -proposed, I uploaded a newer version now
[05:57] <pitti> infinity, RAOF ^ or someone else in ~ubuntu-sru
[06:00] <RAOF> pitti: Certainly, sir!
[06:00] <infinity> pitti: Nope, but RAOF will!
[06:02] <pitti> RAOF: cool, thanks!
[06:07] <RAOF> pitti: Want to add the various SRU headers to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1448259 ?
[06:07] <RAOF> pitti: Particularly test-case (although I expect that you'll be aggressively following up anyway)
[06:09] <pitti> RAOF: ah, can do; there are several reporters who will test this anyway (and already did so in the PPA)
[06:09] <pitti> RAOF: I'll add it
[06:09] <pitti> I thought the description was already sufficiently clear
[06:10] <RAOF> pitti: It is pretty clear, but it's nice to have a simpleminded test case to run through :).
[06:10] <pitti> RAOF: added
[06:10] <RAOF> pitti: Also - what's the regression potential for it? The comment in the revert is all ‘waiting for this is unreliable and breaks stuff’.
[06:11] <pitti> RAOF: typing
[06:12]  * RAOF holds his finger over the ‘accept’ button...
[06:12] <RAOF> ...oh! Tea's ready!
[06:12] <RAOF> :)
[06:13] <pitti> RAOF: added
[06:14] <RAOF> Ah, ok. So the worst failure mode is “shutdown is delayed by some number of 90s timeouts”? Rad.
[06:15] <pitti> RAOF: reportedly in nspawn
[06:15] <pitti> RAOF: so it could also be in LXC
[06:15] <pitti> RAOF: but I've never seen that, so I can't really tell how often it happens
[06:16] <pitti> RAOF: it's ceratinly not a real fix, just a compromise to let stuff actually shut down cleanly (bash, mosh, probably other programs too)
[06:17] <pitti> now: session gets immediately SIGKILLed
[06:17] <pitti> with patch: session gets SIGTERMed, cgroup for the session is being watched for becoming empty, then it gets removed
[06:17] <RAOF> Yeah, seems reasonable.
[06:17] <RAOF> Accepted.
[06:17] <pitti> and it will eventually get SIGKILLed if something is hanging
[06:18] <pitti> RAOF: cheers
[06:48] <cjwatson> wgrant: "reverse-depends: Error: Unknown release" is that something you can fix?
[06:48] <cjwatson> ajmitch: ^- or you?
[06:50] <wgrant> tumbleweed: ^^
[06:58] <pitti> who has the power to modify the description on http://summit.ubuntu.com/uos-1505/meeting/22514/systemd-and-ubuntu-to-1604/ ?
[06:59] <seb128> pitti, I can
[06:59] <pitti> slangasek and balloons are probably already asleep -- dholbach?
[06:59] <seb128> what do you need changed?
[06:59] <pitti> seb128: ah -- let me think
[07:01] <pitti> seb128: how about this: http://paste.ubuntu.com/11005549/
[07:01] <seb128> pitti, done
[07:01] <pitti> seb128: merci beaucoup !
[07:01] <seb128> de rien !
[07:13]  * mgedmin is amazed that his laptop takes more than 20 minutes to reboot (gave up waiting for shutdown staring at a black screen, used alt-sysrq-s,u,b)
[07:18] <pitti> mgedmin: something is clearly hanging; can you have a look at /usr/share/doc/systemd/README.Debian for debugging shutdown hangs?
[07:19] <mgedmin> thanks for that hint!
[08:10] <tjaalton> why would installing xserver-xorg-lts-utopic on trusty cause this http://pastebin.com/S3Zy0FQB ?
[08:10] <tjaalton> the x bits haven't changed
[08:10] <tjaalton> proposed is enabled, though it didn't change without
[08:30] <tjaalton> ok libegl1-mesa-drivers-lts-utopic needs to be installed manually
[08:30] <tjaalton> which is weird
[10:02] <pitti> mvo_: mind if I steal your util-linux merge?
[10:16] <mvo_> pitti: go for it
[10:31] <Laney> tumbleweed: is it on your stack again or should someone else take over?
[12:07] <doko> pitti, bzr ftbfs
[12:29] <zyga> mdeslaur: ping
[12:29] <zyga> mdeslaur: I watched the gsettings vieo
[12:29] <zyga> video*
[12:29] <zyga> mdeslaur: I have one observation that you may find interestinog
[12:29] <zyga> interesting*
[12:30] <zyga> mdeslaur: windows went through a similar approach
[12:30] <zyga> mdeslaur: windows has a layer where some writes are translated
[12:30] <zyga> mdeslaur: and writes to legacy paths are redirected to per-user location
[12:31] <zyga> mdeslaur: this works for filesystem and the registry
[12:31] <zyga> mdeslaur: I can give you pointers after a meeting I'm in
[12:48] <pitti> doko: ah, just saw the mail, yes
[14:13] <Laney> ev: can we maybe delete https://launchpad.net/libtimezonemap ?
[14:13] <Laney> afaik https://launchpad.net/timezonemap is the real thing
[14:28] <ev> Laney, wgrant: any idea how I'd do that?
[14:30] <wgrant> Laney, ev: YOu can't, since it's linked to the libtimezonemap source. You need to unlink it first.
[14:31] <ev> can the UI say that?
[14:31] <wgrant> Well, a mortal also can't delete a project themselves anyway, mostly for historical reasons.
[14:31] <wgrant> But even I can't until it's unlinked.
[14:32] <ev> its unlinked now
[14:32] <wgrant> Yep
[14:32] <Laney> Cheers chaps
[14:32] <wgrant> It's also gone now.
[16:14] <slangasek> barry: your dmesg output has some strange delays in it.  But it also shows the drm module loading 15s after boot, and completing initialization within 2s... so I don't think that explains the gpu-manager delays you're seeing.  It also looks like this all happens in the initramfs and your rootfs is only mounted 17s after boot, which is odd
[16:14] <slangasek> barry: anyway, your 8s delay in the initramfs can't be blamed on systemd ;)
[16:15] <barry> slangasek: ok.  i reboot this machine so infrequently i just haven't been annoyed enough to dig into it.  it's basically been upgraded since lucid at least, so it could be fairly crufty
[16:27] <bdmurray> mpt: Do you have a color suggest for wily for errors.u.c?
[16:30] <smoser> hey... anyone have an idea on how to determine if a drive is bootable ?
[16:30] <smoser> i'm guessing that mr watson has an idea, or that grub can somehow figure it out.
[16:31] <smoser> cjwatson, ^ didnt want to bother you, but if you're there .
[16:33] <tumbleweed> Laney: on it
[16:34] <Laney> cool
[16:34] <Laney> noticed that reverse-depends is broken for wily because of it
[16:35] <tumbleweed> yeah, that's a thing
[16:35] <cjwatson> smoser: grub won't be able to; if I were you I would look up the spec for whatever firmware is in use and implement the algorithm prescribed there
[16:36] <cjwatson> (in the case of BIOS, look up the congealed wisdom of the internet rather than the spec, but there's still an algorithm that the firmware implements)
[16:51] <strikov> smoser: I know nothing about gpt but in case of mbr arbitrary code can be stored inside the mbr boot recoder. It means that the only thing you can check is 0x55AA signature at the end of this code.
[16:52] <strikov> anything else (partition to boot for example) depends on the code which makes decision i.e. you can't understand what's on its mind without running it
[16:52] <smoser> strikov, wellk i need to figure out which device the bios would look at for that data.
[16:53] <smoser> ie, i need the bios search order. or even more simplistically, "would the bios boot from this drive".
[16:53] <cjwatson> there's no way to discover the real bios search order from the os.
[16:53] <smoser> thats what i thought..
[16:53] <smoser> but that sucks.
[16:53] <strikov> smoser: iirc, in case of mbr disks bios chooses first with correct 0x55AA (or AA55 don't remember) signature at the end of boot record
[16:53] <cjwatson> some bioses also implement a bit more than just 55aa too - they check things about the partition type
[16:53] <cjwatson> *partition table
[16:54] <smoser> right.
[16:54] <cjwatson> I expect it's possible to find a sample algorithm somewhere
[16:54] <smoser> well, my google foo fails me.
[16:54] <smoser> just now, i have 2 systems... one of them is ocnfiugred in the bios to boot from cciss/c0d0, one is not.
[16:55] <smoser> i have no way to know, and thus fail to boot on one and work on the other.
[16:55] <smoser> really dont want the user to have to tell me.
[16:55] <cjwatson> this is why my advice for a long time was to install the boot loader to the master boot record of all installed non-removable disks.
[16:56] <smoser> yeah
[16:56] <cjwatson> feel free to try to come up with something better, but I tried for years and failed.
[16:56] <smoser> cjwatson, the othe rthought was to do so, and somehow fingerprint which it came from
[16:56] <strikov> smoser: hm, bios settings are stored inside a separate chip which is powered via the battery on the motherboard
[16:56] <cjwatson> pretty sure I've been down all these paths before you :)
[16:57] <smoser> cjwatson, yes.. .that is why i bother you.
[16:57] <cjwatson> ... and found that it was impossible.
[16:57] <cjwatson> anyway, have to go for dinner, sorry
[17:55] <pitti> elmo, apw: in case you are interested in the "move from ifupdown to networkd" session: https://plus.google.com/hangouts/_/hoaevent/AP36tYdEA6lEvNPGjxR0J_YbKeXK6hLl5joZb9ERTmNXMVN3Fd8Pqg
[17:59] <bdmurray> pitti: If want to create the wily branch of apport I'd just take ~/ubuntu-core-dev/ubuntu/vivid/apport/ubuntu and then push to s/vivid/wily/ right?
[18:40] <leszek> hi does anybody have a clue on what might be wrong when add-apt-repository is adding ppas but with wrong codename (wily instead of vivid) even though /etc/lsb-release is set up correctly and in python aptsources.distro.get_distro().codename shows vivid correctly ? Where does the add-apt-repository script grab the codename from ?
[18:43] <leszek> even SoftwareProperties.distro.codename() shows the correct one vivid
[18:43] <leszek> but in the end it adds wily to the sources
[18:43] <leszek> when I try to add a ppa
[18:44] <Unit193> codename = get_current_series_from_lp(self._info["distribution"])  is what I'm seeing.
[18:48] <leszek> Unit193: thats means ? It only gets the current version of the ppa or what exactly ?
[18:52] <leszek> anyhow it should always add the ppa for the distro I am currently using and not for the one that is default set on ppa (or whatever)
[18:53] <leszek> and best of all the ppa (kubuntu backports) that I want to add does not even have a wily repo xD
[19:04] <leszek> ah ok now I found a clue. Distro Name changing to somethign else then Ubuntu causes the issue. WTF
[19:04] <leszek> in /etc/lsb-release
[19:06] <leszek> I am still not getting why that is though or even should be
[19:10] <pitti> bdmurray: sorry, was in UOS sessions; yes, we need to do that anyway, before we change apport in wily
[19:10] <pitti> bdmurray: thanks for setting up the wily branch! (please update Vcs-* in debian/control too)
[19:17] <hallyn> slangasek: if you have time, would you mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.37-1.dsc into sid?  Also, would you be willing to sponsr me for Debian DM?
[19:17] <highvoltage> :)
[19:46] <arges> infinity: added bug 1452877, going to patch it. any objections ?
[19:49] <infinity> arges: Already fixed in vivid (task updated), but go nuts on the SRUs, sure.
[19:49] <arges> infinity: cool
[19:49] <infinity> Err, s/vivid/wily/
[19:49]  * infinity updates properly.
[19:49] <infinity> My poor brain won't shift codenames for another week or two.
[19:50] <infinity> Despite how many times I've typed "wily" this week.
[19:50] <arges> i keep typing willy
[19:53] <dobey> wascwy wabbit
[21:15] <Unit193> robert_ancell: Now that it is wily time, care to look at lp 1295207?  Been using the patch for a couple months now.
[21:16] <robert_ancell> Unit193, yeah, I guess that makes sense
[21:17] <Unit193> Looks like it may be fixed once .12 is released as well.