[03:06] infinity: http://paste.ubuntu.com/12059133/ seems to be working, and i think incorporates your suggestions [03:08] hallyn: ITYM "after 16.04". [03:08] hallyn: The unnecessary whitespace change in the init script is gross (tabs versus spaces) if that introduces a delta with Debian. [03:09] hallyn: Well, it's gross either way, but worse if it's a delta. :) [03:09] infinity: do I? I thought that so long as 16.04 existed people might be upgrading from something older [03:09] hallyn: I think one of us might be confused about the meaning of the word "after"? [03:09] hallyn: 16.04 needs to have the upgrade code. 16.10 doesn't. 16.10 is after 16.04. [03:10] hallyn: Similar whitespace changes in postinst too. You're good at that. [03:10] Or your editor hates your freedom? [03:11] yes when i edit a block i try to make it tab/space-consistent [03:11] maybe i shouldn't, it does complicate the diff [03:12] Well, it's particularly bad if this is shared code with Debian. [03:12] If it's all your code, meh. [03:12] re debian delta, we're not syncing from debian at all right now. considering trying to merge in next few months, but it's been years since we'v edone that [03:12] hallyn: What does "service libvirt-bin stop" do? Is that going to kill everyone's VMs during the upgrade? [03:13] Kinda looks like it will... [03:15] Oh, but it won't because the init script was missing that bit before. :) [03:15] And the upstart job guards against running stop outside the stop runlevels. [03:16] hallyn: Okay, so that seems reasonable. The same runlevel guard might be nice for the sysv implementation, but we'll never use it anyway (but if you intend to push this to Debian...) [03:17] hallyn: The only remaining question is are the the systemd services similarly guarded somehow, or will stopping the systemd service stop all guests? [03:31] infinity: with the systemd jobs, the libvirt-stop-guests is only run right before machined would kill them anyway [03:32] i.e. libvirt-bin stop by itself does not call kill the vms [03:32] but now that you mention it i'm not sure that the sysvinit variant is doing the right thing there... [03:33] so i think i'll just drop that delta - meaning the bug won't be fixed for anyone who's insisting on running sysvinit [03:33] bc i don't know offhand how to tell in sysvinit jobs what runlevel we're in [03:39] hallyn: You can ask it. [03:41] hallyn: /sbin/runlevel echoes "X X" for previous and current runlevel. [03:42] hallyn: ie "N 2" or whatever. [03:48] meh [03:48] one more thing to break if i do it :) [03:48] all right all righ ti'll do it [03:48] thanks :) [04:02] Good morning [04:03] hallyn: good! [04:04] slangasek: gcc-5 promotion -> \o/ [04:11] infinity: ah, but apparently /sbin/runlevel still says 'N 5' during reboot :) guess it's transitioning *to* 6, but not yet there :) [04:15] pitti: Does it seem sane that apt is waiting on autopkgtests for a version of python-apt that has no binaries? [04:16] infinity: that's a change from yesterday, see ubuntu-release@ [04:16] infinity: it's always a compromise one way or the other :/ [04:16] pitti: Yeah, hrm. [04:16] Oh well, guess I need to merge the newer apt. [04:17] infinity: slangasek responded on the list, I'll respond again [04:17] we might be able to fine-tune this a bit [04:18] infinity: but this illustrates it rather well: at this point we don't know whether the new apt breaks the new python-apt, or whether python-apt is broken in its own right [04:57] doko: oh, http://launchpadlibrarian.net/214180176/okular_4%3A15.04.2-0ubuntu2_4%3A15.04.2-0ubuntu3.diff.gz was not an ABI change? I had it noted down as "needs rename/transition" in the pad [05:34] pitti: hey, what is the 'Removal candidates' list on http://pad.ubuntu.com/gcc-5-transition for? are these things you are proposing to remove, things you know have been identified as removal candidates in Debian? [05:34] slangasek: I think that's Laney's [05:35] ah [05:35] you're right, it's his color not yours :-) [05:35] slangasek: but I read it as "gpid-cpp" is RC buggy and removed in Debian, so we could think about removing it in Ubuntu instead of fixing it [05:35] or bumping to -proposed [05:36] ok; I think that's better handled by flagging down an archive admin rather than putting it in the pad [05:36] we could do the same with bombono-dvd [05:37] slangasek: I'm still working on FTBFS, and finishing up transitions; is there anything else/more important you want me to look into? [05:38] no objection to removing bombono-dvd; at the moment I'm just trying to clean up the pad a bit for readability [05:38] yeah, I went over it and removed the finished items [05:38] pitti: FTBFS+transitions> I think that will probably keep you busy for at least another day [05:39] slangasek: for sure :) I'll need half a day for that systemd bug fix with "systemctl link" and to prep my debconf talks, but I'll continue with the gcc bits [05:42] slangasek: FAOD, http://people.canonical.com/~ubuntu-archive/transitions/html/html/icu.html can be moved to "finished", right? [05:42] boost1.55 is itself obsolete, and cg3 is just NBS (new version built fine) [05:43] Why the *(&*%! is gcc-5 so huge? [05:43] My chroots just doubled in size when I refreshed them. [05:44] they might not have purged gcc-4.9 along? [05:44] pitti: I did. [05:44] pitti: And that really wouldn't account for it anyway. They literally doubled. [05:44] armhf went from 118M to 223M. [05:45] Okay, not quite, but basically double. [05:47] Installed-Size for gcc-5 is 125MB all on its own. [05:47] doko: ^-- Is that intentional or a horrible bug? [05:48] And 135MB for g++-5 [05:48] leftover debug symbols? [05:49] vs. 18 MB for gcc-4.9 [05:49] And 30ish for g++-4.9 [05:49] So, yeah. A bit of growth there. :P [05:49] Oh well. I'll upload these chroots to take pressure off queues, and we can fix this later. [05:50] -rwxr-xr-x 1 root root 124324976 Aug 9 15:14 /usr/lib/gcc/x86_64-linux-gnu/5/lto1 [05:50] "not stripped" [05:50] Hah. [05:50] That would certainly do it. [05:50] Similar failure for g++? [05:50] $ cp /usr/lib/gcc/x86_64-linux-gnu/5/lto1 /tmp/; strip /tmp/lto1; ls -lh /tmp/lto1 [05:50] -rwxr-xr-x 1 martin martin 18M Aug 12 07:50 /tmp/lto1 [05:51] much nicer :) [05:51] -rwxr-xr-x 1 root root 131M Aug 9 15:14 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus [05:51] yes, seems so [05:52] reduces to 20 MB after stripping [05:56] pitti: Can you point those two out to doko when he wakes up so they don't get lost in backscroll? [05:56] infinity: ack [05:56] pitti: And I'm updating chroots anyway, so no pressure to fix it ASAP (as that'll invalidate the chroots...) [05:58] * pitti moves 11 more transitions to "finished", yay [05:58] THough, it'll take a good half hour to upload these chubby chroots. [05:58] La la la. [06:45] Hey, here's an idea [06:46] how about every 6 months automatically backporting the entire standard release repository into the LTS as a point release, and automatically updating anyone who runs apt into the new 6 month release, with no support (or security updates) for the old versions of all the software [06:46] We could call it "Red Hat Enterprise Linux" [06:49] Bluefoxicy, you would have to call it Fedora, RHEL don't backport new versions, just security fixes [06:50] darkxst: I'm just venting. [06:51] RHEL point releases "carry major architectural changes, so you should read the release notes carefully" [06:51] as a result, when you have RHEL 6, you have... something. [06:51] They claim RHEL 6 is a stable software distribution--like, say, Ubuntu 12.04 LTS [06:52] but at every point release--say, 6.3, 6.4, 6.7--they do major version upgrades of software, in a similar way from moving from 12.04 to 12.10 to 13.04 [06:52] This of course means all support for the prior point release effectively ends [06:53] so it's like if Ubuntu ran a 6 month cycle and automatically updated the same existing repository (instead of making a new release), dropping all support for prior versions immediately when a new version came out. [06:53] which, when you get right down to it, with RHEL claiming 20 years support of a stable distribution, is what's colloquially known as talking out both sides of your mouth. [06:55] They asked me at work if we should switch from CentOS to RHEL to get some sort of real support contracts, even though we're aware RHEL support is functionally useless. I told them the pragmatic option--and thus the ethical and responsible one--is to switch from something Redhat-based to Ubuntu LTS :| [06:55] They pay me to do my job well, not to cover my ass with useless but bureaucratically-placating support contracts. [06:55] /rant [06:56] Also, if anyone ever suggests rewriting support policy to favor more major changes on LTS point releases, stab them in the face. [06:57] good morning [07:01] Bluefoxicy, I thought once upon a time, RHEL point releases were opt-in, not automatic [07:05] darkxst: in so much as running yum update is opt-in, the problem with that being you're opting out by no longer running updates. [07:06] let's say you didn't run updates for a month. Well, unless you want to select each update--each security patch and bug fix--prior to the latest point release by hand, specifying the exact version to install, you can't patch up to the latest on current. [07:07] The guy who did this a week before point release is in the same boat, but closer. [07:07] it's as if you just took the Trusty repositories and shoved the Utopic packages into them. [07:08] darkxst: btw, if you have a support contract, and you tell them you haven't run yum update to the latest patch, they will refuse to support you until you do so. :P [07:09] It's like how you have the option to surrender to the police. It's not mandatory; you could just let the police shoot you in the back of the head while you run away. [07:09] Bluefoxicy, go find a red hat channel perhaps! [07:10] ha. [07:10] YEah I've vented more than I cared to tbh. [07:22] doko: ack, thanks [07:36] hmmm, is it just me or is debian unstable/sid archive gone? [07:38] ah [07:38] yeah, I should get a coffee before trying to fix bugs [07:42] doko: do you know when debian plans to switch to python 3.5 as default? [08:12] Laney: I'm currently going through http://people.canonical.com/~ubuntu-archive/transitions/html/ [08:13] Laney: i. e. cleaning up finished transitions, uploading missing rebuilds, noting FTBFSes, and such; pad is up to date [08:13] pitti: nice [08:13] I'll check up on some others shortly [08:14] Laney: I retried some of your FTBFS, but I might have missed smoe [08:14] some kind soul retried bpp stuff [08:14] \o/ [08:14] Laney: yeah, that was part of "going through transitions and try to fix" :) [08:15] but only 40% through so far [08:18] touch-core: * libtinyxml2-2 # camera/gallery [08:18] WTF? [08:18] why are we seeding libraries in touch? [08:18] sdk-libs: * libjsoncpp0v5 [08:18] touch-core: * libzen0 [08:18] pitti: Because someone doesn't understand how dependencies work? [08:18] my friends, this is wrong [08:19] pitti: The sdk-libs thing, unfortunately, has an excuse. All it *is* is a collection of runtime libraries. Though, auto-generating it from the deps of sdk-libs-dev might be clever. [08:19] yes, granted; but in touch-core? [08:19] pitti: The touch-core thing is almost certainly someone doing something wrong. [08:19] is that because we are working around our own click specification? [08:20] i. e. "click packages don't have deb dependencies"? [08:20] pitti: Possibly? [08:20] (also, ew?) [08:21] pitti, that doesn't have much to do with clicks I think [08:21] rather it's up to define what libs we support as part of the base image [08:21] which is othogonal to click depends [08:21] seb128: that should be in sdk-libs, but nowhere else [08:21] right [08:21] just commenting about workarounding clicks [08:21] and it says "camera/gallery" which sounds like a really bad workaround [08:22] workaround to what? [08:22] it's been there forever apparently [08:22] clicks are not part of the OS [08:22] they can't be what brings a lib in [08:22] seb128: to what> well, I don't know -- some broken dependency somewhere, or maybe it's obsolete? [08:23] seb128: yes, that's what I mean -- clicks can only depend on platform-api, so if they have an implicit dependency to a packaged lib they are broken [08:23] that what I mean with "working around our own click spec" [08:23] right [08:23] but that doesn't have to do with the spec [08:23] either the lib should be part of the base image [08:23] or they shouldn't use it [08:24] or they should have their own copy [08:24] right [08:33] er is there some way i can see if a package is still tied up in the gcc5 transition? [08:35] mwhudson: You might need to expand on that a bit. [08:35] mwhudson: A package in proposed? A package you want to upload and you don't know if it'll get stuck? [08:35] it was a bit gnomic wasn't it [08:35] this build blew up https://launchpadlibrarian.net/214259852/buildlog_ubuntu-wily-amd64.unity-scope-snappy_0.1.0%2B15.10.20150721-0ubuntu1_BUILDING.txt.gz [08:36] with things like src/launchpad.net/unity-scope-snappy/internal/launchpad.net/go-unityscopes/v2/activationresponse.cpp:25: undefined reference to `unity::scopes::Variant::deserialize_json(std::__cxx11::basic_string, std::allocator > const&)' [08:36] which certainly tickes my c++ abi break spider sense [08:36] and now i see from https://launchpad.net/ubuntu/+source/unity-scopes-api that there is a package in proposed [08:42] heh i wonder if i'd get more or less brokeness if i enabled proposed as a dep [08:43] mwhudson: PPAs that aim to test things for the archive should generally build against proposed anyway. [08:43] mwhudson: On the flip side, if things can't build in the release pocket, that's a pretty serious issue. [08:43] yes i guess that makes sense [08:45] well the latter point should be easy enough to check [08:47] oh and blargh i guess i should have copied from the release pocket too [08:47] no [08:47] proposed [08:47] infinity: do you ever sleep? [08:48] mwhudson: Sort of. [08:51] seb128, I saw your post on the ML about testing BLuez5. Do you want me to build Blueman2 in a PPA, linked to the Bluez5 trasition PPA, or will you be able to build Blueman2 in the transition PPA? [09:06] Laney: ah, I noticed that several of our demotions (bombono-dvd, crystalspace) went back into wily; for bombono-dvd I went with removal and reupload [09:06] Laney: do you know a better trick for that? [09:06] Laney: a FTBFS bug with "block-proposed" should do [09:09] * pitti demotes again [09:15] pitti: ah, if their deps are still satisfiable then I have blocked in the past [09:15] Laney: ok, will do that from now on [09:15] Laney: yeah, they only will stop being satisfiable once the transitinos land [09:55] meh, we're racing on these [09:58] flexiondotorg, I'm looking at it, but your sync request doesn't state why the delta is not needed anymore [10:04] can somebody moderate my mail on u-d-a? [10:05] looking [10:05] <3 [10:05] gern :) === kickinz1 is now known as kickinz1|lunch [10:21] Laney: I stop firing transition uploads for now, going back to sifting through the resulting FTBFS; so it's all your's :) [10:21] * Laney is test building before uploading so doing both simultaneously :) [10:21] I got through maybe 60% of the transitions, so please check for existing rebuilds before you fire mass-rebuilds [10:21] I tried to use the pad to lock transitions but that wasn't really working [10:21] ah, I don't have enough horsepower for that [10:22] Laney: yeah, I added them this morning, but removed them again as it's too unwieldy [10:22] Laney: I usually just click through the package names on a transition page, and ignore the ones which already have rebuilds [10:22] the rebuild-fix-sign-upload cycle adds some delays here :P [10:24] ah so it's you guys who are stopping my arm64 ppa builds from ever happening [10:24] * mwhudson goes to bed and will resume when all the europeans have gone away [10:24] we are children of doko [10:25] Laney: I started with test-building, but after I ran into the fourth package with a 3 h build time I gave up [10:25] mwhudson, which one? [10:25] mwhudson: trust me, we have the same feeling :) [10:25] doko: https://launchpad.net/~mwhudson/+archive/ubuntu/go15-rc-tests/+packages [10:25] ci-train is eating all the time, it's not me [10:25] mwhudson: this morning 4 out of 5 builders were building PPA stuff [10:26] yeah, i'm mostly just being silly [10:26] anyway, no need for a blame game, we just need to wait [10:26] and really should go to bed [10:26] mwhudson, ahh, not just one package. sorry, has to wait [10:26] mwhudson: no worries, we all like to joke about it :) good night! [10:26] obviously builds for the archive trump ppa builds :) [10:26] bumped golang [10:27] doko: ah thanks [10:27] * pitti cancels all queued arm64 builds which are going to FTBFS anyway, to help a bit [10:29] vtk has a broken shlibs file [10:30] that'll probably be why all http://people.canonical.com/~ubuntu-archive/transitions/html/vtk-g++5.html failed [10:30] at least initially [10:42] Hi, I'm trying to troubleshoot a regression where wily has CHARMAP="ISO-8859-15" instead of CHARMAP="UTF-8" in /etc/default/console-setup, any clues on how to pinpoint that change? [10:43] (it breaks non-ascii output in VTs) [10:52] apw: please ignore bombono-dvd, I demoted it to -proposed [10:55] Laney, are you currently looking at vtk? [10:56] doko: rebuilding it [10:56] locally [10:56] will check it can rebuild stuff before uploading [10:56] takes a while so don't want to waste buildd time :) [10:58] we've got plenty of x86 and even armhf power :) (I just tend to cancel builds of ppc64el and arm64, as these are the scarce ones) [10:58] I can build it faster than they can anyway [10:58] and then I can also iterate [10:59] and instantly try r-deps instead of waiting for publisher [10:59] etc :) [11:02] Is there a bzr branch of console-setup in launchpad that I can branch and find the commit that caused the regression? [11:02] It's Ubuntu-specific, it's not there e.g. in Debian [11:02] apt-cache showsrc console-setup | grep Vcs # or just debcheckout console-setup [11:03] Thanks [11:04] Laney: hi, I've just updated my code for this review (QA tested it). If you're ok with it, I'll push the same changes for 14.04: https://code.launchpad.net/~albertomilone/unity-settings-daemon/non-blocking-touch-mapping-wily/+merge/266248 [11:05] tseliot: ok, will look soon [11:05] thanks [11:05] thanks! [11:18] * pitti moves another 4 transitions to "done" -- this evening after arm64 catches up, http://people.canonical.com/~ubuntu-archive/transitions/html/ ought to fit on one page :) [11:24] pitti: are you tracking the accidental migrations? [11:24] (/me noticed feel++) [11:29] Laney: no, hard to track; thanks, will demote and file an RC bug (after lunch) [11:30] pitti, i think i have actually fixed bonbono-dvd if we care [11:30] apw: oh, even better :) [11:31] upload it [11:31] britney will sort it out [11:37] Meh. Purging and reinstalling console-setup fixes the issue [11:37] So the problem is not in the packaging, it's probably in the code that generates the .isos [11:38] That code is closed-source, isn't it? [11:38] Where would I file a bug report against it? [11:41] alkisg, https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup not closed source :) [11:41] Thanks Oli, checking... [11:41] alkisg, you also want to take a look at livecd-rootfs (that assembles the rootfses) [11:42] (the nusakan branches have equivalents on launchpad) [11:43] (the private/production branch only carrries lists or mail addresses nowadays afaik) [11:44] (nothing relevant for building) === kickinz1|lunch is now known as kickinz1 [11:46] Ah wait it looks like I was wrong, LANG=C apt-get install console-setup ==> broken CHARMAP, LANG=C.UTF-8 apt-get install console-setup ==> UTF-8 CHARMAP [11:46] So a wrong LANG setting at installation (iso generation) time can cause this... [11:47] I think that's best solved in console-setup, to ignore the LANG setting at postinst [11:47] Thanks, I'll file a bug report against it [11:47] (I still don't know at what point the regression started, it's there in 15.04 as well) === _salem is now known as salem_ [12:24] doko, could you comment on the change mentioned on https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1448548? "Only install the openjdk-java.desktop file when using cautious-launcher." ... it makes .java files have no handler in e.g nautilus [12:25] Launchpad bug 1448548 in openjdk-8 (Ubuntu) "OpenJDK 7/8 don't generate .desktop needed by nautilus" [High,Confirmed] [12:25] seb128, I'd like to defer that to jdstrand, mdeslaur, sbeattie. made on their request [12:26] doko, k [12:26] jdstrand, mdeslaur, sbeattie ^ [12:27] mwhudson: actually, CI train service trumps the archive at least for universe packages (what we are largely dealing with) -- 4010 vs. 3270 [12:27] (build score) [12:27] is there a way for deferred package removal? [12:27] so that I can mark a package to be removed later on [12:27] shadeslayer: what should that be? [12:27] a bug report? :-) [12:28] pitti: it's a alternate installer to ubiquity, that needs to remove itself, kind of like how ubiquity-oem marks itself for removal perhaps [12:28] ah, I thought "remove from the archive" [12:28] ah no, from the system [12:28] problem is that the installer is operating in a OEM like mode [12:28] I suppose you could mark it as "automatically installeD", so that apt-get autoremove will clean it up? [12:29] (man apt-mark) [12:29] but IIRC ubiquity has an explicit list of packages that it purges after install [12:30] pitti: the problem is that it loads a plugin to show the "finished" page, that plugin is removed after the package removal step is run, which is before the finished page [12:32] ogra_: how can I file a bug report against ubuntu-cdimage? [12:32] I've filed https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1484101 against console-setup, but I think it should also be solved in the .iso generating code as well [12:32] Launchpad bug 1484101 in console-setup (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,New] [12:33] I.e. when installing packages, it shouldn't be using LANG=C but e.g. C.UTF-8 [12:39] alkisg, https://bugs.launchpad.net/ubuntu-cdimage/+filebug ? [12:39] No items matched "ubuntu-cdimage". [12:39] alkisg, but ubuntu-cdimage doesnt install any packages, it only rolls bootable images out of existing components [12:40] (I'm clicking "also affects project/distribution") [12:40] for the rootfs you want to file against livecd-rootfs ... [12:40] Thanks, searching... [12:42] Yup it does have LANG=C at the top of the BuildLiveCD script [12:42] thats fine [12:43] but the LANG=C in live-build/auto/build is probably not [12:43] BuildLiveCD only sets up the outer-most chroot ... there are multiple chroots in an onion model ... the actual rootfs chroot setup lives in live-build/auto/build [12:51] Done, thank you, fortunately LTS live CDs were not affected [13:11] StevenK, hey, seems like there are no admin atm on the ~bluetooth can you give me access? we would like to re-activate it to maintain bluez&co [13:11] morphis, ^ [13:13] jodh_: I am currently closing segfault bugs for APT, and https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1016040 is assigned to you. Can I close that, it's probably working in recent versions. [13:13] Launchpad bug 1016040 in apt (Ubuntu) "apt_check.py crashed with SIGSEGV in FileName()" [Medium,Confirmed] [13:14] seb128: I've added you, and promoted you to admin and owner. [13:14] pitti, Laney: could you proof-read this draft for u-d-a? http://paste.ubuntu.com/12061573/ [13:14] StevenK, thanks! [13:15] doko: "The majority of the packages" .. actually we rebuilt more than half of them already (but nitpicking) [13:15] doko: erm, I wouldn't recommend that use wily-proposed [13:15] why do you want to do that? [13:15] doko: "brake" -> "break" [13:15] doko: and what Laney said [13:15] we should never ever recommend enabling devel-proposed [13:15] just in schroots [13:16] maybe we should target transitions that touch the desktop though? [13:16] pitti, the majority compared to those already migrated [13:16] I didn't look at the situation there [13:17] doko: maybe add "Relevant FTBFS are tracked on http://pad.ubuntu.com/gcc-5-transition -- help with those is greatly appreciated to unblock library transitions." ? [13:18] http://qa.ubuntuwire.com/ftbfs/ is rather intractable for getting the g++ transitions done IMHO [13:19] Laney, I'm running a wily-proposed desktop, so at least there are no more transitions [13:19] doko: all transitions that touch packages in the desktop need to be finished to get it all to migrate [13:20] that could be a good priority list [13:20] Laney, do you have a list? [13:20] nope [13:22] there's some terrifying thing going on with unity/libsigc++-2.0 [13:22] ? [13:23] Laney, pointers? [13:24] doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt search for libsigc++-2.0 [13:24] it's probably "just" entanglement [13:27] yes, "just" ;) [13:28] * pitti moves 9 more transitions to /finished \o/ [13:30] doko: did you see backscroll about gcc-5 and g++-5 being ginormous due to unstripped binaries? [13:30] /usr/lib/gcc/x86_64-linux-gnu/5/lto1 and /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus are both unstripped [13:30] doko: want a bug report for that? [13:31] pitti, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783876 [13:31] Debian bug 783876 in gcc-5 "gcc-5: consider stripping lto1 / cc1 / cc1plus" [Wishlist,Open] [13:31] infinity: ^ FYI [13:31] doko: ah, thanks; seems quite a regression from -4.9 [13:31] no, intended [13:31] at least for now [13:33] hm, I don't get the talk about plugins etc. not working; we've never had these unstripped so far, are "plugins" a new feature of gcc-5? [13:33] anyway, known, thanks for the pointer [13:33] plugins are not the reason, but the backtraces [13:42] need to at least get libxml2 ready to migrate, and I think boost1.58 too [13:43] Laney, pitti: update at http://paste.ubuntu.com/12061747/ [13:43] boost1.58 and icu already are [13:43] (for unity) [13:43] how did that go in without the transition? [13:44] we forced icu; new soname. and then boost1.58 migrated on its own, as expected === marcusto_ is now known as marcustomlinson [13:48] doko: LGTM now, thanks! [13:54] because boost1.55 still exists, I see [13:54] I can't drill this list down to the qt package which is causing the problem [13:54] * Laney needs food, bbiab [14:00] Hi all === salem_ is now known as _salem === _salem is now known as salem_ [14:02] I search to create and use virtual GPIO for my simulation program [14:02] What is the best way for create virtual gpio device ? Have you another ideas for that ? [14:10] pitti, Laney: could one of you merge debhelper again? [14:10] sure [14:14] infinity: will push http://paste.ubuntu.com/12061910/ for libvirt in a bit === zyga is now known as zyga-afk [14:25] debhelper depends on dpkg-dev (>= 1.18.2~); however: [14:25] Version of dpkg-dev on system is 1.18.1ubuntu1. [14:25] doko: ^ hm, I prepared the merge, but seems we need dpkg first? [14:28] the diff looks simple enough, but I'd at least wait for infinity's "no, I'm doing it" or "it's fine, go ahead" [14:31] * Move the implicit build-essential:native Build-Depends from [14:31] dpkg-checkbuilddeps to a new vendor hook, as it is Debian-specific. [14:31] [14:31] pitti, infinity: does this need extra attention? [14:31] Laney: just to confirm, are you tracking https://launchpadlibrarian.net/214278525/buildlog_ubuntu-wily-amd64.postbooks-updater_2.2.5-9build1_BUILDING.txt.gz and friends? [14:32] doko: ah sorry, I meant diff == "the ubuntu delta", not the substantial diff of dpkg 1.18.1 -> .2 [14:32] doko: can't say, I'm afraid; cjwatson/infinity would know better [14:36] pitti: I'm doing dpkg today. [14:36] infinity: ah, great; I'll test/upload debhelper tmw morning then [14:37] doko: It needs attention, sort of. We can ignore it (the dep was "new" a year ago or so anyway), or we can follow suit for Ubuntu. Haven't decided yet which is less pain. [15:00] infinity: you don't have a time machine and yet you always tell Dustin he's wrong [15:01] kirkland: But if I had a time machine, I could do it *more*, and at more appropriate times. [15:01] kirkland: Like, at birth. [15:01] kirkland: And every day after. [15:01] kirkland: This conversation might be a massive CoC violation. [15:05] pitti: yeah [15:12] infinity, did you see bug 1484101 ? [15:12] bug 1484101 in livecd-rootfs (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,Confirmed] https://launchpad.net/bugs/1484101 [15:12] export LC_ALL=C in live-build/auto/build doesnt sound so clever [15:13] (if we actually want C.UTF-8) [15:19] pitti: could you please score up https://launchpad.net/ubuntu/+source/vtk/5.8.0-17.5ubuntu4/+build/7790378 so that I can do some retries? [15:19] Laney: nudged [15:19] cheers! [15:19] Laney: that's generally a good idea (building dependencies first) to speed up arm64, so please keep pinging [15:22] ogra_: We've done that forever, it's an installer bug if we don't fix console-setup's setup. [15:22] ogra_: That said, I had planned to go all-UTF-8 this cycle if I find the time. [15:24] well, one for cyphermox then :) [15:24] ogra_: Also, I note that bug mentions that touch uses en_US.UTF-8 as a default. Why? [15:24] touch ? [15:24] ./live-build/ubuntu-touch/includes.chroot/etc/default/locale:LANG="en_US.UTF-8" [15:24] ./live-build/ubuntu-touch/hooks/48-setup-env.chroot:LANG=en_US.UTF-8 [15:25] infinity, oh, thats legacy crap that someone from the phone team needs to clean up [15:26] neither of it should be needed ... that stems from the weird OEM builds the phone image originates from [15:26] what updates resolv.conf? [15:26] infinity: what's broken in console-setup? [15:27] it's getting rewritten here, with an empty one [15:27] cyphermox, bug 1484101 [15:27]