=== _salem is now known as salem_ [03:32] wgrant: any idea why LP is spamming Debian lists: http://lists.alioth.debian.org/pipermail/python-modules-team/2015-August/025491.html [03:35] Eugene San (eugenesan) seems to have subscribed https://launchpad.net/~python-modules-team [03:35] Sigh. [03:36] anyone know about android-tools-adb package? [04:03] wgrant: OK, next question (asking as a DPMT admin), how do I get rights to that user so I can unsubscribe things like that? === salem_ is now known as _salem [04:58] ScottK: I've killed the user, let me know if noise continues. [08:12] ahoneybun: what about android-tools-adb? [08:24] cyphermox: man so weird you on at this time ;) [08:25] davmor2: I'm in Germany, at DebConf this week, so yeah it's unusual :) [08:25] cyphermox: yeah I knew where you were still not used to seeing your nick active this early though ;) [08:26] 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] we still have qt4 in the archive ? [09:50] 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] i still have it on my machine, well half of it [09:51] oh and now install -f wants to remove compiz, great [09:52] as i just got gcc-5 and related transitions i assume its dpkg not coping with the level of change [09:53] libsigc++-2.0-0v5 : Conflicts: libsigc++-2.0-0c2a but 2.4.1-1 is to be installed [09:53] i suspect strongly there is a dep here for gcc-5 which is not resolved [09:56] oh i see, it is dbus which is broken, and that is breaking the upgrade, dammit [09:57] apw, what error? [09:58] dbus depends on libexpat1 (>= 2.0.1); however: [09:58] Package libexpat1:amd64 is not configured yet. [09:58] dpkg: error processing package dbus (--configure): [09:58] dependency problems - leaving triggers unprocessed [09:58] its getting dpkg into a triggers loop and failing even for an install -f [09:58] seb128, ^ [09:59] weird [10:01] when apt says "try install -f (or specify a solution)" any idea how i specify such a solutoin [10:02] i guess i could disable triggers for dbus and hope [10:03] specify a solution> list of package names to install [10:04] probably fully dependency-expanded [10:04] but if a maintainer script is failing, specifying a solution is unlikely to help [10:05] 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] and there seems to be no way out [10:06] iU libexpat1:amd64 [10:06] and indeed it isn't a happy library [10:07] what does 'dpkg --configure libexpat1' do? [10:08] that seemed to complete successfully [10:08] and indeed make install -f happy too ... [10:09] 'dpkg --configure -a' would probably have sorted it out too, that's just a slightly bigger hammer requiring less information [10:09] heh, i'll try that next time, you'd think in that situation it could have figured that out, odd [10:09] dig through apt logs and look for the first point where something failed [10:09] everything else is just consequential nonsense [10:10] will do [10:10] once this thing is bootable again [10:10] as i was mid pretty large dist-upgrade [10:12] dpkg: libpcrecpp0:amd64: dependency problems, but removing anyway as you requested: [10:12] libpcre3-dev:amd64 depends on libpcrecpp0 (= 2:8.35-7ubuntu2); however: [10:12] Package libpcrecpp0:amd64 is to be removed. [10:12] is the first thing other than happy it said in the first run [10:14] then we install a lot of stuff, and then [10:14] Unpacking systemd-sysv (224-1ubuntu3) over (224-1ubuntu1) ... [10:14] Processing triggers for man-db (2.7.0.2-5) ... [10:14] dpkg: dependency problems prevent processing triggers for dbus: [10:14] dbus depends on libexpat1 (>= 2.0.1); however: [10:14] Package libexpat1:amd64 is not configured yet. [10:14] that sort of looks like an apt ordering bug [10:14] assuming that there was no indication that libexpat1 actually failed to configure [10:14] the libpcrecpp0 thing is not a problem [10:16] Preparing to unpack .../libexpat1_2.1.0-7_amd64.deb ... [10:16] De-configuring libexpat1:i386 (2.1.0-6ubuntu1) ... [10:16] Unpacking libexpat1:amd64 (2.1.0-7) over (2.1.0-6ubuntu1) ... [10:16] Preparing to unpack .../libexpat1_2.1.0-7_i386.deb ... [10:16] Unpacking libexpat1:i386 (2.1.0-7) over (2.1.0-6ubuntu1) ... [10:16] dbus depends on libexpat1 (>= 2.0.1); however: [10:16] seems to not attempt to configure before erroring it is ont configured, so i think you're right [10:16] i'll file this log against apt [10:17] in case it happens to someone else [10:19] cjwatson, and ... as always ... you are a star, thanks [10:24] apw: yw [10:30] bug #1485970 [10:30] bug 1485970 in apt (Ubuntu) "apt-get dist-upgrade falied with a dbus trigger loop due to an unconfigured library (libexpat1)" [Undecided,New] https://launchpad.net/bugs/1485970 [10:30] i am sure adam will love it === FJKong is now known as FJKong_afk [11:38] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur === shadeslayer_ is now known as shadeslayer [12:02] wgrant: thanks === gshereme|away is now known as gshereme [12:07] 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:07] bug 1482346 in ubufox (Ubuntu) " xul-ext-ubufox isn't signed (cannot be loaded on Mozilla Firefox 41.0a2) " [Undecided,Fix committed] https://launchpad.net/bugs/1482346 [12:08] 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] Mirv, the addon needs to be reviewed and signed by the addons.mozilla.org team. The developer needs to do that though [12:12] chrisccoulson: ok, so no changes to Firefox itself? thanks. [12:16] 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? === _salem is now known as salem_ [12:29] http://cdimage.ubuntu.com/ubuntu-core/daily/pending/wily-core-armhf.manifest < core is totally missing sudo [12:29] as was 15.04 core : http://cdimage.ubuntu.com/ubuntu-core/releases/15.04/release/ubuntu-core-15.04-core-armhf.manifest [12:42] 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:42] Launchpad bug 1484841 in dbus (Ubuntu) "package dbus 1.8.12-1ubuntu5 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Confirmed] [12:47] seb128, that looks very similar indeed [12:48] seb128, i'll tie them togther and offer the OR some options [12:49] apw, thanks [12:51] seb128, i see that already has 4 "also affects" on it [12:51] seb128, hopefully it is the same and trivial to get them out of. [12:51] yeah [13:05] 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] cjwatson, Laney: once they caught up, I'll enable it permanently and annouce it [13:06] cjwatson: seems you looked at exactly that time [13:06] ah, ok [13:07] debci-wily-armhf0 [13:07] \o/ [13:07] it was at 500 yesterday [13:07] nice [13:07] so, how busy is the archive admins team as of late? Out of curiosity. [13:08] pitti: ping :) Any luck with the langpacks? :) [13:08] sil2100: was just about to look into that [13:08] 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] A merge with vivid shouldn't be required as the ubuntu-rtm/15.04 has all the translations now [13:09] 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] (I binary-copied the missing ones) [13:09] pitti: yes :) If, of course, you're confident it'll work ;p [13:10] pitti: in the meantime I'll check if the latest export looks sane [13:13] pitti: those look good from what I see :) [13:13] erk -- http://people.canonical.com/~dpm/data/ubuntu-l10n/ does not yet exist for 15.04 [13:13] and no dpm [13:14] * pitti uses 14.09 and hopes that priorities didn't change too much [13:16] Oh, and what is that? [13:16] Maybe wily should be used for that? [13:16] it essentially tells us which templates we want/need in touch, and which aren't important [13:16] could also do that [13:17] Oh, hm, not sure then, but I know we basically dual-landed to both wily and vivid-overlay [13:17] sil2100: ok, then wily does sound better [13:18] pitti: thanks! Fingers crossed o/ [13:19] sil2100: how much of a disaster would it be to upload to the overlay PPA in case we need a second upload? [13:19] 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] cyphermox: we have adb 1.0.31 but to use adb sideload we need 1.0.32 [13:19] 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] 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] So upload, we can revert if needed [13:21] I built an image not so long ago so we should be good [13:21] ack [13:21] sil2100: just to clarify, these packs should *not* be uploaded to RTM itself, but only the PPA? [13:21] ogra_: ahoneybun: ^ [13:21] sil2100: (as we did upload to rtm/14.09 directly) [13:22] * ogra_ reads backlog [13:22] ogra_: it's about adb sideload [13:22] cyphermox, wont work [13:23] ahoneybun, only after someone ported to key auth ... [13:23] key auth? [13:23] our adbd runs completely as phablet user ... no way to sideload anything [13:24] android-tools-adb has nothing to do with touch.. [13:24] (you would need a sudo wrapper or some such that installs the package) [13:24] I'm talking about android [13:24] ahoneybun, well, it does, the shipped tools and the adb PC tools come from the same source [13:24] someone would need to bump both and make sure all modifications for adbd still work [13:25] sadly anyone who could do that was moved out of the phone team [13:25] 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] ahoneybun, understood [13:26] but someone would need to forward port the existing stuff first [13:26] I had to flash android back to the device to copy the file and then flash it [13:26] darn I understand a bit [13:28] pitti: whom should I poke about my ubuntu-core issue? [13:28] ( sudo not landing on ubuntu-core ) [13:28] apparently it's there in the seed [13:28] uh, since when ? [13:28] I'm not sure who's maintaining that / doing foundations these days [13:29] sudo is definitely not supposed to be in the normal ubuntu-core [13:29] pitti: yes, only to the overlay [13:29] pitti: we don't use ubuntu-rtm anymore [13:29] ogra_: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily/view/head:/core-libs#L61 [13:29] unless that's a different thing [13:29] ah wait, no, that's the task, hm, let me find the seed [13:30] i think it is [13:30] http://cdimage.ubuntu.com/ubuntu-core/daily/current/wily-core-i386.manifest [13:30] ogra_: yeah [13:30] thats the standard ubuntu core ... a tarball based on debootstrap --minbase with just enough extra bits to install packages [13:30] I was wondering why that's the case? [13:30] ah I see [13:30] thats the definition ... [13:30] no users ... just root [13:30] so no sudo either [13:31] right, I was working on a tool that could take that as an rootfs [13:31] shadeslayer, infinity used to maintain it in the past ... not sure he still does [13:31] (and he is at a conferenc i think, so you might not easily catch him) [13:31] and without sudo installed, I can't do much :P [13:31] you can install sudo ;) [13:31] ogra_: yeah, but I wanted it included in the default tar :P [13:32] instead of shipping my own rootfs :P [13:32] untar ... chroot ... install what you need on top ... re-tar [13:32] like I said, out of scope for my tool .. ah well [13:35] sil2100: ok, had to do some hacks for missing l10n stats and missing 15.04 package maps, but build is running now [13:35] pitti: yay! Thanks, let's see how those go o/ [13:37] sil2100: want to get the -pl deb for local testing? seb128 will test the French one [13:38] pitti: sure :) [13:39] I'm not running rc-proposed on my phone though, but I suppose it should be good in overall [13:41] I am [13:41] sil2100: Houston, we have a problem [13:41] sil2100: https://translations.launchpad.net/ubuntu-rtm/15.04/+language-packs tarballs are just 8 MBs, and lots of missing files [13:41] sil2100, we are having issues with using wily for stats :-/ [13:41] sil2100: many of them we probably don't need [13:42] but some we do [13:42] pitti: it's good [13:42] e. g. we might do without ModemManager or gtk30-properties [13:42] 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] but we do need unity.mo and evolution-data-server-3.12.mo for sure? [13:42] pitti: I checked, it only has the templates and translations for the apps we need [13:43] sil2100: wily-15.04 French debdiff: diffhttp://paste.ubuntu.com/12118211/ [13:43] I think we need e-d-s [13:43] http://paste.ubuntu.com/12118215/ -> same for -pl (looks similar) [13:43] Ok, then maybe a merge will be required, we might have missed some of those [13:43] But wait, how come those aren't there? [13:44] so do we need unity.mo, or is it unity8.mo? [13:44] unity8.mo should be enough [13:44] sil2100: the e-d-s-3.16 template wasn't approved in wily [13:44] Ah, ok [13:45] oh, there *is* a unity8.mo [13:45] so hopefully e-d-s is the exceptoin [13:45] because it has the version number in the name, which is unusual [13:45] 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] seb128, sil2100: http://people.canonical.com/~pitti/tmp/ has the french and Polish rtm 15.04 packs [13:45] Some I didn't include as they didn't seem user-visible [13:45] so maybe you can give these a spin [13:46] and I manually crowbar in e-d-s [13:46] which eds version do we need? [13:46] that's showing an issue with our process though [13:46] how did 15.04-rtm got populated? [13:47] pitti: 3.12.11-0ubuntu1 I think [13:47] seb128: it got populated from the packages we have in the overlay-ppa + a few I put manually from vivid [13:47] I grab that from vivid [13:47] sil2100, why didn't you get everything which was in the current langpacks? [13:51] sil2100, seb128: I updated debs on http://people.canonical.com/~pitti/tmp/ to include e-d-s [13:51] I only included the touch specific things, yeah, my bad [13:51] I should have copied over everything [13:51] sil2100: no big deal; we don't really need all those [13:52] I wonder why oxide-qt wasn't there though, since we have it in the overlay [13:52] Maybe the translations weren't batch copied for that yet? [13:52] 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] pitti: ok, thanks! Let's wait with the final upload yet tho :) [13:53] yes, of course [13:53] sil2100: I won't upload until you say that the manual built ones are okay [13:53] sil2100: seb is doing the same [13:54] 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] Is it acceptable for a package postinst to link something in /etc to /usr/share/doc/.../examples? [13:58] I can't see any problem with that but I've not seen it done that way before. [14:02] 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] 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] pitti; ^^^ [14:13] sil2100, pitti, mostly good, but missing uitk is an issue/regression [14:13] 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] Checking that out, and looking at the pl translations on my krillin too [14:14] Had to upgrade it to rc-proposed, my arale is on stable so I didn't even want to test there [14:34] 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] rbasak: I normally put template configuration in /usr/share// instead [14:34] (aside from the readonly thing) [14:35] 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] although I have not checked the export tarball [14:36] and there are Packaging records for ubuntu-ui-toolkit, so the share-translations-via-upstream black magic ought to have worked [14:37] certainly looks like there are some translations in the LP view, I can't imagine those were all contributed manually? [14:37] cjwatson: ah that's perfect to get back to my submitter, thank you. [14:38] 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] pitti, cjwatson: from the export contents, I see ubuntu-ui-toolkit.po [14:38] So I think it's an langpack-o-matic issue then [14:39] cjwatson: maybe it wasn't in the overlay when we were doing the copies? [14:39] We sometimes removed it if there was a new version in -security [14:39] ah, could be, it isn't there now [14:40] 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] so not sure why you said above that it's there now [14:42] Wait, it's not? [14:42] It should be [14:42] We published that recently, a rebuild against the overlay [14:42] hmmmmm [14:43] * sil2100 checks what happened with that [14:43] Oh, we never published the silo [14:43] cjwatson: ok, sorry, my bad ;/ I was sure this landed as I was building the silo on Friday [14:44] cjwatson: I suppose it should land soon... do you think we could have an export later today? [14:44] Are the ubuntu-rtm/15.04 exports taking long? There's not so many translations in those [14:47] * cjwatson checks [14:49] 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] cjwatson: ACK, in the worst case, since it was so fast, we could also have it tomorrow in the morning [14:50] Since the release candidate will be created tomorrow anyway [14:50] cjwatson: thanks! [14:50] 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] 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] 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] Since at first it'll have no translations after the templates get fetched, right? [14:56] sil2100: no, the bulk copy was only needed for sources whose templates were missed [14:57] Ah, ok [14:57] 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] Oh! [14:57] sil2100: but I'm not sure *exactly* when the latter step happens [14:57] That's good to know, ok, I'll give it some time before doing an export after the copy then [14:59] 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] I mean translations in general is kinda slow, give it a few minutes and check in the web UI === Spads_ is now known as Spads === ogra_` is now known as ogra_ [15:02] sil2100: ah, http://people.canonical.com/~dpm/data/ubuntu-l10n/ubuntu_wily_potemplate-stats.json has priority 0 for it [15:02] sil2100: I'll add it as a special case then [15:03] 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? === dholbach_ is now known as dholbach [15:03] 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] well, except it doesn't, it's an overlay! :) [15:03] I think pitti would need to do some changes to langpack-o-matic to merge translations [15:04] I know! [15:04] :) [15:04] ok, so I think that's the real problem ... [15:04] 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] sil2100: we could download the vivid tarball, merge it with the RTM tarball, and import that [15:04] 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] 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 === anthonyf is now known as Guest61698 [15:06] But I do see the merit of using vivid for those translations that didn't change since from the vivid side [15:06] And being more complete then === Guest61698 is now known as anthonyjf [15:09] pitti: anyway, if anything, the vivid tarball should have the ubuntu-rtm/15.04 translations copied over it [15:09] Not the other way around [15:23] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:25] tyhicks: hi, can you take a look at dbus in ppa:laney/experimental to see if it works wrt apparmor please? [15:27] Laney: yes, I will [15:40] tyhicks: thanks - would be good if we could get results so that I can upload before FF (Thursday) [15:40] sorry for the short notice :( [15:42] Laney: I'm quite busy today since I returned from holiday this morning but I can work on it in the background [15:42] Laney: I'll have testing done by tomorrow, for sure [15:55] pitti, kees, stgraber, infinity, slangasek: is everyone at debconf? should we cancel the tech board meeting? [15:55] mdeslaur: pitti and I are at DebConf, infinity is proximate to LinuxCon [15:56] stgraber is maybe there also? [15:56] anyway I'm ok to cancel [15:56] me too === matsubara__ is now known as matsubara === alai is now known as alai-brb [16:07] slangasek, pitti, kees, stgraber, infinity: ok, meeting cancelled [16:07] slangasek: yeah, I'm at LinuxCon [16:07] mdeslaur: ack, thanks [16:12] seb128, sil2100: http://people.canonical.com/~pitti/tmp/ has updated debs now, after way too much manual hacking :/ [16:12] no removed po any more, just three new ones [16:12] plz test [16:13] pitti, danke [16:13] pitti, hum, http://people.canonical.com/~pitti/tmp/ still has the old timestamp [16:13] or is that a debconf proxy issue? [16:14] seb128: perhaps UC? [16:14] UTC [16:14] seb128: sohuld be ~ 250 kB instead of the old ~ 40 kB [16:14] oh, right [16:15] \o/ [16:15] pitti: sorry for the hacking it needed from you ;p [16:15] I'll test the pl in a moment, my krillin is busy with some tests now [16:15] sil2100: can clean this up later, I figure for now we just need some working packs? [16:16] 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] pitti, sil2100, langpacks +1 from me, tested the standard apps and scopes, seems all fine in french [16:26] including uitk translations that were missing earlier [16:26] seb128: c'est grand ! [16:27] seb128: ou es-tu ? nous sommes dans la chambre nourriture [16:27] pitti, je suis à la présentation sur apt === alai-brb is now known as alai [16:38] pitti: looking good here on pl too, not sure what more to check [16:38] I would say - let's upload o/ [16:38] sil2100: ack [16:39] sil2100: hm, argh -- these are currently targeted at 15.04, not "vivid"; they should target the latter? [16:39] pitti: what do you mean? [16:40] sil2100: debian/changelog series target [16:40] sil2100: I won't upload them to RTM 15.04 [16:40] vivid is the target, yes :) [16:40] sil2100: but to "vivid"? [16:40] Ouch! [16:40] ok [16:40] * pitti seds [16:45] sil2100: landing === brainwash_ is now known as brainwash [17:01] pitti: thanks! Yay! [17:01] I see the massive uploads, awesome [17:20] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry === matsubara__ is now known as matsubara [18:22] pitti: Is there a valid argument for the dbus trigger to be "interest" instead of "interest-noawait"? [18:38] 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] or are there individual maintainers and it depends on who is available and when [18:42] mstratman: it looks like ..1build3 has been in wily for nearly two days https://launchpad.net/ubuntu/+source/postgis [18:43] do you have any ideas for typical timelines to make it into 14.04 ? [18:46] 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] mstratman: see e.g. https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions [18:47] Ok, thanks. Too bad because it has a nasty crash [18:47] mstratman: does it fix a specific bug? or does it provide a specific feature? [18:47] yeah, this is the main critical fix afaik: http://trac.osgeo.org/postgis/ticket/3125 [18:49] it sounds like pinning may be a solution, though. [18:50] man, there's no links to fixes in there, how is anyone supposed to use that tracker? o_O === ljp is now known as lpotter [19:43] Hrm. libgtk2.0-dev is not installable on wily/arm64? [19:43] * mterry wonders how best to determine why [19:59] mterry, depends on why it's not installable [20:00] * brendand realises the recursiveness of that question [20:00] i was really just trying to ask what error you got [20:01] 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] I'm trying to see if I can get a qemu pbuilder going for arm64 [20:02] mterry, oh yeah apt is not that helpful there [20:40] 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:40] Launchpad bug 1432871 in coreutils (Ubuntu) "`df` shows bind mounts instead of real mounts." [Low,New] [20:41] ah looks like RAOF is in australia .. arges can you take another look at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871 ?? [20:41] Launchpad bug 1432871 in coreutils (Ubuntu) "`df` shows bind mounts instead of real mounts." [Low,New] [20:49] 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:49] bug 1476470 in trafficserver (Ubuntu) "Sync trafficserver 5.3.0-2 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1476470 [20:50] chiluk: where is the upstream email when you submitted this patch [20:51] arges... read the sru [20:51] I never submitted upstream because upstream has diverged too much and it no longer applies [20:51] mostly because of the move to rely on /proc/mounts [20:57] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [20:58] 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 === sarnold is now known as sarnold_ === salem_` is now known as _salem [22:23] * cjwatson retries mterry's lshw thing above, seems to be working now [22:24] (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)