[00:06] <TheLordOfTime> you guys treat this like any feature request bug, right?  https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1186754
[00:06] <TheLordOfTime> it came up in privmsg with someone asking if it should be marked as "wishlist" / "triaged" as a feature request
[00:16] <infinity> TheLordOfTime: The triager who decided it wasn't a bug seems a bit overzealous.
[00:16] <infinity> TheLordOfTime: jbicha made some fair points as to why this change might be a good thing (consistency, reduced complexity).
[00:17] <TheLordOfTime> infinity:  agreed on the overzealousness we're addressing that now
[00:18] <TheLordOfTime> infinity:  my main question was whether you'd treat it as a feature request :)
[00:18] <TheLordOfTime> at least, as the devs.
[00:18] <infinity> TheLordOfTime: Wishlist certainly seems more valid than Opinion.
[00:19] <TheLordOfTime> infinity:  that's what i thought, but i don't want to tweak "upstream project" statuses.
[00:19] <TheLordOfTime> infinity:  no harm in setting the upstreams back to "new" as they were and let upstream change those bugs' statuses, right?
[00:19] <infinity> TheLordOfTime: Seems fair.
[00:20] <infinity> I'm not even sure why "opinion" exists, except to make people not feel bad by setting bugs to "invalid".
[00:22] <TheLordOfTime> i agree
[00:22] <TheLordOfTime> TBH i think 'Opinion' should be bugcontrol only
[00:23] <TheLordOfTime> because i see it occasionally abused :/
[00:23] <infinity> I might start filing all my bugs as "opinion" and starting all the descriptions with "It is my opinion that..."
[00:23] <infinity> eg: "It is my opinion that this shouldn't segfault when I start it."
[00:25] <TheLordOfTime> heh
[00:25] <TheLordOfTime> infinity:  objections to Wishlist/Triaged which is afaict the usual standard for feature requests in the ubuntu packages?
[00:25] <TheLordOfTime> since i specialize in server packages, i like double checking on packages outside that specialization before messing with em :p
[00:26] <infinity> TheLordOfTime: Nope, seems fine to me.  If the desktop team or s-c hackers decide it should be something else, they can change it.
[00:28] <TheLordOfTime> infinity:  indeed, done btw.
[00:29] <TheLordOfTime> i'm going to go back to facedesking over the fact that nginx FTBFS on centos with the same command line options as nginx-full has in ubuntu >.<
[04:44] <pitti> Good morning
[05:51] <pitti> slangasek: what was broken in particular about 0010-Add-back-support-for-Debian-specific-config-files.patch ? all the {time,hostname,locale}ctl commands were working, now timedated is broken (see failing autopkgtest)
[05:52]  * pitti checks the difference
[05:52] <slangasek> pitti: missing support for /etc/default/keyboard, which is where our keyboard settings are stored
[05:52] <pitti> ah, thanks
[05:52] <slangasek> pitti: hadn't seen the failing autopkgtest yet, sorry - are you going to sort that today, or should I have a look in the morning?
[05:53] <pitti> slangasek: I can sort it out today
[05:53] <slangasek> ok
[05:53] <pitti> slangasek: I'd rather restore Debian's patch and do our's as a new patch on top of it if you don't mind, for easier merging
[05:53] <pitti> and I have a proposed fix for smb's crash
[05:54] <slangasek> pitti: as you prefer.  any sign yet of mbiebl's branch being pushed to the official packaging branch?
[05:54] <pitti> not yet :(
[05:55] <slangasek> strange that timedated would be failing, I thought the patches I changed only touched localed
[05:56] <pitti> no, also src/timedate/timedated.c
[05:57] <pitti> hm, I'm not sure whether Debian also uses /etc/default/keyboard; mbiebl, do you know?
[05:57] <pitti> we did quite some work on that on the ubuntu side AFAIR
[06:01] <slangasek> I haven't checked to be sure, but I'm almost positive that's in sync with Debian
[07:02] <smb> pitti, Moin. I will be in a state to test things (or even look at them) in a min or so
[07:02] <pitti> smb: ah, the amd64 systemd build in my PPA should finish in a few mins, too :)
[07:02] <smb> heh :)
[07:03] <pitti> smb: thanks for your investigations; I think I see the race condition with 0024-avoid-exit-deadlock-for-dm_cookie.patch, which also explains why it doesn't crash without that patch
[07:04] <smb> pitti, Ah ok. I did not get to a good explanation last week. There was (or is) a difference in the way that "force" was able to raise the number of childs but then I never remembered having seen messages about that
[07:05] <pitti> that patch basically keeps the worker running for a DM_COOKIE event, despite having been told to stop
[07:06] <pitti> I still don't quite understand why we need this, but you confirmed that you are still missing /dev/mapper/ devices without the patch
[07:07] <pitti> in theory, this hack of a patch shouldn't be necessary, as /etc/init/udevtrigger.conf should re-trigger all devices (for non-root partitions), and the initramfs already waits for the root partition to appear
[07:07] <smb> Yeah, the missing links seem independant, but as you said in the bug report (which I am slowly reading) lets first fix the crash and then look for the rest
[07:08]  * smb reached the bottom and prepares to boot the noisemaker
[07:08] <pitti> smb: I think missing the links is exactly what that patch was supposed to fix?
[07:09] <pitti> smb: https://launchpad.net/~pitti/+archive/ppa/+build/4637729 -> done :)
[07:10] <smb> It should, but strangely I got the missing links also when booting non-xen which most of the time did not run into the crash
[07:10] <pitti> smb: but after that, perhaps we can boot your version without the patch again, and see why /etc/init/udevtrigger.conf doesn't create the missing devices
[07:11] <smb> sure we can
[07:16] <dholbach> good morning
[07:36] <infinity> pitti: BTW, ddebs are very close to landing now.  Could you have a chat with wgrant to nail down what you'll need to change in your mirror scripts to make ddebs.u.c love the new world order?
[07:36] <pitti> \o/
[07:37] <pitti> wgrant: I guess I primarily need some API to retrieve the (links to the) recent ddebs, where "recent" should mean something like "from the last day" or "from the last 6 hours"
[07:38] <infinity> pitti: I was thinking you might want to do something more clever like backtrack from current Packages/Sources and scrape (and keep a cache, so you don't keep retrying ones that don't have ddebs attached).
[07:38] <pitti> wgrant: but I guess that might actually be similar/the same one as for the static translation tarballs?
[07:38] <pitti> such as in http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/lib/static_translations.py
[07:38] <wgrant> pitti: They're not custom uploads, so not quite the same as that
[07:38] <pitti> infinity: yeah, or that; mapping a source plus version to a set of ddeb links then
[07:38] <wgrant> I'd either scrape from Packages or just follow getPublishedBinaries
[07:39] <pitti> wgrant: so they are part of getPublishedBinaries(), they just don't appear on archive.u.c.?
[07:39] <StevenK> RIght.
[07:39] <infinity> pitti: Well, more likely Packages than Sources, I guess, since ddebs are attached to binaries.
[07:39] <wgrant> lp.distros['ubuntu'].main_archive.getPublishedBinaries(created_since_date=last_check_etc)
[07:39] <smb> pitti, Ok, I need to do more reboots for a qualified result. This first one with the ppa udev version at least had no crash and all 31 lvs of the second vg but none of the first one.
[07:39] <wgrant> pitti: Exactly
[07:39] <wgrant> pitti: They're published like normal binaries, except that they don't actually hit disk or appear in the indices.
[07:39] <StevenK> pitti: And then you can filter by .is_debug
[07:40] <pitti> ok, then mapping by published ones seems fine
[07:41] <infinity> pitti: This should have the positive effect of ddebs.u.c no longer carrying cruft from PPAs, too.
[07:42] <pitti> exactly
[07:42] <infinity> pitti: Anyhow, we plan to do a soft transition where we upload via .changes and keep publishing tarballs to public_html, but I want the latter to go away as quickly as it can.
[07:45] <shadeslayer> infinity: :O ... we're going to get ddebs? :O
[07:46] <StevenK> We've had ddebs for a while? This is ddebs actually being handled properly by Soyuz rather than the hacky band-aid we've had for far too long.
[07:47] <wgrant> (but still not on archive.ubuntu.com, for space reasons)
[07:47] <infinity> pitti: To be clear, you now have space to publish ddebs for all arches, right?  You're not pruning anymore?
[07:48] <infinity> pitti: I know vorlon had a bit of a grump about retracing being completely useless on powerpc due to missing ddebs.
[07:48] <shadeslayer> ah
[07:49] <pitti> infinity: /dev/mapper/ppa_vg-ppa  2.8T  685G  2.2T  25% /srv
[07:49] <pitti> infinity: should be fine indeed
[07:49] <StevenK> Haha, I thought that LV name was familiar
[07:49] <infinity> pitti: Yay.  Though, I know there was also a plan to make retracers fall back to the librarian if ddebs didn't have the file, so that'll also be helpful if ddebs fills up somehow.
[07:50] <infinity> StevenK: Yeah, ddebs is germanium, all repurposed-like.
[07:50] <infinity> And apparently not wiped..
[07:50] <StevenK> infinity: Change the hostname in apache, delete most of /srv, call it done?
[07:50] <pitti> infinity: indeed, and I think that's the better mid-term solution even as we can also retrace crashes from earlier package versions
[07:51] <pitti> infinity: but I guess we still want an actual archive for ddebs, for people who use it with apt
[07:51] <infinity> pitti: Yeah, I like the apt archive existing and, ideally, that should be "published" in a sane fashion, but a bit of shoestring and bubblegum between A and B works.
[07:51] <infinity> pitti: And absolutely, retracers being able to retrace old versions will be great.
[07:59] <zyga> good morning
[08:01] <pitti> slangasek: hm, I tried "localectl set-x11-keymap pc101 et" and that only wrote /etc/X11/xorg.conf.d/00-keyboard.conf, didn't change /etc/default/keyboard
[08:02] <pitti> slangasek: I'm writing a complete autopkgtest now, and will fix this (also for reading)
[08:04] <jamespage> @pilot in
[08:06] <jamespage> mdeslaur, re bug 1184223
[08:07] <jamespage> will the security team be picking up the fixes for < saucy?
[08:10] <pitti> slangasek: ah, ignore me; screw you, autogenerated debian/patches/debian-changes
[08:12] <didrocks> pitti: mind if I join to the complaint from past similar experiences? ;)
[08:35] <pitti> smb: would you say that 11pitti1 generally improves things (maybe not completely fix it yet)?
[08:35] <pitti> smb: I'm pondering an upload to re-fix timedatectl, and that crash fix
[08:36] <pitti> smb: if/when you would like to debug again, perhaps we can mumble?
[08:36] <smb> pitti, So I got a few more reboots (takes a bit on that machine) but at least those are consistent and look like an improvement at least
[08:36] <smb> sure
[08:47] <dpm> morning all. Is there an archive admin around who could upload qreator on https://launchpad.net/ubuntu/saucy/+queue ? It's been sitting there for a while, and it'd be great to have it in Ubuntu. Thanks!
[08:51] <Laney> doko: around? Can you look at this calligra no-change rebuild log and tell me if you think it's a gcc-4.8 issue please? http://paste.ubuntu.com/5728708/
[08:52] <Laney> It builds alright with 4.7
[09:11] <infinity> Laney: Can you crank up the verbosity on that and try again?
[09:11] <infinity> Laney: It just shows the command line and exits, that's not helpful. :P
[09:12] <Laney> infinity: look further up, sorry
[09:12] <Laney> it's a parallell build
[09:12] <Laney> line 9291
[09:12] <infinity> Oh, I missed the earlier exit.  It seems to cascade a few times. :/
[09:13] <Laney> Probably would have been kinder to rebuild it without parallel=9 when sharing the log :P
[09:18] <infinity> Laney: It could be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57279
[09:18] <Laney> I did come across that
[09:18] <Laney> didn't seem to be a 4.8.1 package in the usual place that I could test with though
[09:18] <infinity> Or it could be bad C++.  My C++ skills aren't stellar.
[09:19] <infinity> Laney: It's not fixed in 4.8.1 anyway, hence the milestone bump to 4.8.2
[09:19] <Laney> ah, I misunderstand the last comment then
[09:19] <Laney> indeed
[09:19] <Laney> would it be bad to upload a build with 4.7?
[09:20] <infinity> Wouldn't be world-ending, but it would be nice if you also filed a bug in LP, mention that upstream bug that may or may not relate, and keep an eye on things.
[09:20] <infinity> When doko uploads a new gcc-snapshot, that should have the upstream bugfix in it (the current one is three days too old to...)
[09:20] <Laney> right
[09:22] <Laney> This should get us to migrating poppler, AFAICT
[09:24] <seb128> Laney, do you know why update_output.txt lists libreoffice-mysql-connector ?
[09:25] <Laney> seb128: entangled with mysql-connector-c++
[09:25] <seb128> ah, ok
[09:26] <seb128> Laney, ok, I see they both should be fine with the uploads you did + calligra
[09:26] <Laney> seems fine - the autohinter picks it up if you look near the end of the file
[09:56] <xnox> seb128: Laney: i'm looking into gdcm build failure rabbit hole, so far I am down to patching vtk to rebuild against updated python2.7....
[09:56] <seb128> xnox, did the upload Laney just did failed to build?
[09:56] <xnox> hm.
[09:57] <xnox> seb128: hm. it works. =) oh well, vtk does need rebuilding anyway.
[09:58] <Laney> I did briefly look at new vtk and bashed its rules about a bit
[09:58] <Laney> it assumed python and tcl were in non-multiarch directories
[10:00]  * xnox suspects my machine is polluted with local builds.
[10:01] <Laney> xnox: http://paste.debian.net/8208 was my WIP before I stopped because mitya57 had a sponsoring request up that didn't need it
[10:01] <Laney> feel free to carry it on
[10:04] <xnox> Laney: so calligra is the last one for poppler to transition?!
[10:04] <Laney> think so
[10:04] <hrw> can someone with core-dev permissions take http://pastebin.com/n1TLE7rU and upload libwps? fixed ftfbs
[10:06] <infinity> hrw: Sure.
[10:06] <hrw> infinity: thx
[10:11] <cjwatson> pitti: Re the ddebs discussion above, did anyone happen to mention that ddebs doesn't seem to be picking up saucy-proposed?
[10:11] <cjwatson> i.e. http://ddebs.ubuntu.com/dists/saucy-proposed/main/binary-i386/ has an elderly timestamp
[10:12] <pitti> not to me
[10:12] <pitti> ooh, I know why
[10:12] <pitti> traditionally I have generated the pockets for the devel release once after opening the series only
[10:13]  * pitti updates cronjobs
[10:13] <pitti> we don't let the LP retracers run against saucy-proposed so far, though
[10:14] <cjwatson> pitti: Yeah, I was trying to figure out something manually.  Thanks
[10:14] <pitti> cjwatson: fixed, thanks
[10:14] <cjwatson> (I fell back to a local build, successfully)
[10:14] <pitti> (it's currently running, so it'll take some 4 hours to become effective)
[10:15] <pitti> I wish apt-ftparchive wouldn't be so abysmally slow
[10:15] <infinity> Laney: export CPP=gcc-4.7?  ITYM CC?
[10:15] <infinity> Laney: Though, I'm sure the CXX export will get what you wanted anyway.
[10:15] <Laney> oops, but yeah
[10:16] <Laney> it was test-built, so that's enough
[10:17] <infinity> (curious that exporting CPP=CC doesn't make something explode, but whatever)
[10:53] <pitti> cjwatson: http://ddebs.ubuntu.com/dists/saucy-proposed/main/binary-i386/ is current now, FYI
[10:53] <pitti> s/current/up to date/
[10:54] <cjwatson> pitti: Great, thanks
[10:54] <Sargun> Saucy = 13.10?
[10:55] <cjwatson> Yes
[10:56] <Sargun> Almost out of letters
[10:56] <pitti> unicode has a loooot of letters left :)
[10:56] <Sargun> nooo
[10:57] <mlankhorst> lets start with glyphs
[10:58] <cjwatson> Sargun: We reused our first initial letter five years ago
[10:59] <maxb> But that was a bit of a special case
[11:01] <cjwatson> Sure, but nevertheless
[11:01] <cjwatson> It demonstrates that the universe will not end when we reuse a letter
[11:29] <jamespage> please could someone with the right permissions
[11:29] <jamespage> mark https://code.launchpad.net/~sdeziel/ubuntu/raring/mysql-5.5/fix-for-lp1185573/+merge/166379
[11:29] <jamespage> as merged.
[11:38] <mdeslaur> jamespage: yes, the security team will be doing them (LP: 1184223)
[11:39] <jamespage> mdeslaur, great - thanks for confirming.
[11:39] <mdeslaur> jamespage: we've rated it as "low" though, so it may take a while
[11:40] <mdeslaur> hrm, since someone has a tree, we'll sponsor that and do the others
[11:41] <jamespage> mdeslaur, great - thanks
[11:52] <jamespage> @pilot out
[12:42] <cjwatson> infinity: So, I'm getting pretty bored carrying on with merging your generalisation to all arches of the perl = TRUE stuff in r-base (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679180).  I agree that your version is saner, but it looks like the Debian maintainer ignored it, and since raschsampler appears to build just fine with current r-base on Debian arm* these days, I'm sort of inclined to drop the patch and ...
[12:43] <cjwatson> ... call it good.  Any thoughts
[12:43] <cjwatson> ?
[12:54] <stokachu> xnox: if you get a chance today could you re-upload sosreport for me?
[12:55] <stokachu> ive fixed the non native thing
[13:45] <stokachu> xnox: thanks man
[13:47] <xnox> stokachu: =)
[15:18] <hallyn> the sgabios package is currently in debian's NEW queue.  When it clears, will it be automatically pulled into universe?  Or does a switch need to be toggled?
[15:19] <mlankhorst> the wiki has instructions on how to get packages in universe
[15:22] <hrw> hallyn: man requestsync
[15:22] <hallyn> mlankhorst: what i saw only said "if you can, get it in through debian' but didn't say how to get it into universe from there
[15:23] <hallyn> hrw: ok, thanks.  i'm not motu, but if that needs to be done i'll get it done - thanks
[15:25] <tumbleweed> hallyn: it'll be automatic (as in you don't need to ask), but will need an archive-admin to review it
[15:25] <hallyn> cool, thanks.  Just need to wait on that before qemu 1.5-3 goes into saucy
[15:34] <cjwatson> hallyn: it's automatic
[15:34] <cjwatson> ah, tumbleweed said
[15:34] <hallyn> great - thanks
[15:34] <cjwatson> if it happens before DebianImportFreeze, it doesn't really require much in the way of archive admin - it goes straight past source NEW (we trust Debian ftpmasters enough for that) and binary NEW is pro-forma
[15:53] <dholbach> mfisch, congratulations! :)
[15:53] <hrw> is it normal that launchpad assumes that maintainer==uploader when package is synced from debian?
[15:54] <hrw> https://launchpad.net/ubuntu/+source/vboot-utils/0~20121212-2 lists Antonio as uploader...
[15:55] <tumbleweed> hrw: yeah, look at publishing history for the details
[15:55] <tumbleweed> the UI never really learned about syncs
[15:55] <hrw> tumbleweed: thanks
[16:03] <mfisch> thanks dholbach
[16:05] <Versable> Hey, can someone help me with bzr?
[16:07] <Versable> I have copied a branch into my own bzr branch, changed a couple of files, added a recipe and pushed it into my PPA
[16:09] <Versable> but it only build an i386 build, even though in the control file Architecture: all is specified
[16:10] <Laney> hmm
[16:10] <tumbleweed> Versable: you want Architecture: any
[16:10] <Laney> what's responsible for creating the XDG_RUNTIME_DIR?
[16:10] <tumbleweed> Versable: Architecture: all is for architecture-independant packages
[16:11] <Versable> tumbleweed: Thanks, the package might be architecture independant, I'll check before changing the control file
[16:12] <Laney> some tests in glib now expect to be able to write there but nothing creates it apparently
[16:13] <Versable> tumbleweed: Doh! It was, thanks though ;)
[16:13] <cjwatson> If it really is architecture-independent, then you would only expect an i386 build (since it builds arch-indep binaries), but it would still publish for all arches
[19:05] <bdmurray> kirkland`: did you say you could verify bug 1173209?
[20:41] <infinity> cjwatson: The r-base hack is just a hack anyway, regardless of if it's arch-specific or not, it doesn't fix the real bug, just works around it.
[20:42] <infinity> cjwatson: If the Debian maintainer's hackish workaround works as well as mine, I'm not emotionally attached to mine.
[20:49] <infinity> cjwatson: iz synced now.
[21:34] <quadrispro> hi there
[21:35] <cjwatson> infinity: Ta
[23:15] <bdmurray> robru: would you have a look at bug 1164302?