[14:13] <max2go> I have an Asus Z10PE-D16 Server MB. After last night's update of Ubuntu, I get a "double free at 0x669e6080 Aborted. Press any key to exit." Any help would be greatly appreciated!
[15:27] <nils_> max2go, when does that happen?
[17:26] <nils_> I get a segfault in libc when I run loadkeys.
[18:56] <dr4c4n> hi, when I boot ubuntu gnome 16.10 beta 2, after I login, the screen just freezes, is there anyway to write a bug report or gather more information?


[00:14] <nacc> Laney: ah! ok so each trigger gets specified?
[00:15] <nacc> Laney: good to know
[00:43] <nacc> slangasek: is someone from foundations looking at the remaining perl autopkgtest regression? I spent some time last week, but don't know if I should invest more time this week (libembperl-perl). The root cause is some sort of double evaluation of they DynaLoader module
[00:51] <nacc> mdeslaur: thoughts on (me) possibly looking into if we can separate out http2 support into its own pacakge which could live in universe? there isn't a precedent for that in src:apache2, but a lot of other apache2 modules are in universe.
[00:51] <sarnold> isn't that what we have today?
[00:52] <nacc> sarnold: no, we don't build it at all
[00:52] <nacc> sarnold: our apache2 has no mod_http2 available
[00:52] <nacc> sarnold: because it's not its own package in debian (so the above suggestion would be delta)
[00:53] <nacc> we might still pursue the MIR eventually, etc., but I'm trying to think of something that can resolve the lack of http2 at all in the short-term without that
[00:53] <nacc> Laney: do you mind if I document that on the same wiki page?
[01:01] <nacc> RAOF: thanks for the ping, doing it now
[01:01] <RAOF> nacc: Oh, sweet!
[01:01] <RAOF> Thanks.
[01:34] <nacc> RAOF: done
[01:35] <nacc> RAOF: thank you for the reminder!
[02:19] <RAOF> nacc: ...and released!
[03:49] <slangasek> nacc: I don't know that anyone is tracking that, no
[05:17] <nacc> slangasek: ok, i'll try and debug it more tmrw
[07:17] <josvaz> Morning!
[07:19] <josvaz> Phil's daugther has a high fever (>40C = >104F) so he won't be in, at least in the morning
[07:19] <josvaz> wrong channel sorry
[09:03] <Laney> nacc: go for it
[09:10] <cpaelzer> Hey I'm involved in reviewing and sponsoring an SRU - it seems the last two SRUs (different problems) vanished in proposed (not verified and denied after timing out)
[09:10] <cpaelzer> I'm wondering if it is "ok" to just leave out the two versions in the changelog
[09:10] <cpaelzer> For the user they never happened, so it would be the correct changelog
[09:11] <cpaelzer> but I would like to have anybody confirming that it is ok to jump version.17 version.20 (with .18 and .19 being those that never made it through)
[12:07] <mdeslaur> nacc: can't it wait for z+1? we can MIR the http2 library as soon as z+1 opens...creating a universe package that you'll have to transition back is a lot of work, no?
[12:18] <rbasak> nacc: I'm not sure about that either. If something isn't in main due to quality (eg. "considered experimental upstream"), then I don't think it should be in universe either unless somebody else commits to looking after all the upgrade path issues etc. I don't think it's worth our time to do that.
[12:19] <rbasak> I think the expectation of quality here matches that of a PPA, so it should be in PPA if anywhere. It should be made very clear to users that the usual expectations of quality (eg. a best-effort-to-be-smooth upgrade path to new releases) don't apply to this module.
[12:20] <rbasak> IOW, I don't think it's OK for us to "throw" something into universe that we don't want to support in main.
[12:21] <rbasak> OTOH, if somebody else wants to commit time to maintaining something in universe by spending the effort to maintain it at better quality, then that's fine.
[12:52] <sil2100> slangasek, infinity: hey! I was reviewing the thunar SRUs for xenial and yakkety and I think I would need a TB approval on getting this in
[12:52] <sil2100> slangasek, infinity: it's a new microrelease which doesn't mark all the bugs fixed through LP, and they don't have autopkgtests (or a good test suite)
[12:53] <sil2100> slangasek, infinity: the SRU process mentioned I'd need a single TB member to approve it in this case
[12:53] <zul> doko: ping
[12:53] <sil2100> The release makes sense in overall (besides needing a small tweak in the version number) - all changes look like welcome additions
[13:17] <rbasak> sil2100, tjaalton: in bug 1639896, is there any thought to testing users who are on AMD but not using Polaris?
[13:17] <rbasak> We don't want to regress those users accidentally, right?
[13:17] <rbasak> For example, if the code that detected what card was in use was broken and was accidentally "always Polaris of course".
[13:19] <tjaalton> rbasak: all such tests use pci-id's. this adds new to support polaris
[13:19] <tjaalton> old radeons use -ati
[13:20] <tjaalton> this is for gcn1.0 and up iirc
[13:20] <rbasak> I'm talking of "regression risk in case our understanding is wrong", not "what is our understanding".
[13:21] <tjaalton> "code that detected" is in the driver
[13:21] <tjaalton> you assume it's broken
[13:22] <rbasak> I assume that broken-ness is unknown without some method to try to ensure that it's not.
[13:22] <tjaalton> it's in 16.10
[13:22] <tjaalton> guess we'd have heard by now
[13:23] <rbasak> That's fair.
[13:23] <tjaalton> also on 16.04.2
[13:23] <rbasak> Oh? 16.04.2 pulled from xenial-proposed for this package?
[13:24] <tjaalton> no, same version
[13:24] <tjaalton> x-x-v-amdgpu-hwe-16.04
[13:24] <rbasak> xserver-xorg-video-amdgpu is 1.1.0-1 in xenial release, doesn't exist in xenial-updates and is 1.1.2-0ubuntu<IP_ADDRESS> in xenial-proposed, now?
[13:24] <rbasak> Oh, I see.
[13:24] <rbasak> OK
[13:25] <tjaalton> yes and zesty has 1.2.0
[13:25] <tjaalton> amd made 1.1.2 to add support for polaris in 1.1.x code
[13:27] <tjaalton> actually 1.1.2 was a one-commit fixup release. 1.1.1 had the other commits
[13:32] <Unit193> tjaalton: I don't suppose you saw my poking of jcristau in #debian-devel?
[13:41] <tjaalton> Unit193: what about?
[13:43] <Unit193> tjaalton: In regards to 60x11-common_xdg_path, which adds DESKTOP_SESSION to the XDG_CONFIG_DIRS path.
[13:44] <tjaalton> no
[13:44] <tjaalton> did not
[13:45] <Unit193> Before I had asked one of the Ubuntu devs if it was pushed to Debian, and at the time he said they didn't want it.  jcristau seemed to know nothing about it, and it's very useful in live-build ISOs.
[13:45] <Unit193> Do you happen to know?
[13:45] <tjaalton> nope
[13:46] <Unit193> Huh.  Alrighty, thanks.
[13:46] <tjaalton> needs a bug on debian side
[13:46] <tjaalton> if you want it there
[13:48] <Unit193> Yeah I was just trying to find out why not, but seems there might not be a reason so time to file.
[14:23] <juliank> cjwatson: We have a user in #debian-apt on oftc wondering how to best create a local partial mirror of Ubuntu archives. Seems that with apt-mirror he always runs into inconsistencies. Ideas?
[14:24] <cjwatson> not at the moment sorry
[14:24] <cjwatson> I mean I'd probably start with debmirror
[14:24] <cjwatson> but partial mirroring is always somewhat fiddly
[14:28] <juliank> cjwatson: I think the problem is mostly that the mirror they are mirroring updates while they are mirroring, causing parts to be from the old state and parts from the new state.
[14:29] <juliank> How often are they updated? Every 30 minutes?
[14:35] <cjwatson> juliank: multiple times an hour, not on a fixed schedule exactly
[14:35] <juliank> ah, ok
[14:35] <cjwatson> juliank: sounds like something that might be fixed by having the mirroring tool use by-hash index files
[14:36] <cjwatson> juliank: the stay of execution for everything else is generous enough that that should be enough
[14:48] <caribou> barry: can I trusk sysconfig.get_config_vars() to return _EXACTLY_ the CFLAGS used to build the python interperter ?
[14:51] <barry> caribou: yes, should be accurate.  iirc it reads them right out of the makefile
[14:51] <caribou> barry: ok, thanks
[15:19] <smoser> hey. wonder if anyone has a solution.
[15:19] <smoser> rharper has been working some systemd-networkd bugs and support in cloud-init
[15:19] <smoser> we dont know how we can express what we want correctly
[15:19] <smoser>  https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/317917
[15:19] <smoser> has more info. but basically , as rharper said
[15:20] <smoser> we don't have a way to express the idea that *if* you're using networkd  as your $networking_service *then* you need systemd >= X and resolvconf >= y
[15:25] <rbasak> You might be able to express that using virtual packages, but I don't know if that would be appropriate.
[15:25] <rbasak> (or metapackages)
[15:26] <rbasak> networkd Depends: systemd-networkd-support, systemd-networkd-support Depends: systemd >= X, etc.
[15:26] <rbasak> (or, virtually, a high enough version of systemd Provides systemd-networkd support)
[15:27] <rbasak> Seems ugly to me :-/
[15:27] <rbasak> (also I've never seen that done before, so perhaps there's a reason or better way)
[15:35] <juliank> apt 1.3.5 patch list: https://github.com/Debian/apt/compare/1.3.y...julian-klode:1.3.y?expand=1 - if someone thinks I missed something, or can drop some changes, let me know.
[15:35] <juliank> This brings yakkety up to 1.4~rc2 in terms of important bug fixes
[15:39] <juliank> Highlights: * Bugfix for partial requests on slashdot * The icon tarball thing fixed * sanitized environment for privilege dropping processes * installation ordering / progress fixes
[15:39] <juliank> I think most of that, excluding the installation ordering/progress stuff will also apply to 1.2 (xenial)
[15:40]  * juliank should force himself to more regular SRUs
[15:41] <juliank> Changelog: https://paste.ubuntu.com/24047071/
[15:42] <juliank> Some fixes are not really that important, but tiny, so I still picked them
[15:42] <juliank> stuff like "bash-completion: Only complete understood file paths for install"
[15:49] <nacc> mdeslaur: rbasak: ack, was just thinking through alternatives, as I read through your prior discussions on the topic
[15:49] <juliank> Oh, is there a way to search for apt bugs where I added xenial or yakkety tasks?
[15:50] <rbasak> juliank: https://bugs.launchpad.net/ubuntu/xenial/+source/apt
[15:50] <rbasak> Linked on the right at https://bugs.launchpad.net/ubuntu/+source/apt
[15:51] <rbasak> No idea how to "union" that with yakkety though.
[15:51] <juliank> rbasak: thanks, that's OK
[15:51] <juliank> rbasak: It's more of an or anyway :)
[15:52] <rbasak> Good point :)
[15:52] <juliank> Now I just have to annotate the commits with the proper launchpad bugs
[15:58] <caribou> barry: ah, that would explain why I don't see the LTO optimisation flags, they're passed in the make command during the build
[16:01] <juliank> Heh, we now have coverage information on the whole 1.3.4 to 1.3.5 diff, that seems useful: https://codecov.io/gh/julian-klode/apt/compare/15f32c417545d6e19d459004d510b7101bf6683f...e5f9d66fcc67c1cad96cbb3efa6cc1226ba0ccbf/diff
[16:12] <cult-> when is this bug going to be released? https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
[16:22] <nacc> do isolation-container autopkgtests inherit the enviornment from the top-level (that is, values like no_proxy?)
[16:32] <slangasek> sil2100: nowadays the TB has delegated to the SRU team for the SRU exceptions; so what's your sense of whether thunar should be granted an exception?  Do you have confidence that the upstream QA for the microrelease was up to our standards, despite there not being autopkgtests?
[16:33] <rbasak> xnox: bug 1588330 above - not verification-done?
[16:33] <rbasak> slangasek, sil2100: do we (~ubuntu-sru) explicitly grant and document these exceptions currently? For consistency, I feel that we should.
[16:34] <slangasek> rbasak: if it's intended to be a standing exception, yes
[16:34] <slangasek> if it's a one-off, the paperwork doesn't pay for itself
[16:35] <rbasak> Perhaps we should ask uploaders to document in the bug whether it should be a standing or one-off exception (or ~ubuntu-sru could just edit the bug description on approval, etc).
[16:35] <rbasak> I agree it's not worth anything further for a one-off.
[16:35] <rbasak> s/edit the bug description/just comment/ even.
[16:37] <juliank> APT 1.2.20 queue: https://github.com/Debian/apt/compare/1.2.y...julian-klode:1.2.y?expand=1
[16:38] <juliank> Riddell: ^ might be interested :)
[16:39] <Riddell> juliank: Debian uses github?
[16:39] <rbasak> powersj: so I forgot to mention. The next thing that'll happen is a component mismatch, probably leading to an email to ubuntu-release@ saying that those packages are incorrectly in universe. An archive admin will spot this in the component mismatches report, find the approved MIR bug, and override those packages to main. So it's not entirely done, but needs no further action from us as the MIRs are
[16:39] <rbasak> approved.
[16:39] <juliank> Riddell: We mirror apt there, and I merge pull requests from there
[16:41] <juliank> Well, some bot mirrors there, not sure who is really responsible for that
[16:42] <rbasak> powersj: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg and related files in that directory are the component mismatches reports
[16:42] <Riddell> juliank: yay for "Only merge acquire items with the same meta key" merge :)
[16:42] <powersj> rbasak: ok thanks that will save me a few minutes of panic later today :)
[16:46] <juliank> Riddell: Yeah, now I just need to take a look at some failing tests, and then it should be ready for upload in one to two days.
[16:50] <juliank> Hmm, nothing troubling actually. Just the sections of some test packages being different
[16:51] <cult-> rbasak: can you set it to verification-done?
[16:53] <rbasak> cult-: not without being confident that it was actually verified and what was verified, no.
[16:53] <rbasak> That's why I asked xnox, because it looks like he knows and that approach is least likely to end badly.
[16:53] <xnox> rbasak, verified in xenial; did not finish verification in yakkety; i do have container about.
[16:54] <xnox> for it.
[16:55] <xnox> cult-, rbasak: the bug has not aged yet. It's only 5 days old, thus will not be released yet.
[16:58] <cult-> how many days need to be passed?
[16:58] <cult-> ah damn this is crazy
[16:58] <rbasak> See https://wiki.ubuntu.com/StableReleaseUpdates for full details.
[16:59] <rbasak> Taking care to not regress millions of users isn't crazy.
[17:00] <cult-> i understand it, but the current binaries in universal are unusable
[17:00] <rbasak> And for 16.04 they've been unusable for 10 months. Two days won't make a difference.
[17:00] <cult-> so there's not much to break, if its already broken
[17:01] <cult-> rbasak: ok
[17:01] <xnox> cult-, you can use binaries from xenial-proposed which are mirrored world-wide
[17:01] <xnox> you know that, right?!
[17:01] <cult-> yes
[17:01] <cult-> :P
[17:19] <juliank> Riddell: sudo add-apt-repository ppa:deity/apt-1.2 - 1.2.20~rc1 should appear in the next hour or so, it's currently building
[17:21] <Riddell> that's awfae clever
[17:21] <nacc> xnox: since you're around, have you looked any further at the libaws/liblog4ada regressions in z-p? I am going to try and talk to the Debian maintainers if they have any suggestions
[17:22] <xnox> nacc, i ran a test with all-proposed and it did pass and migrate zlib for me
[17:22] <xnox> (i think libaws test passed)
[17:22] <nacc> xnox: interesting! thanks for that info!
[17:22] <xnox> nacc,and I don't care any more =) doko says that these things should be rebuild in order until it's right =/
[17:22] <xnox> but i'm not sure how to establish that
[17:23] <nacc> xnox: ack
[18:35] <toabctl> could somebody sponsor the fix with https://bugs.launchpad.net/ubuntu/+source/zypper/+bug/1638306 please?
[18:40] <nacc> toabctl: is it fixed in Y and Z? Your versioning also makes it hard to be sure the sort is correct relative to new versions. Maybe not critical, but e.g., 1.12.4-1ubuntu0.1 would make it clearer that it's an SRU (to me)
[18:40] <nacc> tbh, i'm also surprised anyone uses zypper on ubuntu, but that's neither here nor there
[18:42] <sarnold> wow I didn't know we packaged that :)
[18:42] <toabctl> nacc, you just need an rebuild. there is nothing to fix
[18:42] <toabctl> nacc, sarnold we need it in the openstack CI which runs on ubuntu but we also want to create suse images there. for that zypper is useful
[18:43] <nacc> toabctl: i understand, and even my version string above is wrong, since 1.12.4-1ubuntu0.1 would sort ahead of 1.12.4-1build1 (which is what is in y/z)
[18:43] <toabctl> anyway - this bug is really easy to reproduce (zypper -h) and really easy to fix and test the fix.
[18:47] <nacc> toabctl: my worry is that '1.12.4-1+b1' is already in use by Debian as a version string (unstable)
[18:47] <nacc> toabctl: it is wrong (aiui) to use that same string in ubuntu
[18:49] <sarnold> heh, "Binary-only non-maintainer upload for amd64" considering we don't do binary uploads in ubuntu, there's no maintainers, and you can't easily upload for just one architecture, I think every word in that sentence is a lie :) Also the cake is a lie.
[18:50] <nacc> toabctl: i fully agree your fix is probably correct, but i'm not comfortable sponsoring it as-is
[18:50] <Unit193> nacc: I've seen '1.12.4-1~ubuntu0.1'
[18:50] <nacc> Unit193: yeah i'm thinking the ~ is needed here to sort correctly
[18:50] <toabctl> doko, what the correct version string for a pkg rebuild?
[18:50] <Unit193> And I've seen cases like ca-certs that don't add that, thus the version in devel is older. :/
[18:50] <sarnold> what's the core cause of this fault? it feels unlikely to me that a rebuild alone would be sufficient.
[18:51] <mterry> @pilot in
[18:51] <sarnold> (I mean, sure, a rebuild is likely to -fix- it but what would prevent this from recurring?)
[18:56] <toabctl> sarnold, I guess a tighter dep on libzypp could help. but this is a bugfix
[18:56] <sarnold> toabctl: it -does- pass the "minimal effective" test quite well :)
[18:58] <sarnold> ahhhh, libzypp isn't built from the same source package as zypper; that's surprising.
[18:58] <toabctl> sarnold, it's a different thing
[19:03] <smoser> anyone else having issues with vpn ?
[19:05] <sarnold> smoser: zesty?
[19:05] <smoser> barry, ? i see you touched network manager recently... /me is unable to connect to a vpn
[19:05] <smoser> yeah, zesty
[19:06] <smoser> oh. fun. jgrimm
[19:06] <nacc> smoser: you need to do a tweak
[19:06] <smoser> is last-touched on openvpn
[19:06] <nacc> smoser: https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes#OpenVPN
[19:07] <nacc> smoser: verify by name exactly in NM's advanced settings, then elid the '/CN:' string in the textbox
[19:07] <jgrimm> smoser, there's a pending doc update internally to the VPN notes as i understand it too
[19:09] <smoser> nacc, edit to ? canonical.com ?
[19:10] <nacc> smoser: the canonical vpn definition in NM
[19:11] <smoser> nacc, not following. i set " verify by name exactly in NM's advanced settings".
[19:12] <smoser> but then 'elid' (i assume edit) the '/CN:' string... edit to what ?
[19:12] <smoser> i currently have /CN=access.is there
[19:12] <jgrimm> smoser, change to 'access.is'
[19:13] <barry> yeah i saw some recent changes to the wiki page, but haven't tried connecting to the vpn yet
[19:14] <smoser> ok. that worked. \o/
[19:15] <nacc> smoser: sorry, yeah, just remove the '/CN=' part
[19:15] <smoser> elid is esparanto for delete
[19:16] <nacc> *elide :/
[19:19] <infinity> nacc: I tossed some comments on that zypper bug you were looking at.
[19:21] <sarnold> infinity: what do you mean with "but the packages don't"?
[19:21] <smoser> for anyone else who sees this..
[19:21] <smoser>  http://paste.ubuntu.com/24048268/
[19:21] <sarnold> that's a bit of packaging I never deal with :)
[19:21] <infinity> sarnold: The binary package name is libzypp, not libzypp1503
[19:22] <infinity> (Though, in this case, there appears to *also* be an undeclared ABI break happened within the upstream SONAME of 1503, but hard to throw stones at upstream when the packaging is so clearly broken anyway)
[19:23] <sarnold> interesting, I never noticed just how many lib* packages encode version numbers in the names. it always felt like a minority..
[19:24] <infinity> sarnold: Any lib* package that's an ELF library with an SONAME should use the SONAME as the package version.
[19:24] <infinity> s/package version/package name/
[19:24] <infinity> Brain and finger disagreement.
[19:25] <sarnold> infinity: thanks for the explanation :)
[19:25] <infinity> There are some packages so old that they don't conform (zlib1g might be one of the only ones left?), but anything that's had an ABI bump since the glibc transition follows that pattern or is wrong.
[19:26] <infinity> And with versioned provides, we could finally s/zlib1g/libz1/ if we really wanted to.
[19:27] <sarnold> and confuse the heck out of everybody??
[19:27] <infinity> But I kinda like that it's had a stable ABI for so long that it's lived through decades of policy.
[19:39] <nacc> infinity: thanks
[19:44] <nacc> infinity: and just to be clear, re: your last comment, no rebuild is needed for zesty; but xenial only
[19:49] <infinity> nacc: Yeah, yakkety (and thus zesty) got a rebuild for a different transition, which happened to fix this bug in the process. :P
[19:50] <nacc> infinity: yep :)
[19:54] <infinity> nacc: My guess is that the Debian maintainer maintains both packages and hand-waves over the glaring packaging bug by not uploading zypper until libzypp is built everywhere.  Which broke in Ubuntu when we mass-synced.
[19:55] <mterry> @pilot out
[19:56] <nacc> infinity: that makes sense
[20:36] <toabctl> nacc, thanks for sponsoring. Where can I find the package now? will it popup in proposed?
[20:42] <nacc> toabctl: https://wiki.ubuntu.com/StableReleaseUpdates
[20:42] <nacc> toabctl: SRU team needs to handle it once it's built
[20:46] <toabctl> nacc, ok. thx
[21:10] <nacc> lamont: hey, just touching base on maas and python-django. Anything I can do to help?
[21:18] <nacc> slangasek: re: libemperl-perl, I think this is actually a change in behavior in pkg-perl-tools 0.34 (this is when the tests started failing in debian as well). a) they updated autopkgtest to run with PERL_DL_NONLAZY=1 and b) they also added a whitelist functionality for output during a test run, but libembperl-perl doesn't use this for output; and I think it's actually correct for libembperl to emit
[21:18] <nacc> the redefinition error it does when that environment variable is set
[21:21] <jackpot51> I have patches for WPA 2 enterprise support in ubiquity - what should I do with them?
[21:24] <lamont> nacc: I've been working through just how much work it is, and it's not quite trivial
[21:36] <jackpot51> Patches can be seen here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1107935
[21:40] <jbicha> jackpot51: it's best to subscribe ~ubuntu-sponsors to a bug when you attach a patch, https://wiki.ubuntu.com/SponsorshipProcess
[21:41] <jackpot51> ok, cool
[21:42] <jackpot51> Done
[21:51] <jackpot51> Here is an additional change for network-manager-applet: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1667129
[23:01] <nacc> slangasek: in any case, sent to Debian as well, uploaded, and retriggering the tests. I think perl should migrate now
[23:34] <Unit193> cjwatson: It's safe to presume putty won't be making it into Zesty?
[23:43] <Unit193> !info libpcsclite1 yakkety
[23:43] <Unit193> !info libpcsclite1 zesty
[23:45] <slangasek> nacc: cool!


