| infinity | Odd_Bloke: *poke* | 00:16 |
|---|---|---|
| infinity | pitti: I thought you didn't consider the lxc runners good enough to give accurate results for migration purposes. | 04:01 |
| infinity | pitti: Though, I geuss if you're tracking always-failed per-arch, then the lxc ones can just have more failures for now. | 04:01 |
| infinity | pitti: I'm mildly concerned about the armhf tests holding up the show just due to speed now, though. | 04:01 |
| infinity | pitti: Especially since we used to optimise this by triggering x86 tests while armhf was still building. | 04:02 |
| pitti | Good morning | 04:21 |
| pitti | infinity: right, with jenkins we just tracked failures/regressions per package, hence ppc/arm (which have a lot more failures) couldn't be used for regression tracking; now we can | 04:21 |
| pitti | infinity: the speed is actually fine -- armhf finished the gcc5 triggered tests (~ 350) in about the same time as amd64+i386 | 04:22 |
| pitti | and ppc64 is even faster, as I run two tests in parallel per VM | 04:22 |
| === sitter_ is now known as sitter | ||
| Odd_Bloke | infinity: Hm? | 07:49 |
| === _salem is now known as salem_ | ||
| infinity | Odd_Bloke: Oh, I wanted to chat with you about doing powerpc cloud images, but we can do that when I'm not heading to bed. | 07:53 |
| infinity | Odd_Bloke: I figure it'll be 99% "do what ppc64el does", and 1% "ask Adam, cause WTF." | 07:53 |
| Odd_Bloke | infinity: :D | 07:54 |
| Odd_Bloke | That sounds pretty reasonable. | 07:54 |
| infinity | Odd_Bloke: What TZ (ish) are you working in? | 07:54 |
| Odd_Bloke | infinity: BST. | 07:55 |
| infinity | Odd_Bloke: And if the answer is "I started now, so now plus 8 hours", do you have time to stick around a bit after that to chat when I wake up? | 07:55 |
| infinity | Odd_Bloke: If not, we'll catch up another day. | 07:55 |
| Odd_Bloke | infinity: Yeah, that should be fine. | 07:55 |
| infinity | Odd_Bloke: Kay, cool. I'll be back in 6 or 7 hours for meetings, but will try to remember to poke you. :P | 07:55 |
| Odd_Bloke | infinity: :) | 07:56 |
| zzarr | hello! I get this error trying to build an application for my phone (MX4 Ubuntu Edition) "Unknown module(s) in QT: bluetooth" | 08:33 |
| zzarr | it compiles fin on my desktop machine | 08:33 |
| zzarr | fine* | 08:35 |
| pitti | zzarr: missing a qml-module-qtbluetooth or perhaps libqt5bluetooth5 build dep or so? (sorry, no clue about Qt, but usually missing build deps is the reason) | 08:43 |
| zzarr | but where are they missing, and how do I install them? | 08:45 |
| doko | barry, sure. you touched it last ;) | 08:45 |
| pitti | coreycb, jamespage: mind having a look at the wily failure in http://autopkgtest.ubuntu.com/packages/n/neutron/ ? | 08:49 |
| pitti | sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:mysql | 08:50 |
| pitti | missing dependency or something such? | 08:50 |
| pitti | coreycb, jamespage: it coincides with https://launchpad.net/ubuntu/+source/sqlalchemy/1.0.8+ds1-1ubuntu3 , thus britney rightfully held that back: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sqlalchemy | 08:51 |
| pitti | neutron itself is also FTBFS | 08:52 |
| jtaylor | doko: is there a reason our bash uses its on memory allocator and not the one from glibc? | 09:57 |
| tseliot | pitti: is this a known problem with systemd in wily? (it happens in my sbuild chroot) http://pastebin.ubuntu.com/12204790/ | 10:09 |
| pitti | tseliot: hm, not known to me; but that's in dpkg's unpack stage | 10:12 |
| tseliot | pitti: oh, right | 10:15 |
| rbasak | pmcgowan: could you comment on bug 1471903 please? ogra_ wanted you to have an opportunity to comment before we go ahead and upload the proposed fix there to Wily, since we want the fix to end up in the vivid-overlay PPA. | 10:18 |
| ubottu | bug 1471903 in live-build (Ubuntu) "-updates, -security missing from apt lists" [High,In progress] https://launchpad.net/bugs/1471903 | 10:18 |
| rbasak | bdmurray: ^^ | 10:18 |
| rbasak | pmcgowan: my attempt at a summary is in comment #27 | 10:19 |
| pmcgowan | rbasak, reading | 10:26 |
| ogra_ | rbasak, ah, thanks, i was about to ping pat :) | 10:28 |
| pitti | arges, tjaalton: could I bribe you to look at the SRUs in bug 1489045? trivial thing, but it would unblock some infrastructure work | 10:50 |
| ubottu | bug 1489045 in dkms (Ubuntu Trusty) "Backport autopkgtest script to precise/trusty" [Wishlist,Triaged] https://launchpad.net/bugs/1489045 | 10:50 |
| pitti | caribou: some cleanup to do for bug 1464201; otherwise this looks good, thanks! | 11:02 |
| ubottu | bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.9.0-3 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1464201 | 11:02 |
| caribou | pitti: anything you want me to do for that cleanup ? | 11:02 |
| pmcgowan | rbasak, ogra_ comment added | 11:02 |
| ogra_ | thanks ! | 11:02 |
| pitti | caribou: I followed up to the report | 11:02 |
| pitti | caribou: shoudl mostly be "put the .init back and correct the merge changelog" | 11:03 |
| pitti | caribou: and drop some unnecessary delta if you want (but this is just a suggestion) | 11:03 |
| caribou | pitti: sure, just comment in the bug & I'll fix that up | 11:04 |
| pitti | caribou: I did already | 11:04 |
| caribou | k | 11:05 |
| caribou | pitti: looks like the usage of imjournal.so needs some investigation | 11:10 |
| caribou | pitti: there are mentions of performance hit when using it instead of imuxsock | 11:11 |
| pitti | caribou: yeah, not a blocker for the FFE, just a question | 11:11 |
| caribou | pitti: let me look in to it | 11:11 |
| pitti | let's first get the new version in and look at this separately | 11:11 |
| caribou | pitti: their page says "The journal provides imuxsock with a copy of all “classical” syslog messages, however, it does not provide structured data" | 11:12 |
| caribou | pitti: so *maybe* this means that the basic journal data it picked up | 11:13 |
| pitti | oh, it is | 11:13 |
| pitti | it's just not totally reliable when there's a flood of messages | 11:13 |
| coreycb | pitti, neutron autopkgtests should be ok with 1.0.8+ds1-1ubuntu4, uploaded last night. I'll look into the ftbfs. | 11:13 |
| pitti | coreycb: the tests do use sqlalchemy 1.0.8+ds1-1ubuntu4 and fail with that | 11:27 |
| coreycb | pitti, oh I thought you said they were using 1ubuntu3 | 11:27 |
| pitti | coreycb: no, just that they started failing with this version | 11:27 |
| coreycb | pitti, ok I'll look | 11:27 |
| pitti | coreycb: sorry for the misunderstaning | 11:27 |
| pitti | coreycb: thanks! | 11:28 |
| coreycb | pitti, np! | 11:28 |
| zzarr | hello! if I compile a project based on QtQuick for a Ubuntu kit, where's the executable located (on my Ubuntu Phone in this case)? | 11:34 |
| mitya57 | zzarr: you probably want #ubuntu-touch or #ubuntu-app-devel | 11:35 |
| zzarr | mitya57, thanks | 11:35 |
| doko | jibel, online? | 11:42 |
| === salem_ is now known as _salem | ||
| === MacSlow is now known as MacSlow|lunch | ||
| jibel | doko, I am online | 12:09 |
| rbasak | pmcgowan: thanks! | 12:10 |
| rbasak | sil2100, ogra_, bdmurray: so who's sponsoring this? Is everyone happy with sil2100's debdiff in comment #11? | 12:11 |
| * rbasak notes that the changelog entry needs a bug reference | 12:12 | |
| tjaalton | pitti: done | 12:17 |
| sil2100 | rbasak: I'm happy with it, and I know bdmurray and infinity were too | 12:22 |
| sil2100 | Not sure who's ACK would we still need | 12:22 |
| pitti | tjaalton: cheers! | 12:22 |
| ogra_ | sil2100, well, note that pmcgowan asks that the overlay PPA has an override for the change | 12:23 |
| ogra_ | beyond that, yeah, someone should just upload :) | 12:23 |
| sil2100 | Wait, why? | 12:23 |
| tjaalton | arges: fyi ^, acked the dkms sru's already | 12:23 |
| sil2100 | The point of it is having that on our stable phones so that we can get proper reports | 12:24 |
| ogra_ | sil2100, well, effectively we need to re-work apport so we can drop the lists again ... perhaps we can live with the bloat until the next OTA | 12:24 |
| ogra_ | (and have sommeone fix apport) | 12:25 |
| sil2100 | pmcgowan: hey! You don't want the change for including apt lists of -updates and -security in the images? Why? | 12:25 |
| ogra_ | sil2100, seen the mail from john ? | 12:25 |
| ogra_ | regading image size ... | 12:25 |
| ogra_ | the rootfs will soon ship the infrastructure for desktop apps ... they are supposed to be executed in a chroot or container ... we will need to ship another 50-100M for that infrastructure (minimal chroot etc) | 12:26 |
| sil2100 | ogra_: it still should be ok, the difference is small - I understand the point, but holding off this change won't make much difference | 12:26 |
| ogra_ | we can really not waste space like that | 12:26 |
| ogra_ | sil2100, the difference is 50-60M | 12:27 |
| ogra_ | note that we used to wipe these package lists | 12:27 |
| ogra_ | not sure when or how they were added | 12:27 |
| rbasak | I thought that since we're already shipping the lists for the release pocket, the difference for -updates and -security is actually much smaller? | 12:27 |
| pmcgowan | sil2100,this pointed out we previously added 66MB we did not expect | 12:27 |
| sil2100 | ogra_: no it's not | 12:27 |
| ogra_ | rbasak, that we ship them at all is the main buug | 12:27 |
| pmcgowan | right | 12:27 |
| sil2100 | I checked that it's basically 5 MB more | 12:28 |
| sil2100 | ogra_: didn't you see my comment? | 12:28 |
| ogra_ | the original build scripts from the OEM team had code that forcefully removed them | 12:28 |
| pmcgowan | sil2100, te issue is the lists should not be installed at all | 12:28 |
| ogra_ | and all our size measurements we did in malta were based on a rootfs without them | 12:28 |
| sil2100 | pmcgowan: right, but that's a separate bug anyway | 12:28 |
| ogra_ | and these size measurements are the base for our parittioning scheme | 12:28 |
| sil2100 | Since we ship them right now anyway | 12:28 |
| mdeslaur | tkamppeter: how can I test ippusbxd? | 12:29 |
| rbasak | I don't think anyone disagrees with that. The question is about what we do right now. | 12:29 |
| pmcgowan | sil2100, but thats how we want to fix it for next stable update | 12:29 |
| ogra_ | sil2100, yes, as i said, someone needs to fix apport asap to not require them | 12:29 |
| pmcgowan | we dont need to fix it in proposed I'd say | 12:29 |
| pmcgowan | we just want the real fix | 12:29 |
| ogra_ | rbasak, right now we want this fix to land to not hold back other images | 12:29 |
| sil2100 | ogra_, pmcgowan: is bdmurray working on the fix? | 12:30 |
| ogra_ | but for the phone we want a plan that makes us go back to a sane size | 12:30 |
| pmcgowan | sil2100, no one is yet, I just filed a separate bug | 12:30 |
| ogra_ | sil2100, no idea, someone has to though | 12:30 |
| sil2100 | Ok, thanks | 12:30 |
| pmcgowan | sil2100, and I added it to ota7 list | 12:30 |
| ogra_ | pitti, on that note (see backlog above) are there any plans for apport in snappy ? | 12:31 |
| ogra_ | i guess a fix for the phone could be designed in a way that it also helps running apport on snappy | 12:31 |
| pitti | ogra_: we haven't really talked about that yet; i. e. what kind of error reporting do we actually want from snappy? Just for the snappy OS itself, or for any of the apps? the latter surely shouldn't be Ubuntu bugs, but go somewhere else? etc. | 12:57 |
| ogra_ | pitti, well, snappy on the phone and snappy personal will surely want to use some kind of automatic error reporting ... and there we cant rely on apt lists locally | 12:58 |
| pitti | ogra_: if we remove dpkg and /var/lib/dpkg/* we stop being able to associate a binary to a package; so if that's what we conceptually want, we could still file bugs against teh "snappy" project, but we can't associate them to their real packages any more | 12:58 |
| pitti | ogra_: hm, we only need the apt lists to determine the origin, no? mapping a path to a package should just require the dpkg db | 12:59 |
| ogra_ | pitti, and that lists issue already hits us ahrd on the phone today ... so having a plan that can also work on snappy would be good | 12:59 |
| ogra_ | pitti, well, i'd go even further and say we could us a remote locatiojn for that data where we bind psckage lists to specific image versions | 13:00 |
| pitti | ogra_: that doesn't need to be done on the client side, though | 13:00 |
| rbasak | Could you just ask Launchpad? It has this information available already via publishing history, right? | 13:00 |
| barry | doko: :) | 13:00 |
| pitti | ogra_: on the client, specifying the executable path and channel/image number should be sufficient? | 13:01 |
| pitti | and resolving that to a package could then even be done in launchpad/on the retracers, etc. | 13:01 |
| ogra_ | yeah | 13:01 |
| pitti | (probably not in LP itself, but the retracers could post-process reports) | 13:02 |
| cjwatson | rbasak: soooort of, but that often doesn't quite match up to image building for various reasons; more reliable to keep manifests | 13:12 |
| rbasak | OK | 13:17 |
| === _salem is now known as salem_ | ||
| Laney | tyhicks: hi, do you have a bug # to track removing the GetConnectionAppArmorSecurityContext porting? | 13:32 |
| Laney | erm, that sentence made more sense before it got through my fingers | 13:32 |
| Laney | you know what I mean :) | 13:32 |
| pitti | apw: is this uninstallability known? http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#linux-meta | 13:34 |
| mdeslaur | slangasek: weren't you going to upload a new edk2? | 13:40 |
| apw | pitti, why _it_ that uninstallable, there is a linux-image-virtual-lts-utopic | 13:45 |
| pitti | but http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_output.txt says it's not installable | 13:47 |
| apw | oh ... its an arch thing | 14:00 |
| apw | pitti, ok that is plain wrong and has been plain wrong since it was first released by the looks of it | 14:03 |
| pitti | apw: I guess we just never paid attention to britney uninstallables in stables so far? | 14:03 |
| === Laney changed the topic of #ubuntu-devel to: Archive: feature freeze | 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: | ||
| pitti | Laney: \o/ congrats! | 14:03 |
| apw | pitti, i guess not, anyhow, i'll get a bug filed and someone to fix 'er up | 14:03 |
| Laney | pitti: wily is open for breakage again :) | 14:04 |
| pitti | Laney: britney has lots of shiny! :) | 14:04 |
| caribou | pitti: Just uploaded changes for LP: #1464201 | 14:05 |
| ubottu | Launchpad bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.9.0-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1464201 | 14:05 |
| === MacSlow|lunch is now known as MacSlow | ||
| apw | pitti, bug #1489487 | 14:16 |
| ubottu | bug 1489487 in linux-meta (Ubuntu) "linux-meta: is uninstallable in trusty-proposed" [Medium,Triaged] https://launchpad.net/bugs/1489487 | 14:16 |
| tyhicks | Laney: bug #1489489 | 14:23 |
| ubottu | bug 1489489 in media-hub (Ubuntu) "The org.freedesktop.DBus.GetConnectionAppArmorSecurityContext() method is deprecated" [Medium,Triaged] https://launchpad.net/bugs/1489489 | 14:23 |
| tyhicks | Laney: I need to add more source packages that are affected and need to provide an example of how to switch over but at least we have a placeholder now | 14:23 |
| Laney | tyhicks: ok, it'd be nice if we could do this for 15.10 if possible | 14:28 |
| Laney | if it's easy maybe I can help | 14:28 |
| tyhicks | Laney: I doubt 15.10 is possible | 14:40 |
| Laney | why? | 14:41 |
| tyhicks | Laney: I don't have much time to devote to it at the moment | 14:44 |
| tyhicks | Laney: if individual project maintainers want to jump in and make the changes based on the examples that I provide, then it may be possible | 14:45 |
| tkamppeter | mdeslaur, run "ippusbxd -d -n -N -P 60000" on the command line. This runs ippusbxd without presence of a printer but opening the port. | 14:46 |
| tkamppeter | mdeslaur, see "ippusbxd -h", "-N" is the no-printer mode for development and debugging. | 14:46 |
| mdeslaur | tkamppeter: ah! great, thanks | 14:50 |
| === tdaitx_ is now known as tdaitx | ||
| mdeslaur | tkamppeter: ah, my ippusbxd is too old to have those options...it's the vivid cups-filters package | 15:10 |
| mdeslaur | tkamppeter: do you have the required hardware to test the update in https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages ? | 15:10 |
| tkamppeter | mdeslaur, I have the hardware, so tell me whatever steps I have to do (probably with Vivid as Wily uses the new ippusbxd). | 15:15 |
| mdeslaur | tkamppeter: install the cups-filters binaries from that ppa on vivid, and see if ippusbxd still works, that would be an enormous help | 15:16 |
| pitti | cjwatson: britney itself (at least not britney2-ubuntu) doesn't "do" the copy from -proposed to -release, it just computes the set of packages that it can migrate, right? do you know what does that? | 15:20 |
| pitti | sil2100: ^ | 15:20 |
| cjwatson | pitti: Start from lp_import in britney1-ubuntu (which wraps britney2-ubuntu) | 15:21 |
| cjwatson | pitti: promote-to-release is in lp:ubuntu-archive-tools | 15:21 |
| pitti | cjwatson: ah, in britney1 | 15:21 |
| pitti | so britney2 writes HeidiResultData, britney1's ./britney calls promote-to-release | 15:22 |
| sil2100 | \o/ | 15:23 |
| * sil2100 looks at that | 15:23 | |
| sil2100 | cjwatson: thanks! | 15:23 |
| pitti | cjwatson: cheers | 15:24 |
| sil2100 | How did I miss that, sometimes I feel like a blind guy | 15:25 |
| * pitti hasn't touched britney1 at all yet, didn't know it either | 15:25 | |
| tkamppeter | mdeslaur, I have tested and the security fix seems to be OK. | 15:26 |
| mdeslaur | thanks tkamppeter! very much appreciated | 15:26 |
| tkamppeter | mdeslaur, but can you please also apply also this (functional, not security) fix: | 15:26 |
| tkamppeter | https://github.com/tillkamppeter/ippusbxd/commit/3facde24a3b74168047dcd564bf609fd9911edcb | 15:26 |
| cjwatson | To be fair it is a baroque setup, but I was trying to make it as close to the deployed setup in Debian as possible (and theirs had accreted over time) | 15:26 |
| tkamppeter | mdeslaur, it is a simple patch, without it most printers are not able to print but only allow access to their web config interface. | 15:27 |
| tkamppeter | mdeslaur, Wily already has this fix as it uses the 1.22 release. | 15:28 |
| mdeslaur | tkamppeter: we don't usually include fixes in security updates, but I'll include this one | 15:28 |
| mdeslaur | tkamppeter: thanks | 15:28 |
| tkamppeter | mdeslaur, thanks. | 15:28 |
| slangasek | mdeslaur: yeah, but I wasn't in a hurry :) I have another patch pending from dannf for proper arm64 vm support, but he also tells me that something's funny with the arm64 build when cross-built | 15:31 |
| slangasek | dannf: ^^ any progress on that? and do you happen to have checked that rebuilding the existing package with gcc-5 works? | 15:31 |
| mdeslaur | slangasek: ok...I have some updated libosinfo and virt-manager packages...but libvirt needs your edk2 packages to detect the firmware properly | 15:31 |
| mdeslaur | slangasek: so I guess we need to publish these all together under the same FFe | 15:32 |
| dannf | slangasek: yes, same package rebuilt w/ gcc5 fails. i'm doing a gcc bisect, but having to skip a lot of build failure revs | 15:32 |
| dannf | slangasek: one workaround would be to force gcc-4.9 for now | 15:32 |
| slangasek | mdeslaur: I don't think the edk2 side needs an FFe fwiw | 15:32 |
| mdeslaur | hrm, mine does :P | 15:33 |
| slangasek | dannf: that's no workaround, there is no cross gcc-4.9 in Debian ;) | 15:33 |
| slangasek | I would have to back out that change | 15:33 |
| dannf | slangasek: right - well, bisection continues - hopefully that'll find the root cause | 15:33 |
| bdmurray | seb128: While https://errors.ubuntu.com/bucket/?id=failed%3A/usr/lib/i386-linux-gnu/libgtk-3-0/gtk-update-icon-cache-3.0%3A11%3Ai686%3A/usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1%2B6d08%3A/usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2600.1%2B4b49%3A/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so%2Bff4 has failed to retrace do you have any ideas what the problem may be? | 16:17 |
| seb128 | bdmurray, no idea no | 16:18 |
| tkamppeter | Is there some system facility which "corrects" file ownerships and permissions in Ubuntu, for example out of a cron job? | 16:25 |
| dobey | tkamppeter: no | 16:29 |
| Odd_Bloke | infinity: I have a hard EOD in about 90 minutes, if you still want to talk powerpc images today. | 17:21 |
| dannf | slangasek: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1489560 | 18:06 |
| ubottu | Launchpad bug 1489560 in edk2 (Ubuntu) "qemu-efi: hangs in kvm mode when built w/ gcc-5" [Undecided,New] | 18:06 |
| slangasek | dannf: so as you assigned this to edk2 rather than gcc, does that mean you think it's a bug in edk2? | 18:22 |
| dannf | slangasek: i have no idea, though i'd lean towards a gcc regression. marked as impacting both now. | 18:40 |
| bdmurray | Riddell: Do you have any plans to fix the ubuntu-release-upgrader test failure? http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader/wily/amd64/ | 18:48 |
| doko | barry, do you have an estimate what still needs to be done for python3.5 as the default? honestly I'd like to see this for 15.10, even if it breaks some stuff, so we have something stable in preparation for the next LTS | 19:49 |
| barry | doko: i was just chatting w/ slangasek about that. i need to do an updated review of main + seeded packages that ftbfs or fail dep-8 w/py35 as default. my biggest concern frankly is django and its ecosystem. a safer route is to keep 3.5 as supported for 15.10 and do the switch to default as soon as x opens | 19:59 |
| doko | barry, sure, but that won't expose 3.5 that much to users and developers | 20:03 |
| doko | ohh, and I should better run python3.5 in the autopkg tests for python3.5, and not 3.4 ... | 20:04 |
| barry | doko: that's true, but i think we've done a really good job of getting upstreams on the py35 bandwagon just by doing our transition. also: what's the plan for 3.5 as support or default in debian? | 20:07 |
| doko | barry, finishing GCC 5 first according to the release team ... and I'm not the only python3-defaults maintainer | 20:08 |
| barry | doko: right. perfectly reasonable to finish gcc5 first. is there an eta for that? | 20:09 |
| doko | barry, 1-2 months, that's what the release team things. but how does this relate to making 3.5 the default for 15.10? | 20:10 |
| juliank | If somebody wants to try APT 1.1 in wily, the PPA builds that now: https://launchpad.net/~deity/+archive/ubuntu/sid (yes, the name is wrong, sid is tracking HEAD, which is currently experimental) | 20:11 |
| doko | juliank, mvo is back from vacation, hint, hint ;-P | 20:11 |
| barry | doko: doesn't much, mostly curious. i think we're probably not in bad shape for debian to go to 3.5. as for ubuntu, let me see what other main+seeded packages still need love | 20:12 |
| juliank | doko: Sure. But APT 1.1 is post-wily stuff, so the PPA allows people to test it anyway | 20:13 |
| doko | barry, I can start the next test rebuild with 3.5 as the default, but then you would have to identify the 3.5 related ftbfs | 20:13 |
| doko | ahh, ok | 20:13 |
| barry | doko: would that be much different from the ~pythoneers/py35asdefault ppa? | 20:14 |
| doko | barry, it would be recent, and for all archs | 20:14 |
| barry | doko: it would be good data then | 20:15 |
| doko | ok, planning for it | 20:15 |
| juliank | I'll soon release python-apt 1.0~beta4 though, that one is targeted at wily. | 20:16 |
| slangasek | doko: I disagree that it's better to have 3.5 as default in 15.10 when we know it will break packages; especially since we're past FF and barry has already signalled via the mailing list that we're not switching, I think it's more effective to focus on the known issues i.e. build failures) between now and 15.10 release, and get these fixed via Debian | 20:16 |
| doko | slangasek, ohh, didn't see that. but I disagree on the breakage thing. sure, there is django, but we don't know about anything else | 20:20 |
| slangasek | doko: there are still a large number of build failures in the py35default ppa | 20:32 |
| doko | slangasek, afaics the ppa wasn't updated | 20:35 |
| barry | i have a script to sync the archive to the ppa | 20:36 |
| barry | which i just again ran 15m ago :) | 20:37 |
| bdmurray | Riddell: I'll fix ubuntu-release-upgrader | 20:59 |
| ochosi | hey everyone | 21:04 |
| ochosi | who's currently in charge of ubiquity? | 21:04 |
| ochosi | is it cyphermox? | 21:05 |
| Unit193 | Thought so. | 21:15 |
| cyphermox | yo? | 21:18 |
| Riddell | bdmurray: I uploaded to vivid-proposed, awaiting ubuntu-sru approval | 21:33 |
| Riddell | bdmurray: oh but I've not seen the test failure | 21:33 |
| ochosi | cyphermox: just wondering whether another ubiquity release was planned for 15.10 because there is a xubuntu-relevant bugfix in trunk that would be nice to have (aka commit 6307) | 21:34 |
| Logan | slangasek: looks like the Debian maintainer renamed the gtkglextmm shared library package for G++ 5 - should we pull that in? | 21:43 |
| cyphermox | ochosi: yes, there will be an upload soon :) | 21:49 |
| slangasek | Logan: I would say yes | 21:51 |
| ochosi | cyphermox: awesome - thanks! | 21:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!