=== thomi_ is now known as thomi
[00:31] <hallyn_> xnox: so now lxc passed jenkins;  cgmanager is still listed as blocked;  does someone need to manually hit a switch, or will this resolve itself?
=== Ursinha-afk is now known as Ursinha
[00:35] <cjwatson> hallyn_: should catch up automatically
[00:36] <cjwatson> you'd think
[00:37] <cjwatson> yeah, I *think* it will, the master job apparently only finished 13 mins ago
[00:39] <hallyn_> ok thanks :)
[00:42] <cjwatson> I: [Fri Jul 18 00:28:01 2014] - Collected autopkgtest status for lxc_1.1.0~alpha1-0ubuntu2/cgmanager_0.27-0ubuntu7: PASS
[00:42] <cjwatson> looks good
[00:42] <cjwatson> yep, it's migrating
[00:50] <hallyn_> \o/
[00:50] <hallyn_> that should ease things for folks wanting to run systemd
[00:50] <hallyn_> or something
[00:50] <hallyn_> i forget what the problem actually was
[01:14] <cjwatson> sarnold: Have you had any luck with the librevenge MIR?  This is one of the approximately two remaining things blocking the giant libav (etc.) transition, and I think I just made a start at unblocking the other one
[01:14] <sarnold> cjwatson: not yet, still handling the emergency dialer merges
[01:15] <cjwatson> OK
[01:15] <sarnold> cjwatson: I expect to start the librevenge review tomorrow; depending upon how large it is, either finish tomorrow night or monday
[01:16] <cjwatson> Great, thanks.  We probably can't land the other piece until Monday anyway
[01:16] <cjwatson> (Always assuming that the gallery-app people don't hate my patch)
[01:16] <sarnold> hehe
=== ycheng-afk is now known as ycheng
=== _salem is now known as salem_
=== salem_ is now known as _salem
[02:23] <slangasek> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: slangasek
[03:19] <achiang> hallyn_: stgraber: have you guys seen a hugetlb error when creating a new lxc container? https://pastebin.canonical.com/113772/
[03:19] <achiang> oops, that is canonical.com pastebin... one sec
[03:19] <achiang> http://pastebin.ubuntu.com/7812203/
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest32427
[04:03] <hallyn_> achiang: cat /proc/self/cgroups, are you in a cgroup you own?
[04:04] <achiang> hallyn_: that error goes away after a reboot suggesting that something in the installation process is weird
[04:06] <hallyn_> my guess would be the login was done before systemd-login0 or systemd-shim was installed (depending on release), so you didnt' have your own cgroup;  then you installed those, rebooted, logged in, and got a cgroup you owned
[04:07] <achiang> hallyn_: hm... ok, i suppose i could investigate that hint. ftr, this is the exact script i'm using -- https://gist.github.com/achiang/70fb462d27af75be2794
[04:08] <achiang> hallyn_: it dies on line 86 for at least 1 other person; then restarting the PC, it picks up from there and seems to be ok
[04:09] <hallyn_> achiang: yeah - systemd-services gets installed there on line 6
[04:09] <achiang> hallyn_: right...
[04:09] <hallyn_> hm, no wait
[04:09] <achiang> hallyn_: um. should it be installed earlier or something?
[04:09] <hallyn_> how is this script used?
[04:09] <hallyn_> user-data?
[04:10] <hallyn_> it looks like you're running the script as a user ($HOME, etc) but you're doing apt-get without sudo
[04:10] <achiang> hallyn_: it's meant to be run as a normal user with sudo privs, and it's meant to automatically create an LXC container for a piece of software (ubuntu-sdk)
[04:11] <hallyn_> is it meant to be run under sudo?
[04:11] <achiang> yes
[04:11] <hallyn_> ok, then (a) verify my theory by doing a 'cat /proc/self/cgroups' before the lxc-start,
[04:11] <hallyn_> and then (b), if that's verified, then you can just add
[04:12] <hallyn_> apt-get install cgmanager-utils; cgm create all $(logname);  cgm chown all $(logname) $(loguid) $(loggid);  cgm movepid all $(logname) $$
[04:12] <hallyn_> (subsituting loguid and loggid with something real)
[04:12] <achiang> hallyn_: ok, i'll ahve to chase this tomorrow on a fresh VM since things already work here for me
[04:13] <achiang> hallyn_: good hints, thank you
[04:14] <hallyn_> np - good night
=== wgrant_ is now known as wgrant
[06:24] <slangasek> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[08:31]  * Elbrus is looking for the procedure to request a transition.
[08:32] <Elbrus> Debian transitions gnustep, I think it is wise if Ubuntu followed
[08:32] <Elbrus> s/transtions/transitioned/
[08:32] <RAOF> Elbrus: There isn't really an equivalent procedure.
[08:32] <Elbrus> ah
[08:32] <RAOF> At least as far as I know :)
[08:32] <Elbrus> how is the transition tracker filled then?
[08:32] <RAOF> Automatically, I believe.
[08:32] <Elbrus> http://people.canonical.com/~ubuntu-archive/transitions/
[08:32] <Elbrus> aha
[08:33] <RAOF> If gnustep is in Sid, though, we'll automatically go through that transition when it's autosynced.
[08:33] <RAOF> Unless it's got Ubuntu changes.
[08:33] <Elbrus> which it is not, because it has ubuntu specific changes...
[08:33] <Elbrus> yes
[08:33] <Elbrus> so I will need to look into that
[08:34] <Laney> Nah, those things are created manually
[08:34] <Elbrus> apperently the last time Ubuntu didn't fare well on gnustep transition (if I am to believe the Debian maintainer)
[08:35] <Elbrus> Laney: so how to request one similar to https://release.debian.org/transitions/html/gnustep.html
[08:35] <Laney> I'll make one for you
[08:35] <Laney> You going to handle the rebuilds/porting/whatever?
[08:35] <cjwatson> "last time" - when was that?
[08:36] <Elbrus> 10.04 if my memory of last tuesday serves me right
[08:36] <cjwatson> I remember doing some work on a gnustep transition a while back, I don't remember it going particularly badly
[08:36] <cjwatson> oh, that was long before we implemented proposed-migration
[08:36] <cjwatson> nowadays p-m (basically the equivalent of Debian's unstable->testing) means that we tend to notice such things
[08:37] <Elbrus> let me look up the bug I was thinking of
[08:37] <cjwatson> the Debian maintainer is probably out of date on our processes
[08:37] <cjwatson> however, could you please wait?
[08:37] <cjwatson> I'm terrified of anything else getting tangled up with the gigantic libav transition before we finish it
[08:37] <Elbrus> https://bugs.launchpad.net/ubuntu/+source/systempreferences.app/+bug/561920 and it's four brothers
[08:37] <ubottu> Ubuntu bug 561920 in systempreferences.app (Ubuntu) "SystemPreferences crashed with SIGSEGV" [Medium,New]
[08:38] <Elbrus> waiting no problem
[08:38] <cjwatson> I hope we'd probably have noticed that class of things nowadays, although the bug suggests that the package dependencies were inadequate if it managed to start but not crash, so maybe not.
[08:38] <Elbrus> actually, I am currently helping updating the gnustep stack, so when that is done in Debian a transition might be right time..
[08:38] <cjwatson> However, transition trackers normally just look at dependencies, so how much that will help ...
[08:39] <cjwatson> Elbrus: Chances are we'll auto-sync the start of the transition, if it's reasonably soon, and then notice.
[08:39] <Elbrus> cjwatson: don't think so as there are ubuntu specific changes
[08:39] <Elbrus> might be good to block fixing that somehow then...
[08:39] <cjwatson> libav should be done next week, so probably not a problem.
[08:40] <cjwatson> Certainly if Laney feels inspired to set up a transition tracker then great.
[08:40] <Laney> Elbrus: can you adjust http://paste.ubuntu.com/7813325/ to taste?
[08:43] <cjwatson> Incidentally, the reason we don't have much of a transition request procedure is that many of our transitions arrive by auto-sync from Debian, so it would be somewhat futile :)
[08:43] <Elbrus> cjwatson: ack
[08:44] <Elbrus> but how are "binNMU's" handled then in Ubuntu?
[08:44] <cjwatson> Manual rebuild-only uploads
[08:44] <cjwatson> (sadly)
[08:44] <Elbrus> Laney: I believe the libobjc[34] stuff is really old and not relevant anymore
[08:45] <cjwatson> I suspect I do the vast majority of them and I have some scripting for it so it doesn't take too much of my time
[08:45] <Elbrus> ah, how sad ;)
[08:45] <cjwatson> One of these days I'll implement binNMUs in Launchpad and persuade people to take it
[08:45]  * Elbrus doesn't have the permissions to do those, so they will all need acknowledgments from motus
[08:45] <cjwatson> If it's on a transition tracker I can just do them in bulk, not a problem
[08:46] <cjwatson> Rather than faffing about getting approval
[08:46] <Elbrus> (or me should finally apply for motu status)
[08:46] <Elbrus> ok, cool...
[08:47] <Elbrus> mind you, holidays are near, it might shift to after my holidays (not much time/internet combi available).
[08:47] <cjwatson> will be much easier if it can be before our Debian import freeze for 14.10 on 7 Aug
[08:47] <Elbrus> hmm, I'll see what I can do
[08:48] <cjwatson> thanks
=== ycheng is now known as ycheng-afk
[09:22] <Elbrus> Laney: http://paste.ubuntu.com/7813472/
[09:23] <Elbrus> seems like Ubuntu already has the base part, so only gnustep-gui is required
[09:23] <Elbrus> cjwatson: the Ubuntu diff is already incorporated in Debian, should I request a cync now, or wait until after libav?
[09:24] <Elbrus> s/cync/sync/
[09:26] <cjwatson> Elbrus: Let's wait
[09:26] <Elbrus> ack
[09:28] <Laney> Elbrus: kay, I pushed that as a "planned" transition
[09:29] <Laney> Should show up at http://people.canonical.com/~ubuntu-archive/transitions/ soon
[09:58] <Elbrus> cjwatson: how do I see (without me guessing) when you are done with the libav transition?
[09:59] <cjwatson> Elbrus: on https://launchpad.net/ubuntu/+source/libav, the "6:10.2-1" entry will move to "release" rather than "proposed"
[10:00] <Elbrus> ack
=== bruno is now known as Guest65297
=== gusnan_ is now known as gusnan
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
=== jibel_ is now known as jibel
[12:32] <mapreri> pitti: all the ubuntu deltas in scribus are now merged in debian. Do you mind sync scribus for me? :)
=== _salem is now known as salem_
[12:51] <R33D3M33R> hello: big problem after todays upstart upgrade -> cannot login anymore, please check: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1343800
[12:51] <ubottu> Ubuntu bug 1343800 in upstart (Ubuntu) "upstart 1.12.1-0ubuntu4.1 breaks xsession start with lightdm" [Undecided,Confirmed]
[12:55] <cjwatson> R33D3M33R: we already published 1.12.1-0ubuntu4.2 to fix that
[12:56] <R33D3M33R> great,t hanks!
[12:56] <cjwatson> R33D3M33R: can you try that and confirm?
[12:56] <cjwatson> R33D3M33R: if that fixes it, please mark your bug as a duplicate of bug 1343905
[12:56] <R33D3M33R> just a second
[12:56] <ubottu> bug 1343905 in upstart (Ubuntu Trusty) "Empty desktop in Xubuntu 14.04 on reboot after upgrading upstart package" [High,Fix committed] https://launchpad.net/bugs/1343905
[12:58] <R33D3M33R> sorry, I cannot upgrade since the repo I use, isn't synced yet, but judging by the symptoms the bug is really the same
[13:06] <R33D3M33R> found files, installed, rebooted, logged in with no problems -> marking as duplicate
[13:16] <cjwatson> R33D3M33R: thanks
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
[14:07] <barry> pitti: around?
=== Sweetsha1k is now known as Sweetshark
[15:25] <smoser> xnox, you had some primer about packaging for systemd i think ?
[15:26] <smoser> some doc. and how to enable it. which i thought was differen tthan https://wiki.ubuntu.com/systemd
[15:27] <smoser> hm..
[15:27] <smoser> stgraber, around ?
[15:27] <xnox> smoser: dh $@ --with systemd
[15:27] <xnox> smoser: and drop units into debian/*
[15:27] <smoser> didy ou have some doc ? i swear i saw something.
[15:28] <xnox> smoser: there is this https://wiki.ubuntu.com/SystemdForUpstartUsers
[15:28] <xnox> smoser: but it doesn't cover packaging
=== JanC_ is now known as JanC
[15:30] <smoser> xnox, thanks
[15:32] <stgraber> smoser: yep
=== Ursinha is now known as Ursinha-afk
[15:33] <smoser> would you expect http://paste.ubuntu.com/7814920/ to work
[15:33] <smoser> stgraber, ^
[15:35] <smoser> er... what i am trying to do is replace upstar twith systmmed
[15:35] <smoser> in the download container uptoic
[15:37] <stgraber> smoser: the apt-get install should succeed, now I doubt the container will start because systemd is silly and usually tries to mount some pretty scary stuff which gets rejected by apparmor and make it hang
[15:38] <stgraber> smoser: we'll have to come up with either some patches to systemd for that or maybe a variant of the container config that includes the few more bits that are needed
[15:38] <smoser> hm.
[15:38] <smoser> yeah. the apt-get install does work
[15:38] <smoser> but yeah, it hangs basically no boot
[15:38] <stgraber> smoser: you may want to look at e.g. the fedora config in /usr/share/lxc/config/ to see what kind of stuff may be needed. Also setting lxc.aa_profile = unconfined will help as a first step
[15:39] <smoser> stgraber, hm..
[15:39] <stgraber> oh and there's no chance that this would work in an unprivileged container because systemd currently just crashes if you try to start it in there (and yeah, we need to figure out a solution for that soon...)
[15:39] <smoser> dont care about unpriv
[15:39] <smoser> at the moment
[15:39] <smoser> but this will be expected to work at some point
[15:39] <smoser> obviously when /sbin/init == systemd
[15:40] <smoser> i was looking at cloud-images systemd
[15:40] <smoser> and ifgured it'd be easier to try first with lxc
[15:40] <smoser> (or at least faster)
[15:40] <smoser> but maybe i'll have more success looking first at kvm
[15:41] <smoser> i wanted to get a baseline working thing to look at.
[15:41] <stgraber> yeah, I'd expect kvm to be easier as that's what everyone's been using to test systemd so far :)
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[16:39] <LocutusOfBorg1> can anybody please sponsor this?
[16:39] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gccxml/+bug/1344039
[16:39] <ubottu> Ubuntu bug 1344039 in gccxml (Ubuntu) "Sync gccxml 0.9.0+git20140716-1 (universe) from Debian unstable (main)" [Undecided,New]
[16:39] <LocutusOfBorg1> this will (hopefully) fix the insighttoolkit4 problems in ubuntu
[16:39] <LocutusOfBorg1> and the new insighttoolkit4 is going to be uploaded in debian tomorrow I think
[16:39] <LocutusOfBorg1> so would be nice to see it building ;)
[16:40] <LocutusOfBorg1> thanks!
[16:41] <loucura> Hi! Is any Ubuntu developer aware of this critical ubiquity bug: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1265192 ?
[16:41] <ubottu> Ubuntu bug 1265192 in ubiquity (Ubuntu Trusty) "Install/reinstall wipes out all/other partitions" [Critical,Triaged]
[16:42] <loucura> It's causing people to lose data when installing Ubuntu.
[16:43] <loucura> And the 1st point release for Trusty is coming very soon, so fixing this before that would be great (and there's a workaround/fix provided in the comments).
=== Ursinha is now known as Ursinha-afk
=== rvr is now known as rvrOff
=== Ursinha-afk is now known as Ursinha
=== roadmr is now known as roadmr_afk
[18:03] <hallyn_> pitti: ok, so looking into stopping user sessions for systemd-logind;  first off, utopic still has systemd-204, which actually isn't utilizing systemd-shim at all i don't think;
[18:04] <hallyn_> pitti: when i use systemd-208, i have to edit /etc/systemd/logind.conf to set KillUserProcess=yes before StopUnit is sent;  in the other code path, unfortunately, it uses org.freedesktop.systemd.Scope method Abandon
[18:06] <Unit193> hallyn_: Tried shim/cgmanager to see how it'd work (I'm using 214+a few backports in trusty), had to enter password on hitting shut down, and suspend/hibernate were greyed out.
[18:07] <hallyn_> Unit193: 214??
[18:07] <hallyn_> where did you get the packaging for that?  ported from 208?
[18:08] <Unit193> Uhh, forget I said that and pretend I said 208? ;)  (Pulled from Debian experimental VCS and added most of the Ubuntu delta.)
[18:09] <hallyn_> Unit193: ok, i would drop the ubuntu delta (that's what i'm doing here), just do the following:
[18:09] <hallyn_> 1. set the Depends on libpam-systmemd from "systemd-sysv" to "systemd-sysv | systemd-shim",
[18:09] <hallyn_> 2. somehow arrange to create /run/systemd at boot,
[18:10] <hallyn_> 3. arrange for dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.StartServiceByName string:org.freedesktop.login1 uint32:0 to be done at boot,
[18:10] <hallyn_> and finally
[18:10] <hallyn_> 4. edit /usr/share/dbus-1/system-services/org.freedesktop.login1.service to set Exec=/lib/systemd/systemd-logind
[18:10] <Unit193> #1 is part of the delta.  And, alright.
[18:10] <hallyn_> yeah, but the systemd-204 delta is huge :)
[18:10] <hallyn_> and i'm sure we'll want to keep some of that in the end, but a lot of it we won't
[18:11] <hallyn_> mind you im' doing this in a server vm, so i'm not dealing with any of the desktop side effects - so what i'm saying may not help you, but a smaller delta makes it easier to talk to debian and systmed folks
[18:11] <Unit193> Right, I mostly went with what made sense for me to have (cgmanager support patches I didn't need, so dropped.)
[18:12] <hallyn_> perhaps i should push a proposed package to ppa to work from
[18:15] <achiang> hallyn_: stgraber: is there a way to pass a command line env var to a command while using lxc-attach?
[18:15] <achiang> CMD_LINE="QML2_IMPORT_PATH=$LIBDIR qmlscene telegram.qml"
[18:15] <achiang> lxc-attach --clear-env -n ubuntu-sdk -- sudo -u ubuntu -i cd `pwd | sed 's/achiang/ubuntu/'` && $CMD_LINE
[18:15] <achiang> gives an error
[18:16] <Unit193> hallyn_: http://paste.openstack.org/show/ZmJflIQxnlkQLxYaLWpV/ isn't so bad.
[18:16] <achiang> oh, maybe i'll try setting that before the cd
[18:20] <hallyn_> achiang: i don't understand the question :)  you want to clear the env but set one particular variable?  Simples might be to just have a script clear env, set what you want, then call lxc-attach
[18:20] <achiang> hallyn_: actually, i think i figured out the rune i need
[18:20] <hallyn_> Unit193: I'm going to set up a utopic desktop vm to play with this some more
[18:20] <hallyn_> achiang: excellent :)
[18:20] <hallyn_> Unit193: but first i'm going to push something to ppa so i can talk with others more sensibly
[18:21] <Unit193> hallyn_: Good plan!   Have fun!  I have mine pushed to a PPA, if you want to have a strange starting point. :P
[18:23] <hallyn_> Unit193: yours being based on 214?
[18:23] <hallyn_> (http://paste.openstack.org/show/ZmJflIQxnlkQLxYaLWpV/)
[18:24] <Unit193> Of course.
[18:24] <hallyn_> hm, lemme start with 208, then perhaps update to yours for a test - which ppa?
[18:25] <Unit193> /notice
[18:31] <achiang> hallyn_: with lxc-attach, can it only run a single command inside the container? i have something that looks like this: lxc-attach --clear-env -n ubuntu-sdk -- sudo -u ubuntu -i cd `pwd | sed 's/achiang/ubuntu/'` && ./build.sh
[18:31] <achiang> the && ./build.sh is getting run outside the container
[18:31] <achiang> i think this is probably an issue with my bash quoting
[18:31] <achiang> let me stick quotes around that...
[18:32] <hallyn_> yeah, and maybe even "( cmd && cmd )"
[18:32] <hallyn_> let us knwo what exactly you find works, that'llb e instructive
[18:32] <hallyn_> note you can also just write a python function and call it using the lxc python api's attach :)
[18:34] <achiang> ugh, no likey bash quoting
[18:40] <hallyn_> achiang: sudo lxc-attach -n u1 -- bash -c "ps -ef && echo $?"
[18:40] <hallyn_> worked for me
[18:41] <achiang> let me try
[18:42] <achiang> hallyn_: success. thanks!
[18:43] <hallyn_> \o/
[18:43] <achiang> 2014 and we're still fighting the shell
[18:43] <hallyn_> plars: hey, so this could relate to the trouble you've been having;  i just installed a utopic vm from the desktop install dvd, and the final shutdown is not finishing.
[18:44] <hallyn_> (note that never happens to me with installs from the netboot iso)
[18:44] <plars> oh?
[18:44] <plars> well, get this
[18:44] <plars> today - it passes
[18:44] <plars> mostly
[18:44] <plars> a lot better than it used to at least
[18:44] <plars> psivaa has been playing with it today
[18:44] <plars> we have no idea what made it start working though
[18:44] <plars> trusty and utopic both
[18:45] <plars> maybe something changed in the images and this was a legitimate bug we were hitting?
[18:45] <plars> I have no idea
[18:45] <hallyn_> sigh.  but this is not even using preseed - it's just hanging on the 'stopping crypto disks'
[18:45] <hallyn_> yeah, bug in eitghe rkernel or installer?
[18:45] <hallyn_> lemme ctrl-c and see if it boots up now
[18:45] <plars> maybe, yeah
[18:46] <plars> best guess so far is that /target wasn't unmounting at the end, and we were getting a good run of grub
[18:46] <hallyn_> booted up fine
[18:46] <hallyn_> yes, that sounds plausible
[18:46] <hallyn_> so anyway my vm is good.  and yeah that'll wreak havoc on any install automation
[18:46] <hallyn_> wonder if the same happens with trusty iso
[18:53] <hallyn_> cjwatson: (or whoever) - building systemd-208 fails due to a set of #includes (attr/xattr.h and sys/xattr.h) that are not getting along;  i've been working aroudn it locally by putting '#ifndef XATTR_CREATE' around the sys/xattr.h XATTR_CREATE blob, and copying that blog into attr/xattr.h
[18:53] <hallyn_> (see https://launchpadlibrarian.net/180250815/buildlog_ubuntu-utopic-amd64.systemd_208-6ubuntu1%7Eppa1_FAILEDTOBUILD.txt.gz)
[18:53] <hallyn_> i'm not sure what the best way to resolve this is
[18:53] <hallyn_> maybe i shoudl take the weekend to clear my head and fix it whatever way seems cleanest then...
[18:54] <hallyn_> well, for now i'll push packages with the dumb fix to my ppa i guess
=== roadmr_afk is now known as roadmr
[19:11] <cjwatson> hallyn_: Sounds like a libc thing - you probably want infinity
[19:13] <hallyn_> ok, will wait.  really one could argue it's all my own fault as i'd tried to address this in kernel+libc upstream a few months ago, and obviously didn't fully fix it.
[19:14] <hallyn_> i'm putting the lazy fixes into ppa:serge-hallyn/systemd for now
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[20:52] <sarnold> slangasek: the new shadow package mterry uploaded has some quilt patches that apply with fuzz during build: https://launchpadlibrarian.net/180235013/buildlog_ubuntu-utopic-amd64.shadow_1%3A4.1.5.1-1.1ubuntu2_UPLOADING.txt.gz -- I thought the quilt patches had to be perfect or the build would fail. what am I missing?
[20:54] <Laney> sarnold: That limitation is for source format 3.0 (quilt) packages - this one is format 1.0 and driving quilt itself (via cdbs)
[20:54] <sarnold> Laney: ah! so what-patch lies :)
[20:55] <Laney> if it says quilt then that's not a lie
[20:55] <Laney> maybe it could differentiate between quilt and 3.0 (quilt) though
[20:59] <sarnold> Laney: ah perhaps it already does and I didn't know how to read it ;)
[20:59] <sarnold> Laney: thanks :)
[20:59] <sarnold> slangasek: Laney answered, feel free to ignore ;) thanks
[21:00] <Laney> I don't blame you for finding the slightly different implemtations of quilt confusing. :)
[21:02] <sarnold> Laney: hehe, I wonder how many times I've worked with a similar package without even noticing :)
[21:03] <sarnold> It was just a worry that I had screwed up somehow and got fuzz locally when there sholdn't have been any in The Real Package..
[21:03] <Laney> It's probably good practice to defuzz a patch anyway
[21:03] <sarnold> it's in 'shadow', what could go wrong? :)
[21:04] <mterry> I don't think *I* caused the fuzz, but yeah, I didn't notice it was fuzzed in order to defuzz
[23:00] <xnox> "In this situation, gzip /dev/inside to deflate, then pipe the compressed air to /dev/input to clean your keyboard. Avert your eyes when you do."
[23:00] <xnox> awhhhhh =) if only that was true =)
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem