=== DashieIsTheBest[ is now known as Mapley
[01:01] <Unit193> qengho: Howdy!  Is there a chance you can rename chromium-browser (at least the binary package) to chromium to follow the rename in Debian?  It'd make some deps sync better and packages like pepperflashplugin-nonfree syncable (reason for naming it chromium-browser is no longer current, the game is now chromium-bsu)
=== timrc-afk is now known as timrc
=== Ursinha is now known as Ursinha-afk
=== bfiller is now known as bfiller_away
[02:45] <TheMuso> c
=== Ursinha-afk is now known as Ursinha
=== Ursinha-afk is now known as Ursinha
[07:04] <pitti> Good morning
[07:05] <pitti> Noskcaj: gthread.patch> it looked like it was an Ubuntu delta
[07:05] <pitti> Noskcaj: will do, thanks
[07:32] <Noskcaj> Logan__, You around?
[07:33] <Noskcaj> Any chance you could sponsor xubuntu's current biggest bugfix? https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-power-manager/systemd/+merge/202226
[07:42] <didrocks> xnox: hey, your nux/unity rebuild against new glew is making my system crashing here
[07:43] <didrocks> xnox: I have an unity stacktrace, (and it's an upload outside of our test system, can you please really stop doing that, not the first time…)
[08:17] <dholbach> good morning
[08:17] <Noskcaj> hey dholbach. ANy chance you could take a look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-power-manager/systemd/+merge/202226 ? It's xubuntu's biggest bug currently
[08:17] <dholbach> hi Noskcaj
[08:17] <dholbach> Noskcaj, do you know if the libstatgrab situation is resolved now?
[08:18] <Noskcaj> i'll check now
[08:19] <dholbach> Noskcaj, Conflict adding file src/gsd-media-keys-window.c.  Moved existing file to src/gsd-media-keys-window.c.moved.
[08:19] <dholbach> Conflict adding file src/gsd-media-keys-window.h.  Moved existing file to src/gsd-media-keys-window.h.moved.
[08:19] <dholbach> hey mvo
[08:19] <mvo> hey dholbach, good morning
[08:20] <Noskcaj> strange. Is there a different way you could sponsor it?
[08:20] <Unit193> mvo: Howdy.
[08:21] <Noskcaj> No progress on libstatgrab, still very broken and i don't know how to fix
[08:22] <dholbach> Noskcaj, can you bring it up on the mailing list then and ask for help there?
[08:22] <Noskcaj> dholbach, Which list? There's already a bug in debian for it.
[08:23] <Noskcaj> Also, is there anything you can do to make my MOTU application happen faster? No one replies
=== zz_frobware is now known as frobware
[08:24] <mvo> hey Unit193
[08:25] <dholbach> Noskcaj, seems like nobody responded to https://lists.ubuntu.com/archives/devel-permissions/2014-January/000562.html yet - you could try pinging anyone of these: https://launchpad.net/~developer-membership-board/+members
[08:25] <Unit193> I ended up commenting before you responded because I already saw several marked as dupes of that bug, then noticed I couldn't re-open.
[08:26] <Noskcaj> bdrung, micahg, ScottK: Any progress on my MOTU application?
[08:27] <dholbach> Sweetshark, jamespage: happy birthday! :)
[08:30] <pitti> Noskcaj: hm, I don't see g-s-t on http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html ?
[08:31] <Noskcaj> pitti, I hadn't changed the status back because i wanted your opinion on if i needed to do those other changes
[08:32] <Noskcaj> It's at https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-system-tools/merge still
[08:32] <pitti> Noskcaj: status back? oh, on the (wrong) UDD branch
[08:32]  * pitti looks at that again
[08:33] <Noskcaj> status to "needs review"
[08:33] <pitti> no, it needs to be done against https://code.launchpad.net/~ubuntu-desktop/gnome-system-tools/ubuntu, as in Vcs-Bzr:; desktop packages don't use UDD
[08:33] <Noskcaj> ok
[08:34] <pitti> Noskcaj: indeed, gthread is from Debian; sorry for the noise
[08:35] <pitti> Noskcaj: you need to add Breaks:/Replaces: for network/time-admin for (<< 3.0.0-3ubuntu1), and add transitional packages, for upgrades
[08:35] <pitti> that part can be dropped after trusty's release
[08:35] <pitti> but is necessary to move people who only have those installed to g-s-t
[08:35] <Noskcaj> ok
[08:36] <pitti> and the B:/R: for telling apt to unpack them  in the right order, to avoid file conflicts
[08:36] <pitti> as g-s-t now ships files that previously time/net-admin shipped
[08:37] <pitti> Noskcaj: debian/rules additionally does --disable-services; not sure where that came  from
[08:37] <pitti> ah, "don't build services admin"
[08:37] <pitti> yes, makes no sense with upstart
[08:37] <Noskcaj> makes sense, if my internet will let me, i'll fix it now
[08:37] <Noskcaj> And if you've got some spare time, i've got two SRUs xubuntu really needs waiting
[08:37]  * pitti isn't in ~ubuntu-sru
[08:38] <pitti> I can sponsor them, of course
[08:38] <Noskcaj> makes sense, if my internet will let me, i'll fix it now
[08:38] <Noskcaj>  And if you've got some spare time, i've got two SRUs xubuntu really needs waiting
[08:38] <Noskcaj> stupid internet crash
[08:39]  * pitti isn't in ~ubuntu-sru
[08:39] <pitti> I can sponsor them, of course
[08:39] <Noskcaj> https://code.launchpad.net/~noskcaj/update-notifier/tray-notification/+merge/202210 and https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-power-manager/systemd/+merge/202226
[08:39] <Noskcaj> sponsor is what i need currently, we can't SRU till it's in trusty
[08:40] <Noskcaj> And maybe https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-session/light-locker/+merge/196436
[08:41] <pitti> Noskcaj: seems dholbach just did the power-manager one, without closing the MP
[08:41] <zyga> good morning
[08:41]  * pitti sets to "merged" (← dholback, FYI)
[08:42] <Noskcaj> ty dholbach, helps a lot
[08:43] <pitti> Noskcaj: wrt. update-notifier, I thought popping up u-m was a design decision
[08:43] <pitti> (instead of the tray notification)
[08:43] <Noskcaj> pitti, Might be. I'm not sure, just trying to remove bug 1246364
[08:43] <ubottu> bug 1246364 in update-notifier (Ubuntu) "update-notifier does not show a tray icon in xubuntu 13.10" [Undecided,Confirmed] https://launchpad.net/bugs/1246364
[08:44] <Noskcaj> But if so, i'll set it to won't fix or invalid
[08:44] <pitti> well, the "appears minimized" is still a bug
[08:44] <pitti> it should just open; in the background if you are busy typing
[08:45] <Noskcaj> ok, i'll add that info to the bug and remove the MP
=== _salem is now known as salem_
[09:00] <jamespage> thanks dholbach
[09:09] <didrocks> ev: hey, any idea why there is no retrace on this trusty crash report? https://errors.ubuntu.com/oops/a8ea9f18-8068-11e3-a0f6-2c768aafd08c
[09:11] <ev> didrocks: we don't have a mapping backwards from crashes to problems (stupidly on my part, but it's not terribly difficult to add for future reports), so it's hard to answer your question.
[09:12] <didrocks> ev: ah, so there is no (easy) way for me to get from my report to a retraced version?
[09:12] <ev> lp:daisy if anyone wants to add that. Just stick the ProblemIdentifier field in OOPS during bucketing
[09:12] <ev> didrocks: correct :-/
[09:12] <didrocks> ah ok
[09:13] <ev> adding it is easy, back populating it not terribly hard, but time consuming (probably about a few weeks of compute time).
[09:13] <ev> actually, not even
[09:14] <ev> because it just has to iterate the Bucket CF and populate the bucket identifier into each OOPS report for each oopid in bucket
[09:14] <ev> sorry, I realise none of this helps you right now
[09:15] <didrocks> ev: no worry, was more coming to a "is it normal that…" ? ;)
[09:15] <didrocks> so I have my answer now
[09:15] <ev> :)
[09:16] <didrocks> I don't miss any obvious link :p
[09:16] <pitti> seb128: ah, you uploaded e-d-s; I'll upload evolution then?
[09:17] <pitti> (well, and of course build/test it locally first)
[09:23] <seb128> pitti, oh, I forgot about evo, sorry about that ... if you want to do it that would be nice, thanks!
[09:29] <Sweetshark> dholbach: oh, thanks!
[09:29] <Sweetshark> jamespage: Happy birthday then, I guess ;)
[09:29] <jamespage> Sweetshark, happy birthday!
[09:31] <dholbach> :)
[09:38] <dholbach> can somebody reply to https://twitter.com/derEremit/status/424250853747216384 please?
[09:48] <ogra_> dholbach, i guess thats a cjwatson/xnox question
[09:48] <ogra_> Sweetshark, hey old man ... happy bithday !
[09:51] <pitti> seb128: building/working fine here, uploading
[09:51] <seb128> pitti, danke
=== doko__ is now known as doko
[10:03] <Sweetshark> ogra_: thx. now get off my lawn. /me shakes angryoldmanfist
[10:11]  * ogra_ waves with his cane to Sweetshark 
[10:11] <ogra_> :)
[10:12] <didrocks> happy birthday Sweetshark!
=== timrc is now known as timrc-afk
[10:30] <xnox> dholbach: ogra_: that boot-repair is not suitable for default inclusion. Whilst it does a few things right, it does a few things wrong as well and has caused mass-bug reports in the past.
[10:30] <xnox> dholbach: ogra_: ideally it needs integration into ubiquity.
[10:31] <ogra_> xnox, yeah, thats kind of the answer i expected ... though i disagree about ubiquity
[10:32] <ogra_> (the purpose of the app seems to be to not need live media to repair the bootloader setup
[10:32] <ogra_> )
[10:36] <dholbach> xnox, ok
[10:43] <xnox> ogra_: correct, the purpose of ubiquity designs from mpt, had the 3 options: Try Ubuntu, Install Ubuntu, Fix Ubuntu. The later does most common repairs - e.g. out of disk-space, fsck, reinstall boot-loader, etc.
[10:43] <ogra_> xnox, right, but that still forces you to use live media ...
[10:43] <xnox> ogra_: that repair tool modifies configuration files automatically which ends up behaving very bad on upgrade.
[10:44] <xnox> ogra_: not necesseraly. One doesn't need live media to launch ubiquity - see oem-config.
[10:44] <xnox> ogra_: so a stand-alone repair launcher for repair mode can also be easily added.
[10:44] <ogra_> if people edit the grub cmdline by hand to get back into their system or ise another bootloader and want the overwritten grub back they could use an in-system tool instead
[10:44] <ogra_> s/ise/use/
[10:44] <xnox> ogra_: or e.g. see lp:dell-recovery which does only repair/factory-reinstall
[10:45] <xnox> ogra_: people didn't edit the grub cmdline by hand, that boot-repair tool however did modify grub.cfg without asking causing user distress on grub upgrades thereafter.
[10:45] <xnox> (and modified grub.cfg pointlessly / as in when not needed)
[10:46] <xnox> it's a very heavy hammer.
[10:46] <ogra_> yeah, i dont say the tool is good :)
[10:46] <xnox> =)
[10:46] <ogra_> but i understand its purpose
=== timrc-afk is now known as timrc
[10:49] <ogra_> and i think we dont want to install ubiquity by default, so a standalone tool would be better if we would think such a thing is needed
[11:06] <pitti> seb128: nice, the libgweather/evolution/e-d-s/gnome-clocks/gnome-panel combo just migrated \o/
[11:06] <seb128> pitti, great!
[11:24]  * Laney lookss at libwebp as he's planning a webkitgtk upload anwyay
[11:29] <mpt> xnox, ogra_: The “Fix Ubuntu” button in Ubiquity could be merely a launcher for that standalone tool
[11:29] <ogra_> mpt, yeah, something like that
[11:30] <ogra_> i really dont know how important that use case actually is ... do we actually have so many people with broken MBR that it even justifies to have such a tool
[11:30] <ogra_> but yeah, it should be a standalone tool that can be also used from a repair CD
[11:31] <mpt> compare https://wiki.ubuntu.com/StartupSettings
[11:33] <ogra_> oh, cool
[11:34] <ogra_> dholbach, ^^ that seems like a good page to point to in an answer
[11:35] <xnox> ogra_: note that none of that hand drawing is implemented =)
[11:35] <ogra_> xnox, heh, i wouldnt have expected so
[11:35] <ogra_> :)
=== MacSlow is now known as MacSlow|lunch
[11:59] <pitti> cjwatson: did you ever happen to see dpkg erroring with "unable to move aside [...]: Invalid cross-device link" when replacing a directory with a file?
[12:00] <pitti> cjwatson: I'm investigating bug 1220681, one of the first results of our new automatic dist-upgrade testing; and that bug was sent by an actual user, so it doesn't just seem to be an artifact from our test rig
[12:00] <ubottu> bug 1220681 in espeak (Ubuntu) "package espeak-data 1.46.02-2ubuntu1 failed to install/upgrade: unable to move aside `./usr/lib/i386-linux-gnu/espeak-data/voices/en' to install new version: Invalid cross-device link" [Undecided,Confirmed] https://launchpad.net/bugs/1220681
[12:02] <cjwatson> no
=== bfiller_away is now known as bfiller
[12:43] <doko> seb128, according to the version number, pyruntest seems to be a package which desktop or phone should be subscribed tob. see lp #1270812
[12:43] <ubottu> Launchpad bug 1270812 in pyruntest (Ubuntu Trusty) "pyruntest fails to build from source in trusty" [High,Confirmed] https://launchpad.net/bugs/1270812
[12:44] <doko> Mirv, ^^^
[12:45] <doko> xnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20140108/+build/5430771 (you are Debian "upstream" ;p )
[12:45] <seb128> doko, seems like part of the autopilot stack, e.g rather a QA team thing
[12:46] <doko> jibel, pitti: ^^^
[12:49] <xnox> doko: thanks.
=== Sweetsha1k is now known as Sweetshark
[12:55] <Mirv> doko: ok, I'll assign that to thomi who is behind the code
[12:55] <doko> thanks
=== MacSlow|lunch is now known as MacSlow
[13:05] <xnox> Sweetshark: Laney: Riddell: do you remember the bug in Libreoffice or was it KDE (?! or maybe somewhere else) where with Ubuntu default fonts, the bold (fat) version was loaded instead of the correct "normal" one?
[13:05] <Laney> it was libreoffice
[13:05] <Laney> I think there was a bug which I attached screenshots to?
[13:05] <Laney> was quite a while ago :-)
[13:05] <xnox> looks like there is another bug like that with openjdk, https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/937200 and a /possibly/ plausible patch to fix it https://launchpadlibrarian.net/162036139/openjdk-7_7u25-2.3.12-4ubuntu3_7u25-2.3.12-4ubuntu3ppa1.diff.gz
[13:05] <ubottu> Ubuntu bug 937200 in openjdk-7 (Ubuntu) "Fat fonts in Swing applications" [Low,Triaged]
[13:05] <Laney> check the changelog
[13:06] <xnox> Laney: and i'd rather have some font-guru insight if that's the right way to fix it or not.
[13:06] <Laney> doko was pinging about that last week & talked to s_laden a bit
[13:06] <Laney> I didn't follow the outcome
[13:07] <xnox> Laney: well doko is pinging me about it now, as I independantly filed an issue long time ago to "make default latin font be Ubuntu" in fontconfig package, which is "won't fix" due to Ubuntu font have different height from other fonts.
[13:07] <Laney> right
[13:08] <xnox> (or some such other dimention / proper typography term)
[13:13] <Sweetshark> xnox: I remember argueing viciously on that one that I dont like the idea of vendorpatching that as "LO renders it different on Ubuntu as on Windows" is worse from the users perspective that "LO renders it wrong consistently" ...
[13:14] <Sweetshark> (users mostly wouldnt even notice the second one)
[13:15] <xnox> Sweetshark: i see, even if "Ubuntu Font is installed on Windows" ? I thought the core issue was that "ubuntu font provides too many weights like no other: normal, normal+bold, light, light+bold" and since there was no other widely used fonts that did that, the font-code was failing to select "normal" and instead picked "normal+bold".
[13:16] <doko> Sweetshark, but how do you solve this with DejaVu?
[13:17] <Laney> doko: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-pillow/35/ARCH=amd64,label=adt/console is that failing test sensible? I see http://sources.debian.net/src/pillow/2.2.1-3/Tests/test_file_webp.py#L54 ...
[13:18] <Sweetshark> xnox, doko: I would need to dig into that code again -- there was quite some rework on font stuff by Christina upstream recently.
[13:19] <xnox> Sweetshark: a pointer into the rigth direction would be enough, i think. For me to validate if the "font-selection-logic" in openjdk is affected in a similar way, and wether the proposed fix is the "sensible way" to pick between "more than 2 weights".
[13:19] <Laney> We fixed that issue by altering the font itself
[13:20] <xnox> Laney: you mean - as in default font in libreoffice? or by fixing ubuntu-font?
[13:20] <Laney> the latter
[13:20] <xnox> hm....
[13:21] <Laney> Doing $something to the font's metadata fixed it
[13:21] <Laney> so this java issue might be something different
[13:21] <xnox> Laney: unless it doesn't read the $something portions of the font's metadata.
[13:21] <xnox> =))))
[13:23] <Sweetshark> xnox: we are not using Ubuntu-fonts in LibreOffice defaults. As Ubuntu fonts are not shipped on Windows/OS X, every document generated on Ubuntu would use a font fallback (with a different metric) and thus possibly look horrible. Pitchforks and torches stuff.
[13:25] <xnox> Sweetshark: right, sounds reasonable. I wonder what to do with openjdk then - e.g. swig apps looking horrible with ubuntu-font due to selecting bold / possibly miss-aligned, making openjdk pick the right weight / possibly miss-aligned, switch to same font as libreoffice.
[13:25] <xnox> Sweetshark: which one do you use? DejaVu?
[13:27] <Sweetshark> xnox: We might consider using Ubuntu fonts in defaults, as LibreOffice now is able to embed fonts in the ODF. Such stuff would then look fine on recent LibreOffice versions  everywhere (but not e.g. on OOo). However, fontembedding is opt-in and not the default as embedding fonts might need a license. For the Ubuntu font, that might not be an issue, but other fonts might get you into legal fun.
[13:29] <xnox> Sweetshark: i thought that e.g. PDF-A standard mandates font embedding (those that are not part of standard well-defined set) and that most / all fonts are ok to be embedded, as "you shall not extract fonts from the document"
[13:30] <Sweetshark> xnox: as default fonts? LibreOffice 4.1 has Liberation family as defaults. But someone made new defaults for 4.2. lemme check.
[13:31] <Sweetshark> xnox: All I know that nobody bothered with releasing with that upstream. Feel free to let the Canonical legal team have an expensive meditation about it.
[13:35] <Sweetshark> seems to still be liberation (which is natural, as IIRC liberation font are metric compatible with corefonts). (IIRC we also grew ourselves some free fonts from google, but the details escape me right now).
[13:37] <Sweetshark> (caladea and carlito)
[13:38] <xnox> Sweetshark: i wonder why ubuntu-restricted-common (or whatever it's called ) metapackage still recommends  / installs MS corefonts instead of installing just liberation fonts.
[13:39] <Sweetshark> (those two fonts above are metric compatible to Cambria and Calibri)
[13:58] <pitti> hm, since today, apt's "reading package lists.." takes aaaages (every percent takes 2 s, so about two minutes in total); does anyone else get this as well?
[13:58] <pitti> I see the same in a saucy container, so perhaps some weird regression in 3.13.0-4?
[14:02] <seb128> pitti, no such issue here but I didn't reboot with -4 yet
[14:02] <pitti> I'll re-check with both after meeting
[14:05] <pitti> meh, after next apt-get update every percent now takes 10 s
[14:08] <pitti> hmm, fast again after a reboot
=== jpds_ is now known as jpds
[14:26] <seb128> pitti, were you under io load from some other process maybe?
[14:26] <pitti> seb128: no, there was nothing else running
[14:26] <seb128> I had very slow everything while doing an install in a VM earlier, IO load handling still sucks under linux
[14:26] <doko> pitti, jibel: how do I get the autopkg tests of a package run when eglibc is uploaded?
[14:27] <pitti> doko: in theory they should almost all run then, as almost all packages depend on libc6
[14:27] <pitti> doko: in practice this seems to "forget" a few rdeps; we can manually trigger runs of particular packages if you are interested in a specific one
[14:27] <doko> and is there a chance to run autopkg tests on armhf?
[14:28] <pitti> not in CI at the moment, as there is no viable virtualization :/
[14:28] <doko> pitti, well, I would have to write these tests first ;p
[14:28] <pitti> they can of course be run manually on a G4 or so, but each test basically requires a reinstall
[14:28] <pitti> "nexus 4" I meant
[14:30] <cjwatson> well, they might be runnable in the emulator somehow
[14:30] <cjwatson> Steve has asked me to look into that
[14:30] <pitti> in qemu-system-* might be viable, yes
[14:30] <pitti> qemu-user in LXC doesn't quite cut it
[14:31] <cjwatson> well, specifically, Steve asked me to look into hooking autopilot tests up to autopkgtest in the Android emulator
[14:31] <cjwatson> (which isn't quite the same thing as the above, though it's sort of related)
[14:32] <cjwatson> I'm juggling this with 12.04.4 and GRUB 2.02 though ...
[14:32] <doko> the tests in question are: run java -version for openjdk builds, and run the libffi tests with an install environment
[14:32] <cjwatson> I think for any armhf testing we'll have to look into limiting it somehow
[14:33] <pitti> cjwatson: I think a first good limitation would be to only run tests without "needs-root"
[14:33] <cjwatson> otherwise I'd be worried that we'll slow the whole process right down
[14:33] <pitti> those are usually the simpler kinds which don't make strong assumptions about the machine
[14:34] <pitti> (i. e. not things like upstart or udisks)
=== freeflying is now known as freeflying_away
[15:20] <mitya57> zyga: FYI: https://code.launchpad.net/~mitya57/ubuntu/trusty/python-coverage/add-preinst-script/+merge/202323
[15:21] <mitya57> It turned out that indeed that was Ubuntu-specific issue
[15:26] <zyga> mitya57: thanks!
[15:45] <Laney> doko: did you see my message about pillow?
[15:51] <mitya57> Laney: I think that pillow comment is related to "#assert_image_equal(image, target)" (which is commented out), not to the next test (which is the failing one)
[15:51] <Laney> yes
[15:51] <Laney> I was more linking to the comment
[15:51] <Laney> "shouldn't this logic apply to that other test too?"
[15:51] <mitya57> That doesn't mean we can't disable both, though :)
[15:52] <mitya57> similar != equal, so it doesn't necessarily apply
[15:52] <mitya57> maybe bumping 20 to something higher will work, if not, then it's a real bug
[15:54] <Laney> umm
[15:54] <Laney> It's assert_image_equal not assert_image_similar
[15:55] <Laney> http://sources.debian.net/src/pillow/2.2.1-3/Tests/test_file_webp.py#L31 that's the line
[16:24] <doko> pitti, what's the status of the postgres 9.1 deps, http://people.canonical.com/~ubuntu-archive/nbs.html
[16:24] <pitti> oh, I thought I caught them all
[16:24] <cjwatson> tseliot: so, what's the status of the nvidia stuff in precise-proposed?  it's currently v-failed, but your last comment in bug 1268027 suggests that maybe it should be OK?
[16:24] <ubottu> bug 1268027 in nvidia-settings (Ubuntu) "nvidia-settings crashes on exit" [Medium,Incomplete] https://launchpad.net/bugs/1268027
[16:24] <pitti> doko: thanks for pointing out, will fix ASAP
[16:25] <tseliot> cjwatson: yes, I don't think it's a regression. It seems to me like a bug that can be reproduced only on very specific configurations
[16:26] <tseliot> cjwatson: also the nvidia-prime in the queue fixes some issues in the same SRU
[16:52] <pitti> cking: FYI, https://launchpad.net/ubuntu/+source/util-linux/2.20.1-5.1ubuntu14
[16:52] <cking> pitti, nice, thanks for that
[16:53] <pitti> cking: nasty h4ck :/
[16:54] <cking> pitti, well, if it stops eating data, it's worth the ugh factor
[16:54] <pitti> cking: yes, absolutely; thanks for pointing out that bug
[16:54] <cking> np
[16:54] <cking> thanks for fixing it :-)
[16:58] <doko> xnox, will you care about the libav rebuilds?
[16:58] <doko> http://people.canonical.com/~ubuntu-archive/nbs.html
[16:58] <xnox> doko: all is done, mass removal of ffmpeg is required, i believe it was already removed from testing in debian. See the RM bug that ubuntu-archive is subscribed to.
[16:59] <xnox> https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/1253071
[16:59] <ubottu> Ubuntu bug 1253071 in mplayer (Ubuntu) "block migration & demote to proposed & decruft NBS libav/ffmpeg (removed from testing in Debian)" [Undecided,Triaged]
[17:00] <xnox> there are a few packages affected.
[17:01] <xnox> doko: i believe the only things that needs doing are: remove binary packages, demote source packages to -proposed.
[17:02] <doko> xnox, why keep the source?
[17:02] <cjwatson> tseliot: Right.  Looking at that queued upload
[17:03] <xnox> doko: some of them may (e.g. libavg, libnfo, libvalhalla, etc) might get ported to libav9 in debian, and then it will just sync.
[17:03] <tarpman> xnox: hi, about bug 937200: the bug is (imo) in openjdk, anything with fontconfig or fontconfig.properties is just a workaround. still waiting for feedback from upstream about my patch; not happy to propose for ubuntu before getting a review from someone who knows that code
[17:03] <ubottu> bug 937200 in openjdk-7 (Ubuntu) "Fat fonts in Swing applications" [Low,Triaged] https://launchpad.net/bugs/937200
[17:03] <xnox> doko: otherwise, it will need to manually noticed that autosync is not considering something due to "trying sync from debian, but removed from ubuntu"
[17:04] <cjwatson> tseliot: I'm pretty sure the HOST_ARCH_OTHER stuff could've been done more clearly with make conditionals, but not a blocker
[17:04] <xnox> tarpman: i see. Do you have link to upstream submitted patch?
[17:05] <tarpman> xnox: mmf. you know what, I actually just sent information to their list, not the patch itself. I will follow up with that, thanks for reminding
[17:05] <tseliot> cjwatson: right
[17:05] <tarpman> xnox: is there anyone at ubuntu or canonical who has already gone through their copyright signing thing? I am not really interested in paperwork :)
[17:06] <tarpman> and separately, http://cdimage.ubuntu.com/daily-live/ is looking a little bit out of date...?
[17:07] <cjwatson> tarpman: the builds failed until this morning - fixed earlier today, should work tomorrow
[17:07] <tarpman> thanks :)
[17:07] <xnox> tarpman: if it's your patch, and you are not canonical employee, it's hard to steal and impersonate your copyright =) but I thought your patch is trivial and doesn't need copyright... maybe ask doko, as I'd think he might have openjdk commits.
[17:09] <tarpman> xnox: ok. I am going to email the list again (with the patch this time), and also cc the person the upstream bug is assigned to. will report back on the LP bug.
[17:09] <xnox> tarpman: cool, thanks.
=== salem_ is now known as _salem
[17:51] <doko> pitti, jibel, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html show the owncloud-client autopkg tests failing, however the status is green ...
[17:54] <pitti> doko: where is it green? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-owncloud-client/ all failed
[17:54] <doko> pitti, the trend is all green: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-owncloud-client/
[17:54] <pitti> doko: btw, I uploaded everything for the psql 9.1 NBSes
[17:55] <doko> looking at this rules file ...
[17:55] <doko> override_dh_auto_test:
[17:55] <doko>         mkdir obj-$(DEB_HOST_GNU_TYPE)/config
[17:55] <pitti> doko: ah yeah; no idea about tha ttrend thing
[17:55] <doko> so why is DEB_HOST_GNU_TYPE not set during the adt run?
[17:55] <doko> pitti, ^^^
[17:55] <pitti> it's a bug in debian/rules
[17:56] <pitti> hm, this is a déja-vu, I remember fixing a missing DEB_HOST_GNU_TYPE last Thursday or so
[17:56] <pitti> ah right, I filed that as debian bug 735535
[17:56] <ubottu> Debian bug 735535 in owncloud-client "autopkgtest fails" [Normal,Open] http://bugs.debian.org/735535
[17:57] <pitti> doko: I must have forgotten to upload it or so; doing
[17:57] <pitti> doko: ah no, even after fixing that and another bug, the tests still fail
=== _salem is now known as salem_
[17:57] <pitti> doko: and at that point I didn't know any more what the DD's intention was, so I asked on that bug
[17:59] <pitti> doko: FYI, I usertag those: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autopkgtest;users=autopkgtest-devel@lists.alioth.debian.org (in case you wonder about another autopkgtest failure)
[18:07] <doko> pitti: I usually use severity serious for broken autopkg tests by design. it's nice if people add them, but things like this should never happen in the first place
[18:08] <doko> pitti, please overwrite this test. blocks a package removal
=== zz_mwhudson is now known as mwhudson
=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson
[20:00]  * apw wonders if there is any way to suppress: dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision
[20:00] <apw> it is preventing me fro building my signed packages
[20:31] <xnox> apw: use '3.0 (quilt)' with "echo create-empty-orig  > debian/format/options"
[20:31] <xnox> apw: which is "3.0 (native)" with any version number I like.
[20:33] <apw> xnox, nice thanks
=== salem_ is now known as _salem
[20:50] <pitti> doko: release team can do that; OOI, which package do you want removed? (how does a failed test prevent that?)
[20:56] <doko> pitti, libocsync-plugin-owncloud, waits for owncloud-client to go to trusty
[21:01] <pitti> infinity, Laney, slangasek, stgraber: can one of you please ignore the autopkgtest failure of owncloud-client? (test is broken in multiple ways, I filed a Debian bug)
[21:02] <pitti> infinity: if you are online, TB meeting is starting now in #ubuntu-meeting
[21:02] <pitti> but with the US national holiday there probably won't be too many people anyway
[21:12] <Noskcaj> pitti, If you're still around, i've got the g-s-t merge in the right place now
=== echevemaster is now known as echevemaster_afk
=== frobware is now known as zz_frobware
=== _salem is now known as salem_
=== salem_ is now known as _salem
[23:13] <xnox> doko: pyflakes uploaded with fixes/support for 3.4
[23:14] <xnox> (into debian, should autosync into ubuntu)
=== freeflying_away is now known as freeflying
=== timrc is now known as timrc-afk
=== _salem is now known as salem_