| === maclin_ is now known as maclin | ||
| === mwhudson is now known as zz_mwhudson | ||
| Mirv | 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:25 |
|---|---|---|
| Noskcaj | Can someone please upload lp:~noskcaj/+junk/gnome-weather to trusty? debian won't upload it in time and ubuntu-gnome needs it | 05:59 |
| Noskcaj | oops, lp:~noskcaj/+junk/gnome-photos actually | 06:00 |
| RAOF | pitti: Yo! | 06:05 |
| === maclin_ is now known as maclin | ||
| pitti | Good morning | 06:39 |
| pitti | RAOF: hey | 06:39 |
| RAOF | pitti: Good morning! | 06:39 |
| RAOF | 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:40 |
| RAOF | Hm. But first I apparently need to get some mushrooms, so I'll ping you again later :) | 06:41 |
| pitti | RAOF: if you want those commits, I'll do a microrelease/upload today | 06:46 |
| pitti | 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:50 |
| pitti | RAOF: then ioctl_tree_new_from_text() needs to be able to load that | 06:52 |
| pitti | RAOF: perhaps "@DEV /dev/...." (@ to make it an invalid ioctl name) | 06:52 |
| pitti | 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:55 |
| pitti | 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 |
| pitti | 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:56 |
| RAOF | pitti: Ah, good. That was roughly what I was thinking, except using # instead of @. | 06:57 |
| pitti | RAOF: # is an usual comment character, though | 06:57 |
| pitti | RAOF: we support # in .script files; not sure that it already does in .ioctl files, but it should | 06:57 |
| pitti | (particularly when you hand-edit them) | 06:58 |
| RAOF | Right; I was going to have ioctl_record_open write something like "# originally recorded from: /dev/baz"; “@ DEV /dev/...” seems better, though. | 06:58 |
| RAOF | pitti: So, I notice that ioctl_record_open supports appending to existing .ioctl files. How would you want that handled? | 06:59 |
| pitti | RAOF: right, if the file already has non-zero length you shouldn't write it again | 07:00 |
| pitti | syntactically it should be ok (ioctl_tree_* should just ignore @DEV entirely), but it would look confusing | 07:00 |
| RAOF | Or we could support loading for multiple things, with a little bit of extra effort in umockdev.vala | 07:00 |
| RAOF | 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 |
| pitti | hm, I wouldn't want to stuff traces from multiple different devices into one .ioctl file TBH | 07:01 |
| pitti | the format and its traversing is complicated enough as it is | 07:01 |
| RAOF | Sweet. | 07:01 |
| RAOF | So, should umockdev-record error out if it tries to append something from a different device node? | 07:02 |
| pitti | there should be an assertion | 07:02 |
| pitti | it Should Not Happen™, so it doesn't need to be a fancy error message | 07:02 |
| pitti | oh wait | 07:02 |
| pitti | if one umockdev-record sessio opens the device multiple times, it can't happen | 07:03 |
| pitti | but you can record into the same file multiple times, indeed | 07:03 |
| pitti | RAOF: so yes, then umockdev-record should error out | 07:03 |
| RAOF | Good. | 07:03 |
| pitti | if we want to support that at some point, we can do that without breaking compatibility | 07:03 |
| RAOF | 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:04 |
| pitti | *nod* | 07:05 |
| pitti | RAOF: yeah, I'm more concerned about user confusion than implementation | 07:05 |
| pitti | mlankhorst: tested ppa7, I followed up to bug 1278737 | 07:21 |
| ubottu | bug 1278737 in xorg (Ubuntu Trusty) "Upgrade to trusty fails from precise backported enablement stacks" [High,In progress] https://launchpad.net/bugs/1278737 | 07:21 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| mlankhorst | pitti: well it seems that multi-arch: no is required on newer ubuntu, but precise used multi-arch: none.. | 08:33 |
| mlankhorst | I'll just skip that field altogether | 08:34 |
| pitti | if it's not there, it should be similar to M-A: same, right? | 08:34 |
| mlankhorst | no it skips to multi-arch: none I guess | 08:35 |
| mlankhorst | which is what's needed | 08:35 |
| dholbach | good morning | 08:41 |
| mlankhorst | pitti: yeah I fixed m-a none, can you still hit the geode issue? | 09:15 |
| * pitti boots the precise live system | 09:16 | |
| pitti | mlankhorst: confirmed, no held back packages any more; great! | 09:25 |
| mlankhorst | good | 09:26 |
| pitti | mlankhorst: want to upload? I can do the NEWing, and then re-run the full upgrade tests | 09:26 |
| mlankhorst | I can't upload, tjaalton? :P | 09:26 |
| tjaalton | push it to git | 09:27 |
| pitti | mlankhorst: I can sponsor it, if you want | 09:27 |
| pitti | mlankhorst: (with dropping the ~ppa suffix) | 09:27 |
| tjaalton | hm can't use git since it had the merge from debian already staged | 09:27 |
| pitti | it's a new source package | 09:28 |
| tjaalton | ah | 09:28 |
| tjaalton | ok then :) | 09:28 |
| pitti | and it'll get removed in trusty+1 again | 09:28 |
| mlankhorst | https://mblankhorst.nl/etc/ xorg-lts-transitional* | 09:28 |
| pitti | so probably not worth the trouble | 09:28 |
| tjaalton | I thought it was xorg source modified | 09:28 |
| tjaalton | sure | 09:28 |
| mlankhorst | tjaalton: no way I want to have this hit version control | 09:28 |
| mlankhorst | :P | 09:28 |
| tjaalton | hehehe | 09:28 |
| tjaalton | no complaints there | 09:28 |
| mlankhorst | pitti: at one point you need to upgrade and confirm whether /usr/lib/xorg/protocol.txt still exists | 09:30 |
| pitti | mlankhorst: *nod*; is its existance enough, or should we assert some contents? | 09:31 |
| pitti | mlankhorst: I can add that as a post-upgrade test | 09:31 |
| mlankhorst | no, existence is enough | 09:31 |
| pitti | mlankhorst: and protocol-{precise,*}.txt should not exist any more? | 09:32 |
| mlankhorst | I'm also curious about "update-alternatives --config x86_64-linux-gnu_gl_conf" after upgrade | 09:32 |
| mlankhorst | pitti: just protocol-precise.txt that exists | 09:32 |
| mlankhorst | it's overridden by xserver-common | 09:32 |
| pitti | mlankhorst: I mean after the upgrade | 09:32 |
| mlankhorst | yeah protocol-precise.txt should be gone | 09:32 |
| pitti | in trusty we certainly don't expect protocol-precise.txt any more, or do you? | 09:32 |
| mlankhorst | it was a diversion added by xserver-common-lts-w/e | 09:33 |
| pitti | *nod* | 09:33 |
| pitti | mlankhorst: hm, no copyright file, I'll add a simple one | 09:37 |
| mlankhorst | 'not eligible for copyright' really! | 09:37 |
| mlankhorst | there are no contents either! :-) | 09:37 |
| seb128 | 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 |
| seb128 | chrisccoulson, ^ | 09:39 |
| doko | seb128, there are patches for arm64, which were once overwritten by chrisccoulson | 09:41 |
| seb128 | 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 |
| doko | jamespage, 1268915 is still incomplete. could you subscribe? | 09:41 |
| chrisccoulson | 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 |
| chrisccoulson | which is already terrible | 09:42 |
| jamespage | doko: done | 09:43 |
| chrisccoulson | 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:44 |
| seb128 | not having a porting box for ppc doesn't help there | 09:45 |
| pitti | @pilot in | 09:51 |
| === 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 | ||
| seb128 | ups, pitti went offroad | 09:58 |
| seb128 | pitti, easy on the piloting ;-) | 09:59 |
| * seb128 hugs pitti (just saw the ibus-pinyin sync) | 09:59 | |
| pitti | seb128: yeah, sorry about taht; already undid my damage | 09:59 |
| seb128 | no worry | 09:59 |
| seb128 | happyaron filed the libpyzy MIR and mterry already did a first review, good | 10:01 |
| Guest3895 | seb128: hey | 10:03 |
| === Guest3895 is now known as happyaron | ||
| happyaron | seb128: hey | 10:03 |
| seb128 | happyaron, hey | 10:03 |
| seb128 | lol, I was looking for you, I even looking in the calendar to see if you were off | 10:04 |
| happyaron | seb128: shall I subscribe desktop team for libpyzy? | 10:04 |
| happyaron | :) | 10:04 |
| seb128 | happyaron, "desktop-bugs" is our bugs team | 10:04 |
| seb128 | so yes | 10:04 |
| seb128 | or let me know if you don't the rights to do that | 10:04 |
| happyaron | seb128: I can't subscribe it on LP, :( | 10:05 |
| darkxst | pitti, pilot, can you take a look at the gnome-ey stuff in the queue | 10:06 |
| seb128 | darkxst, from #ubuntu-desktop backlog, seems he's already doing | 10:07 |
| darkxst | seb128, boom :( gdm still restarting ;( | 10:08 |
| seb128 | darkxst, did you try twice? | 10:08 |
| seb128 | darkxst, it's the prerm from the installed version that stops it | 10:08 |
| pitti | darkxst: I'm at gnome-menus ATM | 10:09 |
| seb128 | 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 |
| darkxst | seb128, yes, right, it worked second time | 10:09 |
| Laney | you should sed the prerm of the old one ;-) | 10:11 |
| * Laney RUNS | 10:11 | |
| darkxst | pitti, there is also lp:~noskcaj/+junk/gnome-photos, I told Noskcaj to file a bug but he didnt ;( | 10:11 |
| Laney | oh actually I don't think you can | 10:12 |
| Laney | https://wiki.debian.org/MaintainerScripts?action=AttachFile&do=get&target=upgrade.png | 10:12 |
| pitti | darkxst: bug 1279201 | 10:15 |
| ubottu | bug 1279201 in Ubuntu "[needs-packaging] gnome-photos" [Wishlist,Fix committed] https://launchpad.net/bugs/1279201 | 10:15 |
| darkxst | pitti, ah, ok | 10:18 |
| pitti | darkxst: ah, gnome-photos landed in the NEW queue 23 mins ago | 10:19 |
| darkxst | yes, I see that now | 10:20 |
| tjaalton | hum, trusty doesn't seem to recognize win 8.1 at all.. the partitioner says the disk is empty | 10:20 |
| RAOF | tjaalton: And yet grub finds it just fine! | 10:24 |
| tjaalton | RAOF: didn't go that far yet, this is still the installer | 10:24 |
| tjaalton | and I'd like to keep win8.1 there, if only just for civV which just crashes here on wine :) | 10:28 |
| RAOF | Oh, indeed. | 10:29 |
| RAOF | You should probably also want to keep XCOM:EW :P | 10:29 |
| tjaalton | don't have that one, yet anyway :) | 10:32 |
| cjwatson | 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:34 |
| cjwatson | it's probably tractable, but please make sure that that work is done rather than just left to +1 maint or something | 10:35 |
| seb128 | cjwatson, thanks for pointing that out. What would be the right place to have that discussion? ubuntu-devel@? | 10:35 |
| cjwatson | Seems reasonable, yeah | 10:35 |
| seb128 | thanks | 10:39 |
| spineau | 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 |
| ubottu | bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1277408 | 10:39 |
| ubottu | bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,Fix committed] https://launchpad.net/bugs/1278822 | 10:39 |
| pitti | 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:40 |
| RAOF | pitti: (1) yes, and (2) yes, please wait. | 10:41 |
| tseliot | 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 |
| ubottu | bug 1279229 in jockey (Ubuntu) "Jockey is unable to check Saucy's xserver ABI" [High,In progress] https://launchpad.net/bugs/1279229 | 10:41 |
| pitti | RAOF: ack, thanks | 10:42 |
| RAOF | 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 |
| pitti | RAOF: we generally do, yes | 10:42 |
| Laney | They get missed on the first upload AFAIK | 10:42 |
| pitti | that was fixed | 10:42 |
| pitti | RAOF: très interessant, I'll have a look at that later | 10:43 |
| Laney | Well then, :) | 10:43 |
| RAOF | Just to check - they should show up on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/ if they get run, right? | 10:43 |
| pitti | correct | 10:43 |
| pitti | Testsuite: autopkgtest | 10:43 |
| pitti | that looks fine to me, too | 10:43 |
| pitti | 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:45 |
| cjwatson | I'll take care of it, I did most of the rest of that stuff at the core sprint | 10:46 |
| pitti | cjwatson: ack | 10:46 |
| cjwatson | just ran out of time there | 10:46 |
| pitti | https://code.launchpad.net/~dannf/ubuntu/trusty/base-installer/arm64+calxeda-subarches/+merge/199977 as well then, I assume | 10:47 |
| pitti | (which includes the previous MP) | 10:47 |
| cjwatson | yeah | 10:48 |
| seb128 | happyaron, desktop-bugs subscribed to libpyzy now | 10:49 |
| happyaron | seb128: great | 10:49 |
| tjaalton | my partman bug was already reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731736 | 10:56 |
| ubottu | Debian bug 731736 in debian-installer "partman doesn't detect GPT partitions installed Windows 8.1" [Important,Open] | 10:56 |
| tjaalton | huh, why are we still on parted 2.3? | 11:08 |
| tjaalton | found debian #646130 | 11:10 |
| ubottu | Debian bug 646130 in parted "parted versions lags behind" [Normal,Open] http://bugs.debian.org/646130 | 11:10 |
| tseliot | cjwatson: did you get my message? | 11:33 |
| cjwatson | 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:35 |
| pitti | mlankhorst: oh, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 11:36 |
| pitti | mlankhorst: xserver-xorg-video-geode-lts-* mustn't be built on amd64 | 11:36 |
| Laney | bdrung: Is there a way to use ubuntu-distro-info to get the full name (-r) of the current release? | 11:37 |
| cjwatson | tseliot: ok, looks reasonable | 11:37 |
| bdrung_work | Laney, current release = the latest stable release? | 11:38 |
| Laney | bdrung_work: the one you're running it on | 11:38 |
| pitti | mlankhorst: fixing.. | 11:39 |
| Laney | or maybe going from codename to release would be okay | 11:39 |
| Laney | trusty → 14.04 LTS for example | 11:39 |
| cjwatson | tseliot: (accepted) | 11:39 |
| bdrung_work | Laney, no. distro-info has no info what release you are running on | 11:39 |
| bdrung_work | currently it does not support a codename -> fullname/release mapping | 11:40 |
| tseliot | cjwatson: ok, thanks a lot | 11:40 |
| seb128 | bdrung_work, hey, did you get my email about Sweetshark's libroffice's ppu application? | 11:41 |
| Laney | xnox: ^ | 11:41 |
| Laney | I read that as 'patches welcome' | 11:41 |
| bdrung_work | seb128, probably. i'll hope to find time to process my mail backlog at the weekend | 11:42 |
| seb128 | bdrung_work, good ... is that application still blocked on anything? | 11:42 |
| pitti | mlankhorst: http://paste.ubuntu.com/6919521/ | 11:42 |
| xnox | bdrung_work: Laney: thanks. | 11:43 |
| bdrung_work | seb128, i have to look into the mail and look at the progress of the last month | 11:43 |
| bdrung_work | xnox, yes, patches are welcome | 11:44 |
| seb128 | 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:44 |
| seb128 | 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 |
| bdrung_work | seb128, i'll try to do it on the weekend. otherwise i have to delegate it. | 11:45 |
| seb128 | thanks | 11:45 |
| bdrung_work | since i have a job, my free time is heavily reduced | 11:46 |
| === _salem is now known as salem_ | ||
| xnox | bdrung_work: may i upload https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1012439 ? | 11:51 |
| ubottu | Launchpad bug 1012439 in debootstrap (Ubuntu) "carve out distro information to distro-info package" [Undecided,Confirmed] | 11:51 |
| Laney | that's a long week :P | 11:52 |
| bdrung_work | xnox, you may :) | 11:52 |
| bdrung_work | i think there was an objection against this patch | 11:53 |
| denisw | hi | 11:53 |
| xnox | Laney: like my accidental 6 month holliday?! =) | 11:53 |
| Laney | accidents happen right | 11:53 |
| Laney | anyway I heard we know one of the debootstrap maintainers ;-) | 11:54 |
| denisw | 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:54 |
| bdrung_work | xnox, bonus: get the patch into debian | 11:55 |
| xnox | Laney: debootstrap maintainers? who is that? =) | 11:57 |
| bdrung_work | http://packages.qa.debian.org/d/debootstrap.html | 11:57 |
| cjwatson | xnox: please don't diverge debootstrap in Ubuntu, it's hassle | 12:01 |
| xnox | cjwatson: ok. | 12:02 |
| cjwatson | xnox: that latest version of the debootstrap patch is probably ok, but if we use it it should be in Debian | 12:03 |
| cjwatson | (case in point, I just synced debootstrap) | 12:03 |
| === freeflying_away is now known as freeflying | ||
| cjwatson | xnox: but hey, you're in the d-i team these days | 12:04 |
| mardy | cjwatson: hi! I updated https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674 | 12:10 |
| cjwatson | mardy: ack, will look later today, trying to finish something else off | 12:18 |
| doko | bdmurray, did you find out anything about the php issues? | 12:20 |
| shadeslayer | 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:21 |
| cjwatson | -F is "search by this field"; if you want "show this field" you need -s instead | 12:22 |
| shadeslayer | ahh | 12:23 |
| mlankhorst | pitti: can you make xserver-common* architecture: all ? and I want to point out that you matched with *geode** :P | 12:25 |
| apachelogger | pitti: any objections to modifying the apport cleanup cronjob to also clean the drkonqi files we create through kdelibs? | 12:27 |
| pitti | apachelogger: fine for me | 12:28 |
| === MacSlow is now known as MacSlow|lunch | ||
| doko | jamespage, why did you drop the juju gccgo binaries for x86? are these builds still being tested? | 12:38 |
| jamespage | doko, not any longer | 12:39 |
| doko | jamespage, are any gccgo binaries being tested? | 12:40 |
| jamespage | doko, on ppc64el and arm64 yes | 12:40 |
| doko | ok | 12:40 |
| jamespage | doko, oh - and upstream will be checking with gccgo still so we don't regress those platforms | 12:41 |
| doko | upstream? | 12:41 |
| jamespage | doko, juju team | 12:41 |
| doko | ahh | 12:41 |
| apachelogger | hm | 12:49 |
| apachelogger | pitti: apport's cron actually excepts whoopsie's .upload*, do you simply leave them around since they are 0byte anyway? | 12:50 |
| pitti | apachelogger: they are cleaned up after 7 days | 12:51 |
| pitti | 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:51 |
| apachelogger | mh | 12:52 |
| apachelogger | pitti: ok, going hold on to that then since the drkonqi stuff is related ^^ | 12:52 |
| pitti | mlankhorst: WDYT? http://paste.ubuntu.com/6919792/ | 12:53 |
| mlankhorst | pitti: looks good! | 12:54 |
| pitti | uploaded | 12:54 |
| mlankhorst | maybe that will fix the weird issue | 12:54 |
| rbasak | 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 |
| ubottu | bug 1278898 in cobbler (Ubuntu) "cobbler-web: import error with django 1.6.x (trusty)" [Undecided,New] https://launchpad.net/bugs/1278898 | 13:00 |
| tjaalton | rbasak: there's a new upstream bugfix release to address that, I'll push that to trusty soon | 13:00 |
| tjaalton | packaging has been in collab-maint git, but guess there's no itp for it yet | 13:01 |
| rbasak | Ah, OK. Thanks! | 13:01 |
| apachelogger | pitti: https://code.launchpad.net/~apachelogger/apport/cleanup-drkonqi-files/+merge/205955 | 13:01 |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | apachelogger: bah, this is rather hard to read :) | 14:03 |
| pitti | apachelogger: i. e. this cron job does *not* remove drkonqui files after 7 days, while current apport does? | 14:04 |
| apachelogger | pitti: what, for me the find returned the drkonqi files with mtime >7days | 14:05 |
| apachelogger | alas, the find syntax is nigh unparsable to my puny mind | 14:06 |
| pitti | apachelogger: oh of course, I missed the -o | 14:07 |
| apachelogger | pitti: ^^ | 14:07 |
| pitti | apachelogger: merged, danke; how soon do you want/need this in trusty? | 14:08 |
| pitti | (probably not that urgent, right?) | 14:08 |
| apachelogger | pitti: not urgent | 14:09 |
| apachelogger | thanks for merging :) | 14:09 |
| seb128 | hum, what's the best way to run checkrdepends nowadays? | 14:48 |
| * seb128 is reading https://wiki.ubuntu.com/ArchiveAdministration#NBS | 14:48 | |
| pitti | seb128: reverse-depends from ubuntu-dev-tools AFAIK | 14:49 |
| pitti | it's fast, and reasonably correct | 14:49 |
| seb128 | that needs a local mirror right? do we have an archive admin available box recommended for that? | 14:49 |
| pitti | no, it reads from LP or UDD or something like that | 14:49 |
| rbasak | Ah, handy. Thanks! | 14:49 |
| seb128 | pitti, I was speaking about checkrdepends | 14:50 |
| pitti | a local mirror is an incredibly heavy beast, I doubt that many people have one | 14:50 |
| pitti | seb128: so was I | 14:50 |
| seb128 | reverse-depends gnome-control-center-signon-autopilot | 14:50 |
| seb128 | No reverse dependencies found | 14:50 |
| seb128 | pitti, it errors out out on | 14:51 |
| seb128 | IOError: [Errno 2] No such file or directory: '/home/ubuntu-archive/mirror/ubuntu/dists/trusty/main/source/Sources.gz' | 14:51 |
| seb128 | for me | 14:51 |
| seb128 | -B ARCHIVE_BASE, --archive-base=ARCHIVE_BASE | 14:51 |
| seb128 | archive base directory (default: /home/ubuntu- | 14:51 |
| seb128 | archive/mirror/ubuntu) | 14:51 |
| seb128 | or is archive base dir /var/lib/apt/lists? | 14:51 |
| * seb128 tries | 14:51 | |
| pitti | reverse-depends src:gnome-control-center-signon | 14:51 |
| pitti | you might want that? | 14:51 |
| pitti | reverse-depends -b src:gnome-control-center-signon | 14:52 |
| pitti | and that for reverse build deps | 14:52 |
| pitti | (account-plugins and empathy in that case) | 14:52 |
| seb128 | pitti, seems fine to delete the gnome-control-center-signon and gnome-control-center-signon-autopilot binaries then, right? | 14:53 |
| seb128 | or am I overlooking something | 14:53 |
| pitti | seb128: gnome-control-center-signon has reverse depends | 14:54 |
| seb128 | pitti, which one? | 14:54 |
| pitti | seb128: http://paste.ubuntu.com/6920308/ | 14:54 |
| pitti | does that look any different for you? | 14:54 |
| seb128 | pitti, those all have a "unity-control-center-signon | gnome-control-center-signon" | 14:54 |
| pitti | aah | 14:54 |
| seb128 | if I didn't overlook things | 14:55 |
| pitti | fine then | 14:55 |
| seb128 | pitti, should we change https://wiki.ubuntu.com/ArchiveAdministration#NBS to recommends using reverse-depends over "checkrdepends -b"? | 14:59 |
| pitti | seb128: yes, sounds good; shell login is generally disabled now | 15:00 |
| seb128 | cjwatson, infinity: ^ | 15:00 |
| seb128 | pitti, danke | 15:00 |
| geser | pitti, seb128: reverse-depends queries a webservice on qa.ubuntuwire.org | 15:02 |
| cjwatson | ok | 15:02 |
| cjwatson | Let's still keep checkrdepends around though; for those with access to it it has stronger guarantees of being current | 15:02 |
| seb128 | on what box can that be run? pepo? | 15:03 |
| seb128 | (seems I don't have ssh to that one) | 15:03 |
| cjwatson | ubuntu-archive@snakefruit | 15:03 |
| seb128 | cjwatson, thanks | 15:04 |
| bdmurray | doko: no, not yet | 15:04 |
| doko | 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 |
| seb128 | 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 |
| seb128 | doko, seems like you are missing a depends on at-spi or something | 15:12 |
| seb128 | or at-spi2-core rather to be exact | 15:13 |
| doko | seb128, it did build before ... | 15:13 |
| pitti | doko: it's not dbus itself, something in gtk/whatever now requires at-spi2-core | 15:15 |
| mitya57 | I think rather notification-daemon should depend on that | 15:15 |
| pitti | mitya57: agreed | 15:16 |
| seb128 | speaking of notification-daemon, if anyone still uses it/cares about it, it needs to be fixed for incorrect g_source_remove use | 15:16 |
| seb128 | that's an issue with new glib and is ranked high enough on the trusty reports | 15:17 |
| seb128 | on e.u.c | 15:17 |
| mitya57 | Hm, no, neither notification-daemon nor python-notify2 reference a11y in the code | 15:17 |
| pitti | I've seen this quite often recently | 15:18 |
| pitti | my suspicion is that it's something in GTK, and that gtk itself should depend on it | 15:18 |
| seb128 | pitti, libgail-3-0 depends on at-spi2-core | 15:19 |
| * seb128 doesn't understand the a11y stack enough to figure what's the right thing to do there | 15:20 | |
| seb128 | I though libgail was needed for a11y? | 15:20 |
| pitti | that build log doesn't install gail, though | 15:20 |
| seb128 | pitti, https://launchpad.net/ubuntu/+source/gtk+3.0/3.5.8-0ubuntu1 | 15:20 |
| seb128 | that's where it got added | 15:21 |
| seb128 | I think GTK upstream has been working on dropping gail and moving a11y directly in gtk | 15:21 |
| seb128 | so yeah, maybe having libgtk-3-0 depending on it would make sense | 15:22 |
| seb128 | would be useful to get a bt of those warnings | 15:22 |
| seb128 | to see what is the caller | 15:22 |
| pitti | G_DEBUG=fatal-warnings? | 15:25 |
| mitya57 | G_DEBUG=fatal_warnings (with underscore) | 15:26 |
| mitya57 | or maybe dbus-monitor | 15:26 |
| seb128 | thanks guys, I know how to get one | 15:27 |
| seb128 | I'm just dealing with 5 stuff already so I was hinting in case somebody has the setup to trigger the warning | 15:27 |
| seb128 | I can try in a bit otherwise | 15:27 |
| seb128 | ;-) | 15:27 |
| * seb128 usually do "b g_log" instead | 15:28 | |
| seb128 | so you can go pass the first warning | 15:28 |
| * mitya57 is in battle with mathjax packaging, so not now | 15:28 | |
| dobey | 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:30 |
| cjwatson | 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 |
| cjwatson | that's possible, would need to be specced with some thought | 15:31 |
| dobey | 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 |
| cjwatson | 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:32 |
| cjwatson | would that work for you? | 15:33 |
| cjwatson | (if so, please file a bug, I'm not going to get to it this week) | 15:34 |
| dobey | i'm not sure, but probably. | 15:34 |
| dobey | 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:34 |
| dobey | but i'll read the hooks doc and let you know | 15:35 |
| cjwatson | 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:36 |
| dobey | 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:45 |
| caribou | pitti: I see that you have merged my clamav MP, though I thought it was still waiting for a fix | 15:51 |
| caribou | pitti: I just updated the MP with a potential modification | 15:51 |
| pitti | caribou: I posted the modification I did to the MP and to the bug | 15:52 |
| caribou | pitti: yeah, just seeing the emails | 15:53 |
| caribou | 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:53 |
| pitti | caribou: \b looks fine as well, but [[:space:]] should work equally well | 15:54 |
| caribou | pitti: I do think so. So let keep it as it is then | 15:54 |
| pitti | after all, you could potentially have a variable Logfile-Destination /dev/null | 15:54 |
| pitti | and \b would match after LogFile | 15:54 |
| pitti | (perhaps) | 15:54 |
| caribou | pitti: I'll fix the debdiffs in the bug | 15:54 |
| pitti | I mean, I don't know whether clamav allows that | 15:54 |
| pitti | but [[:space:]] seems fine | 15:55 |
| caribou | pitti: dunno. I'll open a bug on this on Debian | 15:55 |
| pitti | caribou: thanks, appreciated | 15:55 |
| caribou | pitti: thanks for the merge, I'll get the SRU fixed | 15:55 |
| === Sweetsha1k is now known as Sweetshark | ||
| pitti | caribou: I already fixed the precise SRU | 15:56 |
| caribou | pitti: ah, ok then I won't bother | 15:56 |
| === cmagina_ is now known as cmagina | ||
| caribou | pitti: such a small fix | 15:56 |
| psusi | how can I get an rdepends on udebs? possibly using the package cache within a d-i build tree? | 15:56 |
| caribou | pitti: btw, I had the same issue with UDD and the time it took to check it out | 15:57 |
| roadmr | 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:57 |
| seb128 | roadmr, you need an archive admin to delete the NBS binaries I think | 15:58 |
| stgraber | roadmr: what source package is that and what binaries did you drop? | 15:59 |
| psusi | ahh, figured it out... | 15:59 |
| roadmr | stgraber: source: checkbox, dropped binaries: checkbox-gtk, checkbox-urwid | 16:01 |
| stgraber | roadmr: ok, taking a look now | 16:01 |
| cjwatson | FWIW this only happens if the binaries were dropped in a subsequent upload when there was already an unmigrated upload in -proposed | 16:01 |
| cjwatson | it's a corner case due to -proposed being a partial suite | 16:01 |
| roadmr | 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 |
| psusi | wait... maybe not... those are non udeb rdepends somehow... | 16:02 |
| stgraber | roadmr: you actually have a bigger problem, you regressed architecture support | 16:02 |
| pitti | @pilot out | 16:02 |
| === 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: | ||
| stgraber | roadmr: checkbox used to build on all architectures, now it fails on arm64, powerpc and ppc64el | 16:02 |
| === freeflying is now known as freeflying_away | ||
| roadmr | 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:03 |
| stgraber | roadmr: I'm looking at https://launchpad.net/ubuntu/+source/checkbox/0.17.4ubuntu3 | 16:04 |
| roadmr | stgraber: oh, I removed the qtsensors5-dev dep but now it's stuck on qtmultimedia5-dev | 16:05 |
| stgraber | 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 |
| stgraber | cjwatson: right, python3-checkbox-support was in that case (introduced in ubuntu2, dropped in ubuntu3, never migrated) | 16:06 |
| roadmr | stgraber: cool, thanks so much! I'll fix that asap | 16:07 |
| alow | infinity: Would like to chat about PPC64el and libv8 | 16:15 |
| infinity | alow: Perhaps when I'm out of this current meeting/call. | 16:17 |
| infinity | alow: I meant to follow up to your email, but I've been headless chickening the last day or two. | 16:17 |
| alow | 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:18 |
| infinity | alow: Awesome. And, as an added bonus (not a requirement, but a bonus), I understand this works on big-endian as well? | 16:19 |
| alow | infinity: It should - I haven't tested that specifically. I'd be happy to hit both BE / LE | 16:19 |
| alow | infinity: I'm off on vacation soon for a bit, so it'd be good to get this working for others soon | 16:20 |
| infinity | 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 |
| infinity | alow: I'll try to find some time to poke at it today, after I throw some time at glibc stuff this morning. | 16:20 |
| alow | so my repo https://github.com/andrewlow/v8ppc/tree/libv8-3.14 doesn't include the debian/ directory in it (yet) - would that be preferred? | 16:21 |
| infinity | alow: No, no. A simple branch of upstream is much easier to work with, importing debian directories and spec files tends to end in tears when they diverge from the distros anyway. | 16:21 |
| alow | infinity: oh good. so.. from here http://packages.ubuntu.com/source/trusty/libv8-3.14 I took the repository git://anonscm.debian.org/collab-maint/libv8.git and used that as a comparison base for https://github.com/andrewlow/v8ppc/tree/libv8-3.14 | 16:22 |
| alow | when I mix in a slightly hacked debian directory to support ppc64el -- I get .deb files out the other side | 16:23 |
| infinity | A positive result. ;) | 16:23 |
| infinity | Does it run a testsuite at build time? I haven't looked at v8 packaging. | 16:24 |
| alow | infinity: one caveat - I don't understand how the debian/patches directory gets applied. So I run the makefile / gyp patch manually | 16:24 |
| alow | infinity: yes - testsuite gets run | 16:24 |
| alow | infinity: >>> Running tests for ppc64.release | 16:25 |
| alow | Converting status file. | 16:25 |
| alow | Converting status file. | 16:25 |
| alow | Converting status file. | 16:25 |
| alow | No connection to distribution server; running tests locally. | 16:26 |
| alow | [01:28|% 100|+ 6093|- 0]: Done | 16:26 |
| infinity | alow: Kay, cool. As for patches, that depends on the source format, but if it's 3.0(quilt), the patches are applied at source unpack by dpkg. | 16:26 |
| infinity | alow: Based on the debian/patches/series file. | 16:26 |
| alow | infinity: Ok - I'm not sure I've setup things correctly in my builds then. I'll poke at that. I start with the source tree in place and use 'fakeroot debian/rules binary' to build | 16:27 |
| alow | infinity: but I'm fairly confident my code in the repo is suitable for the build at this point | 16:27 |
| alow | infinity: patches may not all apply clean - I'll try to validate that | 16:28 |
| infinity | alow: Kay. Will you be around in ~30m, when I'm not multitasking too much here? :) | 16:29 |
| pitti | mlankhorst: success! | 16:29 |
| alow | infinity: yes | 16:29 |
| pitti | mlankhorst: I'll add the protocol.txt post-upgrade test tomorrow; we don't keep around the container after upgrade, so I can't check right now | 16:30 |
| pitti | mlankhorst: I filed bug 1279411 as a reminder, does that sound right? | 16:33 |
| ubottu | bug 1279411 in Auto Upgrade Testing "check for /usr/lib/xorg/protocol.txt after upgrade" [Undecided,New] https://launchpad.net/bugs/1279411 | 16:33 |
| mlankhorst | pitti: thanks | 16:33 |
| infinity | alow: Alright, grabbing the Debian source and cloning your git repo and having a morning smoke. I'll be with you shortly. :P | 16:46 |
| alow | infinity: cool - I'm around | 16:46 |
| pitti | mlankhorst: http://bazaar.launchpad.net/~auto-upgrade-testing-dev/auto-upgrade-testing/trunk/revision/90 (tested locally) | 16:49 |
| infinity | Gah, only 250KB/s from github? Internets, why do you hate me this morning? | 16:50 |
| pitti | mlankhorst: rolled out, I'll check the results tomorrow | 16:51 |
| pitti | mlankhorst: you are right: http://d-jenkins.ubuntu-ci:8080/job/upgrade-ubuntu-precise-trusty-desktop-lts-raring-i386/13/artifact/results/bootstrap.log | 16:59 |
| pitti | - ['/usr/lib/xorg/protocol-precise.txt', '/usr/lib/xorg/protocol.txt'] | 16:59 |
| pitti | mlankhorst: that's what's left after the lts-raring → trusty upgrade | 16:59 |
| pitti | mlankhorst: so the diversions should be cleaned up | 17:00 |
| pitti | mlankhorst: I filed bug 1279424 | 17:02 |
| ubottu | bug 1279424 in xorg-lts-transitional (Ubuntu) "Needs to clean up /usr/lib/xorg/protocol-precise.txt" [Undecided,New] https://launchpad.net/bugs/1279424 | 17:02 |
| pitti | jibel: ^ FYI (in case you wonder why green tests go back to yellow) | 17:03 |
| jibel | pitti, thanks for adding new tests. I'm pretty sure you can find tests that will make it red :) | 17:03 |
| pitti | at most yellow, I hope | 17:05 |
| tester56 | will vlc 2.2 land in trusty? | 17:08 |
| Logan_ | tester56: does it even have an ETA? | 17:10 |
| tester56 | Logan: oh damn ... I do not know, sorry for that. As I have it running here, I supposed it was released already, my mistake sorry for the inconvenience. It has been in development for quite some time now if I am not mistaken | 17:13 |
| Logan_ | haha, no need to apologize | 17:13 |
| Logan_ | if it lands before Feature Freeze, we can likely maneuver it into trusty, but I'd rather go with Debian's releases | 17:13 |
| Logan_ | and Feature Freeze is in eight days, so it doesn't look like that'll be happening :P | 17:14 |
| Logan_ | unless there's a good reason to merge it in | 17:15 |
| cjwatson | Coo, ci.debian.net exists | 17:21 |
| cjwatson | Just noticed it from my qa.debian.org/developer.php page | 17:21 |
| === Lutin is now known as Guest51635 | ||
| roadmr | stgraber: We introduced a few new build-deps (and dependencies) for checkbox, and some aren't available for those archs (arm64 and ppc). That's where my arch support regression comes from. | 17:28 |
| stgraber | roadmr: does checkbox absolutely need those or could you have ti build on those arches without those build-deps? | 17:29 |
| stgraber | roadmr: (making those arch-specific build-deps and deps and have checkbox do the right thing at build time) | 17:29 |
| mpt | bdmurray, I see the new color for 14.04 is on <https://errors.ubuntu.com/>, but the milestone lines aren’t. Does that mean there’s something wrong with the milestone line code, or is it just that the rollout included the former but not the latter? | 17:30 |
| roadmr | stgraber: they're actually for a new checkbox-gui binary, maybe we could do what you say and then checkbox-gui would just be unavailable for those archs | 17:30 |
| mpt | bdmurray, or a simpler way of asking the question: What revision is the current rollout? :) | 17:32 |
| stgraber | roadmr: I guess that'd be reasonable, yes, make checkbox-gui arch:any and only building on the arches that have those bits, changed your build depends to also be arch-specific and change your build process so that it only attempts to build the GUI bits if those build-deps are present. | 17:34 |
| bdmurray | mpt: rhe rollout included the milestone colors, so it may be something with the graph code | 17:34 |
| mpt | ok, thanks | 17:34 |
| roadmr | stgraber: ok, sounds good, I'll get working on this. Thanks so much for your help and guidance! | 17:35 |
| stgraber | np | 17:36 |
| Logan_ | does anyone else run trusty in a VirtualBox VM? I'm having screen resize issues with the latest update | 17:47 |
| Logan_ | debfx: ^ | 17:49 |
| === Trevinho_ is now known as Trevinho | ||
| seb128 | do we have arm64 porter boxes? | 18:01 |
| seb128 | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt has | 18:01 |
| seb128 | skipped: gnome-control-center-signon (52 <- 1) | 18:01 |
| seb128 | * arm64: unity-control-center-signon | 18:01 |
| seb128 | not sure how to debug that | 18:01 |
| infinity | seb128: It means unity-control-center-signon is uninstallable on arm64... | 18:04 |
| seb128 | infinity, yeah, which would be easier to figure out why if I had access to an arm64 chroot/porter box ;-) | 18:04 |
| infinity | So, there isn't a porter box right now due to lack of hardware to go around. | 18:04 |
| seb128 | how would you recommend trying to debug that? | 18:05 |
| infinity | seb128: Check your channel invites. :P | 18:05 |
| seb128 | infinity, and why is unity-control-center-signon being uninstallable blocks migration when it's a new binary and has never been installable? | 18:06 |
| alow | BenC: infinity pointed me your way in regards to e500 v2 hardware. Today my v8 port doesn't work on e500 https://github.com/andrewlow/v8ppc/issues/100 - I'd like to fix, but need ready access to hardware | 18:24 |
| BenC | alow: I can get you access to e500mc, but I don't have anything for e500v2 (which, you probably shouldn't care about anyway) | 18:25 |
| BenC | alow: I can try a build on e500mc and let you know if that works or not... | 18:26 |
| alow | BenC: I know it won't work - check the data in the github issue I linked | 18:26 |
| BenC | alow: That data shows e500v2, which is not entirely the same as e500mc, so let me check | 18:27 |
| alow | BenC: if the basic floating point hasn't changed between e500mc and e500v2 - then either should work | 18:27 |
| BenC | alow: But it has...e500mc has hardware floating point and e500v2 uses softfloat (or mathemu in the kernel) | 18:28 |
| alow | BenC: the reason the code doesn't work is that we are generating FPU instructions - and the encoding is entirely different on e500 (mc / v2) | 18:28 |
| BenC | alow: I've cloned and started a build. In the meantime can you email me: ben.c@servergy.com and I'll get you ssh access to our RPLE server, which is e500mc/P4080 based. | 18:32 |
| BenC | ACTION tools_gyp_v8_gyp_v8_snapshot_target_run_mksnapshot /home/svy/v8ppc/out/ppc.release/obj.target/v8_snapshot/geni/snapshot.cc | 18:43 |
| BenC | Illegal instruction | 18:43 |
| alow | BenC: yes - expected | 18:44 |
| alow | BenC: if you build with "make ppc snapshot=off" it will complete the build.. but crash on startup when it tries to generate FPU instructions into memory and run them (V8 is a JIT) | 18:45 |
| BenC | alow: I can give you access to the hardware if you email me an SSH pub key and username | 18:45 |
| alow | BenC: drat.. just hit send -- will follow up now with key & name | 18:46 |
| BenC | Ah, thanks | 18:46 |
| BenC | alow: So the system has chroots. Probably makes no difference which one you use, but we want people to create a schroot env for their builds so we can easily isolate having to install build-deps if needed | 18:47 |
| BenC | alow: Instructions on how to use the setup is in the motd when you login | 18:47 |
| alow | k - will be a good citizen in that regard | 18:47 |
| === chuck_ is now known as zul | ||
| === bfiller is now known as bfiller_afk | ||
| dobey | kenvandine, robru: is there a way to make friends-service update from twitter more often? also, it seems to never actually pop up notifications on my workstation, but every time i boot my laptop, i get a bunch of notifications from it. :-/ | 19:08 |
| kenvandine | dobey, you can change the interval in gsettings | 19:28 |
| kenvandine | and there is also a setting for notifications | 19:28 |
| dobey | kenvandine: yes, notifications is set to "mentions-only" | 19:29 |
| dobey | kenvandine: which is what i want, but i don't seem to be getting them. | 19:29 |
| dobey | i do on my laptop though of course | 19:29 |
| slangasek | seb128: firefox ppc> I have no opinion on this, other than to reiterate that if there are issues with packages on the ports, this needs to be brought to the attention of the porters prior to give them a chance to respond /before/ it becomes a blocking issue for the desktop | 19:30 |
| seb128 | slangasek, hey, how do I brought attention to the porters? trusty has a firefox which is outdated by 3 versions (and outdated compared to security pockets from other series by almost as much) | 19:42 |
| slangasek | seb128: for powerpc, I would say the first stop is to ping infinity about it :) | 19:42 |
| seb128 | slangasek, it's not like the issue was not visible, it's just that nobody is stepping up to do anything about it, we are past mid-cycle and we got 0 firefox build with the trusty toolchain reaching the release pocket | 19:43 |
| seb128 | infinity, ping :p | 19:43 |
| seb128 | slangasek, done ;-) | 19:43 |
| seb128 | infinity, slangasek: note that firefox "builds", the build fails on a cache generation error after the actual build is done, seeing that the same version works on other series it looks like a toolchain issue (due to the toolchain or to firefox doing wrong thing) | 19:44 |
| slangasek | seb128: it's visible /to you/ because you're paying attention to the package; build failure reports from launchpad go to the uploader, not to the porters | 19:45 |
| slangasek | so no, it's not fair to assume that a package build failure is "visible" to the porters unless someone lets them know it's blocking them | 19:46 |
| seb128 | slangasek, right, I'm not especially paying attention, out of the fact that my firefox is outdated by 3 versions | 19:46 |
| seb128 | slangasek, I wish we had a better way to flag such issues :/ | 19:47 |
| infinity | seb128: Right, the toolchain pointer is an interesting hint. It might be a workable workaround to build with an older GCC on ppc for now, though the actual problem should be hunted down. | 19:48 |
| infinity | seb128: It might also be an acceptable workaround to drop ffox and its rdeps from PPC for now, but I want to look into the impact of that before I go on a deletion spree. | 19:49 |
| seb128 | infinity, I've said that before, and thanks for stepping up to provide us solution when that happened, but not having a porter box available doesn't help there | 19:49 |
| seb128 | how the heck can we support an arch without having access to one box to debug issues? | 19:49 |
| infinity | seb128: A porter box is on my Very Soon TODO. It got pushed back by an externally-imposed ABI break on ppc64el that I have to deal with this week. | 19:49 |
| seb128 | infinity, that's good news ;-) | 19:49 |
| seb128 | infinity, anyway, help on the firefox issue is welcome, we don't have a firefox maintainer anymore atm | 19:50 |
| seb128 | chrisccoulson does what he can on his extra-work-hours time to keep it going | 19:50 |
| seb128 | but he said several times that he doesn't have the free slots/motivations to deal with "exotic" archs (that includes ppc) | 19:51 |
| infinity | Pretty sure, to most people, "exotic" is everything that their home computer isn't. :P | 19:51 |
| seb128 | lol | 19:51 |
| infinity | (It just so happens that my home contains a lot of computers...) | 19:51 |
| chrisccoulson | my home computer isn't i386 or arm, but i'm happy to deal with those ;) | 19:51 |
| seb128 | infinity, it's rather than we have to be given proof that anyone uses firefox on ppc and it's usable there | 19:52 |
| infinity | seb128: To be fair, I don't use a desktop on PPC either, mine are all servers. So, yeah, I'm happy to examine the "just drop the binaries" option, but I want to poke the "why is it broken?" bit first. | 19:53 |
| seb128 | infinity, thanks | 19:53 |
| seb128 | infinity, I got that you are busy this week, do you think you can have a look before the end of the month? | 19:53 |
| seb128 | infinity, I would like to see us publishing a firefox update in trusty before beta time | 19:54 |
| infinity | seb128: Yeah, I can commit to having a fix, one way or the other, before beta. | 19:55 |
| psusi | cjwatson: quick question... partman-ufs is broken on linux so I got the monolithic image to build once after removing it from pkg-lists/standard-udebs... but this file seems to be auto generated somehow so it keeps getting put back. how is this? | 19:56 |
| === zz_mwhudson is now known as mwhudson | ||
| infinity | seb128: Although, I'm not seeing the toolchain change argument here, with rmadison output. Looks like powerpc is missing for precise-updates too. | 19:57 |
| infinity | The last version that built on ppc on any series was 25. | 19:57 |
| seb128 | shrug | 19:57 |
| infinity | So, 25->26 deltas and looking for stupid would be my first pass. | 19:57 |
| seb128 | infinity, sorry, I saw the security/updates going through on other series, I assumed that's because they didn't regresses on archs | 19:58 |
| infinity | seb128: Nah, the security team will happily regress unsupported arches if they can't immediately sort out the breakage. | 19:58 |
| seb128 | I didn't think we pushed through updates that don't build on all supported arches | 19:58 |
| seb128 | k | 19:59 |
| seb128 | I learnt something there | 19:59 |
| seb128 | infinity, anyway, if you can help getting that resolved one way or another that would be appreciated ;-) | 19:59 |
| * infinity nods. | 19:59 | |
| seb128 | I'm just chrisccoulson would join in buying you drinks at the next event | 19:59 |
| infinity | This whole work-for-drinks thing needs to stop before my liver falls out. | 20:00 |
| infinity | I'm staring at a bottle of gin from Carlos, and wondering if it's going to kill me. | 20:00 |
| seb128 | infinity, can buy you some vegetables if you prefer! | 20:01 |
| sarnold | chrisccoulson also runs on steak, would that work? hehe | 20:01 |
| infinity | seb128: Steak? :) | 20:01 |
| seb128 | oh, you said you want french cheese if I remember | 20:01 |
| infinity | Steak! | 20:01 |
| seb128 | that works too ;-) | 20:01 |
| infinity | A few kilos of d'Affinois cheese wouldn't go amiss either. | 20:01 |
| seb128 | hehe | 20:01 |
| infinity | In fact, it's nice melted on top of a filet mignon. Two for one. | 20:02 |
| seb128 | lol, I see where you a going ;-) | 20:02 |
| * seb128 starts wanting some steak | 20:02 | |
| seb128 | infinity, ok, gnome-control-center-signon built, I just deleted the arm64 debs from trusty/trusy-proposed since he can't work there (lack of qt5) and is depwaiting in the current upload | 20:12 |
| seb128 | infinity, if there is still work needed, after the next run, please do your magic if you can ;-) | 20:12 |
| infinity | seb128: Alrighty. | 20:12 |
| seb128 | thanks | 20:12 |
| infinity | seb128: That should have been all the magic required. Hopefully your deletes didn't misfire and take out anything else this time. :P | 20:12 |
| * seb128 hides | 20:13 | |
| seb128 | let's see, I'm confident I'm not going to screw twice in a day ;-) | 20:13 |
| infinity | That sentence really needs another word to be significantly less embarassing. | 20:13 |
| seb128 | screw -> screw up an Ubuntu upload? ;-) | 20:15 |
| seb128 | see why french should be default, it would be easier! | 20:15 |
| stgraber | it'd be a lot less fun ;) | 20:17 |
| infinity | seb128: "up" was indeed the missing word. :) | 20:19 |
| infinity | seb128: Entirely different meaning without it. :P | 20:19 |
| seb128 | ;-) | 20:21 |
| seb128 | I was going for fun, stgraber got it :p | 20:21 |
| seb128 | anyway, let's see if britney is happy once the arm64 binaries are gone | 20:21 |
| infinity | Should be. | 20:22 |
| seb128 | great | 20:22 |
| infinity | Unless something depends on the now-missing binaries. | 20:22 |
| infinity | But if so, we should sort that anyway, not ignore it. | 20:22 |
| seb128 | things depends on those yes | 20:22 |
| seb128 | but those have never been installable | 20:23 |
| infinity | I'm going to go pizza hunting. | 20:23 |
| seb128 | since they depended on qtdeclarative | 20:23 |
| seb128 | infinity, if you have internet, or a phone, you can get pizza delivered ... rather than having to hunt for it. Just saying... | 20:23 |
| seb128 | infinity, enjoy ;-) | 20:24 |
| ogra_ | seb128, he probably likes the guns ;) | 20:24 |
| seb128 | ogra_, did he move to Texas? ;-) | 20:24 |
| ogra_ | maple syrup guns ;) | 20:25 |
| jdstrand | seb128: powerpc isn't 'supported' by us in that sense. amd64, i386 and armhf get security support. the other archs are along for the ride (https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures) | 20:25 |
| seb128 | jdstrand, yeah, sorry I use "supported" for "existing" | 20:26 |
| infinity | jdstrand: Time to update the table for a new release and a new arch. :) | 20:27 |
| jdstrand | infinity: yes, a couple of them :) | 20:29 |
| jdstrand | oh no, arm64 is already there | 20:29 |
| jdstrand | infinity: and thank you for looking into ff/powerpc | 20:29 |
| seb128 | infinity, \o/ that worked, g-c-c-signon migrated to trusty | 20:32 |
| dobey | is it impossible to disable ctrl+super+left/right keybindings? | 20:33 |
| seb128 | dobey, you tried ccsm? | 20:34 |
| dobey | seb128: no, but tried dconf-editor, and don't see them in there. and setting them to a different action didn't help | 20:35 |
| === salem_ is now known as _salem | ||
| seb128 | dobey, I'm not sure, I think that's the grid plugin but you might want to ask Townsend when he's online, I think he cleaned that code previous cycle | 20:45 |
| === SpamapS_ is now known as SpamapS | ||
| infinity | jdstrand: You might want to split that table in two, for historical and current, too. Then the current one would have fewer arches, and fewer still next year. | 22:19 |
| jdstrand | yeah | 22:34 |
| jdstrand | I was thinking about that | 22:34 |
| === psivaa is now known as psivaa-afk | ||
| === bfiller_afk is now known as bfiller | ||
| miseria | "la verdadera felicidad de un ser humano, se logra cuando deja de ser esclavo, de la avaricia y la codicia" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival* | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
