=== maclin_ is now known as maclin === mwhudson is now known as zz_mwhudson [05:25] ScottK: my best estimate would be in 2.5 weeks from now, with the new 5.2.1 fixing some remaining issues and QA team coming up to speed in testing with 5.2.1 appearing in PPA soon. there'll be a bit of new extra work also because mkspecs location changed in Debian recently and that wasn't reflected in our packaging before now. [05:59] Can someone please upload lp:~noskcaj/+junk/gnome-weather to trusty? debian won't upload it in time and ubuntu-gnome needs it [06:00] oops, lp:~noskcaj/+junk/gnome-photos actually [06:05] pitti: Yo! === maclin_ is now known as maclin [06:39] Good morning [06:39] RAOF: hey [06:39] pitti: Good morning! [06:40] I've got two questions - how soon will those umockdev commits land in trusty, and how would you like the load_ioctl(testbed, NULL, "foo.ioctl") thing implemented? [06:41] Hm. But first I apparently need to get some mushrooms, so I'll ping you again later :) [06:46] RAOF: if you want those commits, I'll do a microrelease/upload today [06:50] RAOF: ioctl_record_open() needs to write $UMOCKDEV_IOCTL_RECORD_DEV (major/minor) as the first line into the .ioctl file; or if that's impractical/ugly, umockdev-record needs to pass the original device name in addition (perhaps UMOCKDEV_IOCTL_RECORD_DEVNAME) [06:52] RAOF: then ioctl_tree_new_from_text() needs to be able to load that [06:52] RAOF: perhaps "@DEV /dev/...." (@ to make it an invalid ioctl name) [06:55] RAOF: hm, actually evaluating it in ioctl_tree_new_from_text() is a bit impractical, as you'd need to pass it upwards and back in time [06:56] RAOF: so I guess ioctl_tree_new_from_text() should just ignore it, and load_ioctl() itself needs to open it once, read the first lines, and evaluate the @ commands [06:56] RAOF: you need to make "string dev" to "string? dev", check it for null, and if it is, open the file, read the devname, and use that instead of "dev" [06:57] pitti: Ah, good. That was roughly what I was thinking, except using # instead of @. [06:57] RAOF: # is an usual comment character, though [06:57] RAOF: we support # in .script files; not sure that it already does in .ioctl files, but it should [06:58] (particularly when you hand-edit them) [06:58] Right; I was going to have ioctl_record_open write something like "# originally recorded from: /dev/baz"; “@ DEV /dev/...” seems better, though. [06:59] pitti: So, I notice that ioctl_record_open supports appending to existing .ioctl files. How would you want that handled? [07:00] RAOF: right, if the file already has non-zero length you shouldn't write it again [07:00] syntactically it should be ok (ioctl_tree_* should just ignore @DEV entirely), but it would look confusing [07:00] Or we could support loading for multiple things, with a little bit of extra effort in umockdev.vala [07:01] If you don't think loading for multiple things is likely to be valuable (it's not something I want at the moment), just suppressing it for non-zero file lengths is fine. [07:01] hm, I wouldn't want to stuff traces from multiple different devices into one .ioctl file TBH [07:01] the format and its traversing is complicated enough as it is [07:01] Sweet. [07:02] So, should umockdev-record error out if it tries to append something from a different device node? [07:02] there should be an assertion [07:02] it Should Not Happen™, so it doesn't need to be a fancy error message [07:02] oh wait [07:03] if one umockdev-record sessio opens the device multiple times, it can't happen [07:03] but you can record into the same file multiple times, indeed [07:03] RAOF: so yes, then umockdev-record should error out [07:03] Good. [07:03] if we want to support that at some point, we can do that without breaking compatibility [07:04] Indeed. It wouldn't be _super_ hard to do (read in the file in umockdev.vala, split it out into the apropriate ioctl files), but I don't know if it's _useful_ :) [07:05] *nod* [07:05] RAOF: yeah, I'm more concerned about user confusion than implementation [07:21] mlankhorst: tested ppa7, I followed up to bug 1278737 [07:21] bug 1278737 in xorg (Ubuntu Trusty) "Upgrade to trusty fails from precise backported enablement stacks" [High,In progress] https://launchpad.net/bugs/1278737 === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [08:33] pitti: well it seems that multi-arch: no is required on newer ubuntu, but precise used multi-arch: none.. [08:34] I'll just skip that field altogether [08:34] if it's not there, it should be similar to M-A: same, right? [08:35] no it skips to multi-arch: none I guess [08:35] which is what's needed [08:41] good morning [09:15] pitti: yeah I fixed m-a none, can you still hit the geode issue? [09:16] * pitti boots the precise live system [09:25] mlankhorst: confirmed, no held back packages any more; great! [09:26] good [09:26] mlankhorst: want to upload? I can do the NEWing, and then re-run the full upgrade tests [09:26] I can't upload, tjaalton? :P [09:27] push it to git [09:27] mlankhorst: I can sponsor it, if you want [09:27] mlankhorst: (with dropping the ~ppa suffix) [09:27] hm can't use git since it had the merge from debian already staged [09:28] it's a new source package [09:28] ah [09:28] ok then :) [09:28] and it'll get removed in trusty+1 again [09:28] https://mblankhorst.nl/etc/ xorg-lts-transitional* [09:28] so probably not worth the trouble [09:28] I thought it was xorg source modified [09:28] sure [09:28] tjaalton: no way I want to have this hit version control [09:28] :P [09:28] hehehe [09:28] no complaints there [09:30] pitti: at one point you need to upgrade and confirm whether /usr/lib/xorg/protocol.txt still exists [09:31] mlankhorst: *nod*; is its existance enough, or should we assert some contents? [09:31] mlankhorst: I can add that as a post-upgrade test [09:31] no, existence is enough [09:32] mlankhorst: and protocol-{precise,*}.txt should not exist any more? [09:32] I'm also curious about "update-alternatives --config x86_64-linux-gnu_gl_conf" after upgrade [09:32] pitti: just protocol-precise.txt that exists [09:32] it's overridden by xserver-common [09:32] mlankhorst: I mean after the upgrade [09:32] yeah protocol-precise.txt should be gone [09:32] in trusty we certainly don't expect protocol-precise.txt any more, or do you? [09:33] it was a diversion added by xserver-common-lts-w/e [09:33] *nod* [09:37] mlankhorst: hm, no copyright file, I'll add a simple one [09:37] 'not eligible for copyright' really! [09:37] there are no contents either! :-) [09:39] slangasek, infinity, cjwatson: does any of you have a strong objection to restrict the list of archs for firefox to amd64/armhf/i386? (same as chromium) It fails to build on arm64/ppc/ppc64 and noboby seems to have available slots to work on those issues, meanwhile that blocks migration to trusty and means we are 3 versions behind (we never had a version built on the trusty toolchain yet) [09:39] chrisccoulson, ^ [09:41] seb128, there are patches for arm64, which were once overwritten by chrisccoulson [09:41] doko, those patches were not upstreamed and we don't have the resources to distro maintain them and rebase on new versions by ourself [09:41] jamespage, 1268915 is still incomplete. could you subscribe? [09:42] indeed, and they only make it build. without a jit compiler for arm64, it would be even more unusable than the current arm build [09:42] which is already terrible [09:43] doko: done [09:44] it looks like ppc actually builds, but then crashes when creating the startup cache. that needs someone with real hardware to debug that really [09:45] not having a porting box for ppc doesn't help there [09:51] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti [09:58] ups, pitti went offroad [09:59] pitti, easy on the piloting ;-) [09:59] * seb128 hugs pitti (just saw the ibus-pinyin sync) [09:59] seb128: yeah, sorry about taht; already undid my damage [09:59] no worry [10:01] happyaron filed the libpyzy MIR and mterry already did a first review, good [10:03] seb128: hey === Guest3895 is now known as happyaron [10:03] seb128: hey [10:03] happyaron, hey [10:04] lol, I was looking for you, I even looking in the calendar to see if you were off [10:04] seb128: shall I subscribe desktop team for libpyzy? [10:04] :) [10:04] happyaron, "desktop-bugs" is our bugs team [10:04] so yes [10:04] or let me know if you don't the rights to do that [10:05] seb128: I can't subscribe it on LP, :( [10:06] pitti, pilot, can you take a look at the gnome-ey stuff in the queue [10:07] darkxst, from #ubuntu-desktop backlog, seems he's already doing [10:08] seb128, boom :( gdm still restarting ;( [10:08] darkxst, did you try twice? [10:08] darkxst, it's the prerm from the installed version that stops it [10:09] darkxst: I'm at gnome-menus ATM [10:09] darkxst, so when installing the new fixed deb it's going to restart, because of the prerm of the installed version, then it should work [10:09] seb128, yes, right, it worked second time [10:11] you should sed the prerm of the old one ;-) [10:11] * Laney RUNS [10:11] pitti, there is also lp:~noskcaj/+junk/gnome-photos, I told Noskcaj to file a bug but he didnt ;( [10:12] oh actually I don't think you can [10:12] https://wiki.debian.org/MaintainerScripts?action=AttachFile&do=get&target=upgrade.png [10:15] darkxst: bug 1279201 [10:15] bug 1279201 in Ubuntu "[needs-packaging] gnome-photos" [Wishlist,Fix committed] https://launchpad.net/bugs/1279201 [10:18] pitti, ah, ok [10:19] darkxst: ah, gnome-photos landed in the NEW queue 23 mins ago [10:20] yes, I see that now [10:20] hum, trusty doesn't seem to recognize win 8.1 at all.. the partitioner says the disk is empty [10:24] tjaalton: And yet grub finds it just fine! [10:24] RAOF: didn't go that far yet, this is still the installer [10:28] and I'd like to keep win8.1 there, if only just for civV which just crashes here on wine :) [10:29] Oh, indeed. [10:29] You should probably also want to keep XCOM:EW :P [10:32] don't have that one, yet anyway :) [10:34] seb128: there are a *lot* of rdepends on firefox - for instance packagekit's arch-specific build-depends would need to be tweaked if we were removing firefox/powerpc. I can see your point but it needs actual thought and hard work following the rdepends stack and thinking about it rather than just restricting the arch set [10:35] it's probably tractable, but please make sure that that work is done rather than just left to +1 maint or something [10:35] cjwatson, thanks for pointing that out. What would be the right place to have that discussion? ubuntu-devel@? [10:35] Seems reasonable, yeah [10:39] thanks [10:39] doko: hello, could it be possible to move to main the following checkbox dependencies? bug 1277408 and bug 1278822. So that our next upload of checkbox can have all its dep in main [10:39] bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1277408 [10:39] bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,Fix committed] https://launchpad.net/bugs/1278822 [10:40] RAOF: oh, to clarify: (1) do you want to work on the load_ioctl(NULL) thingy, and (2) do you want a release now or wait on (1)? [10:41] pitti: (1) yes, and (2) yes, please wait. [10:41] cjwatson: QA caught an issue with Jockey in 12.04.3 (hybrid graphics won't work with the new X stack). I've filed bug #1279229 and uploaded a fix in precise-proposed [10:41] bug 1279229 in jockey (Ubuntu) "Jockey is unable to check Saucy's xserver ABI" [High,In progress] https://launchpad.net/bugs/1279229 [10:42] RAOF: ack, thanks [10:42] pitti: Also - do we get DEP-8 tests run on syncs from Debian? I added some to fsharp, but they don't seem to have been run. [10:42] RAOF: we generally do, yes [10:42] They get missed on the first upload AFAIK [10:42] that was fixed [10:43] RAOF: très interessant, I'll have a look at that later [10:43] Well then, :) [10:43] Just to check - they should show up on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/ if they get run, right? [10:43] correct [10:43] Testsuite: autopkgtest [10:43] that looks fine to me, too [10:45] cjwatson: is https://code.launchpad.net/~dannf/ubuntu/trusty/base-installer/arm64/+merge/199972 something you'd rather handle yourself, or should I sponsor this? [10:46] I'll take care of it, I did most of the rest of that stuff at the core sprint [10:46] cjwatson: ack [10:46] just ran out of time there [10:47] https://code.launchpad.net/~dannf/ubuntu/trusty/base-installer/arm64+calxeda-subarches/+merge/199977 as well then, I assume [10:47] (which includes the previous MP) [10:48] yeah [10:49] happyaron, desktop-bugs subscribed to libpyzy now [10:49] seb128: great [10:56] my partman bug was already reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731736 [10:56] Debian bug 731736 in debian-installer "partman doesn't detect GPT partitions installed Windows 8.1" [Important,Open] [11:08] huh, why are we still on parted 2.3? [11:10] found debian #646130 [11:10] Debian bug 646130 in parted "parted versions lags behind" [Normal,Open] http://bugs.debian.org/646130 [11:33] cjwatson: did you get my message? [11:35] tseliot: probably best not to rely on just me for all things precise since I need a break from it after 12.04.4, but I'll have a look at this SRU I guess [11:36] mlankhorst: oh, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [11:36] mlankhorst: xserver-xorg-video-geode-lts-* mustn't be built on amd64 [11:37] bdrung: Is there a way to use ubuntu-distro-info to get the full name (-r) of the current release? [11:37] tseliot: ok, looks reasonable [11:38] Laney, current release = the latest stable release? [11:38] bdrung_work: the one you're running it on [11:39] mlankhorst: fixing.. [11:39] or maybe going from codename to release would be okay [11:39] trusty → 14.04 LTS for example [11:39] tseliot: (accepted) [11:39] Laney, no. distro-info has no info what release you are running on [11:40] currently it does not support a codename -> fullname/release mapping [11:40] cjwatson: ok, thanks a lot [11:41] bdrung_work, hey, did you get my email about Sweetshark's libroffice's ppu application? [11:41] xnox: ^ [11:41] I read that as 'patches welcome' [11:42] seb128, probably. i'll hope to find time to process my mail backlog at the weekend [11:42] bdrung_work, good ... is that application still blocked on anything? [11:42] mlankhorst: http://paste.ubuntu.com/6919521/ [11:43] bdrung_work: Laney: thanks. [11:43] seb128, i have to look into the mail and look at the progress of the last month [11:44] xnox, yes, patches are welcome [11:44] bdrung_work, do you think you are going to have slots to do that soon? if not can you delegate to other ppu members? [11:45] bdrung_work, that application is ongoing for ages and we feel like we addressed all the initial concerns, it would be nice to see things moving or have an update on what more should be done [11:45] seb128, i'll try to do it on the weekend. otherwise i have to delegate it. [11:45] thanks [11:46] since i have a job, my free time is heavily reduced === _salem is now known as salem_ [11:51] bdrung_work: may i upload https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1012439 ? [11:51] Launchpad bug 1012439 in debootstrap (Ubuntu) "carve out distro information to distro-info package" [Undecided,Confirmed] [11:52] that's a long week :P [11:52] xnox, you may :) [11:53] i think there was an objection against this patch [11:53] hi [11:53] Laney: like my accidental 6 month holliday?! =) [11:53] accidents happen right [11:54] anyway I heard we know one of the debootstrap maintainers ;-) [11:54] was it a deliberate decision to have the desktop web apps integration use the touch-optimized webbrowser-app in trusty? will that app be made more desktop friendly before the trusty relase? [11:55] xnox, bonus: get the patch into debian [11:57] Laney: debootstrap maintainers? who is that? =) [11:57] http://packages.qa.debian.org/d/debootstrap.html [12:01] xnox: please don't diverge debootstrap in Ubuntu, it's hassle [12:02] cjwatson: ok. [12:03] xnox: that latest version of the debootstrap patch is probably ok, but if we use it it should be in Debian [12:03] (case in point, I just synced debootstrap) === freeflying_away is now known as freeflying [12:04] xnox: but hey, you're in the d-i team these days [12:10] cjwatson: hi! I updated https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674 [12:18] mardy: ack, will look later today, trying to finish something else off [12:20] bdmurray, did you find out anything about the php issues? [12:21] so if I run : grep-dctrl -P kde4libs -F Build-Depends /var/lib/apt/lists/es.archive.ubuntu.com_ubuntu_dists_trusty_main_source_Sources : it seems to give me the entire kde4libs source information, but I explicitly told it to give me the Build Depends field, any ideas what I'm doing wrong? [12:22] -F is "search by this field"; if you want "show this field" you need -s instead [12:23] ahh [12:25] pitti: can you make xserver-common* architecture: all ? and I want to point out that you matched with *geode** :P [12:27] pitti: any objections to modifying the apport cleanup cronjob to also clean the drkonqi files we create through kdelibs? [12:28] apachelogger: fine for me === MacSlow is now known as MacSlow|lunch [12:38] jamespage, why did you drop the juju gccgo binaries for x86? are these builds still being tested? [12:39] doko, not any longer [12:40] jamespage, are any gccgo binaries being tested? [12:40] doko, on ppc64el and arm64 yes [12:40] ok [12:41] doko, oh - and upstream will be checking with gccgo still so we don't regress those platforms [12:41] upstream? [12:41] doko, juju team [12:41] ahh [12:49] hm [12:50] pitti: apport's cron actually excepts whoopsie's .upload*, do you simply leave them around since they are 0byte anyway? [12:51] apachelogger: they are cleaned up after 7 days [12:51] apachelogger: I guess ev did it that way to avoid cleaning up crahses which have an .upload but not an .uploaded yet, or so (but I'm not sure, it woudln't work that way) [12:52] mh [12:52] pitti: ok, going hold on to that then since the drkonqi stuff is related ^^ [12:53] mlankhorst: WDYT? http://paste.ubuntu.com/6919792/ [12:54] pitti: looks good! [12:54] uploaded [12:54] maybe that will fix the weird issue [13:00] tjaalton: just looking at bug 1278898. The server team aren't actively looking after cobbler now, since the MAAS team stopped depending on it. I also note that there's no Debian package for this now. Are you happy to continue caring for the package in universe, or should we drop it? [13:00] bug 1278898 in cobbler (Ubuntu) "cobbler-web: import error with django 1.6.x (trusty)" [Undecided,New] https://launchpad.net/bugs/1278898 [13:00] rbasak: there's a new upstream bugfix release to address that, I'll push that to trusty soon [13:01] packaging has been in collab-maint git, but guess there's no itp for it yet [13:01] Ah, OK. Thanks! [13:01] pitti: https://code.launchpad.net/~apachelogger/apport/cleanup-drkonqi-files/+merge/205955 === MacSlow|lunch is now known as MacSlow [14:03] apachelogger: bah, this is rather hard to read :) [14:04] apachelogger: i. e. this cron job does *not* remove drkonqui files after 7 days, while current apport does? [14:05] pitti: what, for me the find returned the drkonqi files with mtime >7days [14:06] alas, the find syntax is nigh unparsable to my puny mind [14:07] apachelogger: oh of course, I missed the -o [14:07] pitti: ^^ [14:08] apachelogger: merged, danke; how soon do you want/need this in trusty? [14:08] (probably not that urgent, right?) [14:09] pitti: not urgent [14:09] thanks for merging :) [14:48] hum, what's the best way to run checkrdepends nowadays? [14:48] * seb128 is reading https://wiki.ubuntu.com/ArchiveAdministration#NBS [14:49] seb128: reverse-depends from ubuntu-dev-tools AFAIK [14:49] it's fast, and reasonably correct [14:49] that needs a local mirror right? do we have an archive admin available box recommended for that? [14:49] no, it reads from LP or UDD or something like that [14:49] Ah, handy. Thanks! [14:50] pitti, I was speaking about checkrdepends [14:50] a local mirror is an incredibly heavy beast, I doubt that many people have one [14:50] seb128: so was I [14:50] reverse-depends gnome-control-center-signon-autopilot [14:50] No reverse dependencies found [14:51] pitti, it errors out out on [14:51] IOError: [Errno 2] No such file or directory: '/home/ubuntu-archive/mirror/ubuntu/dists/trusty/main/source/Sources.gz' [14:51] for me [14:51] -B ARCHIVE_BASE, --archive-base=ARCHIVE_BASE [14:51] archive base directory (default: /home/ubuntu- [14:51] archive/mirror/ubuntu) [14:51] or is archive base dir /var/lib/apt/lists? [14:51] * seb128 tries [14:51] reverse-depends src:gnome-control-center-signon [14:51] you might want that? [14:52] reverse-depends -b src:gnome-control-center-signon [14:52] and that for reverse build deps [14:52] (account-plugins and empathy in that case) [14:53] pitti, seems fine to delete the gnome-control-center-signon and gnome-control-center-signon-autopilot binaries then, right? [14:53] or am I overlooking something [14:54] seb128: gnome-control-center-signon has reverse depends [14:54] pitti, which one? [14:54] seb128: http://paste.ubuntu.com/6920308/ [14:54] does that look any different for you? [14:54] pitti, those all have a "unity-control-center-signon | gnome-control-center-signon" [14:54] aah [14:55] if I didn't overlook things [14:55] fine then [14:59] pitti, should we change https://wiki.ubuntu.com/ArchiveAdministration#NBS to recommends using reverse-depends over "checkrdepends -b"? [15:00] seb128: yes, sounds good; shell login is generally disabled now [15:00] cjwatson, infinity: ^ [15:00] pitti, danke [15:02] pitti, seb128: reverse-depends queries a webservice on qa.ubuntuwire.org [15:02] ok [15:02] Let's still keep checkrdepends around though; for those with access to it it has stronger guarantees of being current [15:03] on what box can that be run? pepo? [15:03] (seems I don't have ssh to that one) [15:03] ubuntu-archive@snakefruit [15:04] cjwatson, thanks [15:04] doko: no, not yet [15:12] pitti, does dbus in trusty diverge that much from unstable? https://launchpadlibrarian.net/164705202/buildlog_ubuntu-trusty-i386.python-notify2_0.3-2_FAILEDTOBUILD.txt.gz [15:12] doko, ** (notification-daemon:2593): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files [15:12] doko, seems like you are missing a depends on at-spi or something [15:13] or at-spi2-core rather to be exact [15:13] seb128, it did build before ... [15:15] doko: it's not dbus itself, something in gtk/whatever now requires at-spi2-core [15:15] I think rather notification-daemon should depend on that [15:16] mitya57: agreed [15:16] speaking of notification-daemon, if anyone still uses it/cares about it, it needs to be fixed for incorrect g_source_remove use [15:17] that's an issue with new glib and is ranked high enough on the trusty reports [15:17] on e.u.c [15:17] Hm, no, neither notification-daemon nor python-notify2 reference a11y in the code [15:18] I've seen this quite often recently [15:18] my suspicion is that it's something in GTK, and that gtk itself should depend on it [15:19] pitti, libgail-3-0 depends on at-spi2-core [15:20] * seb128 doesn't understand the a11y stack enough to figure what's the right thing to do there [15:20] I though libgail was needed for a11y? [15:20] that build log doesn't install gail, though [15:20] pitti, https://launchpad.net/ubuntu/+source/gtk+3.0/3.5.8-0ubuntu1 [15:21] that's where it got added [15:21] I think GTK upstream has been working on dropping gail and moving a11y directly in gtk [15:22] so yeah, maybe having libgtk-3-0 depending on it would make sense [15:22] would be useful to get a bt of those warnings [15:22] to see what is the caller [15:25] G_DEBUG=fatal-warnings? [15:26] G_DEBUG=fatal_warnings (with underscore) [15:26] or maybe dbus-monitor [15:27] thanks guys, I know how to get one [15:27] I'm just dealing with 5 stuff already so I was hinting in case somebody has the setup to trigger the warning [15:27] I can try in a bit otherwise [15:27] ;-) [15:28] * seb128 usually do "b g_log" instead [15:28] so you can go pass the first warning [15:28] * mitya57 is in battle with mathjax packaging, so not now [15:30] cjwatson: can we install a hook or something from the click scope, that gets run whenever a click package is installed (like a dpkg trigger but for click)? [15:31] click packages can attach to hooks; there's no way to write a hook that will run for *any* click package installation right now [15:31] that's possible, would need to be specced with some thought [15:32] cjwatson: oh ok. i was just thinking that it would be nice for the click scope to be refreshed when i adb shell and install a click package that way (or do it from qtcreator or whatever) [15:32] I suppose the simplest way would be to make the Pattern field (https://click.readthedocs.org/en/latest/hooks.html) optional, in which case no symlink would be created and we'd just run whatever Exec says [15:33] would that work for you? [15:34] (if so, please file a bug, I'm not going to get to it this week) [15:34] i'm not sure, but probably. [15:34] right, we're in a bit of rush on scope development right now as well. so if we can't do it right now, it'll have to wait a bit anyway [15:35] but i'll read the hooks doc and let you know [15:36] well. I could maybe do it on Thu/Fri if it's a simple enough approach, but it'd be my first proper release under the ci train stuff so I can't guarantee it [15:45] cjwatson: yeah, no worries. i don't want to block the scope work on it so we're going to have to do the results invalidation call a different way for now. but i'll see if your suggestion makes sense (or if i think of something better while reading the docs), and file a bug [15:51] pitti: I see that you have merged my clamav MP, though I thought it was still waiting for a fix [15:51] pitti: I just updated the MP with a potential modification [15:52] caribou: I posted the modification I did to the MP and to the bug [15:53] pitti: yeah, just seeing the emails [15:53] pitti: my suggestion was to replace the [[:space:]] with \b as the reasoning behind that is to be able to discriminate on word boundary [15:54] caribou: \b looks fine as well, but [[:space:]] should work equally well [15:54] pitti: I do think so. So let keep it as it is then [15:54] after all, you could potentially have a variable Logfile-Destination /dev/null [15:54] and \b would match after LogFile [15:54] (perhaps) [15:54] pitti: I'll fix the debdiffs in the bug [15:54] I mean, I don't know whether clamav allows that [15:55] but [[:space:]] seems fine [15:55] pitti: dunno. I'll open a bug on this on Debian [15:55] caribou: thanks, appreciated [15:55] pitti: thanks for the merge, I'll get the SRU fixed === Sweetsha1k is now known as Sweetshark [15:56] caribou: I already fixed the precise SRU [15:56] pitti: ah, ok then I won't bother === cmagina_ is now known as cmagina [15:56] pitti: such a small fix [15:56] how can I get an rdepends on udebs? possibly using the package cache within a d-i build tree? [15:57] pitti: btw, I had the same issue with UDD and the time it took to check it out [15:57] Hello! My source package stopped building some now-deprecated binaries, so the new upload is in -proposed with a series of "out-of-date" on the deprecated binaries. How can I fix this? do the old binaries need to be removed? [15:58] roadmr, you need an archive admin to delete the NBS binaries I think [15:59] roadmr: what source package is that and what binaries did you drop? [15:59] ahh, figured it out... [16:01] stgraber: source: checkbox, dropped binaries: checkbox-gtk, checkbox-urwid [16:01] roadmr: ok, taking a look now [16:01] FWIW this only happens if the binaries were dropped in a subsequent upload when there was already an unmigrated upload in -proposed [16:01] it's a corner case due to -proposed being a partial suite [16:02] stgraber: also, my source package was building python3-checkbox-support which exists only in -proposed, but that overlaps the same package (version 0.1 I think) from debian. I fixed this but I guess the stale binary stayed in proposed and is also considered out-of-date [16:02] wait... maybe not... those are non udeb rdepends somehow... [16:02] roadmr: you actually have a bigger problem, you regressed architecture support [16:02] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [16:02] roadmr: checkbox used to build on all architectures, now it fails on arm64, powerpc and ppc64el === freeflying is now known as freeflying_away [16:03] stgraber: I saw it failing due to lack of some qt5-sensors dependency, but it's not actually needed, my latest upload should have fixed that. I can double-check that too [16:04] roadmr: I'm looking at https://launchpad.net/ubuntu/+source/checkbox/0.17.4ubuntu3 [16:05] stgraber: oh, I removed the qtsensors5-dev dep but now it's stuck on qtmultimedia5-dev [16:06] roadmr: so I resolved the pytohn3-checkbox-support bit for now, I'll let you upload something which fixes those 3 arches then we can see what britney thinks about migrating those [16:06] cjwatson: right, python3-checkbox-support was in that case (introduced in ubuntu2, dropped in ubuntu3, never migrated) [16:07] stgraber: cool, thanks so much! I'll fix that asap [16:15] infinity: Would like to chat about PPC64el and libv8 [16:17] alow: Perhaps when I'm out of this current meeting/call. [16:17] alow: I meant to follow up to your email, but I've been headless chickening the last day or two. [16:18] infinity: no problem. I've been hacking away to create minimal diffs between the v8 levels. I've created a unique branch for libv8 https://github.com/andrewlow/v8ppc/tree/libv8-3.14 [16:19] alow: Awesome. And, as an added bonus (not a requirement, but a bonus), I understand this works on big-endian as well? [16:19] infinity: It should - I haven't tested that specifically. I'd be happy to hit both BE / LE [16:20] infinity: I'm off on vacation soon for a bit, so it'd be good to get this working for others soon [16:20] alow: Righto. I will probably end up testing on ppc32be by accident, since that's my primary development workstation in my house. :P [16:20]