[00:11] <cjwatson> micahg: looks like it got stuck on a download; I've killed it and hopefully the next run will work better
[00:11] <micahg> cjwatson: thanks
[00:13] <smoser> is there some tool i can use to easily get the payload of a debconf value ?
[00:13] <smoser> ideally very standard.
[00:22] <smoser> i'm hoping to
[00:22] <smoser>  a.) dump all keys matching some string
[00:22] <smoser>   that can be the same package, or not be, thats fine
[00:23] <smoser>  b.) iterate over items in 'a', and get the value of each
[00:23] <smoser> for this situation, they're all strings
[00:24] <smoser> looks lke maybe i can make debconf do what i want
[01:30] <RAOF> @pilot in
[02:22] <Jack_> Hi, Does Ubuntu development have anything to do with developing Grub 2 or configuring Grub 2 for use on Ubunutu?
[02:24] <JackyAlcine> Well, Grub's a distro-independent kind of thing.
[02:24] <JackyAlcine> You could set it up for a Windows-only system (though MS would wipe it out with its own boot manager)
[02:24] <JackyAlcine> If anything, there's probably a few patches made by the dev team here to make it more homely for Ubuntu.
[02:24] <Jack_> so a query about grub2 wouldn't be relavant here?
[02:26] <JackyAlcine> All depends, it's IRC, have to ask if you want to know.
[02:26] <JackyAlcine> I know that I don't know anything Grub-specific.
[02:26] <Jack_> I was wondering if there was any particular reason why windows boot menu entries don't get parttool (hdX,Y) +boot applied by default?
[02:29] <Jack_> I have a tri-boot system with windows 7, windows 8 and Ubuntu installed. Both versions of Windows have their own boot manager. Windows 7 will only hibernate, and Windows 8 will only shut down if it has the boot flag set.
[02:30] <Jack_> So with the default grub2 install, I could only make one work with setting the boot flag, but by adding parttool +boot to the menu entry it works fine.
[02:30] <JackyAlcine> Well, again, it might be with how Windows communicates with the boot manager itself. Since it's a bit unpredictable (due to its closed nature), it might not work as expected.
[02:31] <Jack_> Could anything bad result from having Grub set the windows partitions boot flag?
[02:34] <JackyAlcine> No background with that, I'm sorry.
[02:35] <Jack_> That's okay. Do you know anyone I could contact about it?
[04:45] <RAOF> @pilot out
[04:49] <jalcine> o.O
[05:02] <ScottK> slangasek: Now that doko made python arch:any, someone's going to have to do a bit of bootstrapping on archs !i386 since two of it's dependencies need python.
[05:02] <ScottK> It won't be me, because I'm going to sleep.
[05:02] <ScottK> Maybe pitti will be around soon.
[05:03] <ScottK> I'm very tired, so I'm sure I haven't thought through all the implications of no 'python' package on !i386, but I'm pretty sure it's "not good".
[05:06] <micahg> :(
[05:06] <micahg> ScottK: thanks for fixing python3-defaults though
[05:07] <ScottK> I fixed python-defaults too, it just can't build due to uninstallable build-deps.
[05:07] <ScottK> It's just moving the python-policy generation to the arch:any part of debian/rules.
[05:16] <ScottK> Maybe this isn't that hard to fix.
[05:29] <ScottK> It isn't but I'm more tired than it's not hard.
[05:30] <ScottK> Image builds failing now too.
[05:30] <ScottK> skaet: ^^^
[05:30] <ScottK> Good luck and good night.
[05:38] <micahg> slangasek: are you around at all?
[05:48] <micahg> slangasek: unping
[05:55] <micahg> infinity: around?
[06:30] <pitti> Good morning
[06:32] <micahg> hi pitti, there was a broken python-defaults upload which made python uninstallable on !i386, I reverted the change to unbreak the archive (hopefully)
[06:32] <pitti> micahg: ah, thanks
[06:34] <micahg> pitti: I just hope nothing else was depending on that change other than multiarch
[06:35] <micahg> pitti: I wonder if the python3-defaults upload needs to be reverted as well
[06:35] <micahg> bug 934593
[06:35] <micahg> python3-defaults is currently depwait on ~i386
[06:36] <slangasek> sounds like the sort of change that should have gone through the FFe process; I'd say revert it, at least for now
[06:36] <micahg> slangasek: python3-defaults?
[06:36] <slangasek> yeah
[06:36] <pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[06:36] <pitti> micahg: looks like it
[06:37] <pitti> micahg: yes, a reversion definitively sounds like the right and quick thing here, as it breaks half the archive right now
[06:37] <micahg> pitti: python-defaults should fix precise_probs
[06:37] <pitti> unless you know exactly what to fix
[06:37] <micahg> I"m flying blind here :)
[06:37] <pitti> there's a fair amount of python3* stuff there, too
[06:37] <pitti> micahg: right :) so, our new policy is to revert
[06:38] <micahg> ah, ok, then I should upload this quick
[06:38] <pitti> micahg: thanks!
[06:46] <micahg> pitti: uploaded
[06:46] <pitti> cheers!
[06:47]  * micahg hopes the beer reappears soon
[06:48]  * slangasek waits for beer on https://jenkins.qa.ubuntu.com/view/Precise Upgrade Testing Dashboard :)
[06:50] <pitti> slangasek: there's still 5 armel packages which are uninstallable; so no beer today :/
[06:50] <slangasek> phooey
[06:52] <slangasek> micahg: so did you revert python-defaults entirely?
[06:52] <micahg> slangasek: yes, is that bad?
[06:52] <slangasek> oh, well, it's suboptimal from my POV :)
[06:53] <slangasek> I was only after python-all-dev, python-dev being marked Arch: any; I don't know why python also got marked Arch: any
[06:53] <micahg> slangasek: with your multiarch hat or your manager hat?
[06:53] <slangasek> with my multiarch hat only ;)
[06:54] <slangasek> you're well within your rights to have reverted the whole thing, just wanting to make sure I understand the current status
[06:54] <micahg> slangasek: I didn't have the expertise to fix it properly, nor the time, I figure you and doko can work out the right thing in a fraction of the time it would take me to do it :)
[06:55] <micahg> I'm still curious about the binary domination in that case though
[06:56] <slangasek> yeah, I dunno
[07:09] <infinity> micahg: Err, around now.  I assume it was about the python mess?
[07:09] <micahg> infinity: yeah, was going to ask you to bootstrap, but I reverted instead, in the end, it might not be needed at all
[07:10] <infinity> It wouldn't need to bootstrap, it would just need them all to build in the same publisher cycle (or i386 last).
[07:10] <micahg> infinity: or that :), I'm wondering why that's the case though
[07:13] <infinity> micahg: The reason it all went pear-shaped was because doko's first upload was FTBFS on !i386, due to missing build-deps.
[07:13] <infinity> micahg: And by the time he fixed that, the i386 packages had been uploaded, making python unintallable on all other arches.
[07:14] <infinity> micahg: So, yeah, if his change had been done properly, and in one publisher cycle, no one would have ever noticed.
[07:14] <micahg> oh, I think I figured out the answer to my question
[07:14] <infinity> micahg: So, I stick with my assertion that if we want this change, we just need to revert your revert, and it'll work fine.
[07:15] <infinity> (After your packages are published)
[07:15] <infinity> slangasek: ^^
[07:17] <infinity> micahg: Basically, if you're positice that -9ubuntu5 builds on !i386 with dpkg-buildpackage -B, it would be safe to reupload that as -9ubuntu7
[07:17] <infinity> positive, too.
[07:18] <infinity> micahg: But also perfectly valid to leave it as-is and let slangasek and doko argue about it later. ;)
[07:18] <micahg> infinity: yeah, well, I tested that, but with a slightly behind mirrror
[07:18] <micahg> infinity: I'd rather let them sort it out as I have other things to do before bed
[07:18] <infinity> micahg: Sure, the behind mirror bit is fine, since that would simulate the current fixed situation. ;)
[07:18] <micahg> infinity: that's why I uploaded ubuntu5 as a workaround :)
[07:21] <micahg> infinity: anyways, slangasek said he didn't expect the whole source to be multiarched anyways
[07:22] <micahg> err..arch any, not multiarched :)
[07:31] <micahg> umm, there was no need for me to revert python3 defaults apparently
[07:35]  * micahg fixes
[08:04] <dholbach> good morning
[08:28] <jibel> server images 20120316 failed to install this morning bug 956766
[08:29] <micahg> jibel: should be fixed already
[08:32] <jibel> micahg, this is fixed with python-defaults 2.7.2-9ubuntu6 ?
[08:32] <micahg> jibel: yeah
[08:33] <jibel> micahg, thanks, updating report.
[09:20] <jamespage> @pilot in
[09:22] <pitti> hallyn, Daviey: did you notice that the latest libvirt upload is in depwait, because of the new numa universe dep?
[09:36] <pitti> sabdfl: Hey Mark, how are you? found an animal with Q yet? :-)
[09:36] <pitti> Quarreling Quail!
[09:40] <dholbach> pitti, there's more https://wiki.ubuntu.com/DevelopmentCodeNames#Q :)
[09:40] <pitti> "Quetzalcoatl"? Wasn't this an Aztec king or so?
[09:41] <ochosi> pitti: an aztec god
[09:41] <pitti> aah, off-by-one in the hierarchy
[09:41] <yellowduino> dholbach: just finished reading your "Getting Started" :)
[09:42] <ochosi> pitti: could be that historically he was a king first
[09:42] <dholbach> pitti, an animal too
[09:42] <dholbach> yellowduino, nice (although I need to be honest - it's not only my work, but that of a bunch of others too :-))
[09:42] <ochosi> "quirky quokka" (what a beautiful alliteration)
[09:43] <yellowduino> dholbach: I bet :) I hope to get some things fixed and get involved
[09:43] <dholbach> yellowduino, rock and roll - I'm looking forward to seeing you here more often :)
[09:49] <yellowduino> quit
[09:53] <pitti> Riddell: do you plan a calligra upload soon to fix the armhf FTBFS? If so, could you please slip in the ttf-lyx recommends drop?
[09:54] <pitti> and perhaps also the missing transitional packages, to fix upgrde
[09:56] <Riddell> pitti: good point, I'll try and do that today
[09:56] <pitti> Riddell: cheers
[10:22] <dholbach> thanks everyone who helped to get the sponsoring queue from ~50 to ~30
[10:22] <dholbach> http://reqorts.qa.ubuntu.com/reports/1glance-sponsoring/
[10:22] <dholbach> it's nice to see how many did more than 20 review pieces
[10:22] <soren> What's the correct way to set a dynamically computed, default value in debconf? db_set <template> <default value>; db_fset <template> seen false  ?
[10:22] <dholbach> you all rock
[10:25] <seb128> dholbach, \o/
[10:25]  * dholbach hugs seb128
[10:26] <seb128> dholbach, thanks for keeping the ball rolling and making sure new contributors are well received ;-)
[10:26]  * seb128 hugs dholbach
[10:26] <dholbach> I can't take credit for all the good review work :)
[10:26] <ogra_> no, but for the nagging work :P
[10:27] <ogra_> without that we wouldnt be there ;)
[10:27] <dholbach> go back to doing some reviewing work then! *crack whip*
[10:27] <dholbach> :-P
[10:28] <ogra_> lolk
[10:41] <tseliot> cjwatson: do you know if there's a way to prevent grub from using "vt.handoff=7" without disabling the splash in /etc/grub.d/10_linux? Not all drivers play well with it
[11:06] <MacSlow> mvo, so yesterday evening the result was still the same... update failed due to the libtinfo5 circular dependency-issue.
[11:42] <ev> anyone particularly good with x86 assembly? I'm running into difficulty trying to build syslinux from 10.10 on precise using precise's nasm, which blows up with "cannot mix real and virtual attributes in nobits section"
[11:47] <davmor2> ev: man you just hate yourself don't you with this whole how can I make my life harder and uglier attitude ;)
[11:47] <ev> heh
[12:08] <dholbach> can https://code.launchpad.net/~dereknance-413/ubuntu/oneiric/klogshow/fix-for-678153/+merge/96059 please be rejected based on the last two comments?
[12:17] <pitti> dholbach: *zap*
[12:19] <dholbach> thanks pitti
[12:26] <jamespage> dholbach, thanks - I'll remember that trick in future :-)
[12:36]  * jamespage comes up for air (and coffee)
[12:36] <jamespage> @pilot out
[12:38] <jamespage> can https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/distribute/oneiric-updates/+merge/94896 be rejected as well - its not required (see comments)
[12:38] <jamespage> ta
[12:43] <pitti> jamespage: done
[12:45] <jamespage> pitti, thankyou!
[12:49] <mdeslaur> cyphermox: so, when I create an adhoc WPA2 network, and look at wpa_supplicant's status, it's showing "group_cipher=TKIP", but "pairwise_cipher=NON". This explains why scanning shows it as being protected, but you can still connect without a password.
[12:55] <cyphermox> mdeslaur: no
[12:55] <mdeslaur> cyphermox: hehe, no what?
[12:55] <cyphermox> AFAIK adhoc WPA is supposed to be pairwise none. :)
[12:56] <cyphermox> WPA adhoc is key-mgmt=wpa-none; pairwise=none ; group=tkip
[12:56] <cyphermox> mdeslaur: I do think that's correct, as is documented as the proper config
[12:57] <mdeslaur> cyphermox: that doesn't make sense...why do you say that's the proper config?
[13:02] <cyphermox> mdeslaur: pairwise=none is the right way to configure adhoc.
[13:06] <mdeslaur> cyphermox: yes, you've said that already...show me the spec :)
[13:07] <cyphermox> mdeslaur: not quite spec, but it's documented in multiple places as such; see http://lists.shmoo.com/pipermail/hostap/2011-July/023483.html
[13:07] <mdeslaur> yes, I agree that people keep pasting the wrong config :)
[13:07]  * mdeslaur researches further
[13:07] <cyphermox> no, it's also elsewhere, just a second
[13:09] <cyphermox> mdeslaur: you can also see the example config for IBSS in wpa_supplicant.conf shipped in the wpasupplicant tarballs; bzr branch ubuntu:wpasupplicant; vi wpassupplicant/wpa_supplicant/wpa_supplicant.conf
[13:13] <mdeslaur> hrm, yeah, it does say that there
[13:15] <cyphermox> mdeslaur: even if you use IBSS/RSN, it's still showing as unsecured sometimes
[13:16] <cyphermox> or android can't connect to it, so I'm thinking it's busted anyway
[13:16] <cyphermox> mdeslaur: IBSS/RSN (wpa2) is with mgmt=wpa-none, proto=rsn, pairwise=ccmp, group=ccmp
[13:18] <pgraner> seb128, looks like the gnome-settings-daemon is crashing on my wacom tablet again
[13:18] <mdeslaur> cyphermox: yeah, let me read the specs...something fishy here
[13:19] <pgraner> seb128, http://pastebin.ubuntu.com/886295/
[13:20] <seb128> pgraner, you never replied to my comment on the bug where I asked if the patch we put it last time was working btw...
[13:20] <seb128> pgraner, they might just have dropped it since you never came back to us
[13:20] <seb128> pgraner, let me check
[13:20] <pgraner> seb128, sorry I must have missed it in the bug mail. It was working fine until today
[13:21] <seb128> pgraner, weird
[13:21] <seb128> pgraner, can you run dpkg -l | grep gnome-settings-daemon and give me the version listed?
[13:21] <hrw> where I can report wishlist for http://qa.ubuntuwire.org/ftbfs/ list?
[13:22] <pgraner> seb128, pgraner@zorak:~$ dpkg -l | grep gnome-settings-daemon
[13:22] <pgraner> ii  gnome-settings-daemon                  3.3.91-0ubuntu6
[13:22] <hrw> would be great to have tags from bug number listed there - as most of armhf bugs now are Ada/FreePascal/Haskell/OpenGL related
[13:22] <davmor2> Is anyone else having difficulties trying to grab the scroll bar overlay buttons
[13:23] <carif> not sure I'm asking this question in the right place, when I dch -i for some pkgs and change the version in the changelog, the source directory is modifed to match when I exit. This works for some pkgs and not for others (it seems intermittent). Any reason why? I like the behavior and want to see it always happen
[13:24] <seb128> pgraner, weird, the fix is still there, can you report a bug using apport?
[13:25] <pgraner> seb128, sure, one thing to note is, when the machine first boot with the tablet connected, g-s-d crashes and for some reason apport never sees it, the only way I noticed was I had the old gnome theme
[13:25] <pgraner> seb128, then I started g-s-d form the command line and got that output
[13:28] <seb128> pgraner, can you check /var/log/apport.log?
[13:30] <pgraner> seb128, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/956956
[13:31] <seb128> pgraner, is there any way you could report it through apport so we get a stacktrace? there is not a lot we can do without one
[13:34]  * dholbach hugs jamespage
[13:35] <jamespage> dholbach, ta
[13:35] <dholbach> :)
[13:35] <pgraner> seb128, got it, new bug https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/956962
[13:35]  * jamespage likes a hug!
[13:35] <pgraner> seb128, I duped the other one to it
[13:35] <seb128> pgraner, thanks! waiting for retracing and I will deal with it
[13:35] <pgraner> seb128, cool, I'm here all day if you want to me to do anything
[13:36] <seb128> pgraner, ok, I might ping you back in a bit for extra infos, thanks ;-)
[13:38] <dholbach> we're down to 18 items in the queue - I didn't think I'd live to see this happening
[13:42] <jamespage> dholbach, w00t!
[13:43] <ajmitch> dholbach: that's great
[13:46] <cyphermox> mdeslaur: finding anything?
[13:46] <mdeslaur> cyphermox: finding que c'est compliqué en tabarnak
[13:47] <cyphermox> lol
[13:49] <mdeslaur> cyphermox: how have you not gone insane yet? :)
[13:49] <cyphermox> mdeslaur: redefine sanity.
[13:52] <mdeslaur> hrm, desktop team, network manager and evolution...yeah...too late :)
[14:12] <hrw> does someone has any idea of visualvm? bug 935481
[14:43] <ockham> pitti: hi, just added a comment to bug #956098
[14:53] <pitti> ockham: ah, splendid! sorry, missed the link to the other bug
[14:53] <pitti> ockham: I'll sync both now
[14:53] <ockham> pitti: np
[14:53] <ockham> pitti: great, thx!
[14:59] <lamont> is it too much to ask ghc to reap its dead children more frequently?
[14:59] <ajmitch> lamont: is it causing a few issues on the buildds?
[15:01] <lamont> it is making them yell at me
[15:01] <lamont> this is not nice of it
[15:01] <lamont> PROCS CRITICAL: 25 processes with STATE = Z
[15:01] <ajmitch> oops
[15:02] <lamont> specifically washngo and pandoc
[15:02] <lamont> at least so far
[15:03] <ajmitch> lamont: there's only another ~100 packages to go :)
[15:03] <lamont> remind me to hurt you. :-p
[15:03] <ajmitch> blame Laney, not me!
[15:04] <lamont> Laney: fwiw, ajmitch just threw you under the bus. :-p
[15:04] <ajmitch> he's used to it
[15:04] <lamont> heh
[15:13] <Laney> :(
[15:13] <Laney> i'm sure ghc upstream would welcome a bug report ♥
[15:13]  * Laney fades away
[15:23] <pitti> slangasek: mono prerm bug> can't this be fixed in precise as well, for people who don't install SRUs before dist-upgrading? prerm failed-install or so?
[15:23] <pitti> (it should still be an SRU, I figure)
[15:23] <slangasek> pitti: the root bug isn't in the prerm of the package being removed; and the package being removed doesn't exist in precise
[15:24] <pitti> ah, that'd spoil it of course
[15:24] <pitti> thanks
[15:24] <slangasek> it's a script being called from the prerm of each -cil package that's being removed as part of the upgrade
[15:31] <G__81> Hi I am interested in contributing to Ubuntu. I am not sure whether this is *the* channel to ask, if not can someone point me to the right channel ?
[15:35] <slangasek> jibel_: https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/ shows as a "failed" test due to conffiles, but there are no details available about what conffiles are wrong; do you have more information?
[15:38] <pitti> heh, indeed; the console output says
[15:38] <pitti> AssertionError: Obsolete config file found. Check log file '/var/log/dist-upgrade/obsolete_conffiles.log'
[15:38] <pitti> and further down
[15:38] <pitti> scp: /tmp/obsolete_conffiles.log: No such file or directory
[16:25] <mr_pouit> pitti: thanks for the indicator-applet fix! (now i've the same issue with lightdm recommending unity-greeter ;D)
[16:34] <pitti> mr_pouit: ah, lightdm gets installed before resolving the xubuntu-desktop dependencies all over again, argh
[16:34] <pitti> mr_pouit: can you please file a bug about it as well, and subscribe me? we need to discuss that with a few people
[16:40] <mr_pouit> pitti: this is because xubuntu-default-settings depends on lightdm (>= 0.9.3-0ubuntu2), x11-common (>= 1:7.6+7ubuntu2), lightdm-gtk-greeter (>= 1.0.0-0ubuntu2)
[16:40] <mr_pouit> pitti: if I swap them, it should be fine
[16:41] <mr_pouit> (I'll try, and file a bug later if it doesn't help)
[16:41] <pitti> mr_pouit: ah, it's x-d-s itself?
[16:41] <mr_pouit> yeah
[16:41] <pitti> mr_pouit: in the other bug, i-applet was pulled in much earlier
[16:41] <pitti> so this seems to be easier then
[16:41] <pitti> mr_pouit: I'm nto sure whether the order of dependencies matters, though
[16:41] <pitti> mr_pouit: you might try dropping the lightdm dependency perhaps?
[16:42] <pitti> it should then resove x-desktop -> gtk-greeter -> lightdm with already fulfilled greeter dep
[16:43] <mr_pouit> it was required because earlier versions didn't ship lightdm-set-default. But that was for oneiric only, so this should be fine now
[16:44] <mr_pouit> I'll try that then, thanks.
[16:49] <ogra_> diwic, yo ... seems your last upload reverted a fix from adam ... could it be that your bzr tree is out of sync ?
[16:49] <ogra_> diwic, (alsa-lib that is)
[17:04] <diwic> ogra_, I don't have upload rights, but I have seen fixes from adam earlier which he has not committed to the bzr tree, so that's recipe for failure if you ask me...
[17:05] <ogra_> diwic, well, would be nice if alsa-lib could just use UDD ... then it would have been automerged
[17:05] <ogra_> i ran into that issue as well several times before
[17:05] <diwic> ogra_, TheMuso is the one you want to talk to about that
[17:05] <ogra_> k, will note that down for a UDS evening :)
[17:08] <dholbach> what is the best way to replace duplicate files with symlinks?
[17:09] <ogra_> take your microphone and tell it to the HUD ?
[17:09] <ogra_> ah, wait, that was 14.04
[17:09] <dholbach> ogra_, it's not working for you?
[17:09] <dholbach> :-P
[17:09] <ogra_> :P
[17:10] <dholbach> maybe you have too much noise in the background :)
[17:10] <ogra_> haha, i sure do
[17:24] <dholbach> shadeslayer, congratulations!
[17:24] <shadeslayer> thanks!
[17:24] <shadeslayer> :)
[17:32] <abeer> hi, is anybody here planning to be a mentor at Google Summer of Code?
[17:32] <ScottK> Ubuntu isn't in GSoC.
[17:34] <abeer> There was a thread
[17:34] <abeer> where one of the developers posted that Ubuntu would be participating GSOC '12
[17:34] <abeer> there was a search for mentors as it missed out in 11.
[17:37] <micahg> yeah, we missed the deadline by ~10 minutes apparently
[17:38] <abeer> oh damn! I was really hoping to work under Ubuntu
[17:38] <micahg> abeer: you still can, just not under the GSoC banner :)
[17:39] <abeer> The thing is I am new to world of submitting code
[17:40] <abeer> GSOC would have been an opportunity where I could have a mentor who would be able to guide me completely towards the completion of a project.
[17:42] <ScottK> Depending on what you want to do, you can accomplish similar things independent of GSoC, just with a little more team approach.
[17:43] <abeer> Well, the thing is I have experience with Java to make small applets and am kind of proficient in C++.
[17:43] <bdmurray> pitti: ubuntu-bug should work with a command name for example do-release-upgrade right?
[17:44] <abeer> I've been trying to pick Python up so I can contribute using quickly as shown on the dev page,  but I can't figure out what would be the best way of go about learning Python as there are an umpteen number of resources available.
[17:47] <ScottK> Python is (IME) generally easy enough that the best way is to find some problem and figure out how to solve it.
[17:47] <ScottK> Careful what you admit about C++ knowledge or apachelogger will try to steal you away to work on Kubuntu (which also uses a lot of Python)
[17:49] <apachelogger> see plus plus
[17:49] <apachelogger> best thing since godzilla
[19:54] <mfisch> Ampelbein: ping
[20:06]  * Sweetshark is looking for a brave sponsor.
[20:10] <Sweetshark> kenvandine, cjwatson, bryceh, mdeslaur, mterry: anyone volunteering to sponsor the upload of 3.5.1-1ubuntu1 to be found in /home/bjoern on chinstrap?
[20:13] <Sweetshark> micahg: ^ (just skimming through timezone data)
[20:13] <micahg> Sweetshark: sorry, in the middle of too many other things
[20:16] <bryceh> Sweetshark, yep can do
[20:26] <Sweetshark> bryceh: great, thanks!
[20:33] <micahg> Sweetshark: I wonder if Friday EOD is the best time for a new LibreOffice code drop
[20:35] <bryceh> Sweetshark, upload sponsored
[20:37] <bryceh> micahg, fair point, sorry didn't see your comment before I pushed the button
[20:38] <chrisccoulson> Friday EOD is actually the best time for a new LO code drop, because you won't have to worry about it for 2 days if it blows up :-)
[20:38] <chrisccoulson> j/k ;)
[20:38] <bryceh> hehe
[20:38] <bryceh> well, for better or worse the upload got rejected
[20:38] <micahg> \o/
[20:39] <chrisccoulson> in any case, doesn't it take pretty much the entire weekend to build?
[20:39] <micahg> I thought it was down to just over a day on teh pandas
[20:40] <micahg> yep, ~31 hours
[20:40] <bryceh> Sweetshark, I've emailed you what LP sent back.  For some reason it didn't pick up the various tar.gz files
[20:40] <bryceh> (did you run debuild -S -sa ?)
[20:46] <bryceh> going to run it through pbuilder and maybe a ppa first, for now.
[20:47] <bryceh> Sweetshark, out of curiousity, how is testing handled with libreoffice uploads for ubuntu?
[20:47] <Sweetshark> bryceh: gah, yes. I didnt switch back to -sa for the new upstream upload.
[20:48] <Sweetshark> mom
[20:48] <ScottK> micahg: If Thursday, way past COB is a good time to break the archive, I think Friday COB is a great time for an LO upload.
[20:49] <bryceh> Sweetshark, also, even with the -sa added my pbuilder is croaking on it
[20:50] <bryceh> (which admittedly might be local pbuilder borkage)
[20:51]  * bryceh chucks it into ppa:bryce/lo-3.5.1
[20:52] <Sweetshark> bryceh: I am always building on a pbuilder here (one for the source package and one for the binary build). The debs build from that then are smoketested in a VirtualBox (open some document etc.)
[20:55] <Sweetshark> (the pbuilders are kicked off from a jenkins instance)
[20:56] <Ampelbein> mfisch: re-ping!
[20:57] <bryceh> hmm, my pbuilder still operates on X packages ok
[20:59] <bryceh> libexttextcat-dev (>= 3.1.1) maybe?
[21:01] <mfisch> Ampelbein: I have an update on a ftbfs that you worked on bug #935385
[21:01] <mfisch> Ampelbein: unfortunately, I don't know how to proceed, I'm not sure I have the ability to pull and then post a new upstream version
[21:03] <Ampelbein> mfisch: Everyone can pull current packaging and propose a merge via the sponsorship process.
[21:03] <Ampelbein> mfisch: Let me quickly check that report.
[21:17]  * Sweetshark watches ppa build
[21:24] <Sweetshark> bryceh: the ppa seems to build, doesnt it? did it break earlier at your local pbuilder?
[21:26] <bryceh> Sweetshark, yeah looks like it's doing better in the ppa
[21:26] <bryceh> Sweetshark, yeah in pbuilder it terminates on unsatisfied deps, even after freshly updating it.  One of the packages is 'uninstallable'
[21:28] <bryceh>                                  Depends: libexttextcat-dev (>= 3.1.1) but it is not installable
[21:28] <lborda> Hi guys, I am running precise (upgraded from oneiric) and one of the updates crashed unity. I was able to upgrade the packages again but now every time I press right-click on the mouse unity crashes and restart again... Any idea?
[21:29] <bryceh> lborda, collect backtrace, file a bug
[21:29] <Sweetshark> bryceh: strange, I remember having that too, but it was transitional.
[21:30] <bryceh> libexttextcat-dev  precise  3.2.0-1ubuntu1
[21:30] <lborda> bryceh, should I use use ubuntu-bug unity ?
[21:30] <bryceh> lborda, yes
[21:30] <lborda> alright tks
[21:30] <Sweetshark> bryceh: libexttextcat was only recently MIRed, maybe your mirror does somehow missed out on that?
[21:30] <bryceh> ah, could be
[21:30] <Sweetshark> s/does/did/
[21:30] <bryceh> yep, showing it in universe
[21:32] <bryceh> Sweetshark, this is pulling from us.archive.ubuntu.com
[21:32] <micahg> Sweetshark: it's still in universe
[21:32] <Sweetshark> micahg: indeed.
[21:33] <Sweetshark> https://bugs.launchpad.net/ubuntu/+source/libexttextcat/+bug/938582
[21:33] <micahg> well, nothing is depending on it
[21:34] <micahg> oh, hmm, there is a recommends
[21:34]  * micahg wonders why that's not on component-mismatches
[21:40]  * Sweetshark is a bit confused by the MIR being "Fix Released", although it is not in main yet.
[21:44] <slangasek> Sweetshark: because pitti promoted it to main before it was seeded, which means the next archive admin to come along demoted it back to universe ;)
[21:45] <Sweetshark> slangasek: nasty archive admins!
[21:45] <Sweetshark> slangasek: should I reopen the MIR?
[21:45] <slangasek> no
[21:45] <slangasek> is there something that pulls it into main now?
[21:45] <bryceh> slangasek, libreoffice
[21:46] <slangasek> i.e., has the LibO that uses it been uploaded?
[21:46] <bryceh> slangasek, no, it doesn't build in my pbuilder due to the missing dep, so I've hesistated uploading it
[21:46] <slangasek> ah
[21:46] <slangasek> bryceh: can you turn universe on for testing in your pbuilder?
[21:46] <slangasek> although... how long is a build test of this going to take? :)
[21:46] <bryceh> slangasek, I popped it into a ppa where it appears to be building ok
[21:46] <slangasek> ok
[21:47] <Sweetshark> slangasek: I am always building in a pbuilder here fwiw
[21:47] <slangasek> yeah - component mismatches don't block being able to build with pbuilder
[21:47] <slangasek> it's just bryce's particular pbuilder config
[21:47] <slangasek> anyhoo
[21:47] <slangasek> if someone gets that uploaded to precise, I can take care of the promotion straight away
[21:48] <bryceh> slangasek, build logs going @ https://launchpad.net/~bryce/+archive/lo-3.5.1/+packages
[21:48] <bryceh> slangasek, shall I wait until that ppa has finished building, or does it look ok to send it in now?
[21:48] <Sweetshark> slangasek: 15min for the source, 2:10h for the binary build with ccache (on a quad i7 notebook with 16GB RAM). 3:30h without ccache.
[21:49] <slangasek> bryceh: I would be inclined to upload it straight away
[21:49] <bryceh> slangasek, micahg also raised the issue of it being past COB Friday... worth waiting until monday?  since it takes so long to build anyway, perhaps it doesn't matter?
[21:49] <slangasek> what's the build-time on armel?
[21:50] <bryceh> slangasek, alright.  I'm comfortable with that given Sweetshark's testing practices
[21:51] <bryceh> micahg, your thoughts?  still think it being friday is a red flag?
[21:52] <slangasek> bryceh: if the world explodes after you upload, are you going to be around to help clean it up? ;)
[21:52] <micahg> slangasek: arm* build time on the pandas is 31 hours
[21:52]  * slangasek nod
[21:52] <slangasek> so I think it would be a good idea to get it built over the weekend
[21:52] <Sweetshark> fyi, the oneiric backport ppa builds took 6:38h on i386 and and 6:40h on amd64.
[21:52] <micahg> right, that's the questions if bryceh or someone else and Sweetshark are committed to being around to fixing issues, I don't have a problem with it
[21:52] <bryceh> slangasek, I'll be gone much of the day Saturday but am here for the next 4 hrs at least
[21:52] <Sweetshark> arm build time is why I would like to have this in before the weekend ;)
[21:53] <slangasek> I can keep an eye out tomorrow
[21:53]  * micahg would think with the package's history, it would be more prudent to upload very early monday
[21:54] <micahg> i386/amd64 hit Monday, everything else tuesday
[21:54] <micahg> but if there's coverage for breakage, then it doesn't matter when
[21:55] <Sweetshark> its 2300 local here. I can be around tommorrow till around noon but not later. sunday i could be on guard.
[21:56] <bryceh> I'd be willing to pop in to do the upload Saturday night my time.  Should only take a few minutes, not a big deal
[21:56] <bryceh> not sure what plans I have for sunday, but probably will be checking in periodically
[21:57] <Sweetshark> bryceh: that would be great. I would be around to take the bullets when it finishes then ...
[21:59] <micahg> Sweetshark: re libexttextcat> sometimes, things get promoted prematurely, but then get demoted since nothing depends on it
[21:59] <micahg> they
[22:00] <micahg> * they're supposed to remain Fix Committed until it's seeded or depended on
[22:00] <micahg> but there is a recommends in this case, so I have no idea
[22:00] <Sweetshark> micahg: k
[22:01] <Sweetshark> just leaving stuff as is then for now
[22:01] <mterry> Is there an easy way to test software under a VPN?  (like a demo VPN test server somewhere?)
[22:01] <Sweetshark> micahg, bryceh, slangasek: thank you very much.
[22:01]  * Sweetshark wanders of for the night.
[22:01] <bryceh> Sweetshark, great sounds like a plan, will pick it up Sat night


