[03:32] <ScottK> wgrant: any idea why LP is spamming Debian lists: http://lists.alioth.debian.org/pipermail/python-modules-team/2015-August/025491.html
[03:35] <Unit193> Eugene San (eugenesan) seems to have subscribed https://launchpad.net/~python-modules-team
[03:35] <ScottK> Sigh.
[03:36] <ahoneybun> anyone know about android-tools-adb package?
[04:03] <ScottK> wgrant: OK, next question (asking as a DPMT admin), how do I get rights to that user so I can unsubscribe things like that?
[04:58] <wgrant> ScottK: I've killed the user, let me know if noise continues.
[08:12] <cyphermox> ahoneybun: what about android-tools-adb?
[08:24] <davmor2> cyphermox: man so weird you on at this time ;)
[08:25] <cyphermox> davmor2: I'm in Germany, at DebConf this week, so yeah it's unusual :)
[08:25] <davmor2> cyphermox: yeah I knew where you were still not used to seeing your nick active this early though ;)
[08:26] <cyphermox> it messed up my whole schedule, I stay up until 3 am easily, still up early, etc. I understand 3am is already getting quite late for EST :D
[09:48]  * apw just dist-upgraded on wily and it looks like qt4 is an utter disaster
[09:49] <ogra_> we still have qt4 in the archive ?
[09:50] <apw>  libqt4-dbus : Breaks: libqt4-dbus:i386 (!= 4:4.8.6+git64-g5dc8b2b+dfsg-3~ubuntu8) but 4:4.8.6+git64-g5dc8b2b+dfsg-3~ubuntu7 is to be installed
[09:50] <apw> i still have it on my machine, well half of it
[09:51] <apw> oh and now install -f wants to remove compiz, great
[09:52] <apw> as i just got gcc-5 and related transitions i assume its dpkg not coping with the level of change
[09:53] <apw>  libsigc++-2.0-0v5 : Conflicts: libsigc++-2.0-0c2a but 2.4.1-1 is to be installed
[09:53] <apw> i suspect strongly there is a dep here for gcc-5 which is not resolved
[09:56] <apw> oh i see, it is dbus which is broken, and that is breaking the upgrade, dammit
[09:57] <seb128> apw, what error?
[09:58] <apw>  dbus depends on libexpat1 (>= 2.0.1); however:
[09:58] <apw>   Package libexpat1:amd64 is not configured yet.
[09:58] <apw> dpkg: error processing package dbus (--configure):
[09:58] <apw>  dependency problems - leaving triggers unprocessed
[09:58] <apw> its getting dpkg into a triggers loop and failing even for an install -f
[09:58] <apw> seb128, ^
[09:59] <seb128> weird
[10:01] <apw> when apt says "try install -f (or specify a solution)" any idea how i specify such a solutoin
[10:02] <apw> i guess i could disable triggers for dbus and hope
[10:03] <cjwatson> specify a solution> list of package names to install
[10:04] <cjwatson> probably fully dependency-expanded
[10:04] <cjwatson> but if a maintainer script is failing, specifying a solution is unlikely to help
[10:05] <apw> cjwatson, i think the underlying issue is dbus triggers need to run, but dbus is unwilling to run them because a dependancy is broke
[10:05] <apw> and there seems to be no way out
[10:06] <apw> iU  libexpat1:amd64
[10:06] <apw> and indeed it isn't a happy library
[10:07] <cjwatson> what does 'dpkg --configure libexpat1' do?
[10:08] <apw> that seemed to complete successfully
[10:08] <apw> and indeed make install -f happy too ...
[10:09] <cjwatson> 'dpkg --configure -a' would probably have sorted it out too, that's just a slightly bigger hammer requiring less information
[10:09] <apw> heh, i'll try that next time, you'd think in that situation it could have figured that out, odd
[10:09] <cjwatson> dig through apt logs and look for the first point where something failed
[10:09] <cjwatson> everything else is just consequential nonsense
[10:10] <apw> will do
[10:10] <apw> once this thing is bootable again
[10:10] <apw> as i was mid pretty large dist-upgrade
[10:12] <apw> dpkg: libpcrecpp0:amd64: dependency problems, but removing anyway as you requested:
[10:12] <apw>  libpcre3-dev:amd64 depends on libpcrecpp0 (= 2:8.35-7ubuntu2); however:
[10:12] <apw>   Package libpcrecpp0:amd64 is to be removed.
[10:12] <apw> is the first thing other than happy it said in the first run
[10:14] <apw> then we install a lot of stuff, and then
[10:14] <apw> Unpacking systemd-sysv (224-1ubuntu3) over (224-1ubuntu1) ...
[10:14] <apw> Processing triggers for man-db (2.7.0.2-5) ...
[10:14] <apw> dpkg: dependency problems prevent processing triggers for dbus:
[10:14] <apw>  dbus depends on libexpat1 (>= 2.0.1); however:
[10:14] <apw>   Package libexpat1:amd64 is not configured yet.
[10:14] <cjwatson> that sort of looks like an apt ordering bug
[10:14] <cjwatson> assuming that there was no indication that libexpat1 actually failed to configure
[10:14] <cjwatson> the libpcrecpp0 thing is not a problem
[10:16] <apw> Preparing to unpack .../libexpat1_2.1.0-7_amd64.deb ...
[10:16] <apw> De-configuring libexpat1:i386 (2.1.0-6ubuntu1) ...
[10:16] <apw> Unpacking libexpat1:amd64 (2.1.0-7) over (2.1.0-6ubuntu1) ...
[10:16] <apw> Preparing to unpack .../libexpat1_2.1.0-7_i386.deb ...
[10:16] <apw> Unpacking libexpat1:i386 (2.1.0-7) over (2.1.0-6ubuntu1) ...
[10:16] <apw>  dbus depends on libexpat1 (>= 2.0.1); however:
[10:16] <apw> seems to not attempt to configure before erroring it is ont configured, so i think you're right
[10:16] <apw> i'll file this log against apt
[10:17] <apw> in case it happens to someone else
[10:19] <apw> cjwatson, and ... as always ... you are a star, thanks
[10:24] <cjwatson> apw: yw
[10:30] <apw> bug #1485970
[10:30] <apw> i am sure adam will love it
[11:38] <mdeslaur> @pilot in
[12:02] <ScottK> wgrant: thanks
[12:07] <Mirv> chrisccoulson: hey! can you give specifics on how bug #1482346 was fixed on firefox-next and what would eg be needed for mozvoikko, another main extension.
[12:08] <Mirv> and I also wonder a bit if Debian's Iceweasel would require a similar change if it's something within Firefox that has been changed
[12:11] <chrisccoulson> Mirv, the addon needs to be reviewed and signed by the addons.mozilla.org team. The developer needs to do that though
[12:12] <Mirv> chrisccoulson: ok, so no changes to Firefox itself? thanks.
[12:16] <Mirv> chrisccoulson: hmm, so firefox-next does not have ubufox changes, but instead only Firefox updated - something to check/accept the signature was added to make ubufox work, and you signed / got reviewed the ubufox at addons.mozilla.org?
[12:29] <shadeslayer> http://cdimage.ubuntu.com/ubuntu-core/daily/pending/wily-core-armhf.manifest < core is totally missing sudo
[12:29] <shadeslayer> as was 15.04 core : http://cdimage.ubuntu.com/ubuntu-core/releases/15.04/release/ubuntu-core-15.04-core-armhf.manifest
[12:42] <seb128> apw, https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1484841 looks like an issue similar to your (just mentioning it since I saw it while looking at recent reports)
[12:47] <apw> seb128, that looks very similar indeed
[12:48] <apw> seb128, i'll tie them togther and offer the OR some options
[12:49] <seb128> apw, thanks
[12:51] <apw> seb128, i see that already has 4 "also affects" on it
[12:51] <apw> seb128, hopefully it is the same and trivial to get them out of.
[12:51] <seb128> yeah
[13:05] <pitti> cjwatson, Laney: I enabled armhf for one run yesterday so that the exec nodes can now grind through the 500 tests; but I didn't want to keep it enabled to avoid blocking packages on the armhf lag
[13:05] <pitti> cjwatson, Laney: once they caught up, I'll enable it permanently and annouce it
[13:06] <pitti> cjwatson: seems you looked at exactly that time
[13:06] <cjwatson> ah, ok
[13:07] <pitti> debci-wily-armhf0
[13:07] <pitti> \o/
[13:07] <pitti> it was at 500 yesterday
[13:07] <pitti> nice
[13:07] <teward> so, how busy is the archive admins team as of late?  Out of curiosity.
[13:08] <sil2100> pitti: ping :) Any luck with the langpacks? :)
[13:08] <pitti> sil2100: was just about to look into that
[13:08] <sil2100> pitti: the OTA-6 translation export I think happened already so would be great if we could get those updated in the overlay-ppa
[13:09] <sil2100> A merge with vivid shouldn't be required as the ubuntu-rtm/15.04 has all the translations now
[13:09] <pitti> sil2100: so you want me to build fresh packs from https://translations.launchpad.net/ubuntu-rtm/15.04/+language-packs straight into the overlay PPA?
[13:09] <sil2100> (I binary-copied the missing ones)
[13:09] <sil2100> pitti: yes :) If, of course, you're confident it'll work ;p
[13:10] <sil2100> pitti: in the meantime I'll check if the latest export looks sane
[13:13] <sil2100> pitti: those look good from what I see :)
[13:13] <pitti> erk -- http://people.canonical.com/~dpm/data/ubuntu-l10n/ does not yet exist for 15.04
[13:13] <pitti> and no dpm
[13:14]  * pitti uses 14.09 and hopes that priorities didn't change too much
[13:16] <sil2100> Oh, and what is that?
[13:16] <sil2100> Maybe wily should be used for that?
[13:16] <pitti> it essentially tells us which templates we want/need in touch, and which aren't important
[13:16] <pitti> could also do that
[13:17] <sil2100> Oh, hm, not sure then, but I know we basically dual-landed to both wily and vivid-overlay
[13:17] <pitti> sil2100: ok, then wily does sound better
[13:18] <sil2100> pitti: thanks! Fingers crossed o/
[13:19] <pitti> sil2100: how much of a disaster would it be to upload to the overlay PPA in case we need a second upload?
[13:19] <pitti> sil2100: I can also upload them to another PPA, but the overall turnaround time would be the same, and it's harder to test
[13:19] <ahoneybun> cyphermox: we have adb 1.0.31 but to use adb sideload we need 1.0.32
[13:19] <pitti> sil2100: i. e. should the overlay only get firmly tested ready-to-release stuff, or sohuld I use it for the "first upload" too?
[13:20] <sil2100> pitti: should be safe... we try to have everything tested there, but we only build rc-proposed images from it so basically we say: 'yeah, stuff can be broken'
[13:20] <sil2100> So upload, we can revert if needed
[13:21] <sil2100> I built an image not so long ago so we should be good
[13:21] <pitti> ack
[13:21] <pitti> sil2100: just to clarify, these packs should *not* be uploaded to RTM itself, but only the PPA?
[13:21] <cyphermox> ogra_: ahoneybun:  ^
[13:21] <pitti> sil2100: (as we did upload to rtm/14.09 directly)
[13:22]  * ogra_ reads backlog
[13:22] <cyphermox> ogra_: it's about adb sideload
[13:22] <ogra_> cyphermox, wont work
[13:23] <ogra_> ahoneybun, only after someone ported to key auth ...
[13:23] <ahoneybun> key auth?
[13:23] <ogra_> our adbd runs completely as phablet user ... no way to sideload anything
[13:24] <ahoneybun> android-tools-adb has nothing to do with touch..
[13:24] <ogra_> (you would need a sudo wrapper or some such that installs the package)
[13:24] <ahoneybun> I'm talking about android
[13:24] <ogra_> ahoneybun, well, it does, the shipped tools and the adb PC tools come from the same source
[13:24] <ogra_> someone would need to bump both and make sure all modifications for adbd still work
[13:25] <ogra_> sadly anyone who could do that was moved out of the phone team
[13:25] <ahoneybun> one of big reasons I use ubuntu is that the package is easy to install and I don't need the whole Android SDK :(
[13:25] <ogra_> ahoneybun, understood
[13:26] <ogra_> but someone would need to forward port the existing stuff first
[13:26] <ahoneybun> I had to flash android back to the device to copy the file and then flash it
[13:26] <ahoneybun> darn I understand a bit
[13:28] <shadeslayer> pitti: whom should I poke about my ubuntu-core issue?
[13:28] <shadeslayer> ( sudo not landing on ubuntu-core )
[13:28] <shadeslayer> apparently it's there in the seed
[13:28] <ogra_> uh, since when ?
[13:28] <shadeslayer> I'm not sure who's maintaining that / doing foundations these days
[13:29] <ogra_> sudo is definitely not supposed to be in the normal ubuntu-core
[13:29] <sil2100> pitti: yes, only to the overlay
[13:29] <sil2100> pitti: we don't use ubuntu-rtm anymore
[13:29] <shadeslayer> ogra_: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily/view/head:/core-libs#L61
[13:29] <shadeslayer> unless that's a different thing
[13:29] <shadeslayer> ah wait, no, that's the task, hm, let me find the seed
[13:30] <ogra_> i think it is
[13:30] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily/current/wily-core-i386.manifest
[13:30] <shadeslayer> ogra_: yeah
[13:30] <ogra_> thats the standard ubuntu core ... a tarball based on debootstrap --minbase with just enough extra bits to install packages
[13:30] <shadeslayer> I was wondering why that's the case?
[13:30] <shadeslayer> ah I see
[13:30] <ogra_> thats the definition ...
[13:30] <ogra_> no users ... just root
[13:30] <ogra_> so no sudo either
[13:31] <shadeslayer> right, I was working on a tool that could take that as an rootfs
[13:31] <ogra_> shadeslayer, infinity used to maintain it in the past ... not sure he still does
[13:31] <ogra_> (and he is at a conferenc i think, so you might not easily catch him)
[13:31] <shadeslayer> and without sudo installed, I can't do much :P
[13:31] <ogra_> you can install sudo ;)
[13:31] <shadeslayer> ogra_: yeah, but I wanted it included in the default tar :P
[13:32] <shadeslayer> instead of shipping my own rootfs :P
[13:32] <ogra_> untar ... chroot ... install what you need on top ... re-tar
[13:32] <shadeslayer> like I said, out of scope for my tool .. ah well
[13:35] <pitti> sil2100: ok, had to do some hacks for missing l10n stats and missing 15.04 package maps, but build is running now
[13:35] <sil2100> pitti: yay! Thanks, let's see how those go o/
[13:37] <pitti> sil2100: want to get the -pl deb for local testing? seb128 will test the French one
[13:38] <sil2100> pitti: sure :)
[13:39] <sil2100> I'm not running rc-proposed on my phone though, but I suppose it should be good in overall
[13:41] <seb128> I am
[13:41] <pitti> sil2100: Houston, we have a problem
[13:41] <pitti> sil2100: https://translations.launchpad.net/ubuntu-rtm/15.04/+language-packs tarballs are just 8 MBs, and lots of missing files
[13:41] <seb128> sil2100, we are having issues with using wily for stats :-/
[13:41] <pitti> sil2100: many of them we probably don't need
[13:42] <pitti> but some we do
[13:42] <sil2100> pitti: it's good
[13:42] <pitti> e. g. we might do without ModemManager or gtk30-properties
[13:42] <tseliot> pitti: test_system_device_drivers_chroot fails again in u-d-c in my wily chroot. Is it just me? (I'm trying to fix a couple of separate issues)
[13:42] <pitti> but we do need unity.mo and evolution-data-server-3.12.mo for sure?
[13:42] <sil2100> pitti: I checked, it only has the templates and translations for the apps we need
[13:43] <pitti> sil2100: wily-15.04 French debdiff: diffhttp://paste.ubuntu.com/12118211/
[13:43] <seb128> I think we need e-d-s
[13:43] <pitti> http://paste.ubuntu.com/12118215/ -> same for -pl (looks similar)
[13:43] <sil2100> Ok, then maybe a merge will be required, we might have missed some of those
[13:43] <sil2100> But wait, how come those aren't there?
[13:44] <pitti> so do we need unity.mo, or is it unity8.mo?
[13:44] <sil2100> unity8.mo should be enough
[13:44] <pitti> sil2100: the e-d-s-3.16 template wasn't approved in wily
[13:44] <sil2100> Ah, ok
[13:45] <pitti> oh, there *is* a unity8.mo
[13:45] <pitti> so hopefully e-d-s is the exceptoin
[13:45] <pitti> because it has the version number in the name, which is unusual
[13:45] <sil2100> I made sure to include all the ones we really required, but I might have missed some that weren't obvious for me
[13:45] <pitti> seb128, sil2100: http://people.canonical.com/~pitti/tmp/ has the french and Polish rtm 15.04 packs
[13:45] <sil2100> Some I didn't include as they didn't seem user-visible
[13:45] <pitti> so maybe you can give these a spin
[13:46] <pitti> and I manually crowbar in e-d-s
[13:46] <pitti> which eds version do we need?
[13:46] <seb128> that's showing an issue with our process though
[13:46] <seb128> how did 15.04-rtm got populated?
[13:47] <sil2100> pitti: 3.12.11-0ubuntu1 I think
[13:47] <sil2100> seb128: it got populated from the packages we have in the overlay-ppa + a few I put manually from vivid
[13:47] <pitti> I grab that from vivid
[13:47] <seb128> sil2100, why didn't you get everything which was in the current langpacks?
[13:51] <pitti> sil2100, seb128: I updated debs on http://people.canonical.com/~pitti/tmp/ to include e-d-s
[13:51] <sil2100> I only included the touch specific things, yeah, my bad
[13:51] <sil2100> I should have copied over everything
[13:51] <pitti> sil2100: no big deal; we don't really need all those
[13:52] <sil2100> I wonder why oxide-qt wasn't there though, since we have it in the overlay
[13:52] <sil2100> Maybe the translations weren't batch copied for that yet?
[13:52] <pitti> sil2100: need to run out for a bit for group photo; please let me know how they work
[13:52]  * pitti reworks the upload script in the meantime to go to the overlay
[13:53] <sil2100> pitti: ok, thanks! Let's wait with the final upload yet tho :)
[13:53] <pitti> yes, of course
[13:53] <pitti> sil2100: I won't upload until you say that the manual built ones are okay
[13:53] <pitti> sil2100: seb is doing the same
[13:54] <sil2100> And unity-ui-toolkit? I wonder why that's missing, we have UITK in the overlay since AGES
[13:54]  * sil2100 is a bit worried now
[13:58] <rbasak> Is it acceptable for a package postinst to link something in /etc to /usr/share/doc/.../examples?
[13:58] <rbasak> I can't see any problem with that but I've not seen it done that way before.
[14:02] <dobey> rbasak: would be better to install the example conf to the /etc/ location in the .install file or override_dh_auto_install rule, i think
[14:03] <rbasak> dobey: makes sense. Then the normal conffile handling would work and the user wouldn't have to mess with it to make it not be readonly.
[14:12] <tseliot> pitti; ^^^
[14:13] <seb128> sil2100, pitti, mostly good, but missing uitk is an issue/regression
[14:13] <sil2100> seb128: yeah... worried about that, will investigate - I didn't forget about that one as I didn't have to, we have UITK in the overlay so it should have been fetched
[14:13] <sil2100> Checking that out, and looking at the pl translations on my krillin too
[14:14] <sil2100> Had to upgrade it to rc-proposed, my arale is on stable so I didn't even want to test there
[14:34] <cjwatson> rbasak: that seems like it would violate https://www.debian.org/doc/debian-policy/ch-docs.html#s12.3 "Packages must not require the existence of any files in /usr/share/doc/ in order to function"
[14:34] <cjwatson> rbasak: I normally put template configuration in /usr/share/<package>/ instead
[14:34] <cjwatson> (aside from the readonly thing)
[14:35] <cjwatson> seb128,sil2100: doesn't seem like an LP issue, https://translations.launchpad.net/ubuntu-rtm/15.04/+source/ubuntu-ui-toolkit/+pots/ubuntu-ui-toolkit exists
[14:35] <cjwatson> although I have not checked the export tarball
[14:36] <cjwatson> and there are Packaging records for ubuntu-ui-toolkit, so the share-translations-via-upstream black magic ought to have worked
[14:37] <cjwatson> certainly looks like there are some translations in the LP view, I can't imagine those were all contributed manually?
[14:37] <rbasak> cjwatson: ah that's perfect to get back to my submitter, thank you.
[14:38] <cjwatson> I'm not sure what's going on with oxide-qt; https://translations.launchpad.net/ubuntu/wily/+source/oxide-qt exists but https://translations.launchpad.net/ubuntu-rtm/15.04/+source/oxide-qt does not
[14:38] <sil2100> pitti, cjwatson: from the export contents, I see ubuntu-ui-toolkit.po
[14:38] <sil2100> So I think it's an langpack-o-matic issue then
[14:39] <sil2100> cjwatson: maybe it wasn't in the overlay when we were doing the copies?
[14:39] <sil2100> We sometimes removed it if there was a new version in -security
[14:39] <cjwatson> ah, could be, it isn't there now
[14:40] <cjwatson> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=oxide-qt&field.status_filter=published&field.series_filter=
[14:40] <cjwatson> so not sure why you said above that it's there now
[14:42] <sil2100> Wait, it's not?
[14:42] <sil2100> It should be
[14:42] <sil2100> We published that recently, a rebuild against the overlay
[14:42] <sil2100> hmmmmm
[14:43]  * sil2100 checks what happened with that
[14:43] <sil2100> Oh, we never published the silo
[14:43] <sil2100> cjwatson: ok, sorry, my bad ;/ I was sure this landed as I was building the silo on Friday
[14:44] <sil2100> cjwatson: I suppose it should land soon... do you think we could have an export later today?
[14:44] <sil2100> Are the ubuntu-rtm/15.04 exports taking long? There's not so many translations in those
[14:47]  * cjwatson checks
[14:49] <cjwatson> sil2100: today's took six minutes; we can certainly ask webops for another, although bear in mind that I'm the only LP staff member around at the moment and I have a guest for dinner this evening
[14:50] <sil2100> cjwatson: ACK, in the worst case, since it was so fast, we could also have it tomorrow in the morning
[14:50] <sil2100> Since the release candidate will be created tomorrow anyway
[14:50] <sil2100> cjwatson: thanks!
[14:50] <cjwatson> sil2100: so what I suggest you do is ask #webops yourself for it in this case: they need to run 'LPCONFIG=production nice -16 /srv/launchpad.net/production/launchpad/bin/py /srv/launchpad.net/production/launchpad/cronscripts/language-pack-exporter.py ubuntu-rtm 15.04 --force-utf8-encoding -q --log-file=INFO:/srv/launchpad.net/production-logs/rosetta/language-pack-exporter.log' as launchpad@loganberry
[14:54] <cjwatson> sil2100: you might not want to be in *too* much of a rush though; I can't remember how long it takes for the message sharing stuff to kick in
[14:55] <sil2100> cjwatson: ah, excellent, thanks :) I'm wondering about one thing though - once I copy oxide-qt over, won't it require a translation batch copy from wily/vivid?
[14:56] <sil2100> Since at first it'll have no translations after the templates get fetched, right?
[14:56] <cjwatson> sil2100: no, the bulk copy was only needed for sources whose templates were missed
[14:57] <sil2100> Ah, ok
[14:57] <cjwatson> sil2100: the package copy will copy the template, and when message sharing kicks in it'll copy translations across too (since both ubuntu and ubuntu-rtm oxide-qt share with upstream, so that works transitively)
[14:57] <sil2100> Oh!
[14:57] <cjwatson> sil2100: but I'm not sure *exactly* when the latter step happens
[14:57] <sil2100> That's good to know, ok, I'll give it some time before doing an export after the copy then
[14:59] <cjwatson> sil2100: oh, it's a job that's scheduled as a result of the copy, that's right - so it should be reasonably quick
[14:59] <cjwatson> I mean translations in general is kinda slow, give it a few minutes and check in the web UI
[15:02] <pitti> sil2100: ah, http://people.canonical.com/~dpm/data/ubuntu-l10n/ubuntu_wily_potemplate-stats.json has priority 0 for it
[15:02] <pitti> sil2100: I'll add it as a special case then
[15:03] <cjwatson> sil2100: but I don't understand why this is a big deal; aren't the translations from vivid merged into the touch language packs, just as the image is made up of vivid + stable-phone-overlay?
[15:03] <sil2100> cjwatson: not yet I guess, right now we're only building those from the overlay, as it in theory should have all touch-specific stuff in it
[15:03] <cjwatson> well, except it doesn't, it's an overlay! :)
[15:03] <sil2100> I think pitti would need to do some changes to langpack-o-matic to merge translations
[15:04] <sil2100> I know!
[15:04] <sil2100> :)
[15:04] <cjwatson> ok, so I think that's the real problem ...
[15:04] <sil2100> Well, I mean, in theory it shouldn't, but I copied over the few touch ones we're managing that were missing, so at least we're covered there
[15:04] <pitti> sil2100: we could download the vivid tarball, merge it with the RTM tarball, and import that
[15:04] <pitti> but I thought the point of ubuntu RTM was that we don't need to do that, as this will probably reintroduce obsolete translations?
[15:05] <sil2100> Well, I wanted to have all important translations in ubuntu-rtm/15.04 so that translators don't need to go to two different places when dealing with translations
[15:06] <sil2100> But I do see the merit of using vivid for those translations that didn't change since from the vivid side
[15:06] <sil2100> And being more complete then
[15:09] <sil2100> pitti: anyway, if anything, the vivid tarball should have the ubuntu-rtm/15.04 translations copied over it
[15:09] <sil2100> Not the other way around
[15:23] <mdeslaur> @pilot out
[15:25] <Laney> tyhicks: hi, can you take a look at dbus in ppa:laney/experimental to see if it works wrt apparmor please?
[15:27] <tyhicks> Laney: yes, I will
[15:40] <Laney> tyhicks: thanks - would be good if we could get results so that I can upload before FF (Thursday)
[15:40] <Laney> sorry for the short notice :(
[15:42] <tyhicks> Laney: I'm quite busy today since I returned from holiday this morning but I can work on it in the background
[15:42] <tyhicks> Laney: I'll have testing done by tomorrow, for sure
[15:55] <mdeslaur> pitti, kees, stgraber, infinity, slangasek: is everyone at debconf? should we cancel the tech board meeting?
[15:55] <slangasek> mdeslaur: pitti and I are at DebConf, infinity is proximate to LinuxCon
[15:56] <slangasek> stgraber is maybe there also?
[15:56] <slangasek> anyway I'm ok to cancel
[15:56] <pitti> me too
[16:07] <mdeslaur> slangasek, pitti, kees, stgraber, infinity: ok, meeting cancelled
[16:07] <stgraber> slangasek: yeah, I'm at LinuxCon
[16:07] <slangasek> mdeslaur: ack, thanks
[16:12] <pitti> seb128, sil2100: http://people.canonical.com/~pitti/tmp/ has updated debs now, after way too much manual hacking :/
[16:12] <pitti> no removed po any more, just three new ones
[16:12] <pitti> plz test
[16:13] <seb128> pitti, danke
[16:13] <seb128> pitti, hum, http://people.canonical.com/~pitti/tmp/ still has the old timestamp
[16:13] <seb128> or is that a debconf proxy issue?
[16:14] <pitti> seb128: perhaps UC?
[16:14] <pitti> UTC
[16:14] <pitti> seb128: sohuld be ~ 250 kB instead of the old ~ 40 kB
[16:14] <seb128> oh, right
[16:15] <sil2100> \o/
[16:15] <sil2100> pitti: sorry for the hacking it needed from you ;p
[16:15] <sil2100> I'll test the pl in a moment, my krillin is busy with some tests now
[16:15] <pitti> sil2100: can clean this up later, I figure for now we just need some working packs?
[16:16] <sil2100> pitti: yes :) Good thing you had time today since the plans changed and I will have to spin the first candidate today at nighttime
[16:26] <seb128> pitti, sil2100, langpacks +1 from me, tested the standard apps and scopes, seems all fine in french
[16:26] <seb128> including uitk translations that were missing earlier
[16:26] <pitti> seb128: c'est grand !
[16:27] <pitti> seb128: ou es-tu ? nous sommes dans la chambre nourriture
[16:27] <seb128> pitti, je suis à la présentation sur apt
[16:38] <sil2100> pitti: looking good here on pl too, not sure what more to check
[16:38] <sil2100> I would say - let's upload o/
[16:38] <pitti> sil2100: ack
[16:39] <pitti> sil2100: hm, argh -- these are currently targeted at 15.04, not "vivid"; they should target the latter?
[16:39] <sil2100> pitti: what do you mean?
[16:40] <pitti> sil2100: debian/changelog series target
[16:40] <pitti> sil2100: I won't upload them to RTM 15.04
[16:40] <sil2100> vivid is the target, yes :)
[16:40] <pitti> sil2100: but to "vivid"?
[16:40] <sil2100> Ouch!
[16:40] <pitti> ok
[16:40]  * pitti seds
[16:45] <pitti> sil2100: landing
[17:01] <sil2100> pitti: thanks! Yay!
[17:01] <sil2100> I see the massive uploads, awesome
[17:20] <mterry> @pilot in
[18:22] <infinity> pitti: Is there a valid argument for the dbus trigger to be "interest" instead of "interest-noawait"?
[18:38] <mstratman> This is a bit of naive question, but is there a general or rough average time between a proposed build (specifically https://launchpad.net/ubuntu/+source/postgis/2.1.8+dfsg-1build3/+build/7764679) and when it'll be available?  Basically I'm trying to assess whether to build from source or wait for a package update
[18:38] <mstratman> or are there individual maintainers and it depends on who is available and when
[18:42] <sarnold> mstratman: it looks like ..1build3 has been in wily for nearly two days https://launchpad.net/ubuntu/+source/postgis
[18:43] <mstratman> do you have any ideas for typical timelines to make it into 14.04 ?
[18:46] <sarnold> mstratman: it won't; once a distribution is released, most packages get patched for specific issues. a handful of programs like firefox, chromium-browser, mysql, libreoffice, get their updates made available, but those are by far the minority
[18:46] <sarnold> mstratman: see e.g. https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions
[18:47] <mstratman> Ok, thanks. Too bad because it has a nasty crash
[18:47] <sarnold> mstratman: does it fix a specific bug? or does it provide a specific feature?
[18:47] <mstratman> yeah, this is the main critical fix afaik: http://trac.osgeo.org/postgis/ticket/3125
[18:49] <mstratman> it sounds like pinning may be a solution, though.
[18:50] <sarnold> man, there's no links to fixes in there, how is anyone supposed to use that tracker? o_O
[19:43] <mterry> Hrm.  libgtk2.0-dev is not installable on wily/arm64?
[19:43]  * mterry wonders how best to determine why
[19:59] <brendand> mterry, depends on why it's not installable
[20:00]  * brendand realises the recursiveness of that question
[20:00] <brendand> i was really just trying to ask what error you got
[20:01] <mterry> brendand, :)  I don't know, I don't have much output.  It's causing a ftbfs for me on lshw, but the log is very vague: https://launchpadlibrarian.net/214901083/buildlog_ubuntu-wily-arm64.lshw_02.17-1.1ubuntu2_BUILDING.txt.gz
[20:01] <mterry> I'm trying to see if I can get a qemu pbuilder going for arm64
[20:02] <brendand> mterry, oh yeah apt is not that helpful there
[20:40] <chiluk> RAOF, are you around?  Can you take a look at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871 ,  and give me an upload or a reject on it?
[20:41] <chiluk> ah looks like RAOF is in australia ..  arges can you take another look at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871  ??
[20:49] <ari-tczew> infinity: could you quickly take a look on  bug 1476470 and give your feedback whether really delta can be dropped? (in your opinion, as you're last uploader)
[20:50] <arges> chiluk: where is the upstream email when you submitted this patch
[20:51] <chiluk> arges... read the sru
[20:51] <chiluk> I never submitted upstream because upstream has diverged too much and it no longer applies
[20:51] <chiluk> mostly because of the move to rely on /proc/mounts
[20:57] <mterry> @pilot out
[20:58] <chiluk> yeah arges ... I know it would be a sauce patch.. it's documented as such in the text of the patch..  I really need an accept or reject on it
[22:23]  * cjwatson retries mterry's lshw thing above, seems to be working now
[22:24] <cjwatson> (I tried 'ssh -t snakefruit sudo -iu ubuntu-archive chdist-mainonly apt-get wily-proposed-arm64 build-dep lshw', which is only useful for a small group of people but you can do the same thing with a suitably configured chdist instance, no need for qemu or pbuilder or what-have-you)