| hallyn | infinity: http://paste.ubuntu.com/12059133/ seems to be working, and i think incorporates your suggestions | 03:06 |
|---|---|---|
| infinity | hallyn: ITYM "after 16.04". | 03:08 |
| infinity | hallyn: The unnecessary whitespace change in the init script is gross (tabs versus spaces) if that introduces a delta with Debian. | 03:08 |
| infinity | hallyn: Well, it's gross either way, but worse if it's a delta. :) | 03:09 |
| hallyn | infinity: do I? I thought that so long as 16.04 existed people might be upgrading from something older | 03:09 |
| infinity | hallyn: I think one of us might be confused about the meaning of the word "after"? | 03:09 |
| infinity | hallyn: 16.04 needs to have the upgrade code. 16.10 doesn't. 16.10 is after 16.04. | 03:09 |
| infinity | hallyn: Similar whitespace changes in postinst too. You're good at that. | 03:10 |
| infinity | Or your editor hates your freedom? | 03:10 |
| hallyn | yes when i edit a block i try to make it tab/space-consistent | 03:11 |
| hallyn | maybe i shouldn't, it does complicate the diff | 03:11 |
| infinity | Well, it's particularly bad if this is shared code with Debian. | 03:12 |
| infinity | If it's all your code, meh. | 03:12 |
| hallyn | 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 |
| infinity | hallyn: What does "service libvirt-bin stop" do? Is that going to kill everyone's VMs during the upgrade? | 03:12 |
| infinity | Kinda looks like it will... | 03:13 |
| infinity | Oh, but it won't because the init script was missing that bit before. :) | 03:15 |
| infinity | And the upstart job guards against running stop outside the stop runlevels. | 03:15 |
| infinity | 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:16 |
| infinity | hallyn: The only remaining question is are the the systemd services similarly guarded somehow, or will stopping the systemd service stop all guests? | 03:17 |
| hallyn | infinity: with the systemd jobs, the libvirt-stop-guests is only run right before machined would kill them anyway | 03:31 |
| hallyn | i.e. libvirt-bin stop by itself does not call kill the vms | 03:32 |
| hallyn | but now that you mention it i'm not sure that the sysvinit variant is doing the right thing there... | 03:32 |
| hallyn | 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 |
| hallyn | bc i don't know offhand how to tell in sysvinit jobs what runlevel we're in | 03:33 |
| infinity | hallyn: You can ask it. | 03:39 |
| infinity | hallyn: /sbin/runlevel echoes "X X" for previous and current runlevel. | 03:41 |
| infinity | hallyn: ie "N 2" or whatever. | 03:42 |
| hallyn | meh | 03:48 |
| hallyn | one more thing to break if i do it :) | 03:48 |
| hallyn | all right all righ ti'll do it | 03:48 |
| hallyn | thanks :) | 03:48 |
| pitti | Good morning | 04:02 |
| pitti | hallyn: good! | 04:03 |
| pitti | slangasek: gcc-5 promotion -> \o/ | 04:04 |
| hallyn | infinity: ah, but apparently /sbin/runlevel still says 'N 5' during reboot :) guess it's transitioning *to* 6, but not yet there :) | 04:11 |
| infinity | pitti: Does it seem sane that apt is waiting on autopkgtests for a version of python-apt that has no binaries? | 04:15 |
| pitti | infinity: that's a change from yesterday, see ubuntu-release@ | 04:16 |
| pitti | infinity: it's always a compromise one way or the other :/ | 04:16 |
| infinity | pitti: Yeah, hrm. | 04:16 |
| infinity | Oh well, guess I need to merge the newer apt. | 04:16 |
| pitti | infinity: slangasek responded on the list, I'll respond again | 04:17 |
| pitti | we might be able to fine-tune this a bit | 04:17 |
| pitti | 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:18 |
| pitti | 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 | 04:57 |
| slangasek | 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 |
| pitti | slangasek: I think that's Laney's | 05:34 |
| slangasek | ah | 05:35 |
| slangasek | you're right, it's his color not yours :-) | 05:35 |
| pitti | 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 |
| pitti | or bumping to -proposed | 05:35 |
| slangasek | ok; I think that's better handled by flagging down an archive admin rather than putting it in the pad | 05:36 |
| pitti | we could do the same with bombono-dvd | 05:36 |
| pitti | slangasek: I'm still working on FTBFS, and finishing up transitions; is there anything else/more important you want me to look into? | 05:37 |
| slangasek | no objection to removing bombono-dvd; at the moment I'm just trying to clean up the pad a bit for readability | 05:38 |
| pitti | yeah, I went over it and removed the finished items | 05:38 |
| slangasek | pitti: FTBFS+transitions> I think that will probably keep you busy for at least another day | 05:38 |
| pitti | 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:39 |
| pitti | slangasek: FAOD, http://people.canonical.com/~ubuntu-archive/transitions/html/html/icu.html can be moved to "finished", right? | 05:42 |
| pitti | boost1.55 is itself obsolete, and cg3 is just NBS (new version built fine) | 05:42 |
| infinity | Why the *(&*%! is gcc-5 so huge? | 05:43 |
| infinity | My chroots just doubled in size when I refreshed them. | 05:43 |
| pitti | they might not have purged gcc-4.9 along? | 05:44 |
| infinity | pitti: I did. | 05:44 |
| infinity | pitti: And that really wouldn't account for it anyway. They literally doubled. | 05:44 |
| infinity | armhf went from 118M to 223M. | 05:44 |
| infinity | Okay, not quite, but basically double. | 05:45 |
| infinity | Installed-Size for gcc-5 is 125MB all on its own. | 05:47 |
| infinity | doko: ^-- Is that intentional or a horrible bug? | 05:47 |
| infinity | And 135MB for g++-5 | 05:48 |
| ricotz | leftover debug symbols? | 05:48 |
| pitti | vs. 18 MB for gcc-4.9 | 05:49 |
| infinity | And 30ish for g++-4.9 | 05:49 |
| infinity | So, yeah. A bit of growth there. :P | 05:49 |
| infinity | Oh well. I'll upload these chroots to take pressure off queues, and we can fix this later. | 05:49 |
| pitti | -rwxr-xr-x 1 root root 124324976 Aug 9 15:14 /usr/lib/gcc/x86_64-linux-gnu/5/lto1 | 05:50 |
| pitti | "not stripped" | 05:50 |
| infinity | Hah. | 05:50 |
| infinity | That would certainly do it. | 05:50 |
| infinity | Similar failure for g++? | 05:50 |
| pitti | $ cp /usr/lib/gcc/x86_64-linux-gnu/5/lto1 /tmp/; strip /tmp/lto1; ls -lh /tmp/lto1 | 05:50 |
| pitti | -rwxr-xr-x 1 martin martin 18M Aug 12 07:50 /tmp/lto1 | 05:50 |
| pitti | much nicer :) | 05:51 |
| pitti | -rwxr-xr-x 1 root root 131M Aug 9 15:14 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus | 05:51 |
| pitti | yes, seems so | 05:51 |
| pitti | reduces to 20 MB after stripping | 05:52 |
| infinity | pitti: Can you point those two out to doko when he wakes up so they don't get lost in backscroll? | 05:56 |
| pitti | infinity: ack | 05:56 |
| infinity | pitti: And I'm updating chroots anyway, so no pressure to fix it ASAP (as that'll invalidate the chroots...) | 05:56 |
| * pitti moves 11 more transitions to "finished", yay | 05:58 | |
| infinity | THough, it'll take a good half hour to upload these chubby chroots. | 05:58 |
| infinity | La la la. | 05:58 |
| Bluefoxicy | Hey, here's an idea | 06:45 |
| Bluefoxicy | 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 |
| Bluefoxicy | We could call it "Red Hat Enterprise Linux" | 06:46 |
| darkxst | Bluefoxicy, you would have to call it Fedora, RHEL don't backport new versions, just security fixes | 06:49 |
| Bluefoxicy | darkxst: I'm just venting. | 06:50 |
| Bluefoxicy | RHEL point releases "carry major architectural changes, so you should read the release notes carefully" | 06:51 |
| Bluefoxicy | as a result, when you have RHEL 6, you have... something. | 06:51 |
| Bluefoxicy | They claim RHEL 6 is a stable software distribution--like, say, Ubuntu 12.04 LTS | 06:51 |
| Bluefoxicy | 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 |
| Bluefoxicy | This of course means all support for the prior point release effectively ends | 06:52 |
| Bluefoxicy | 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 |
| Bluefoxicy | 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:53 |
| Bluefoxicy | 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 |
| Bluefoxicy | They pay me to do my job well, not to cover my ass with useless but bureaucratically-placating support contracts. | 06:55 |
| Bluefoxicy | /rant | 06:55 |
| Bluefoxicy | Also, if anyone ever suggests rewriting support policy to favor more major changes on LTS point releases, stab them in the face. | 06:56 |
| dholbach | good morning | 06:57 |
| darkxst | Bluefoxicy, I thought once upon a time, RHEL point releases were opt-in, not automatic | 07:01 |
| Bluefoxicy | 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:05 |
| Bluefoxicy | 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:06 |
| Bluefoxicy | The guy who did this a week before point release is in the same boat, but closer. | 07:07 |
| Bluefoxicy | it's as if you just took the Trusty repositories and shoved the Utopic packages into them. | 07:07 |
| Bluefoxicy | 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:08 |
| Bluefoxicy | 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 |
| darkxst | Bluefoxicy, go find a red hat channel perhaps! | 07:09 |
| Bluefoxicy | ha. | 07:10 |
| Bluefoxicy | YEah I've vented more than I cared to tbh. | 07:10 |
| zyga | doko: ack, thanks | 07:22 |
| zyga | hmmm, is it just me or is debian unstable/sid archive gone? | 07:36 |
| zyga | ah | 07:38 |
| zyga | yeah, I should get a coffee before trying to fix bugs | 07:38 |
| zyga | doko: do you know when debian plans to switch to python 3.5 as default? | 07:42 |
| pitti | Laney: I'm currently going through http://people.canonical.com/~ubuntu-archive/transitions/html/ | 08:12 |
| pitti | Laney: i. e. cleaning up finished transitions, uploading missing rebuilds, noting FTBFSes, and such; pad is up to date | 08:13 |
| Laney | pitti: nice | 08:13 |
| Laney | I'll check up on some others shortly | 08:13 |
| pitti | Laney: I retried some of your FTBFS, but I might have missed smoe | 08:14 |
| Laney | some kind soul retried bpp stuff | 08:14 |
| Laney | \o/ | 08:14 |
| pitti | Laney: yeah, that was part of "going through transitions and try to fix" :) | 08:14 |
| pitti | but only 40% through so far | 08:15 |
| pitti | touch-core: * libtinyxml2-2 # camera/gallery | 08:18 |
| pitti | WTF? | 08:18 |
| pitti | why are we seeding libraries in touch? | 08:18 |
| pitti | sdk-libs: * libjsoncpp0v5 | 08:18 |
| pitti | touch-core: * libzen0 | 08:18 |
| infinity | pitti: Because someone doesn't understand how dependencies work? | 08:18 |
| pitti | my friends, this is wrong | 08:18 |
| infinity | 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 |
| pitti | yes, granted; but in touch-core? | 08:19 |
| infinity | pitti: The touch-core thing is almost certainly someone doing something wrong. | 08:19 |
| pitti | is that because we are working around our own click specification? | 08:19 |
| pitti | i. e. "click packages don't have deb dependencies"? | 08:20 |
| infinity | pitti: Possibly? | 08:20 |
| infinity | (also, ew?) | 08:20 |
| seb128 | pitti, that doesn't have much to do with clicks I think | 08:21 |
| seb128 | rather it's up to define what libs we support as part of the base image | 08:21 |
| seb128 | which is othogonal to click depends | 08:21 |
| pitti | seb128: that should be in sdk-libs, but nowhere else | 08:21 |
| seb128 | right | 08:21 |
| seb128 | just commenting about workarounding clicks | 08:21 |
| pitti | and it says "camera/gallery" which sounds like a really bad workaround | 08:21 |
| seb128 | workaround to what? | 08:22 |
| pitti | it's been there forever apparently | 08:22 |
| seb128 | clicks are not part of the OS | 08:22 |
| seb128 | they can't be what brings a lib in | 08:22 |
| pitti | seb128: to what> well, I don't know -- some broken dependency somewhere, or maybe it's obsolete? | 08:22 |
| pitti | 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 |
| pitti | that what I mean with "working around our own click spec" | 08:23 |
| seb128 | right | 08:23 |
| seb128 | but that doesn't have to do with the spec | 08:23 |
| seb128 | either the lib should be part of the base image | 08:23 |
| seb128 | or they shouldn't use it | 08:23 |
| seb128 | or they should have their own copy | 08:24 |
| pitti | right | 08:24 |
| mwhudson | er is there some way i can see if a package is still tied up in the gcc5 transition? | 08:33 |
| infinity | mwhudson: You might need to expand on that a bit. | 08:35 |
| infinity | mwhudson: A package in proposed? A package you want to upload and you don't know if it'll get stuck? | 08:35 |
| mwhudson | it was a bit gnomic wasn't it | 08:35 |
| mwhudson | 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:35 |
| mwhudson | 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<char, std::char_traits<char>, std::allocator<char> > const&)' | 08:36 |
| mwhudson | which certainly tickes my c++ abi break spider sense | 08:36 |
| mwhudson | and now i see from https://launchpad.net/ubuntu/+source/unity-scopes-api that there is a package in proposed | 08:36 |
| mwhudson | heh i wonder if i'd get more or less brokeness if i enabled proposed as a dep | 08:42 |
| infinity | mwhudson: PPAs that aim to test things for the archive should generally build against proposed anyway. | 08:43 |
| infinity | mwhudson: On the flip side, if things can't build in the release pocket, that's a pretty serious issue. | 08:43 |
| mwhudson | yes i guess that makes sense | 08:43 |
| mwhudson | well the latter point should be easy enough to check | 08:45 |
| mwhudson | oh and blargh i guess i should have copied from the release pocket too | 08:47 |
| mwhudson | no | 08:47 |
| mwhudson | proposed | 08:47 |
| mwhudson | infinity: do you ever sleep? | 08:47 |
| infinity | mwhudson: Sort of. | 08:48 |
| flexiondotorg | 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? | 08:51 |
| pitti | 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 |
| pitti | Laney: do you know a better trick for that? | 09:06 |
| pitti | Laney: a FTBFS bug with "block-proposed" should do | 09:06 |
| * pitti demotes again | 09:09 | |
| Laney | pitti: ah, if their deps are still satisfiable then I have blocked in the past | 09:15 |
| pitti | Laney: ok, will do that from now on | 09:15 |
| pitti | Laney: yeah, they only will stop being satisfiable once the transitinos land | 09:15 |
| Laney | meh, we're racing on these | 09:55 |
| seb128 | flexiondotorg, I'm looking at it, but your sync request doesn't state why the delta is not needed anymore | 09:58 |
| dholbach | can somebody moderate my mail on u-d-a? | 10:04 |
| pitti | looking | 10:05 |
| dholbach | <3 | 10:05 |
| pitti | gern :) | 10:05 |
| === kickinz1 is now known as kickinz1|lunch | ||
| pitti | 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 | |
| pitti | I got through maybe 60% of the transitions, so please check for existing rebuilds before you fire mass-rebuilds | 10:21 |
| Laney | I tried to use the pad to lock transitions but that wasn't really working | 10:21 |
| pitti | ah, I don't have enough horsepower for that | 10:21 |
| pitti | Laney: yeah, I added them this morning, but removed them again as it's too unwieldy | 10:22 |
| pitti | Laney: I usually just click through the package names on a transition page, and ignore the ones which already have rebuilds | 10:22 |
| Laney | the rebuild-fix-sign-upload cycle adds some delays here :P | 10:22 |
| mwhudson | 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 | |
| Laney | we are children of doko | 10:24 |
| pitti | 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 |
| doko | mwhudson, which one? | 10:25 |
| pitti | mwhudson: trust me, we have the same feeling :) | 10:25 |
| mwhudson | doko: https://launchpad.net/~mwhudson/+archive/ubuntu/go15-rc-tests/+packages | 10:25 |
| doko | ci-train is eating all the time, it's not me | 10:25 |
| pitti | mwhudson: this morning 4 out of 5 builders were building PPA stuff | 10:25 |
| mwhudson | yeah, i'm mostly just being silly | 10:26 |
| pitti | anyway, no need for a blame game, we just need to wait | 10:26 |
| mwhudson | and really should go to bed | 10:26 |
| doko | mwhudson, ahh, not just one package. sorry, has to wait | 10:26 |
| pitti | mwhudson: no worries, we all like to joke about it :) good night! | 10:26 |
| mwhudson | obviously builds for the archive trump ppa builds :) | 10:26 |
| doko | bumped golang | 10:26 |
| mwhudson | doko: ah thanks | 10:27 |
| * pitti cancels all queued arm64 builds which are going to FTBFS anyway, to help a bit | 10:27 | |
| Laney | vtk has a broken shlibs file | 10:29 |
| Laney | that'll probably be why all http://people.canonical.com/~ubuntu-archive/transitions/html/vtk-g++5.html failed | 10:30 |
| Laney | at least initially | 10:30 |
| alkisg | 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:42 |
| alkisg | (it breaks non-ascii output in VTs) | 10:43 |
| pitti | apw: please ignore bombono-dvd, I demoted it to -proposed | 10:52 |
| doko | Laney, are you currently looking at vtk? | 10:55 |
| Laney | doko: rebuilding it | 10:56 |
| Laney | locally | 10:56 |
| Laney | will check it can rebuild stuff before uploading | 10:56 |
| Laney | takes a while so don't want to waste buildd time :) | 10:56 |
| pitti | 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 |
| Laney | I can build it faster than they can anyway | 10:58 |
| Laney | and then I can also iterate | 10:58 |
| Laney | and instantly try r-deps instead of waiting for publisher | 10:59 |
| Laney | etc :) | 10:59 |
| alkisg | Is there a bzr branch of console-setup in launchpad that I can branch and find the commit that caused the regression? | 11:02 |
| alkisg | It's Ubuntu-specific, it's not there e.g. in Debian | 11:02 |
| Laney | apt-cache showsrc console-setup | grep Vcs # or just debcheckout console-setup | 11:02 |
| alkisg | Thanks | 11:03 |
| tseliot | 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:04 |
| Laney | tseliot: ok, will look soon | 11:05 |
| tseliot | thanks | 11:05 |
| Laney | thanks! | 11:05 |
| * 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:18 | |
| Laney | pitti: are you tracking the accidental migrations? | 11:24 |
| Laney | (/me noticed feel++) | 11:24 |
| pitti | Laney: no, hard to track; thanks, will demote and file an RC bug (after lunch) | 11:29 |
| apw | pitti, i think i have actually fixed bonbono-dvd if we care | 11:30 |
| pitti | apw: oh, even better :) | 11:30 |
| Laney | upload it | 11:31 |
| Laney | britney will sort it out | 11:31 |
| alkisg | Meh. Purging and reinstalling console-setup fixes the issue | 11:37 |
| alkisg | So the problem is not in the packaging, it's probably in the code that generates the .isos | 11:37 |
| alkisg | That code is closed-source, isn't it? | 11:38 |
| alkisg | Where would I file a bug report against it? | 11:38 |
| ogra_ | alkisg, https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup not closed source :) | 11:41 |
| alkisg | Thanks Oli, checking... | 11:41 |
| ogra_ | alkisg, you also want to take a look at livecd-rootfs (that assembles the rootfses) | 11:41 |
| ogra_ | (the nusakan branches have equivalents on launchpad) | 11:42 |
| ogra_ | (the private/production branch only carrries lists or mail addresses nowadays afaik) | 11:43 |
| ogra_ | (nothing relevant for building) | 11:44 |
| === kickinz1|lunch is now known as kickinz1 | ||
| alkisg | 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 |
| alkisg | So a wrong LANG setting at installation (iso generation) time can cause this... | 11:46 |
| alkisg | I think that's best solved in console-setup, to ignore the LANG setting at postinst | 11:47 |
| alkisg | Thanks, I'll file a bug report against it | 11:47 |
| alkisg | (I still don't know at what point the regression started, it's there in 15.04 as well) | 11:47 |
| === _salem is now known as salem_ | ||
| seb128 | 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:24 |
| ubottu | Launchpad bug 1448548 in openjdk-8 (Ubuntu) "OpenJDK 7/8 don't generate .desktop needed by nautilus" [High,Confirmed] | 12:25 |
| doko | seb128, I'd like to defer that to jdstrand, mdeslaur, sbeattie. made on their request | 12:25 |
| seb128 | doko, k | 12:26 |
| seb128 | jdstrand, mdeslaur, sbeattie ^ | 12:26 |
| pitti | mwhudson: actually, CI train service trumps the archive at least for universe packages (what we are largely dealing with) -- 4010 vs. 3270 | 12:27 |
| pitti | (build score) | 12:27 |
| shadeslayer | is there a way for deferred package removal? | 12:27 |
| shadeslayer | so that I can mark a package to be removed later on | 12:27 |
| pitti | shadeslayer: what should that be? | 12:27 |
| pitti | a bug report? :-) | 12:27 |
| shadeslayer | 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 |
| pitti | ah, I thought "remove from the archive" | 12:28 |
| shadeslayer | ah no, from the system | 12:28 |
| shadeslayer | problem is that the installer is operating in a OEM like mode | 12:28 |
| pitti | I suppose you could mark it as "automatically installeD", so that apt-get autoremove will clean it up? | 12:28 |
| pitti | (man apt-mark) | 12:29 |
| pitti | but IIRC ubiquity has an explicit list of packages that it purges after install | 12:29 |
| shadeslayer | 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:30 |
| alkisg | ogra_: how can I file a bug report against ubuntu-cdimage? | 12:32 |
| alkisg | 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 |
| ubottu | Launchpad bug 1484101 in console-setup (Ubuntu) "Broken CHARMAP with LANG=C on postinst, affects all installations after 14.10" [Undecided,New] | 12:32 |
| alkisg | I.e. when installing packages, it shouldn't be using LANG=C but e.g. C.UTF-8 | 12:33 |
| ogra_ | alkisg, https://bugs.launchpad.net/ubuntu-cdimage/+filebug ? | 12:39 |
| alkisg | No items matched "ubuntu-cdimage". | 12:39 |
| ogra_ | alkisg, but ubuntu-cdimage doesnt install any packages, it only rolls bootable images out of existing components | 12:39 |
| alkisg | (I'm clicking "also affects project/distribution") | 12:40 |
| ogra_ | for the rootfs you want to file against livecd-rootfs ... | 12:40 |
| alkisg | Thanks, searching... | 12:40 |
| alkisg | Yup it does have LANG=C at the top of the BuildLiveCD script | 12:42 |
| ogra_ | thats fine | 12:42 |
| ogra_ | but the LANG=C in live-build/auto/build is probably not | 12:43 |
| ogra_ | 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:43 |
| alkisg | Done, thank you, fortunately LTS live CDs were not affected | 12:51 |
| seb128 | 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 |
| seb128 | morphis, ^ | 13:11 |
| juliank | 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 |
| ubottu | Launchpad bug 1016040 in apt (Ubuntu) "apt_check.py crashed with SIGSEGV in FileName()" [Medium,Confirmed] | 13:13 |
| StevenK | seb128: I've added you, and promoted you to admin and owner. | 13:14 |
| doko | pitti, Laney: could you proof-read this draft for u-d-a? http://paste.ubuntu.com/12061573/ | 13:14 |
| seb128 | StevenK, thanks! | 13:14 |
| pitti | doko: "The majority of the packages" .. actually we rebuilt more than half of them already (but nitpicking) | 13:15 |
| Laney | doko: erm, I wouldn't recommend that use wily-proposed | 13:15 |
| Laney | why do you want to do that? | 13:15 |
| pitti | doko: "brake" -> "break" | 13:15 |
| pitti | doko: and what Laney said | 13:15 |
| pitti | we should never ever recommend enabling devel-proposed | 13:15 |
| pitti | just in schroots | 13:15 |
| Laney | maybe we should target transitions that touch the desktop though? | 13:16 |
| doko | pitti, the majority compared to those already migrated | 13:16 |
| Laney | I didn't look at the situation there | 13:16 |
| pitti | 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:17 |
| pitti | http://qa.ubuntuwire.com/ftbfs/ is rather intractable for getting the g++ transitions done IMHO | 13:18 |
| doko | Laney, I'm running a wily-proposed desktop, so at least there are no more transitions | 13:19 |
| Laney | doko: all transitions that touch packages in the desktop need to be finished to get it all to migrate | 13:19 |
| Laney | that could be a good priority list | 13:20 |
| doko | Laney, do you have a list? | 13:20 |
| Laney | nope | 13:20 |
| Laney | there's some terrifying thing going on with unity/libsigc++-2.0 | 13:22 |
| doko | ? | 13:22 |
| doko | Laney, pointers? | 13:23 |
| Laney | doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt search for libsigc++-2.0 | 13:24 |
| Laney | it's probably "just" entanglement | 13:24 |
| doko | yes, "just" ;) | 13:27 |
| * pitti moves 9 more transitions to /finished \o/ | 13:28 | |
| pitti | doko: did you see backscroll about gcc-5 and g++-5 being ginormous due to unstripped binaries? | 13:30 |
| pitti | /usr/lib/gcc/x86_64-linux-gnu/5/lto1 and /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus are both unstripped | 13:30 |
| pitti | doko: want a bug report for that? | 13:30 |
| doko | pitti, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783876 | 13:31 |
| ubottu | Debian bug 783876 in gcc-5 "gcc-5: consider stripping lto1 / cc1 / cc1plus" [Wishlist,Open] | 13:31 |
| pitti | infinity: ^ FYI | 13:31 |
| pitti | doko: ah, thanks; seems quite a regression from -4.9 | 13:31 |
| doko | no, intended | 13:31 |
| doko | at least for now | 13:31 |
| pitti | 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 |
| pitti | anyway, known, thanks for the pointer | 13:33 |
| doko | plugins are not the reason, but the backtraces | 13:33 |
| Laney | need to at least get libxml2 ready to migrate, and I think boost1.58 too | 13:42 |
| doko | Laney, pitti: update at http://paste.ubuntu.com/12061747/ | 13:43 |
| doko | boost1.58 and icu already are | 13:43 |
| Laney | (for unity) | 13:43 |
| Laney | how did that go in without the transition? | 13:43 |
| doko | we forced icu; new soname. and then boost1.58 migrated on its own, as expected | 13:44 |
| === marcusto_ is now known as marcustomlinson | ||
| pitti | doko: LGTM now, thanks! | 13:48 |
| Laney | because boost1.55 still exists, I see | 13:54 |
| Laney | I can't drill this list down to the qt package which is causing the problem | 13:54 |
| * Laney needs food, bbiab | 13:54 | |
| AkrogAmes | Hi all | 14:00 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| AkrogAmes | I search to create and use virtual GPIO for my simulation program | 14:02 |
| AkrogAmes | What is the best way for create virtual gpio device ? Have you another ideas for that ? | 14:02 |
| doko | pitti, Laney: could one of you merge debhelper again? | 14:10 |
| pitti | sure | 14:10 |
| hallyn | infinity: will push http://paste.ubuntu.com/12061910/ for libvirt in a bit | 14:14 |
| === zyga is now known as zyga-afk | ||
| pitti | debhelper depends on dpkg-dev (>= 1.18.2~); however: | 14:25 |
| pitti | Version of dpkg-dev on system is 1.18.1ubuntu1. | 14:25 |
| pitti | doko: ^ hm, I prepared the merge, but seems we need dpkg first? | 14:25 |
| pitti | 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:28 |
| doko | * Move the implicit build-essential:native Build-Depends from | 14:31 |
| doko | dpkg-checkbuilddeps to a new vendor hook, as it is Debian-specific. | 14:31 |
| doko | 14:31 | |
| doko | pitti, infinity: does this need extra attention? | 14:31 |
| pitti | 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:31 |
| pitti | doko: ah sorry, I meant diff == "the ubuntu delta", not the substantial diff of dpkg 1.18.1 -> .2 | 14:32 |
| pitti | doko: can't say, I'm afraid; cjwatson/infinity would know better | 14:32 |
| infinity | pitti: I'm doing dpkg today. | 14:36 |
| pitti | infinity: ah, great; I'll test/upload debhelper tmw morning then | 14:36 |
| infinity | 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. | 14:37 |
| kirkland | infinity: you don't have a time machine and yet you always tell Dustin he's wrong | 15:00 |
| infinity | kirkland: But if I had a time machine, I could do it *more*, and at more appropriate times. | 15:01 |
| infinity | kirkland: Like, at birth. | 15:01 |
| infinity | kirkland: And every day after. | 15:01 |
| infinity | kirkland: This conversation might be a massive CoC violation. | 15:01 |
| Laney | pitti: yeah | 15:05 |
| ogra_ | infinity, did you see bug 1484101 ? | 15:12 |
| ubottu | 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 |
| ogra_ | export LC_ALL=C in live-build/auto/build doesnt sound so clever | 15:12 |
| ogra_ | (if we actually want C.UTF-8) | 15:13 |
| Laney | 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 |
| pitti | Laney: nudged | 15:19 |
| Laney | cheers! | 15:19 |
| pitti | Laney: that's generally a good idea (building dependencies first) to speed up arm64, so please keep pinging | 15:19 |
| infinity | ogra_: We've done that forever, it's an installer bug if we don't fix console-setup's setup. | 15:22 |
| infinity | ogra_: That said, I had planned to go all-UTF-8 this cycle if I find the time. | 15:22 |
| ogra_ | well, one for cyphermox then :) | 15:24 |
| infinity | ogra_: Also, I note that bug mentions that touch uses en_US.UTF-8 as a default. Why? | 15:24 |
| ogra_ | touch ? | 15:24 |
| infinity | ./live-build/ubuntu-touch/includes.chroot/etc/default/locale:LANG="en_US.UTF-8" | 15:24 |
| infinity | ./live-build/ubuntu-touch/hooks/48-setup-env.chroot:LANG=en_US.UTF-8 | 15:24 |
| ogra_ | infinity, oh, thats legacy crap that someone from the phone team needs to clean up | 15:25 |
| ogra_ | neither of it should be needed ... that stems from the weird OEM builds the phone image originates from | 15:26 |
| tjaalton | what updates resolv.conf? | 15:26 |
| cyphermox | infinity: what's broken in console-setup? | 15:26 |
| tjaalton | it's getting rewritten here, with an empty one | 15:27 |
| ogra_ | cyphermox, bug 1484101 | 15:27 |
| ubottu | 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:27 |
| ogra_ | cyphermox, alkisg just reported it | 15:27 |
| pitti | tjaalton: resolvconf updates /run/resolvconf/resolv.conf and /etc/resolv.conf sohudl be a symlink to that | 15:27 |
| pitti | tjaalton: and resolvconf is called from /etc/dhcp/dhclient-enter-hooks.d/resolvconf | 15:27 |
| pitti | tjaalton: and from /etc/network/if-up.d/000resolvconf too (for ifupdown) | 15:28 |
| tjaalton | pitti: yeah, ifup br0 is sets it up fine, then a few minutes later it's rewritten | 15:28 |
| pitti | tjaalton: by openvpn possibly? | 15:28 |
| cyphermox | infinity: ah, I see | 15:28 |
| Laney | pitti: maybe https://launchpad.net/ubuntu/+source/postbooks/4.7.0-3build1/+build/7790500 too then | 15:28 |
| Laney | thanks | 15:28 |
| tjaalton | pitti: when I use it yes, but not on this machine | 15:28 |
| pitti | Laney: got it a 1st class build ticket too :) | 15:29 |
| cyphermox | where do we default to C though? the installer should mostly get you things right unless you go out of your way to pick or preseed C | 15:29 |
| cyphermox | (IIRC) | 15:29 |
| tjaalton | pitti: anyway, I'll keep poking at it, must be something transient | 15:29 |
| infinity | cyphermox: We default to C when building the rootfs, and the installer doesn't fix console-setup's setup to match the locale being installed for. | 15:29 |
| ogra_ | cyphermox, well, the build defaults to C ... but the installer should reconfigure | 15:29 |
| cyphermox | ok | 15:30 |
| cyphermox | maybe I can find the time to fix for ubuntu and debian next week :) | 15:30 |
| infinity | cyphermox: So, two bugs there (maybe three). 1) livecd-rootfs should probably have a saner default for people building raw rootfses that don't use installers (like snappy), 2) real installers (d-i, ubiquity, etc) should dpkg-reconfigure console-setup (or similar) under the right locale to get the right setup, and (maybe) 3) console-setup's postinst might be dumb. | 15:31 |
| cyphermox | yeah, a bit of 2 and 3 | 15:31 |
| cyphermox | 1 is up to you :) | 15:31 |
| infinity | cyphermox: Yeah, (1) will be part of my blanket s/C/C.UTF-8/ across the world of buildds, d-i, base system, etc. | 15:33 |
| cyphermox | ok | 15:33 |
| cyphermox | fwiw I just installed a trusty ppc64el vm with the mini iso and I got UTF-8 ;) | 15:34 |
| cyphermox | that was explicitly without a rootfs though | 15:34 |
| ogra_ | well, thats plain d-i | 15:34 |
| cyphermox | right | 15:34 |
| ogra_ | not using the rootfs from livecd-rootfs | 15:35 |
| cyphermox | now for servers and desktop we mostly copy a rootfs | 15:35 |
| cyphermox | correct | 15:35 |
| ogra_ | and d-i most likely sets C.UTF-8 which makes console-setup DTRT from the start | 15:35 |
| alkisg | cyphermox: trusty didn't have this issue because the older console-setup version didn't care about LANG | 15:36 |
| alkisg | Now I think it's trying to be more clever, and ends up to ISO-8859-15 because livecd-rootfs sets LANG=C | 15:37 |
| ogra_ | not clever enough ;) | 15:38 |
| cyphermox | alkisg: I'm pretty sure a straight d-i install with mini.iso would do the same on later releases too | 15:38 |
| cyphermox | hell, let me try the fix right now :) | 15:38 |
| ogra_ | heh | 15:38 |
| alkisg | cyphermox: the .iso contents of all releases after 14.04 that I saw, had ISO-8859-15 in filesystem.squashfs | 15:39 |
| ogra_ | thats finne | 15:39 |
| alkisg | I don't know if mini.iso has console-setup preinstalled | 15:39 |
| ogra_ | what isnt fine is that the installer doesnt recobfigure it | 15:39 |
| alkisg | ogra_: it's not fine, we can't use the VTs in the live CDs | 15:39 |
| ogra_ | and mini.iso installs package per package ... | 15:40 |
| cyphermox | alkisg: it doesn't ship a squashfs at all; so things get installed separately | 15:40 |
| ogra_ | and likely hardcodes C.UTF-8 | 15:40 |
| cyphermox | ogra_: nah, you get to pick which you want | 15:40 |
| ogra_ | alkisg, you use the raw rootfs without installation ? | 15:40 |
| alkisg | cyphermox: then it depends on the LANG setting when `apt-get install console-setup` is executed | 15:40 |
| * cyphermox zsyncs latest server image | 15:40 | |
| ogra_ | cyphermox, is plain "C" even in the list ? | 15:40 |
| cyphermox | ogra_: yeah, I think it is | 15:40 |
| alkisg | ogra_: you mean that casper should reconfigure it on boot? But why should it be broken in the first place? | 15:41 |
| cyphermox | somewhere out of the way though | 15:41 |
| ogra_ | alkisg, the point is that it doesnt matter whats in the rootfs ... the installer *must* reconfigure it properly | 15:41 |
| alkisg | E.g. suppose that I want an initramfs shell, why should it be broken there, and fixed later on on boot... | 15:41 |
| ogra_ | the rootfs part is mostly cosmetic | 15:41 |
| ogra_ | (we should indeed clean the rootfs side too ... but the bug is in the installer) | 15:42 |
| cyphermox | ogra_: well, the bug is in both. console-setup shouldn't necessarily have to go back and reconfigure itself just to be extra sure things are correct | 15:42 |
| ogra_ | cyphermox, well, it should ... since the installer allows you to select a language it has to | 15:43 |
| alkisg | I don't know why anyone wouldn't use UTF-8 in the console | 15:44 |
| alkisg | (as the CHARMAP, not as the CODESET) | 15:44 |
| ogra_ | yeah, the ISO charsets should just be wiped from the face of the earth | 15:44 |
| cyphermox | ogra_: it already does some amounts of magic to get you the correct /etc/default/keyboard | 15:44 |
| ogra_ | yep | 15:45 |
| infinity | alkisg: So, we're slowly converging on a world where most people think UTF-8 is basically okay, but you're wrong in assuming it's right for EVERYONE. | 15:45 |
| infinity | A proper installer will check the locale the user asked for and reconfigure anything that needs reconfiguring. | 15:45 |
| seb128 | @pilot in | 15:45 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -&gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 | ||
| infinity | If that includes a boot menu locale selection leading to reconfiguring early terminals, so be it, though that sounds scary hard to get right. | 15:46 |
| alkisg | infinity: setupcon has been broken in ubuntu for about 6 years now | 15:48 |
| Laney | Can I tell apt to use some random Packages file that I give it as its brain state? | 15:48 |
| * dholbach hugs seb128 | 15:48 | |
| seb128 | dholbach, :-) | 15:48 |
| alkisg | It's not called at boot, it doesn't apply the fonts unless someone calls it manually | 15:48 |
| Laney | I want to write something to come up with the state that britney is trying to mutate the archive to that I can then give to apt in order to get some intelligible output | 15:49 |
| alkisg | UTF-8 was hardcoded in console-setup.postinst afaik | 15:49 |
| infinity | Laney: You can reconfigure the Etc root. | 15:49 |
| alkisg | Sure advanced menus are fine, but I think the basics should be taken cared of first ... | 15:49 |
| infinity | alkisg: No one's arguing with you that defaults could and should be better. | 15:50 |
| cyphermox | alkisg: did you file bugs for each of these particular issues? that way I (or someone else) can get to them and fix them | 15:50 |
| infinity | alkisg: But sometimes bugs lead to these things called "discussions", where we do this thing called "exploring possible solutions". Don't take it as a personal insult about the validity of your bug, or a prompt for you to keep arguing the point. | 15:51 |
| cyphermox | I'm looking into reconfiguring console-setup right now | 15:51 |
| alkisg | cyphermox: about setupcon, I think I've filed 2 bugs, 6 and 4 years ago... | 15:51 |
| ogra_ | cyphermox, only the one i pointed to you | 15:51 |
| ogra_ | lol | 15:51 |
| cyphermox | alkisg: ok, if you tell me which ones those are, I'll look when I have a bit of time | 15:51 |
| ogra_ | alkisg, none in bugzilla ? | 15:51 |
| alkisg | ogra_, in launchpad | 15:52 |
| ogra_ | (that we used before launchpad :) ) | 15:52 |
| alkisg | Haha | 15:52 |
| ogra_ | :) | 15:52 |
| alkisg | I think they'll be closed now, EOL etc | 15:52 |
| arges | cyphermox: the upload for bug 1481780 looks a little messed up. i see two patches unaccounted for can you confirm and I'll reject | 15:52 |
| ubottu | bug 1481780 in ipmitool (Ubuntu Vivid) "ipmitool 1.8.13 needs 2 patches for OpenPower systems" [High,In progress] https://launchpad.net/bugs/1481780 | 15:52 |
| Laney | infinity: Yeah. Maybe I can just make a sources.list that points to this or something. | 15:53 |
| alkisg | cyphermox: here's one: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/133072 comments #20 - #24 are mine | 15:54 |
| ubottu | Launchpad bug 133072 in console-setup (Ubuntu) "tty console doen't show characters with accent" [Medium,Fix released] | 15:54 |
| alkisg | Someone marked it fix released but it's still broken | 15:54 |
| cyphermox | arges: yes, please reject I screwed up | 15:54 |
| arges | cyphermox: ack | 15:54 |
| pitti | Laney, infinity: FYI: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration | 15:55 |
| infinity | pitti: Does some useful group (like ubuntu-archive) have access to wendigo, or are those commands just there in case we need to ask a GSA to drive? | 15:57 |
| pitti | rod-ues-proposed-migration:x:2997:pitti,adconrad,vorlon,stgraber,laney | 15:57 |
| pitti | infinity: it's the Canonical persons in ~ubuntu-release (by intent, I hope it's reasonably correct) | 15:57 |
| infinity | pitti: Mmkay. | 15:57 |
| Laney | good old rod | 15:57 |
| pitti | infinity: retrying tests requires snakefruit ubuntu-archive access, that's a larger group | 15:58 |
| infinity | pitti: ubuntu-archive should be a smaller group, the largeness of it is a bug. :P | 15:58 |
| infinity | A bug we should fix. | 15:58 |
| pitti | Laney: oh, now I get it | 15:58 |
| infinity | ASAFP. | 15:58 |
| pitti | it's of course "p"rod | 15:58 |
| Laney | :) | 15:58 |
| infinity | Because people in that UNIX group have way more power than they should. | 15:58 |
| Laney | Don't fix it | 15:58 |
| Laney | You'll fix me out of it | 15:59 |
| pitti | ubuntu_archive:x:2552:cjwatson,seb128,doko,pitti,adconrad,vorlon,didrocks,stgraber,laney | 15:59 |
| infinity | Yeah, actually, it's not as bad as I remember. | 16:00 |
| === alkisg is now known as work_alkisg | ||
| infinity | Though it does suspiciously have that one person who isn't an AA. :) | 16:00 |
| infinity | Laney: Should we do formal AA training and make you part of the team some day, so you're not bypassing community governance with your Canonical machine creds? | 16:01 |
| Laney | infinity: That'd be nice | 16:01 |
| infinity | Laney: Cause you have literally carte blanche in the archive from that UNIX account, which makes me uneasy as a community member. | 16:01 |
| pitti | Laney: I retried the vtk rebuilds, but many of them still fail due to uninstallability :/ | 16:03 |
| pitti | I just moved three more transitions to /finished | 16:04 |
| pitti | $ bzr diff -r 278..|grep 'renamed'|wc -l47 | 16:04 |
| pitti | 47 transitions done, not bad for a day! | 16:04 |
| pitti | and with that, good night everyone! | 16:05 |
| Laney | infinity: Let's do it when we're free | 16:05 |
| Laney | Shame no Debconf eh | 16:05 |
| Laney | see you pitti! | 16:05 |
| infinity | Laney: Yeah, conflicted with Plumbers. Someone didn't plan that out well. | 16:05 |
| infinity | pitti: 'Night! | 16:05 |
| Laney | man | 16:55 |
| Laney | writing that script was a good use of time | 16:55 |
| slangasek | pitti: are you beige on http://pad.ubuntu.com/gcc-5-transition ? | 16:58 |
| slangasek | pitti: someone wrote that asterisk blocks the jack transition; there is no jack transition | 16:58 |
| Laney | So looks like strigi qtdeclarative-opensource-src kde-runtime would be good to get passing excuses | 17:01 |
| Laney | that's from analysing a few packages broken by trying to migrate the big libsigc++-2.0 block | 17:03 |
| Laney | (which contains unity) | 17:03 |
| slangasek | Laney: I hadn't triggered rebuilds for strigi because the list of library dependencies was long and hairy, and also because I started to second-guess myself because KDE | 17:05 |
| slangasek | I'd love to have confirmation that this is actually an ABI change for strigi and we should push ahead | 17:05 |
| Laney | Ah, I didn't look if they were themselves transitions | 17:05 |
| Laney | but: https://packages.qa.debian.org/s/strigi/news/20150808T100114Z.html looks good | 17:06 |
| slangasek | pitti: I see you did rebuilds for voms (libvomsapi1) but you seem to have missed lcmaps-plugins-voms, not sure if you're using a script that you're debugging | 17:06 |
| slangasek | Laney: check | 17:06 |
| slangasek | triggering rebuilds now for strigi | 17:06 |
| infinity | slangasek: How closely do you watch build times on some of your uploads? | 17:06 |
| infinity | slangasek: Curious if you've noticed things that appear to be mutex-heavy being crazy slow on arm64? | 17:07 |
| slangasek | infinity: not very, why? | 17:07 |
| Laney | I'll make my dear-update-output-what-are-you-really-telling-me script usable by others tomorrow | 17:07 |
| slangasek | infinity: I've noticed arm64 being the long pole, that's all | 17:07 |
| * infinity is trying to decide if tbb is a flaming heap or if there's a nasty toolchain/glibc/kernel bug at play here. | 17:07 | |
| slangasek | infinity: ah. I haven't in general noticed arm64 being orders of magnitude slower than others if that's what you mean, just delayed | 17:07 |
| infinity | slangasek: Sure, arm64 lags just for resource reasons. Slower CPU than PPC, fewer builders than everyone else, very slow I/O. | 17:08 |
| infinity | slangasek: But, yeah, check tbb, the build times are insanely bad on arm64. And it's all in those mutex tests. | 17:08 |
| infinity | It almost made me go hunting for glibc bugs at 5am, but I figured I'd wasted enough of my life on two packages. | 17:08 |
| slangasek | infinity: robru had noted yesterday that the previous successful build on arm64 (before the buildd timeout) was also long, ~4x the other archs IIRC | 17:09 |
| slangasek | there may be an underlying bug, but tbb is the only thing I've heard affected | 17:09 |
| infinity | slangasek: Yeah. Tres weird. Maybe I'll revive my carefactor later and throw a debugger or profiler at it. For now, I'll chalk it up to tbb being crap. | 17:10 |
| infinity | slangasek: At least it's fixed on PPC. :P | 17:10 |
| * infinity goes to find more caffeine to keep his caffeine company. | 17:11 | |
| === juliank0 is now known as juliank | ||
| slangasek | Laney: kdegraphics-mobipocket ftbfs (strigi) | 17:16 |
| seb128 | @pilot out | 17:25 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -&gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| ochosi | doko: hi! | 17:28 |
| ochosi | doko: just quickly wanted to check whether we pinged the right person last night and whether the libreoffice patch would be generally acceptable | 17:30 |
| * hallyn ponders where he might find some caffeine | 17:33 | |
| * ochosi guesses a café might be the place to go to | 17:33 | |
| doko | ochosi, sorry, please ask SweetShark. seb128 might be able to help as well | 17:34 |
| hallyn | none near here. maybe the snackshop | 17:34 |
| ochosi | doko: thanks will do! | 17:34 |
| ochosi | doko: sorry if we pinged the wrong person, just saw you're on the LO packaging team ;) | 17:34 |
| doko | for historical reasons, yes | 17:35 |
| ochosi | okeydokey! | 17:36 |
| ochosi | thanks for the heads up | 17:36 |
| robru | infinity: oh you got tbb working? can you show me the final diff on that for educational purposes? | 17:36 |
| doko | robru, you can see that diff in lp ... | 17:39 |
| doko | not showing myself for educational purposes ;-P | 17:39 |
| robru | heh | 17:41 |
| robru | not awake yet | 17:41 |
| seb128 | ochosi, Bjoern is on holidays, but ask on #ubuntu-desktop tomorrow on european working on hours (or try now but I'm about to call it a day and I'm unsure who is still around) | 17:46 |
| doko | robru, https://launchpad.net/ubuntu/+source/<source package> | 17:51 |
| robru | doko: thanks | 17:52 |
| infinity | robru: The tbb and openvdb diffs should both be more or less self-explanatory, I hope. | 18:03 |
| infinity | robru: Though I note that I didn't mention dropping the crap patch in debian/changelog. So, do as I say, not as I do in that case. :P | 18:03 |
| doko | pitti, http://autopkgtest.ubuntu.com/packages/k/kservice/wily/i386/ is this an installation error? | 18:03 |
| robru | infinity: well, it's the sort of thing that makes sense when I read it, but I have no idea how you got there from where I left it off | 18:04 |
| infinity | robru: Making sense when you read it is a good first step. I don't know how you best learn, but for me, it's by watching "smarter" people be smart until I absorb it. | 18:07 |
| infinity | robru: When I first decided I wanted to transition from a Debian user to a Debian contributor, I subscribed to debian-bugs-dist (I don't recommend this) and just watched people argue about bugs and iterate on fixes until patterns emerged and I realised most of this isn't really hard, it's just about seeing the same damned bug 700 times in a row. | 18:08 |
| ubottu | bug 700 in boa-constructor (Ubuntu) "After installing Boa Constructor, no menu items in Gnome" [Medium,Fix released] https://launchpad.net/bugs/700 | 18:08 |
| infinity | ubottu: Thanks, that was super helpful. | 18:08 |
| ubottu | infinity: I am only a bot, please don't think I'm intelligent :) | 18:08 |
| robru | lol | 18:09 |
| robru | infinity: that seems a reasonable approach, I'm more of a learn-by-doer, it's best if somebody stands over my shoulder and tells me what to do until I get the hang of it | 18:10 |
| infinity | robru: Are you inviting me to come visit and loom over you while you type? | 18:10 |
| infinity | robru: You're in Vancouver, right? I could use a vacation on the coast. | 18:11 |
| robru | infinity: I wouldn't say no | 18:11 |
| robru | infinity: even better: Victoria! | 18:11 |
| infinity | FSVO "better"... | 18:11 |
| infinity | I guess you're only a ferry away from a real city. | 18:11 |
| robru | infinity: more actual ocean & mountains, less obnoxious big city noise | 18:11 |
| infinity | robru: I live for city noise. :) | 18:12 |
| robru | infinity: I'll have you know I only live in capital cities. First Edmonton, then Winnipeg, now Victoria. Vancouver never had a chance! | 18:12 |
| infinity | Can't sleep without the soothing sounds of dumpsters being emptied at 4am. | 18:12 |
| robru | yeah... | 18:12 |
| infinity | (I'm not actually joking, I've lived in CBDs so long that life without that background noise is unsettling) | 18:13 |
| robru | CBDs? | 18:15 |
| mterry | doko, poke about some gccxml/gcc5 issues that I'm looking at, if you have time | 18:15 |
| mterry | doko, I will explain here and you can get back to me when you have time | 18:16 |
| infinity | robru: Central Business District. Generally known in most of North America as "downtown", despite that only making sense in Manhattan. | 18:16 |
| doko | mterry, this is now replaced by castxml | 18:16 |
| mterry | doko, yup, and that's causing some problems for me | 18:17 |
| doko | ouch | 18:17 |
| robru | ah | 18:17 |
| mterry | doko, I'm trying to build activiz.net. Which calls gccxml, which now calls castxml. Then uses cableswig to consume the xml. | 18:17 |
| mterry | doko, unfortunately, castxml seems to be writing slightly different xml than gccxml (namely, it's leaving off some 'name=' attributes). cableswig errors out if certain types of elements don't have name= attributes | 18:18 |
| mterry | doko, having castxml always write out a name attribute, even if just name="" seems to get activiz.net building... | 18:18 |
| mterry | doko, but I'm not sure if that's really the best thing :) | 18:19 |
| mterry | doko, maybe alternative would be making cableswig less strict? But I don't know if breaking that assumption would mess other things up, or maybe that's actually a valid level of strictness and castxml is in the wrong | 18:19 |
| mterry | This is not my area of expertise | 18:19 |
| doko | mterry, debian-med packages aren't my expertise either ... can we just demote that to -proposed ? | 18:25 |
| mterry | doko, you mean take it out of the release pocket? So it wouldn't block migrations? | 18:28 |
| doko | yes | 18:30 |
| mterry | The chain I know about is activiz.net -> gdcm -> insighttoolkit4 -> plastimatch. Maybe there are other packages. But *I* don't care about those being in release pocket. But I'm not familiar with how important they might be | 18:30 |
| doko | argh | 18:31 |
| mterry | I take it from your argh that those are packages we want to remain in release? | 18:32 |
| doko | hmm, no. but all these packages are marked for autoremoval in testing | 18:34 |
| doko | and the maintainer apparently at debcamp uploading again new packages instead of fixing his existing ones | 18:34 |
| mterry | doko, yeah, looks like a sizeable bubble of packages, but all in that debian-med universe. Seemingly not terrible to demote. so what's the process for demoting? | 18:39 |
| mterry | doko, alternatively, I could land a patch to castxml that inserts empty name attributes instead of leaving them off... | 18:39 |
| mterry | Seems hacky though | 18:40 |
| doko | mterry, file a bug, add tasks for all involved packages, make sure there are no other rdeps, and add th block-proposed tag. then wait for an archive admin | 18:40 |
| mterry | doko, paperwork! :) OK, will chase exact list of rdeps | 18:41 |
| doko | the bug needs to be there, or else the package will migrate again | 18:42 |
| mterry | doko, yeah makes sense | 18:42 |
| mterry | doko, subscribing archive team is enough to get their notice in this case? | 18:43 |
| mterry | doko, also... is there a fancy way to get all recursive rdeps, besides using reverse-depends a bunch? | 18:44 |
| * mterry writes a tiny script | 18:45 | |
| doko | mterry, everse-depends src:activiz.net and everse-depends -b src:activiz.net | 18:46 |
| mterry | yeah, but then I have to recurse | 18:47 |
| doko | ahh | 18:47 |
| doko | no, don't know one | 18:47 |
| mterry | (also, it would be nice to not have to run twice, to say -b and -normal) | 18:47 |
| slangasek | who's copying packages from wily to wily-proposed? pitti? | 18:54 |
| slangasek | (crystalspace) | 18:54 |
| slangasek | pitti: would you please leave the FTBFS package in wily-proposed and delete the package from wily instead? | 18:55 |
| slangasek | the current approach leaves the packages in -proposed on the tracker, and makes it harder to script an upload (since 'build1' is already taken) | 18:56 |
| doko | slangasek, hmm, I assume the same would hapen when use demote-to-proposed? | 18:57 |
| slangasek | oh, there's a script for that? maybe that's the problem yes | 18:58 |
| slangasek | but if the package is already *in* proposed, we should remove-package -s wily, not remove-package -s wily-proposed + demote-to-proposed | 18:58 |
| infinity | slangasek, doko: demote-to-proposed does no version checking, it just copies from release to proposed, and deletes from release. There's no conscious "deleting from proposed" going on here, just copying over it. | 19:12 |
| infinity | slangasek, doko: Arguably a bug in the script that it doesn't at least warn and prompt when you're about to downgrade (patches welcome), but currently the onus is on the user to know what they're doing. | 19:13 |
| slangasek | ok | 19:13 |
| slangasek | I would say that demote-to-proposed is not the right tool in this circumstance then | 19:14 |
| infinity | No, if there's a higher version in proposed already, the correct tool is remove-package. | 19:14 |
| infinity | demotion only makes sense if the release version is broken and there's no proposed version. | 19:14 |
| infinity | One could turn demote-to-proposed into the catch-all tool for this by adding a version check with a "would you like to just delete the release version, then?" prompt. | 19:15 |
| === jincreator1 is now known as jincreator | ||
| mterry | doko, ok filed bug 1484258. Think it's right | 19:43 |
| ubottu | bug 1484258 in vtk-dicom (Ubuntu) "Demote activiz.net and friends to proposed (from release)" [Undecided,New] https://launchpad.net/bugs/1484258 | 19:43 |
| mterry | infinity, ^ is that right process? new to demoting/removing-from-release | 19:46 |
| infinity | mterry: Do any of those exist in -proposed at higher versions? | 19:47 |
| slangasek | tyhicks: I'm looking to merge new audit, and I see that you have a delta to drop the build-dep on libwrap. Is that really needed, given that libwrap is in main? | 19:48 |
| slangasek | tyhicks: (seems to be a no-op change, so I'd rather reduce the delta) | 19:48 |
| tyhicks | slangasek: we build our audit differently due to not wanting auditd to have networking capabilities | 20:00 |
| tyhicks | slangasek: it has been long enough since I brough audit into main that I've forgotten if libwrap was part of that | 20:00 |
| * tyhicks takes a quick look | 20:01 | |
| slangasek | tyhicks: ok. I checked and libwrap is in main, so it's just an inert build-dep | 20:01 |
| tyhicks | slangasek: ok, then you can add the --with-libwrap and corresponding Build-Depends back in but the --disable-listener delta needs to stay | 20:02 |
| infinity | No need for libwrap if you're disabling TCP connections. | 20:02 |
| tyhicks | right | 20:02 |
| tyhicks | which is why I removed it | 20:02 |
| mterry | infinity, yes. Some have rebuilds, some have imported new versions from debian | 20:03 |
| infinity | mterry: Okay, so, as we just discussed up there, for all of those, the correct action isn't "demote to proposed", but rather just "delete from the release pocket". | 20:03 |
| infinity | mterry: Enumerating which is which would be helpful. | 20:04 |
| slangasek | tyhicks, infinity: right - no need for it but also no need for a delta. adding it back, but of course leaving --disable-listener there | 20:04 |
| mterry | infinity, ok, I will make two lists | 20:05 |
| infinity | mterry: Ta. I'm running out of steam here, probably going to crash after I verify and release tzdata SRUs, so slangasek will likely be actioning your lists. He'll appreciate them not being wrong. ;) | 20:06 |
| slangasek | haha | 20:07 |
| mterry | infinity, unlike you? :) | 20:07 |
| infinity | mterry: I'm endlessly tolerant, everyone knows that. | 20:07 |
| * infinity wonders if he just ruined any keyboards. | 20:08 | |
| mterry | :) | 20:09 |
| mterry | slangasek, infinity: posted lists to bug 1484258. (no rush) Thanks! | 20:09 |
| ubottu | bug 1484258 in vtk-dicom (Ubuntu) "Demote activiz.net and friends to proposed (from release)" [Undecided,New] https://launchpad.net/bugs/1484258 | 20:09 |
| slangasek | mterry: you appear to have missed invesalius as a reverse-dep (but not reverse-build-dep) of gdcm; can you check if there's more hiding there? | 20:41 |
| slangasek | mterry: nope nevermind I see it in the "demoted" list sorry | 20:43 |
| slangasek | mterry: all packages demoted; I'm leaving it to you to close out the bug tasks... | 20:46 |
| doko | slangasek, will the packages stay in proposed with closed bugs? | 20:49 |
| slangasek | doko: yes, half of them have no binaries and the other half depend on binaries that don't exist | 20:50 |
| mterry | slangasek, thanks! will close | 21:27 |
| === benonsoftware is now known as MerryChristmas | ||
| === robert_ancell_ is now known as robert_ancell | ||
| mwhudson | did we get a new gccgo with the gcc 5 transition? | 23:20 |
| doko | no, already was at 5 | 23:21 |
| mwhudson | hm | 23:21 |
| doko | mwhudson, what's the problem? | 23:22 |
| mwhudson | doko: docker.io failed to build on ppc64el | 23:22 |
| mwhudson | in my ppa with go 1.5, but docker still built with gccgo this time | 23:23 |
| mwhudson | doko: https://launchpadlibrarian.net/214275071/buildlog_ubuntu-wily-ppc64el.docker.io_1.6.2~dfsg1-1ubuntu3_BUILDING.txt.gz | 23:23 |
| doko | mwhudson, can you retry with -O2? | 23:23 |
| mwhudson | doko: i don't think that's the problem | 23:23 |
| mwhudson | maybe some dep got updated, i haven't really looked at this at all yet | 23:24 |
| doko | don't see any recent checkins for this | 23:25 |
| mwhudson | yeah, it's pretty odd | 23:27 |
| * mwhudson is wdiffing the build environments | 23:27 | |
| mwhudson | cooooooooouuuuuuuuuuld be some cgo change maybe? | 23:29 |
| mwhudson | oh god | 23:31 |
| mwhudson | it's the type of syscall.RawSockaddr.Data or something like that | 23:32 |
| mwhudson | i think this did get changed on ppc64el | 23:32 |
| mwhudson | doko: it's this https://go.googlesource.com/gofrontend/+/a850225433a66a58613c22185c3b09626f5545eb%5E%21/ | 23:33 |
| sarnold | http://codesearch.debian.net/results/ifrDataByte/page_0 | 23:33 |
| mwhudson | doko: so it's terrible but not our fault i guess | 23:34 |
| * mwhudson thinks | 23:35 | |
| mwhudson | no real idea how to fix this :( | 23:35 |
| mwhudson | i can at least complain at people | 23:35 |
| doko | mwhudson, please open a bug report for golang *and* gcc upstream | 23:36 |
| mwhudson | doko: as in bugzilla? | 23:36 |
| mwhudson | sure | 23:36 |
| doko | yes | 23:36 |
| doko | and mark it as a regression, if it worked before (or subscribe me) | 23:37 |
| mwhudson | doko: step 1 https://github.com/golang/go/issues/12124 | 23:42 |
| mwhudson | doko: how do i mark it as a regression? | 23:44 |
| doko | prefix with [5/6 Regression] | 23:46 |
| mwhudson | doko: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198 | 23:47 |
| ubottu | gcc.gnu.org bug 67198 in go "[5/6 Regression] change of type of syscall.RawSockaddr.Data on ppc64 breaks compilation of existing programs" [Normal,Unconfirmed] | 23:47 |
| doko | ta | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!