[00:24] <Ahmuck> k, so i was looking for linux entertainment, specifically linux or something that could be adapted via wine
[00:24] <Ahmuck> but more on the linux side.
[00:24] <Ahmuck> preferably educational, but not necessarily
[00:24] <Ahmuck> and i ran accross this site
[00:25] <Ahmuck> http://www.mygamecompany.com/Products/main.htm
[00:25] <Ahmuck> i'm not sure what to make of the "fasion" game set
[00:25] <Ahmuck> it's ...
[00:26] <Ahmuck> ah, and another, american history
[00:26] <Ahmuck> the problem with history, is it's usually written by those in power, or recorded anyhow and doesn't really show what happend
[02:13]  * HedgeMage returns
[07:35] <nubae|work> join #sugar
[07:36] <nubae|work> ooops
[17:35] <LaserJock> highvoltage: around?
[17:49] <highvoltage> hi LaserJock
[17:50] <highvoltage> LaserJock: I updated the image and installed it in a VM last night
[17:50] <LaserJock> highvoltage: I committed a change to the DVD seed last night to hopefully get edubuntu-desktop and friends onto the live system
[17:51] <highvoltage> LaserJock: It has one or two odd problems, like while it's starting up, it gives the message that you must press enter to eject the tray, etc
[17:51] <LaserJock> highvoltage: I was trying to check whether today's build had the edu stuff or not
[17:51] <highvoltage> but when I pressed enter it continued booting fine
[17:51] <highvoltage> I guess it might be a generic ubuntu problem, I'll check up
[17:52] <LaserJock> highvoltage: yeah, those are the kind of issues I was afraid of
[19:35] <bencrisford> ello
[19:35] <bencrisford> hi sbalneav_
[19:45] <sbalneav_> Hello bencrisford


[13:13] <seb128> tseliot: is bug #297706 really a g-c-c bug? or is that a bug in the tool which does set the virtual setting
[13:43] <tseliot> seb128: it can't be a bug in the python part since we calculate the virtual resolution in the C part
[13:44] <seb128> tseliot: ok, I didn't look at the code and it's not clear to me what code does what there
[13:45] <tseliot> seb128: anyway I'll ask the user to try again
[13:45] <seb128> tseliot: thanks
[13:47] <tseliot> you're welcome
[15:42] <superm1> bryce, ping
[15:43] <superm1> bryce, regarding that vbios on the 1535, i'm assuming the vbios should remain identical regardless of the LCD used on it, so i can add in a vbios from a "functional" machine?
[15:46] <bryce> superm1, I'm assuming it needs to be from an afflicted machine
[15:46] <superm1> okay well i won't bother then