[03:26] <Noskcaj> thanks for the syncs Logan_. There should be a fair few more there
[03:26] <Noskcaj> And another SRU
[03:27] <Logan_> Noskcaj: lol, you should be happy I'm doing this now. first day of the new semester tomorrow :O
[03:28] <Noskcaj> :)
[03:28] <Noskcaj> I've got another week still
[03:28] <Logan_> unfortunately there aren't any Ubuntu packaging classes I could TA
[03:28] <Logan_> it's a shame
[03:28] <Noskcaj> Are there any ubuntu packaging classes ever now?
[03:29] <Logan_> if there were one, that would be awesome
[03:29] <Logan_> make it happen!
[03:30] <Noskcaj> i'll try. First i need all the xubuntu 14.01 stuff sponsored and to finish adopting xsane
[05:47] <pitti> Good morning
[07:58] <jibel> pitti, provisioning of VMs for adt is working with kernel -5
[07:58] <pitti> jibel: indeed, I verified this morning
[08:07] <dholbach> good morning
[08:11] <pitti> erk, since when do we switch consoles using Alt+Left/Right? that's very confusing, and I use these for other things already
[08:12] <pitti> is that a kernel thing, or X.org?
[08:12] <pitti> apw, RAOF ^
[08:13] <mlankhorst> morning
[08:32] <pitti> stgraber: if I may bother you again: I use apt-cacher-ng on my workstation; is it possible to tell lxc to set an apt proxy for creation of a container? or is that  something you'd set up manually for each container after its created?
[08:47] <smb> pitti, Courtesy of unity default keybindings I would guess. The kernel does not care about that
[08:48] <pitti> smb: I can switch between VTs with Alt+left/right as well
[08:49] <didrocks> (nothing related to unity keybindings)
[08:49] <pitti> gah, it's only now that I realize how often I use Alt+left/right
[08:49] <pitti> switching between channels in IRC, going back and forth in firefox
[08:49] <pitti> I'm fairly sure this is new from today
[08:50] <pitti> or new with kernel -5, I was running the saucy kernel yesterday afternoon to test something else
[08:50] <pitti> I'll bisect
[08:50] <didrocks> pitti: I didn't update yet and alt + left/right works here to switch IRC channels
[08:50] <didrocks> pitti: let me see what I didn't update since yesterday
[08:51] <smb> pitti, I woul d be pretty sure that the changes between those kernels did not contain something to change that
[08:51] <didrocks> pitti: http://paste.ubuntu.com/6796175/
[08:51] <didrocks> quite a lot
[08:51] <didrocks> want me to try upgrading to latest kernel first?
[08:52] <pitti> didrocks: yeah, fortunately most packages are unrelated to that
[08:52] <smb> didrocks, that at reast would rule out the that or not
[08:52] <pitti> didrocks: if you want; I'll try downgrading the kernel first, and then some other updates
[08:52] <apw> pitti, using -5 kernel here and Alt+Left/Right is working as expected
[08:52] <smb> pitti, Thats still installed, no?
[08:52] <didrocks> pitti: as you wish, I can apt-get install linux-image
[08:52] <pitti> smb: "still installed"> I'm running that, if you mean that
[08:53] <smb> pitti, I mean downgrading to -4
[08:53] <smb> Both should be installed if you upgraded
[08:53] <smb> via grub
[08:53] <pitti> smb: apt-get autoremove already cleaned it up, but I'll get it from LP
[08:53] <pitti> sec
[08:54] <smb> apw, Isn't autoremove supposed to leave at least the previous one?
[08:55] <pitti> smb, didrocks: ah, a mere reboot fixed it apparently (without changing packages)
[08:55] <apw> the last three, plus the current kernel if it isn't one of those
[08:55] <pitti> so it was either some funny thing that qemu or LXC did this morning, or some transient thing from dist-upgrading without rebooting
[08:55] <pitti> smb, apw: I had -5 installed and running, plus the saucy kernel, so -4 got autocleaned
[08:56] <pitti> which I was quite happy about, given how leaky -4 was
[08:56] <pitti> perhaps booting precise in LXC does some funny console setup or so?
[08:56] <smb> pitti, It surely was not the best one. Though I would not expect autoremove to be that smart ;)
[08:56] <pitti> smb: ah, it doesn't have a "remove dangerous kernels" mode? :-)
[08:57] <apw> no indeed :)
[08:57] <pitti> reminds me of http://www.youtube.com/watch?v=ytVdBLMmRno
[08:57] <pitti> (watch it till the end)
[08:57] <apw> perhaps you were running the saucy kernel when you autoremoved
[08:57] <smb> pitti, Maybe if we flag them as broken when we send them out. Like all those we do especially to check whether qa is paying attention. ;-P
[08:59] <pitti> apw: no, that was this morning when I ran -5
[08:59] <didrocks> pitti: oh :)
[08:59] <pitti> apw: anyway, I had the current, running, and a previous kernel
[09:01] <jibel> pitti, re proxy for LXC, set HTTP_PROXY to your apt proxy or to 'apt'
[09:01] <jibel> pitti, ie sudo HTTP_PROXY=apt lxc-create ....
[09:01] <pitti> jibel: ah, nice
[09:01] <jibel> or or sudo HTTP_PROXY="http://.../" lxc-create....
[09:03] <pitti> hm, doesn't seem to work
[09:03] <pitti> I can stop apt-cacher-ng and it still works; and there's nothing in the container's apt.conf.d/ to set it?
[09:03] <pitti> jibel: ^
[09:04] <pitti> jibel: or perhaps this doesn't work as it's using a cached base system already
[09:04] <jibel> pitti, yes, you may need to flush the cache with option -F of the template
[09:05] <pitti> jibel: trying
[09:06] <jibel> pitti, "sudo HTTP_PROXY=apt lxc-create -n test_proxy -t ubuntu -- -F -d" works here and it creates /var/lib/lxc/test_proxy/rootfs/etc/apt/apt.conf.d/70proxy with the right proxy
[09:07] <pitti> jibel: ah, so I suppose it doesn't create that file when using a cached base fs
[09:08] <pitti> jibel: ah, now it's using apt-cacher-ng even during creation
[09:08] <pitti> jibel: merci
[09:08] <pitti> stgraber: ^
[09:10] <pitti> jibel: ah, HTTP_PROXY=apt would use 127.0.0.1, which doesn't work in a container; but it proves that it did configure a proxy :)
[09:11]  * pitti updates it to 10.0.3.1
[09:12] <jibel> pitti, right, =apt gets the configuration from apt, alternatively you can specify the IP or hostname of your host instead of apt
[09:12] <jibel> if it is on the same machine
[09:13] <pitti> ah, hostname sounds like a nice idea, avoids hardcoding the IP
[09:13] <pitti> so 70proxy is *not* in  /var/cache/lxc/precise/, so lxc-create does create it after copying; but apparently not if it's using a cache
[09:14]  * pitti files a bug, that doesn't sound hard to fix
[09:14] <oskie> hello. it seems cloud-init or something is bricking my machines if I set up my own ephemeral...
[09:20] <pitti> stgraber, jibel: FYI, filed bug 1271455
[09:23] <pitti> yay, now my host ubuntu, schroots, autopkgtest, and now lxc are all using the same apt-cacher-ng; this thing rocks :-)
[09:51] <darkxst> pitti, any chance you could take a look at https://code.launchpad.net/~darkxst/ubuntu/trusty/gdm/nokill/+merge/202393
[09:52] <pitti> darkxst: sure
[09:52] <darkxst> note debian does not kill gdm in postinst, except in the case where they transition from gdm -> gdm3
[09:52] <darkxst> thanks
[09:53] <pitti> darkxst: hm, not in the recent big upload though, it seems? (http://launchpadlibrarian.net/162697567/gdm_3.8.4-0ubuntu2_3.10.0.1-0ubuntu1.diff.gz)
[09:56] <pitti> darkxst: uploaded
[10:01] <darkxst> pitti, thanks, that code has been there for a while, but only just started triggering a kill
[11:29] <TuxBrother> I'm trying to build the suPHP package updated to 0.7.2 with uupdate
[11:29] <TuxBrother> But it seems the libtool patch is causing the build package command to fail
[11:30] <TuxBrother> Can someone look into this? 0.7.1 Has an exploit
[11:36] <mitya57> TuxBrother: try filing a bug :)
[11:36] <mitya57> Is that an Ubuntu-specific patch?
[11:36] <TuxBrother> I don't know
[11:37] <mitya57> What patch then?
[11:38] <TuxBrother> http://www.suphp.org/Home.html < FYI The patch: 02_libtool.dpatch in debian/rules/patches
[11:38] <TuxBrother> mitya57: Do I need to post the contents on pastebin?
[11:40] <mitya57> TuxBrother: Err, what package is that patch in? Is suPHP packaged in Ubuntu?
[11:40] <mitya57> I thought it was not.
[11:41] <mitya57> Ah, it is, let me look then.
[12:21] <TuxBrother> mitya57: Any luck so far?
[12:26] <mitya57> TuxBrother: https://launchpad.net/ubuntu/+source/suphp/0.7.2-0ubuntu1
[12:27] <TuxBrother> Great1
[12:28] <TuxBrother> mitya57: Any chance to see this backported to precise?
[12:29] <mitya57> TuxBrother: please file a bug first.
[12:29] <mitya57> Then I'll attach a debdiff for security team review.
[12:33] <mitya57> TuxBrother: http://paste.ubuntu.com/6797026/ — this is the relevant part of the diff, right?
[12:36] <TuxBrother> mitya57: I'm not a developer, only a sysop
[12:38] <TuxBrother> I will file a bug report later today
[12:39] <mitya57> OK, feel free to subscribe me (~mitya57) there
[12:53] <mitya57> zyga: Any reason why you plainbox autopkgtest is redirecting output to /dev/null? It makes it harder to figure out what happens.
[12:53] <mitya57> Also, maybe you are going to fix the failure yourself? :)
[13:14] <zyga> mitya57: my ignorance while writing the initial tests, it's on my TODO list, just swamped with other tasks
[13:15] <zyga> mitya57: it prints to stderr and I just need to add that flag to make that safe
[13:15] <zyga> mitya57: if you remember how to do it could you please fix it in debian SVN? I'll make my life easier with the next release
[13:17] <zyga> it'll
[13:18] <mitya57> zyga: OK, actually I've already found the failure and am looking at that
[13:18] <zyga> mitya57: what is the failure?
[13:19] <mitya57> FAIL: test_perfect_match (impl.exporter.test_html.HTMLExporterTests)
[13:19] <mitya57> ----------------------------------------------------------------------
[13:19] <mitya57> Traceback (most recent call last):
[13:19] <mitya57>   File "/usr/lib/python3/dist-packages/plainbox/impl/exporter/test_html.py", line 142, in test_perfect_match
[13:19] <mitya57>     self.assertEqual(self.actual_result, expected_result)
[13:19] <zyga> mitya57: hmm, interesting!
[13:19] <mitya57> (LOTS of HTML output below)
[13:19] <zyga> mitya57: can you pastebin that somewhere? alternatively, can you open a bug on lp:checkbox with that output?
[13:20] <mitya57> Will do
[13:20] <smb> infinity, something for your "amusement" (as you seem to be touching eglibc quite often): bug 1271534
[13:20] <mitya57> Let me try assertMultiLineEqual first
[13:20] <zyga> mitya57: many thanks!
[13:20] <zyga> mitya57: perhaps self.maxDiff = None will help
[13:22] <mitya57> Ah, that is bytes, not str, so assertMultiLineEqual doesn't much help
[13:37] <mitya57> zyga: filed bug 1271542 and attached output there
[13:40] <zyga> mitya57: thanks, we'll take it from there
[13:40] <zyga> mitya57: I love how launchpad renders graphics in that log :)
[13:43] <mitya57> Yes, my Firefox also thinks it's HTML file ;)
[13:44] <zyga> mitya57: yeah, that test is checking our our HTML inliner injects various resources
[13:44] <zyga> this might be a security issue, we probably can inject js into launchpad.net domain and do XSS
[13:51] <mitya57> zyga: here's the first non-matching lines: https://launchpadlibrarian.net/163098330/plainbox.diff
[13:52] <zyga> mitya57: ohhh
[13:52] <zyga> mitya57: I just did the same :)
[13:52] <zyga> mitya57: thanks :)
[13:53] <zyga> mitya57: yeah, I wonder why that happens, I cannot reproduce that failure
[13:53] <mitya57> I also can't reproduce it locally, but can in trusty chroot
[13:53] <zyga> I meant in trunk, I'll check out that debian release though, this is curious
[13:54] <zyga> or better, I'll let roadmr do it, I'm busy wity something else :/
[13:54] <zyga> mitya57: ideally we'd re-render those images and see what they really look like
[13:54] <zyga> mitya57: do you know how to do that?
[13:54] <mitya57> They look the same
[13:54] <zyga> mitya57: hmm, maybe base64 is somehow not deterministic? (though that would be odd)
[13:54] <zyga> mitya57: like some junk or seed?
[13:54] <mitya57> Just copy-paste the data:... URI into the adress bar
[13:55] <zyga> oh!
[13:55] <zyga> good idea
[13:55] <mitya57> No, base64 is deterministic :)
[13:56] <zyga> mitya57: maybe different encodings are possible? python has b64 and standard_b64?
[13:57] <zyga> mitya57: theory, the images are the same, the encoding has junk in both versions, that junk is not used by the the png decoder, the junk is a reused buffer of some kind?
[13:58]  * mitya57 looks
[13:59]  * zyga looks at the source
[13:59] <mitya57> zyga: I think when you encode PNG, it is in bytes, not in unicode, so encoding shouldn't matter here
[13:59] <zyga> mitya57: encoding as in "this is how png bitstream looks like"
[13:59] <zyga> mitya57: maybe there's fixed-lenght buffer and the stuff "afte the end" of the real data is irrelevant
[14:00]  * zyga imagines interesting data injection capabilities in "identical" PNGs
[14:01] <zyga> the part that converts a file to data URI looks sane to me
[14:01] <mitya57> zyga: No, the images are not equal. I can spot "Created with GIMP" comment in the second one but not in the first one
[14:01] <zyga> ohhh
[14:01] <zyga> wow, cool
[14:02] <zyga> so somehow, the images got changed
[14:02] <mitya57> Ah, pngbinarymangler
[14:02] <zyga> I wonder when that happened, everything that lands to trunk runs the full test suite
[14:02] <zyga> !!!
[14:02] <mitya57> *pkgbinarymangler
[14:02] <zyga> cool :D
[14:02] <zyga> why does it do that?
[14:02] <zyga> I mean, why does it strip the comment
[14:02] <mitya57> In Ubuntu all PNGs are stripped
[14:03] <zyga> hmmmm
[14:03] <zyga> I see
[14:03] <mitya57> I think there is some env variable to disable that
[14:03] <zyga> interesting, thanks for solving this bug then
[14:03] <zyga> mitya57: I'll add this to the bug report
[14:04] <mitya57> zyga: export NO_PNG_PKG_MANGLE=1 in debian/rules should fix that
[14:04] <zyga> mitya57: interestingly, we also run the test suite at build time, but obviously adt runs it after the build, that's really tricky thing to find
[14:05] <mitya57> Should I commit that to SVN?
[14:05] <zyga> mitya57: do you want to patch it in svn?
[14:05] <zyga> mitya57: yes please!
[14:06] <zyga> mitya57: if you can, do a changelog and I'll ask our sponsort to release it
[14:06] <zyga> changelog bump
[14:11] <mitya57> zyga: feel free to ask p1otr now :)
[14:12] <zyga> mitya57: thanks, just sending email
[14:14] <zyga> mitya57: thanks a lot, you fixed that instantly :)
[14:16] <mitya57> zyga: You are welcome :)
[14:25] <xnox> ev: bdmurray: cjwatson: looks like 12.04 installer still has the "creepy" webcam step, which was removed in raring and up. Should the webcam step be removed / disabled for 12.04.4, or let it be.
[14:26] <xnox> stgraber: ^
[14:26] <cjwatson> xnox: I don't like it, but I would let it be at this stage
[14:27] <cjwatson> Maybe a month or two ago ...
[14:27]  * zyga liked the webcam step
[14:27] <zyga> why did we think it's creepy?
[14:29] <brendand> zyga, because photographs steal your soul
[14:29] <zyga> brendand: that's okay, we sold ours to get the mortage ;)
[14:30] <brendand> zyga, and ubuntu installer photographs assign copyright of your soul to canonical
[14:31] <xnox> brendand: don't spread rumours.
[14:31] <zyga> even better, after sending my photo to facebook, google and amazon I really need canonical to own a copy ;)
[14:32] <ev> xnox: creepy? :(
[14:32]  * zyga mutters something about CLA, photos and forking
[14:32] <zyga> and gets back to wokr
[14:32] <xnox> zyga: creepy, cause you get to see your own face whilst installing ubuntu =) (and apw used that term) but in fact it's mostly useless as the pics didn't actually propagate anywhere.
[14:32] <xnox> (and places it did propagate to, got removed / changed since webcam introduction)
[14:33] <zyga> xnox: yeah but that's not the reason not to use it, my only complaint was that the "live feed" was much brighter, more naturally exposed, than the picture it took, but I guess that's related to video/still pic transition
[14:33] <zyga> xnox: I'd love if it could be my u1 user photo and if u1 had more features around users later
[14:37] <brendand> and SSO for login!
[14:40] <zyga> brendand: yeah
[14:45] <hallyn> jodh: regarding unusable kvm for you;  kvm really works splendidly on both my amd and intel based trusty laptops;  can you bring the laptop you're having trouble on next week so I can take a look?
[14:45] <pitti> ogra_: hey Oliver, how are you? do you have a sec for an arm kernel install question?
[14:45] <ogra_> pitti, sure, shoot (and i'm fine)
[14:46] <pitti> ogra_: so, I dist-upgraded a raring arm calxeda node in the lab from raring to saucy
[14:46] <pitti> ogra_: it didn't come back when booting, so I suspect it might not like the 3.11.0-15 kernel
[14:46] <pitti> ogra_: I did the same upgrade to another node, but didn't reboot yet
[14:46] <pitti> ogra_: I'd like to tell the boot loader to boot with the raring kernel
[14:47] <pitti> ogra_: I suppose I'll change the symlinks in /boot (vmlinuz, initrd.img) to point back to the 3.8 raring kernel
[14:47] <ogra_> pitti, ah, i havent dont much with server recently ... usually flash-kernel should do the right thing though ...
[14:47] <pitti> ogra_: is there something I need to runa fter that, like flash-kernel?
[14:47] <ogra_> pitti, try dannf or rbasak
[14:47] <jodh> hallyn: are you referring to bug 1268906 or bug 1257352? The former kernel issue occurs on 2 systems I have. I'll be bringing one with me.
[14:47] <ogra_> pitti, the package postinst should have run flash-kernel
[14:47] <pitti> ogra_: ack, talking to rbasak
[14:47] <pitti> ogra_: right, but I suppose that flashed 3.11 (saucy kernel) on dist-upgrade
[14:47] <ogra_> yeah
[14:49] <ogra_> pitti, i remember a bug where flash-kernel forcefully always flashes the latest kernel ... newer f-k versions use linux-version for that iirc
[14:49] <hallyn> jodh: the former
[14:49] <jodh> hallyn: right. It's entirely repeatable with every image I throw at kvm.
[14:50] <ogra_> pitti, you might need to remove the 3.11 kernel completely and then run f-k manually
[14:51] <pitti> ogra_: ah, might be safer
[14:52] <ogra_> (make sure to clean up /boot manually, iirc there is stuff left behind)
[14:53] <pitti> ogra_: ah, it also seems that it wasn't due to the kernel but due to a net interface problem
[14:53] <ogra_> oh
[14:53] <apw> phew, i thought ppisati tested those
[14:58] <pitti> rbasak, ogra_: FTR, merely changing the symlinks is sufficient; boot.scr has the symlinks and the boot loader reads/resolves those
[14:59] <ogra_> good
[14:59] <rbasak> Thanks
[14:59]  * ogra_ wonders why highbank uses boot.scr though ... dont we use uEnv.txt ?
[15:00] <rbasak> flash-kernel writes out boot.scr, doesn't it?
[15:00] <rbasak> That happened when we synced to Debian. Some time around the 12.10 timeframe IIRC.
[15:00] <ogra_> well, for anda we switched to uEnv.txt long ago
[15:00] <ogra_> ah, k
[15:01] <ogra_> so its lool's fault then
[15:01] <ogra_> :P
[15:19] <stgraber> pitti: I've never tried that part of the Ubuntu template myself because I use a transparent proxy, but try setting HTTP_PROXY=apt before running lxc-create
[15:19] <pitti> stgraber: bonjour
[15:19] <stgraber> pitti: looking at the code, that should query apt-config for the current proxy value and use it for the container
[15:19] <pitti> stgraber: right, that's what I did at last; works except for said bug
[15:19] <pitti> stgraber: not quite as my proxy is 127.0.0.1, but HTTP_PROXY=http://`hostname`:3142 worked
[15:20] <stgraber> pitti: ah yeah, sounds like the proxy stuff isn't done at the right stage of lxc-ubuntu...
[15:24] <jibel> stgraber, the proxy is set when sources.list is written ie during initial download _or_ if the arch of the host and the container are diffrent
[15:27] <pitti> stgraber: do you have an idea about http://paste.ubuntu.com/6797756/?
[15:27] <pitti> stgraber: in particular "confused by argument: armhf"?
[15:27] <pitti> stgraber: that's from an arm machine
[15:28] <pitti> which is runnning saucy
[15:28] <stgraber> pitti: you're running an old version of the cloudimg query tool which doesn't know about armhf
[15:28] <stgraber> pitti: the same on trusty should work (at least it did last week)
[15:29] <pitti> stgraber: ok; I'll try upgrading this node to trusty
[15:29] <pitti> stgraber: or perhaps the cloud query tool first; which package is that?
[15:30] <stgraber> cloud-image-utils
[15:30] <pitti> arch: all, how nice
[15:30] <pitti> stgraber: merci
[15:56] <zul> doko:  which package needed porting to bs4 again?
[15:58] <doko> zul, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:58] <zul> doko:  cool thanks
[17:03] <jodh> hallyn: can we wait until the next upstart release (next week) for a fix for bug 1263738 to land in trusty?
[17:04] <hallyn> jodh: yeah that's fine
[17:04] <hallyn> jodh: i wanted it fixed by feature freeze if possible.  containers are useful without the fix
[17:04] <hallyn> jodh: thanks!
[17:05] <jodh> hallyn: ok, thanks. shouldn't be a problem as we've fixed it upstream now.
[19:06] <Noskcaj> infinity, xfce4-weather-plugin 0.7.4-5 is now in s-p-u, is that enough to sync to precise?
[19:36] <Noskcaj> Is there anything i can do do make my motu application happen faster? It's three weeks since i sent the email
[19:44] <tumbleweed> Noskcaj: the DMB isn't particularly good at e-mail applications. I'll poke people again
[19:45] <Noskcaj> tumbleweed, thanks.
[19:45] <Noskcaj> There's a heap of stuff xubuntu needs uploaded, and not many sponsors.
[20:07] <jtaylor> Noskcaj: just saw you want to merge xfwm4
[20:07] <jtaylor> is that a stable release?
[20:07] <jtaylor> its not mentioned on their homepage
[20:07] <jtaylor> they might be using old gnome versioning, odd unstable, even stable
[20:07] <jtaylor> so we probably don't want .11 in trusty
[20:13] <Noskcaj> jtaylor, We try ro use the old gnome versioning, but everything is very stable anyway and contains stuff we need for xubuntu
[20:13] <Noskcaj> 4.11 is mostly the same as 4.12, just 4.12 has to have everything released at once, but panel isn't fully ready
[20:14] <jtaylor> when is it expected to be ready?
[20:15] <Noskcaj> jtaylor, No one really knows. Probably before trusty's final release, probably not before feature freeze
[20:20] <infinity> smb: Ew.  Stop flipping your dom0 from Xen to bare metal.
[20:20] <infinity> smb: (But yes, good catch.  I wonder why no one else has noticed this for years...)
[20:23] <Noskcaj> robert_ancell, Any chance you could do the packaging for lightdm (and greeter) in debian? We've got a pointless duplication of work currently
[20:23] <robert_ancell> Noskcaj, no, I want to release fast into Ubuntu. You can copy changes into Debian
[20:24] <Noskcaj> ok. debian is pretty fast to upload though
[20:27] <infinity> smb: So, that's probably something I should fix in Debian but, also, worth noting that you don't need libc6-xen on Ubuntu at all, our default i386 flavour is also built with -mno-tls-direct-seg-refs
[20:28] <infinity> smb: (In other words, we shouldn't ship libc6-xen in Ubuntu at all, and I'm trying to decide if it's worth coming up with a migration plan to make that more obvious)
[21:04] <Unit193> Meh, since I was updating the packaging for myself, it was trivial to generate the merge too: https://unit193.net/dropbear_2012.55-1.4ubuntu1_dropbear_2013.60-1ubuntu1.debdiff  https://unit193.net/dropbear_2013.60-1_dropbear_2013.60-1ubuntu1.debdiff
[21:59] <smoser> ok. so in live-build, i have a package-lists/ubuntu-cloud that works for 12.04-13.10.
[21:59] <smoser> but in trusty, i want to *not* include the 'Task' of 'server^'.
[21:59] <smoser> anyone know how to put logic like that in there:
[22:00] <Noskcaj> jtaylor, Are you able to sponsor xfwm4?
[22:06] <smoser> ok.
[22:14]  * seb128 wonders wth with dch in trusty
[22:14] <seb128>  $ dch -i "Rebuild for the new poppler soname"
[22:14] <seb128>  $ dch -r
[22:14] <seb128> -> gives "the" as a release
[22:14] <seb128> $ dch -i "Rebuild"
[22:14] <seb128> -> works fine
[22:15] <seb128> does anyone see anything wrong in there? (or feel like debugging dch? ;-)
[22:19] <dobey> https://ubuntuone.com/3vkRPzVaPpF8p6xferyRnT <- wtf. why i am on a vt with a mouse cursor, and unable to get back into my running xorg session, which btw, is still responding to presses of the multimedia keys?!
[22:19] <Laney> bahaha
[22:20] <dobey> happened during dist-ugprade, i think during configuration of the new kernel. my screeens just went dead but X was still running, and i could still control rhythmbox with my keyboard
[22:20] <Laney> seb128: check /usr/bin/dch line 1375
[22:20] <seb128> Laney, shrug, is that a feature?! (and how did you debug that? ;-)
[22:21] <Laney> sk1llz
[22:22]  * seb128 is impressed by Laney p0wers
[22:22] <Laney> yeah I can trace perl code, that's why they pay me the big bucks
[22:22] <seb128> hehe
[22:23]  * seb128 notes to recommend that Laney gets more bucks in the next review
[22:23] <Laney> :>
[22:23] <Laney> I wonder if anyone even knows that feature exists any more
[22:23] <Laney> on the other hand, you now know how to work around it ...
[22:24] <Laney> desire to patch... slipping...
[22:30] <seb128> Riddell, could you get calligra rebuild for the new poppler soname change? (there is one small api change, http://cgit.freedesktop.org/poppler/poppler/commit/?h=poppler-0.24&id=ebe49d597a62aa94601c2e4595dbad1895ea7ef0 ... it's not likely it requires change but it would be good to test build still)
[22:43] <seb128> slangasek, it would be nice if you would fwd you upgrade fixes to Debian ;-)
[22:44] <slangasek> seb128: if you mean mutter, the new upstream version was a -0ubuntu1 change...
[22:45] <seb128> slangasek, no, it just made me think of https://launchpad.net/ubuntu/+source/harfbuzz/0.9.24-2ubuntu2 which is our only diff on that source (crossed that this week because we were a version behind and it's our only diff and it's not forwarded)
[22:47] <slangasek> seb128: ah, ok.  yes, that should be forwarded; I'm just getting a little tired of having to garden these kinds of issues in libraries in Ubuntu, because they break update-manager in the devel series, which means either nobody's using update-manager or nobody minds being prompted about partial upgrades
[22:48] <slangasek> so my motivation to forward these to Debian, who aren't affected by this update-manager code, is low
[22:48] <seb128> can we fix update-manager if the issue is limited to it? (or would it affect and "apt-get update" upgrade as well?)
[22:51] <seb128> slangasek, well, I would be fine fixing some of those/forwarding them if I understood the issue enough to explain the impact in a bug fwd to Debian (or is that just a "it's how it should be done")?
[22:53] <seb128> slangasek, (and yeah, I've to admit I'm one of those who don't pay attention to the partial upgrade dialog during unstable serie because we have enough transitions happening that's not un-usual, even if we didn't have bugs)
[22:54] <slangasek> seb128: yeah, the issue is update-manager knows what Conflicts/Replaces means and will accept removing a package for that reason, but Breaks/Replaces (or Conflicts without Replaces) means something different according to policy so won't silently allow it
[22:56] <seb128> slangasek, I see
[22:56] <slangasek> so yeah, long explanation for a patch that doesn't make any practical difference in Debian
[22:57] <seb128> having to maintain the diff/rebase is annoying as well
[22:57] <seb128> not sure that's worth the diff in fact, it only impact users who follow unstable and updated before that version
[22:57] <seb128> those changing series now are going to dist-upgrade anyway
[22:57] <seb128> so it could be dropped?
[22:58] <seb128> well, it doesn't hurt to keep that one until the LTS...
[22:59] <seb128> on that note, calling in a day
[22:59] <seb128> good night everyone
[23:54] <Laney> I usually commit those if I see them and can
[23:54] <Laney> as I did do for harfbuzz, IIRC