=== Jacky is now known as GLaDOS
=== GLaDOS is now known as Guest12539
=== emma is now known as em
=== Guest12539 is now known as Jacky
=== Adri2000 is now known as Guest74775
[11:12] <jtaylor> I'm gone nuke all recommends on blcr-dkms, I'm feed up of deduping the bugs
[11:26] <jtaylor> how could I solve the upgrade issue of users having openmpi installed?
[11:27] <jtaylor> I guess only lucid is of concern, the other upgrades have probably weeded out the package already as its broken since natty
[11:28] <directhex> what's wrong with openmpi?
[11:28] <jtaylor> that it recommends blcr
[11:28] <jtaylor> which recommends blcr-dkms
[11:28] <jtaylor> which only works with 2.6.30 kernels
[11:28] <jtaylor> there are hundreds of upgrade failure bugs
[11:29] <jtaylor> even though I added a bug pattern in natty :/
[11:30] <jtaylor> every week or two another bug makes it through
[11:30] <directhex> blcr-dkms should be more sensitive to kernel versions. i'm sure you can define a range in dkms
[11:30] <jtaylor> I never dealt with dkms yet
[11:45] <jtaylor> hm dkms failures do not harm installation, silencing it in apport directly should be enough then
[12:26] <tumbleweed> erm, silencing the bug reports presumably wouldn't make the situation any better. Then we wouldn't even know that we'd forgotten to update/remove it
[12:28] <jtaylor> we already have the bug with the most dupes in the archive to remind us
[12:29] <tumbleweed> right, I mean in future releases
[12:29] <jtaylor> nice we have an ubuntu only openmpi1.5, I wonder when that will start to bitrot
[12:30] <jtaylor> added in precise with an depend on blcr  which never worked in precise
[12:30] <jtaylor> yey testing
[12:32] <tumbleweed> :/
[12:46] <Daviey> openmpi1.5 was added for ARM support, i assume you have validated that blcr doesn't work with ARM?
[12:47] <jtaylor> does arm have a 2.6.30 kernel?
[12:47] <jtaylor> hm I think -12 even supports 2.6.34
[12:49] <jtaylor> Daviey: does blcr work without the kernel module? if yes dropping the recommend would solve a lot of issues for users
[12:50] <rbasak> Daviey: hello!
[12:50] <Daviey> rbasak: meet jtaylor.. he's looking at openmpil(1.5)
[12:50] <jamespage> Daviey, hey
[12:50] <rbasak> hello jtaylor!
[12:51] <jtaylor> hi
[12:52] <Daviey> rbasak: context, http://pb.daviey.com/Usz2/
[12:52] <jtaylor> issues is bug 804943
[12:52] <ubottu> Launchpad bug 804943 in blcr (Ubuntu) "blcr kernel module failed to build with kernel 3.0 : configure: error: --with-linux argument '3.0-x' is neither a kernel version string nor a full path" [High,Triaged] https://launchpad.net/bugs/804943
[12:52] <jtaylor> people installing openmpi get blcr which pulls blcr-dkms which is broken
[12:53] <jtaylor> given the number of dumplicates and comments users do not know how to deal with that
[12:53] <Daviey> a reasonable amount of dupes :)
[12:53] <rbasak> I've not seen this before
[12:54] <jtaylor> I guess openmpi works fine without blcr, so we could just drop the recommends from libcr0 and less users would get this ugly bug
[12:54] <rbasak> See bug 949044 for what I tested. IIRC, I tried this on amd64 and didn't run into the problem you describe.
[12:54] <ubottu> Launchpad bug 949044 in openmpi (Ubuntu) "Basic openmpi hello world fails on arm" [High,Fix released] https://launchpad.net/bugs/949044
[12:54] <rbasak> Perhaps I understand it wrong?
[12:55] <jtaylor> the issue is not really openmpi1.5, other mpi implementations also depend on blcr
[12:55] <Daviey> I've not looked into it.. but i wonder if a Pre-Depends or Breaks is required.
[12:55] <rbasak> Steps to reproduce? Just apt-get install...what?
[12:55] <jtaylor> apt-get install blcr-dkms
[12:56] <rbasak> No for the openmpi breakage. What are people trying that pulls in blcr? Sorry I can't see the LP bug - timeout
[12:56] <jtaylor> libcr0
[12:56] <jtaylor> recommends blcr-dkms
[12:56] <jtaylor> most uses autoinstall recommends
[12:56] <rbasak> So they're installing what which pulls in libcr0?
[12:57] <jtaylor> http://paste.ubuntu.com/1011215/
[12:57] <rbasak> Sorry, it would help if I could actually see the bug :-/
[12:58] <jtaylor> its got so many dupes lp probably can'T deal with it ;)
[12:58] <rbasak> Do we have to fix bugs that we can't see? :-P
[12:59] <jtaylor> really fixing it will be hard, upstream only supports 2.6.38
[12:59] <jtaylor> https://ftg.lbl.gov/projects/CheckpointRestart/
[12:59] <jtaylor> what I want to archive is to reduce the collateral damage, I don't think many users really need blcr-dkms but get it installed indirectly
[13:01] <rbasak> I can't see the whole picture right now, but it sounds to me like blcr is out of date and should be removed from Debian, and that anything that depends on it needs to be fixed
[13:01] <jtaylor> it probably will be removed from debian
[13:01] <jtaylor> if not fix turns up soon
[13:02] <jtaylor> but that doesn't help our current situation
[13:03] <rbasak> openmpi1.5 is a temporary "fork" of debian experimental, for people who wanted the ARM support it has. As soon as Debian transitions to openmpi 1.5, the plan is to drop openmpi1.5.
[13:03] <jtaylor> good
[13:04] <rbasak> https://lists.ubuntu.com/archives/ubuntu-server/2012-April/006245.html
[13:04] <jtaylor> I didn't want to imply bad maintenace, its just that so much ubuntu only stuff tends to just bitrot especially complicated stuff like openmpi is hard to handly by motu
[13:06] <jtaylor> do does anyone see an issue with just removing libcr0's recommend on blcr-dkms?
[13:06] <jtaylor> it should not break anything but save users from an error they might not know how to deal with
[13:07] <rbasak> I understand. For openmpi, I'm here to help. Some Canonical partners wanted it for ARM support, and so I'm indirectly sponsored to look after it AIUI.
[13:07] <rbasak> I don't see a problem with it, especially as it's broken already anyway, from what I understand.
[13:08] <jtaylor> k I'll do that then for quantal and precise
[13:08] <rbasak> thanks!
[13:08] <jtaylor> lucid upgraders will still get the bug
[13:09] <jtaylor> not sure how to handle that, removing the recommend in lucid will only help for new installs
[13:09] <jtaylor> and -dkms might actually work in lucid
[13:09] <rbasak> Is this kind of knowledge something that do-release-upgrade is supposed to take care of?
[13:09] <rbasak> (and if so, how does that work for universe?)
[13:11] <jtaylor> maybe adding a breaks to the linux package would get it removed in the upgrade?
[13:11] <rbasak> I think that's what Daviey was suggesting?
[13:12] <rbasak> It seems a bit horrible though. I'm new to this stuff. Is it possible for us to remove the blcr-dkms package as an exception to Debian?
[13:12] <jtaylor> the other option is just silence apport, the module build failure does not harm the upgrade process itself
[13:13] <jtaylor> removing blcr-dkms will not help on upgrades
[13:13] <jtaylor> also it might be useful to some users who install their own kernels, this is the reason its still in debian for now
[13:15] <rbasak> I'm just learning this here. Why would it not help with upgrades? If the package is gone and no other packages recommend it, wouldn't do-release-upgrade remove it?
[13:15] <geser> Laney: is ghc (from quantal) not working on armel: every haskell-* build on armel seem to fail with "Error: selected processor does not support ARM mode `movw r3,:lower16:stg_CAF_BLACKHOLE_info'" (and more similar ones)
[13:15] <Laney> geser: /every/ build?
[13:16] <jtaylor> upgrades to not remove packages
[13:16] <rbasak> My upgrades always do!
[13:16] <jtaylor> it might be a user installed package
[13:16] <Laney> geser: maybe ghc itself needs rebuilding (probably syncing) to use the armel toolchain changes
[13:16] <jtaylor> hm I'm not very familiar with upgrade procedures either
[13:17] <geser> Laney: looks like, just pick some random haskell-* armel build logs to see yourself
[13:17] <jtaylor> I though they only remove obsolete libraries
[13:17] <Laney> geser: I saw it for haskell-text and assumed the rest flowed from that
[13:17] <Laney> didn't look too deep
[13:17] <rbasak> That's what I'm thinking. What qualifies as an obsolete library, and wouldn't blcr-dkms fall into this category?
[13:17] <Laney> anyway, you can build-test and sync if you like
[13:18] <tumbleweed> rbasak: we also can't remove packages from stable releases
[13:20] <geser> Laney: I don't have an armel pbuilder for easy checking
[13:20] <rbasak> I didn't think we'd need to. What upgrade are we trying to fix here? An upgrade to Quantal, or an upgrade to something previous? Are you suggesting removing the Suggests in an SRU?
[13:20] <rbasak> s/Suggest/Recommends/
[13:20] <tumbleweed> upgrades from lucid to precise
[13:21] <Laney> geser: I wouldn't worry about that. If it builds on whatever you have then we can sync it and see if it fixes armel on the buildds.
[13:21] <tumbleweed> jtaylor: urgh, at removing the recommends from libcr0, but yes, that sounds like the sane option here
[13:21] <Laney> that or ask someone in #-arm to test for us
[13:21] <tumbleweed> rbasak: yes, he's suggesting doing an SRU
[13:22] <Daviey> Laney: Are there still no ARM MOTU porter boxes?
[13:22] <Laney> no
[13:22] <geser> Laney: I'll test build on amd64 and sync, it can't get worse for armel :) (I hope this doesn't start a new GHC transition)
[13:22] <Laney> it will
[13:22] <Laney> but we're pretty much in one anyway
[13:22] <tumbleweed> there are no MOTU porter boxes at all
[13:22] <Laney> the C arm porterbox is down too
[13:22] <Daviey> Scott was setting that up, he's had the hardware at least 18 months
[13:24] <jtaylor> filed bug 1005524
[13:24] <ubottu> Launchpad bug 1005524 in blcr (Ubuntu) "remove recommends on blcr-dkms" [Undecided,New] https://launchpad.net/bugs/1005524
[13:42] <jtaylor> uploaded to quantal and precise
[13:47] <rbasak> thanks!
[16:59] <Laney> jbicha: hey, any reason you didn't mark the arduino-mk rdep of arduino as tested?
[17:06] <jbicha> Laney: because I didn't test it, since arduino-mk seemed too difficult for me to use
[17:07] <Laney> ok
[17:18] <tumbleweed> bdrung: do we really need --vendor= and DEBCHANGE_VENDOR in devscripts? What's wrong with simply exporting DEB_VENDOR?
[17:26] <tumbleweed> bdrung: on that topic, on the plane to UDS I did some devscripts back-merging. It's incomplete, though, and still needs further tidying up http://anonscm.debian.org/gitweb/?p=users/stefanor/devscripts.git
[17:26] <tumbleweed> plus I want to figure out how necessary all those ubuntu-specific dch options are
[17:34] <geser> Laney: the same error when building ghc on armel :( https://launchpadlibrarian.net/106320724/buildlog_ubuntu-quantal-armel.ghc_7.4.1-3_FAILEDTOBUILD.txt.gz
[17:47] <bdrung> tumbleweed: i want one command line parameter to set the vendor. DEBCHANGE_VENDOR could be dropped as compromise
[17:48] <bdrung> tumbleweed: do you have some changes in the pipe for dch using distro-info?
[17:56] <bdrung> tumbleweed: can you implement following: if no vendor is specified on the command line, try to determine the vendor based on the given distribution
[18:17] <Laney> geser: well, armel has now broken both ghc and mono for q
[18:26] <tumbleweed> bdrung: you'll see some distro-info patches included in that branch
[18:26] <tumbleweed> Laney: \o/ :)
[18:30] <bdrung> tumbleweed: can you refresh your patches against master head?
[18:30] <tumbleweed> yeah must do that
[18:33] <bdrung> tumbleweed: or i can review the changes and let you commit them directly
[18:34] <bdrung> tumbleweed: you can commit part 2 of 2880f1a67 directly
[18:34] <bdrung> tumbleweed: and 304f973
[18:35] <tumbleweed> bdrung: I was intending to break them up into clearly defined and standalone patches. But in the end, it got a bit messy and there are later commits fixing mistakes in earlier ones. And it's all largely untested
[18:36] <bdrung> tumbleweed: i have some tests in the pipe
[18:37] <tumbleweed> I want to wave the substvar stuff by the other devscripts maintainers. It's a fairly invasive packaging change
[18:37] <bdrung> tumbleweed: i have some time _now_ and want to get the changes into devscripts. what workflow do you suggest?
[18:38] <bdrung> tumbleweed: the subvars stuff didn't convinced me yet
[18:38] <tumbleweed> we could also just wait for archive-reorg :P
[18:38] <tumbleweed> right now, I need to get a chicken into the oven, so you have half an hour to do whatever you want :)
[18:39] <tumbleweed> feel free to push any of that into master if you like the look of it
[18:39] <bdrung> tumbleweed: may i merge some of your changes under my name?
[18:39] <tumbleweed> sure, it's not like it's my original work. I was just extracting ubuntu changes
[18:39] <bdrung> k
[18:39] <tumbleweed> (well, much of it)
[18:40] <bdrung> tumbleweed: ping me after dinner and you will get a status update
[18:53] <bdrung> tumbleweed: pushed. afk for 2h
[19:20] <tumbleweed> bdrung: thanks
[20:20] <highvoltage> tumbleweed: where's that ubuntu conflicts page that shows packages with conflicing files again?
[20:55] <MrChrisDruif> Good evening all. How are dependencies determined for packages like epiphany-extensions?
=== soren_ is now known as soren
=== Adri2000 is now known as Guest35099
[22:15] <tumbleweed> highvoltage: http://conflictchecker.ubuntu.com/possible-conflicts/ (according to qa.ubuntuwire.org)
[22:33] <highvoltage> tumbleweed: thanks (and sorry for the random bother)
[22:34] <tumbleweed> np. If I wasn't outside swatting off mosquitos I'd have replied sooner
[22:34] <tumbleweed> bdrung: pushed some distro-info changes, btw.
[22:35] <tumbleweed> bdrung: releasing u-d-t. Screw testing, that's what users are for
[22:36] <tumbleweed> (I joke, naturally)
[22:37]  * ajmitch saves that quote
[22:38] <tumbleweed> there is quite a bit of churn, I'm sure there are still issues. But I can't see them rgiht now.
[22:46] <highvoltage> heh, at least that boosts your mosquito body count :)
[22:47] <bdrung> tumbleweed: your changes look good. what do you think about http://paste.ubuntu.com/1012276/ ?
[22:49] <bdrung> tumbleweed: hope that your upload fixes more bugs than introducing new ones ;)
[22:54] <tumbleweed> bdrung: if that works, no objection
[22:57] <bdrung> tumbleweed: that works (compare that with testHelp() for example)
[22:57] <bdrung> tumbleweed: i played user regarding bug #999727
[22:57] <ubottu> Launchpad bug 999727 in ubuntu-dev-tools (Ubuntu) "[backportpackage] -v and -m options don't work" [Undecided,Triaged] https://launchpad.net/bugs/999727
[22:57] <bdrung> :P
[23:02] <bdrung> tumbleweed: should we release distro-info 0.10?
[23:02] <bdrung> tumbleweed: what happens if python-distro-info throws an out-of-date exeption without distro-info being installed?
[23:04] <tumbleweed> move that README to distro-info-data?
[23:10] <bdrung> tumbleweed: then it will be always present
[23:10] <tumbleweed> exactly
[23:10] <bdrung> can you do that?
[23:12] <tumbleweed> bdrung: that readme assumes we'd use stable-updates (the modern volatile) but we haven't actually asked the release-team if they'd do that.
[23:13] <bdrung> tumbleweed: can you ask them?
=== Guest35099 is now known as Adri2000