[00:05] <maxb> hallyn: http://package-import.ubuntu.com/ can show you packages the importer is currently errorring on, libvirt being one of them
[00:06] <maxb> In this case it looks like some sort of bug in bzr-builddeb's code
[00:40] <infinity> lifeless: Nah, it's just on my list of things to informally chat with mvo about, no big deal.
[05:19] <didrocks> good morning
=== calc is now known as Guest60078
=== calc is now known as Guest72138
=== tkamppeter_ is now known as tkamppeter
=== Quintasan_ is now known as Quintasan
=== smb` is now known as smb
[08:19] <bambee> hi, http://paste.ubuntu.com/658502/ <-- an idea ?
[08:31] <hrw> hi
[08:32] <hrw> can someone maintaining networkmanager look at bug 819700 and tell me how to help?
[08:32] <ubottu> Launchpad bug 819700 in network-manager-applet (Ubuntu) "NM applet does not lists networks" [Undecided,New] https://launchpad.net/bugs/819700
[08:35] <debfx> bambee: could you try reinstalling virtualbox-dkms
[08:36] <geser> hrw: cyphermox takes care of network-manager
[08:36] <hrw> geser: thx, will wait for him to wake up
[09:23] <bambee> debfx: trying
[09:26] <bambee> debfx: good point, it's fixed, thanks
[11:13] <tkamppeter> I am packaging CUPS 1.5.0 and the saemon segfaults. If I start it from the command line ("sudo cups -F") it does not dump core, even after "ulimit -c 9999999". How do I get a core file?
[11:13] <tkamppeter> s/saemon/daemon/
[11:14] <geser> tkamppeter: IIRC you had so set a value in /proc else the core dump gets routed to apport
[11:16] <tkamppeter> geser, thanks, found a solution: Run the command in a root shell.
[11:17] <tkamppeter> geser, did not core, what do I have to set in /proc exactly
[11:21] <geser> tkamppeter: echo core > /proc/sys/kernel/core_pattern
[11:21] <geser> currently it should contain a pipe to apport
[11:25] <tkamppeter> geser, yes
[11:26] <tkamppeter> geser, I tried your command and could not find the core, then I tried to set /tmp/core and did not ghet a core in /tmp ...
[11:26] <geser> hmm
[11:28] <tkamppeter> geser, switched AppArmor to complain and also does not help.
[11:37] <geser> and the root shell you run "cups -F" from doesn't have a core limit set? (just to be sure)
[11:41] <tkamppeter> geser, I had set "ulimit -c 9999999" there, too.
[11:45] <geser> why not set it to "unlimited" in your root shell? but I guess that's not the reason why you don't get a core file
=== MacSlow is now known as MacSlow|lunch
[11:46] <tkamppeter> geser, thanks. Tried it now and did not work, too. Seems to be a kernel bug generally preventing to generate core files.
[11:50] <geser> might one of our security features prevent it too?
[11:52] <tkamppeter> geser, seems that I have to switch back to apport and create a bug report on code which was never uploaded, only to extract a core ...
[11:52] <geser> urgs
[11:53] <tkamppeter> geser, or is there a possibility to extract the core from /var/crash/_usr_sbin_cupsd.0.crash without sending it to Launchpad?
[11:55] <geser> "apport-unpack: Unpack a report into single files (one per attribute). This is most useful for extracting the core dump." (from https://wiki.ubuntu.com/Apport)
[11:58] <tkamppeter> geser, that's it. Got access to a core by that. Thank you very much.
[12:00] <geser> np
=== vila_ is now known as vila
=== kentb-out is now known as kentb
[13:31] <ahasenack> Spads: ping
[13:31] <ahasenack> Spads: nm, wrong nick
[13:31] <ahasenack> SpamapS: ping
[13:32] <ahasenack> SpamapS: can you give me an update on the landscape-client lucid sru? I think it has been in proposed for a week now
[13:35] <cyphermox> hrw: am here now.
=== MacSlow|lunch is now known as MacSlow
[14:04] <hrw> cyphermox: can we talk in 0.5h? meeting in progress
=== dendro-afk is now known as dendrobates
[14:08] <cyphermox> sure, just ping me
[14:10] <hrw> ok
[14:16] <apw> cjwatson, what defines which modules are packaged up for the live initramfs used by casper ?
=== Ursinha-afk is now known as Ursinha
[14:29] <kees> tkamppeter, geser: I didn't read full backscroll, but you can't get a core dump out of a proces that has changed uid. you can bypass this by setting /proc/sys/fs/suid_dumpable to "1", though, but it will leave a system rather exposed to local attacks.
[14:32] <tkamppeter> kees, so better to use the apport-unpack method.
[14:34] <kees> tkamppeter: well, apport won't see a core dump at all for processes that have made uid transitions, iirc
[14:35] <kees> tkamppeter: but if you have a reproducible crash, you can temporarily set the flag, crash the service, let apport catch it, then restore the flag
[14:40] <tkamppeter> kees, no chance, I do not get a core.
[14:42] <kees> tkamppeter: hm, dunno
[14:47] <infinity> apw: It's just a default initramfs-tools config, unless something's changed, so it will be "modules=most" in initramfs.conf.
=== dendrobates is now known as dendro-afk
[14:48] <apw> infinity, ahh thanks, obvious
[14:49] <infinity> apw: Following that codepath in update-initramfs is fairly self-evident, I assume :)
[14:49] <infinity> apw: Are we missing anything specific, or was the question purely educational?
[14:51] <apw> infinity, yeah we may be missing a new module, will go and look at it, thanks
[15:15] <mdeslaur> so, because of the accidental sync, swig2.0 in universe now has a swig package that supersedes the swig1.3 swig package in main, causing some main packages to FTBFS
[15:15]  * mdeslaur isn't sure how to fix it
[15:17] <Laney> 1.3 was removed from Debian. Follow suit?
[15:17] <mdeslaur> Laney: there are 115 reverse build depends on swig
[15:18] <mdeslaur> I don't know if they need to be fixed or not
[15:19] <Laney> there is a gotcha here https://bugs.launchpad.net/ubuntu/+source/swig1.3/+bug/682613/comments/5
[15:19] <ubottu> Ubuntu bug 682613 in swig1.3 (Ubuntu) "Transition to swig2.0?" [Wishlist,Expired]
[15:22] <SpamapS> ahasenack: yes! I will go ahead and release it today
[15:22] <mdeslaur> Laney: ouch :(
[15:22] <Laney> mdeslaur: indeed, but Debian apparently made the switch anyway …
[15:23] <mdeslaur> Laney: I guess switching is the less painful solution
[15:23] <Laney> you could revert
[15:23] <apw> when something builds for i386, that includes the any packages as well right?  or more specifically, we always do the equivalent of dpkg-buildpackage -b on i386 and -B on everything else ... right ?
[15:23] <mdeslaur> Laney: how? bump swig1.3's version to 2.0.really.1.3 or something?
[15:24] <Laney> mdeslaur: it's 2.0 that's the problem, right?
[15:24] <mdeslaur> Laney: yeah
[15:24] <Laney> oh, hm, but the swig binary will have to increase in version
[15:26] <SpamapS> ahasenack: landscape-client should show up in -updates soon
[15:26] <Laney> mdeslaur: maybe do test rebuilds and decide from there
[15:26] <SpamapS> I maintain one of those packages that is broken regarding swigh 1.3 vs 2.0 autoconf check..
[15:27] <SpamapS> swig even
[15:27] <Laney> how did Debian go ahead if it's that badly broken?
[15:27] <SpamapS> Its not swig that is badly broken, but the old autoconf rules
[15:27] <SpamapS> and because they have about 1.5 years left till release. :)
[15:27] <Laney> exposed by changing the version though?
[15:27] <Laney> the release team usually still cares about such things :-)
[15:27] <maco> 2.0~really1.3 is how im used to seeing it be done
[15:27] <SpamapS> Its a transition really..
[15:28] <Laney> +really.., but you can't do that here
[15:28] <maco> oops
[15:28] <Laney> swig1.3 needs to reclaim the swig binary package, and versions can't go backwards
[15:28] <SpamapS> The fix is fairly small.. I did it for gearman-interface already..
[15:28]  * maco is not thinking about sort rules today
[15:28] <maco> oh the number is in the name?
[15:29] <Laney> both versions were coexisting for some time, with 'swig' providing the default
[15:29] <Laney> that got switched in this accidental sync and broke stuff
[15:29] <Laney> SpamapS: you think the transition is doable?
[15:29] <SpamapS> I don't know the scope of it
[15:29] <SpamapS> For my one package, it was a small patch
[15:30] <mdeslaur> Laney: so, we remove the swig package from swig2.0, and rename swig1.3-1.3.40 to swig1.3-2.0+really1.3.40
[15:30] <mdeslaur> well, 2.0.4+really1.3.40
[15:30] <SpamapS> -  AC_PROG_SWIG(1.3.31)
[15:30] <SpamapS> +  AX_PKG_SWIG(1.3.31)
[15:30] <Laney> mdeslaur: right, revert swig2.0 to what it was before and bump swig1.3 to something >> the current version of swig2.0
=== dendro-afk is now known as dendrobates
[15:30] <SpamapS> And build-depend on autoconf-archive
[15:31] <SpamapS> or drop the new ax_pkg_swig.m4 in m4
[15:31] <Laney> it sounds like this would break most of the swig-using packages; I don't think we can do this unless someone volunteers to lead it
[15:32] <mdeslaur> Laney: you mean the transition? if we don't revert?
[15:32] <SpamapS> Its tough to even find them because they don't end up Depending on swig .. its a build-dep only.
[15:32] <Laney> yeah
[15:32] <Laney> SpamapS: we can determine that easily enough
[15:32] <mdeslaur> SpamapS: the "reverse-build-depends" script figures that out nicely
[15:34] <SpamapS> I knew it existed, but never went looking for it. :)
[15:34] <mdeslaur> SpamapS: it's in ubuntu-dev-tools now
[15:34] <SpamapS> OUCH.. 107
[15:35] <Laney> but like I said, I don't know how many of those are actually busted
[15:35] <SpamapS> Could we possibly do a mass rebuild *now* ... note the ones that fail, then do the reverting?
[15:35] <Laney> that would be ideal
[15:36] <mdeslaur> heck, maybe we'll get lucky and they've all been fixed already in debian :P
[15:37] <SpamapS> I know mine isn't, because I've been waiting for a sponsor. ;)
[15:37] <SpamapS> an lazy
[15:37] <SpamapS> and
[15:38] <Laney> do you have one lined up?
[15:40] <ahasenack> SpamapS: thanks! (re: landscape-client)
[15:40] <apw> u
[15:40] <czajkowski> hey just sent a message to -devel if it could be moderated I'd appreciate it, thanks.
[15:41] <apw> infinity, you'll likley know this, does i386 build -B instead of -b when there are no Arch: all packages ?
[15:41] <mdeslaur> Laney, SpamapS: so, who can do the test builds, and the fix, etc.?
[15:41] <Laney> not me I'm afraid
[15:41] <Laney> (building machine is down temporarily)
=== ara_ is now known as ara
=== beuno is now known as beuno-lunch
[16:15] <micahg> mdeslaur, Laney, SpamapS I would suggest dropping the swig package from 2.0 and doing the version bump on 1.3, that way packages can transition if they're ready, but might want to ask the release team as suggested to be sure
[16:15] <Laney> I'd just like the data
[16:15] <Laney> but in the absence of that to revert
[16:18] <mdeslaur> ok, I'll do it on monday if nobody gets around to it before then
[16:19] <mdeslaur> slangasek: ^ any thoughts/objections?
[16:22] <slangasek> mdeslaur: lacking context :)  -vv?
[16:23] <slangasek> ah, fake upstream version bump on swig 1.3 to restore compatibility?
[16:23] <mdeslaur> slangasek: because of the unfortunate merge, swig2.0 in universe now owns the swig package, instead of swig1.3
[16:23] <slangasek> and we don't want to just carry on and fix up the regressions this introduced?
[16:24] <mdeslaur> slangasek: well, that's the question...there are 115 reverse build deps...more info in bug 862613
[16:24] <ubottu> Error: Launchpad bug 862613 could not be found
[16:24] <mdeslaur> bug 682613
[16:24] <ubottu> Launchpad bug 682613 in swig1.3 (Ubuntu) "Transition to swig2.0?" [Wishlist,Expired] https://launchpad.net/bugs/682613
[16:24]  * slangasek nods
[16:24] <infinity> apw: The buildds have no way of knowing in advance if there will or won't be arch:all packages, i386 always builds with -b, and other arches always with -B
[16:25] <micahg> infinity: don't you mean the reverse?
[16:25] <infinity> mdeslaur: The transition would (in theory) be preferrable, but yeah, only if we think it's something we can commit to doing in time.
[16:25] <slangasek> mdeslaur: do we necessarily need to get swig1.3 out of the archive at the same time as fixing up the things that depend on swig?
[16:25] <slangasek> or can this be a soft transition across releases?
[16:26] <infinity> micahg: No.
[16:26] <micahg> infinity: sorry, you're right :)
[16:26] <mdeslaur> well, I don't really want to ship oneiric with 60 packages that FTBFS because of swig
[16:26] <mdeslaur> I'm the security guy, remember ;)
[16:26] <Laney> slangasek: it's because the 'swig' binary package (which provides the default) moved from 1.3 to 2.0
[16:26] <Laney> this is what most packages BD on
[16:26] <slangasek> mdeslaur: right, I was suggesting we fix up those with coordination w/ Debian; but if it's that many, yeah, probably better to revert
[16:27] <Laney> so you can't really soft transition it
[16:27] <slangasek> mdeslaur: also, swig2.0 is not migrating to testing in Debian because of two new RC bugs - so it's not considered releasable there
[16:27] <mdeslaur> either someone takes it, and does test rebuilds and fixes them, or I revert it
[16:27] <slangasek> so +1 for the mock-up version
[16:28] <mdeslaur> ok, cool. thanks slangasek, Laney, infinity, micahg
[16:28] <Laney> one of the rcbugs is this configure problem
[16:29] <Laney> (I think)
[16:30] <ryanakca> Is there an equivalent to http://snapshot.debian.org/ for Ubuntu? I'm looking for easy access to at least all binary package names of all Ubuntu releases across time, and preferably the contents of said packages across time.
[16:31] <Laney> no, but that would be cool
[16:31] <slangasek> ryanakca: not really; we let the launchpad librarian keep track of all that for us, but while there's a per-package history index, there's nothing that gives you a time-based index AFAIK
[16:32] <infinity> Yeah, even using lplib, you'd be stuck walking source package publishing histories, I imagine.
[16:34] <ryanakca> Laney: Well, I'm willing to dump the database I'll have somewhere if you'd like it.
[16:34] <ryanakca> slangasek, infinity: Thanks.
[16:35] <ryanakca> On a side note, should I ask in #launchpad before fetching all of this data?
[16:36] <infinity> If you can DoS one of our appservers with a single lplib client, we'd be curious to know about it, I imagine.
[16:37] <ryanakca> infinity: Alright ;)
[16:45] <bdmurray> stgraber: is bug 819624 fixed now?
[16:45] <ubottu> Launchpad bug 819624 in casper (Ubuntu Oneiric) "casper doesn't configure autologin for lightdm properly" [High,Confirmed] https://launchpad.net/bugs/819624
=== dendrobates is now known as dendro-afk
[16:56] <Daviey> skaet: just to confirm, I am happy with the current server and cloud images for A3.
[16:56] <skaet> Daviey,  thanks!
[16:56] <stgraber> bdmurray: I think this particular one is. xubuntu still won't have working autologin but that's another lightdm bug (lightdm hardcodes "ubuntu" as the session, so won't start xfce)
=== beuno-lunch is now known as beuno
=== dendro-afk is now known as dendrobates
[17:33] <bdmurray> slangasek: does bug 816117 seem sru'able to lucid to you?
[17:33] <ubottu> Launchpad bug 816117 in ifupdown (Ubuntu) "Files installed by ifupdown in /etc/init should be conffiles" [Medium,Triaged] https://launchpad.net/bugs/816117
[17:35] <slangasek> bdmurray: yes, though I think the SRU itself will clobber any local changes the user has made in lucid, so it probably should only be SRUed if there's some other change needed to the package in lucid
[17:36] <slangasek> bdmurray: I'm also surprised that he needed to edit this particular script to get his ppp working; would be best if he could file another bug report explaining why
[19:06] <Keybuk> jhunt_: I'm starting the countdown
[19:07] <jhunt_> Keybuk: ?
[19:08] <Keybuk> you've posted the notes to upstart-devel
[19:08] <Keybuk> Lennart reads upstart-devel
[19:08] <jhunt_> :)
[19:08] <Keybuk> so I'm going to time how long it takes him to reply
[19:08] <Keybuk> in his usual style, of course
[19:09] <davmor2> Keybuk: and 3.......2.........1............RANT!
[19:10] <davmor2> Keybuk: you sure it's not an auto-reply?
[19:15] <juliank> Keybuk: Everyone knows that systemd is better, so why are still working on it, just switch over, damnit! ?:)
[19:17] <Keybuk> juliank: I imagine he'll throw something like "oh, now you're going to use cgroups; why not just use systemd?" certainly
[19:17] <Keybuk> I'm not sure he'll be able to find anything in jhunt_'s mail that constitutes "a personal attack", but I'd still put money on him making that accusation in his reply
[19:18] <Keybuk> perhaps instead saying things like "after all the personal attacks from the Upstart community"
[19:18] <Keybuk> and I look forward to finding out what new obscure English word he's learned this week that he'll use repeatedly in his reply ;-)
[19:18] <juliank> "after all the personal attacks from the Upstart community, they are now copying MY ideas,"
[19:21] <Keybuk> that's not really Lennart's style
=== dendrobates is now known as dendro-afk
[19:33]  * jhunt_ goes to polish and oil his panoply...
[19:34] <tkamppeter> Can someone help me with building a package? I have problems on the linking step.
[19:34] <tkamppeter> It is argyll from this PPA: https://launchpad.net/~pmjdebruijn/+archive/ppa
[19:34] <tkamppeter> It builds on Natty but not on Oneiric.
[19:34] <tkamppeter> I need it to build on Oneiric to include it as part of the new Color Management support.
[19:36] <tkamppeter> Problem is probably the new Gold linker. all needed libraries are specified with "-l..." on the command line but the linking fails.\
=== dendro-afk is now known as dendrobates
=== hggdh_ is now known as hggdh
[20:31] <ryanakca> Is there a list of source packages that have been removed from the archive?
=== bambee_ is now known as bambee
[21:01] <ahasenack> hi guys, when does one use "+" in the version/release of a package? I'm trying to understand that
[21:01] <ahasenack> I kind of understand that something called 1.1~1234 could mean "revision 1234, working towards releasing version 1.1"
[21:01] <ahasenack> so that when 1.1 is finally released, it will upgrade any 1.1~revno
[21:01] <ahasenack> is there a similar use case for "+"?
[21:02] <ahasenack> something like "1.1+1234" which could mean "revision 1234 of the 1.1 stable branch"?
[21:02] <ahasenack> since 1.1+1234 is higher than 1.1?
[21:03] <slangasek> ahasenack: yes, 1.1+1234 sorts higher than 1.1 and lower than 1.1.1, so is generally suitable
[21:03] <micahg> ahasenack: yeah, generally, pre-release vs post-release snapshots
[21:03] <ahasenack> hmmmmm
[21:03] <ahasenack> micahg: good terminology
[21:03] <slangasek> (however, 1.1+1234 sorts higher than 1.1a, so care must be taken to not trip over upstream versioning conventions)
[21:04] <ahasenack> I was looking at how a packaging branch revision could be added to a debian version/release in a package
[21:04] <ahasenack> the recipes have this example: deb-version 1.0+{revno}-0ubuntu0+{revno:packaging}
[21:05] <ahasenack> I just hit a problem because I was only using the code revision, not the packaging revision, and the packaging branch changed and the upload failed then
[21:05] <slangasek> 0ubuntu0+{revno:packaging} would not be typical IME, but I don't see anything against it offhand
[21:05] <ahasenack> slangasek: would you have another suggestion about how to use both revision numbers in the versioning?
[21:06] <ahasenack> slangasek: considering I have one branch for the code and another branch for the debian/* parts
[21:06] <slangasek> if this isn't the authoritative branch for packaging for this work, using 0+{revno:packaging} could be ambiguous and confusing
[21:06] <slangasek> but other conventions give only incremental improvement in that regard
[21:07] <ahasenack> ok, I would need to put my stamp in there somewhere, like ~ppa is used for ppa builds
[21:07] <ScottK> Even if it is the authoritative branch, bzr revision numbers can change.
[21:07] <slangasek> right, ~ppa<serial> is more typical
[21:07] <ahasenack> or ~landscape in my case, I have seen some use that convention too
[21:07]  * slangasek nods
[21:08] <ahasenack> but in the recipe example, the packaging revision is added to the package release number, not version
[21:08] <ahasenack> is there any preference regarding that?
[21:08] <ahasenack> or, what about just concatenating both in the version? Like 1.0+{revno}+{revno:packaging}-0ubuntu0?
[21:09] <slangasek> that implies a new upstream tarball for every packaging change
[21:09] <ahasenack> ah, good point
[21:09] <ahasenack> I knew there was a reason :)
[21:09] <slangasek> 1.0+{revno}-0ubuntu0+<something> would be preferred
[21:09] <slangasek> or 1.0+{revno}-0ubuntu1~<something>
[21:09]  * Daviey write a ppa-version-o-matic in go. </jest>
=== dendrobates is now known as dendro-afk
[21:10] <ahasenack> so, hmm
[21:12] <ahasenack> 1.0+{revno}-0ubuntu0+{revno:packaging}~landscape1, so I have both revnos in there (and daily builds work), and the ~landscape identifier/stamp
[21:12] <ahasenack> and the recipe will still add ~<ubuntu-release>1 to all that
=== yofel_ is now known as yofel
=== apachelogger_ is now known as apachelogger
[21:16] <slangasek> ahasenack: it does strike me as odd to encode the bzr revno of the packaging branch in the version number, especially considering debian/changelog is conventionally maintained in the VCS so there's a bit of a circular dependency there - are you autogenerating debian/changelog?
[21:16] <ahasenack> slangasek: no, the idea is to have daily builds and when we cook up a release, then populate debian/changelog with real data
[21:17] <slangasek> ok
[21:18] <slangasek> IMHO an auto-incrementing serial is more practical for this than encoding the packaging revno
[21:19] <ahasenack> slangasek: a timestamp, then. Recipes don't have autoincrement serials
[21:20] <slangasek> oh, so these recipes are for how to construct a version that doesn't itself get committed to debian/changelog on the packaging branch
[21:20] <slangasek> so in that sense you are autogenerating :)
[21:20] <slangasek> that's perfectly ok then
[21:20] <ahasenack> slangasek: hmm, true
[21:20] <ahasenack> slangasek: I mean launchpad recipes, if that wasn't clear
[21:21] <slangasek> I'm afraid I know nothing about how launchpad recipes work
[21:22] <ahasenack> slangasek: np, it's the versioning that always confuses me, there are several policies about that. It's one thing to read the dpkg version comparison rules, but another to see how they are being used in real life
[21:23] <ahasenack> or should I say, best practices, not policies
[21:23] <slangasek> yeah :)
[21:23] <ahasenack> is there a doc about these best practices? Or just the policy manual? For example, the ~ppa suffix
[21:24] <slangasek> I don't know of any documentation anywhere about ~ppa versioning conventions
[21:24] <ahasenack> ok
[21:24] <slangasek> it might exist, but I haven't read it
[21:24] <ahasenack> I'll keep going, thanks a lot for your help
[21:24] <slangasek> sure thing :)
[21:28] <maxb> It seems to me that the ~ppa versioning convention is usually used incorrectly
[21:29] <maxb> The problem seems to be that people who don't really understand dpkg versions have seized on it as the only possible way, even to the extent of using ~ as a default separator. Which it really isn't
[21:30] <ahasenack> the idea was to make sure the ppa version was lower than the released one, thinking that the PPA can only be used for backports
[21:30] <maxb> Ah, good
[21:30] <ahasenack> is that what you mean?
[21:30] <maxb> Someone has apparently redrafted https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage to remove the ~ppa sillyness
[21:31] <ahasenack> ah, cool!
[21:31] <ahasenack> it mentions "+" :)
[21:31] <ahasenack> I will give it my full attention
[21:31] <ahasenack> maxb: thanks for that
[21:32]  * ahasenack -> away
[21:32] <maxb> Ultimately, though, there's no substitute for just thinking about the actual version comparisons yourself, rather than following recipes
=== ScottK changed the topic of #ubuntu-devel to: Archive: open for business | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[22:08] <hallyn> a package in main cam suggest a package not in main?
[22:08] <micahg> hallyn: yes
[22:09] <hallyn> thanks
=== Quintasan_ is now known as Quintasan
[22:12] <TheMuso> oio/c
[22:30] <TheMuso> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open for business | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
[22:34] <TheMuso> The joys of creating an account on a bugzilla instance for a project where I need to forward 1 bug to usptream.
[22:36] <micahg> TheMuso: if you get a chance, could you please look at bug 820773
[22:36] <ubottu> Launchpad bug 820773 in glew1.5 (Ubuntu) "glew1.5 shouldn't provide unversioned dev packages" [Medium,Confirmed] https://launchpad.net/bugs/820773
[22:36] <TheMuso> micahg: Will make it the next thing on my list.
[22:36] <micahg> TheMuso: great, thanks
[22:37] <TheMuso> Actually, I'll do it now. I need to wait for an email for the above referred to bugzilla account.
[22:38] <micahg> k, I just was hoping it could be done before the weekend to unblock libglew transitions and FTBFS (depwait)
[22:38] <TheMuso> micahg: Sure.
[22:45] <TheMuso> micahg: Uploaded.
[23:01] <micahg> TheMuso: thanks, hopefully this time something won't break :)
[23:03] <SpamapS> hrm.. looks like something has changed to make collectd FTBFS.. last time it built was Mar 31
[23:03] <SpamapS> it can't seem to link to libperl
[23:03] <micahg> SpamapS: new version of perl?
[23:05] <SpamapS> probably
[23:08] <micahg> SpamapS: it was missed in the perl5.12 transition: http://people.canonical.com/~ubuntu-archive/transitions/perl.html
[23:10] <SpamapS> hmm
[23:12] <SpamapS> micahg: it actually doesn't end up depending on libperl.. which is .. confusing
[23:13]  * SpamapS wonders if it statically links perl
[23:14] <SpamapS> 	libperl.so.5.10 => not found
[23:14] <SpamapS> Interesting..
[23:14] <SpamapS> the "perl" plugin does in fact link to libperl
[23:15] <RAOF> SpamapS: We obviously do something special with translation-pack SRUs.  What is it?  I'd rather like to get the natty-proposed unapproved queue down below 800 :)
[23:15]  * TheMuso prods mercurial to work faster... I should have asked for more verbose output when cloning...
[23:15] <SpamapS> RAOF: no idea, I've never seen that either.. been meaning to ask pitti
[23:16] <RAOF> A perfectly timed holiday for pitti!
[23:17] <SpamapS> RAOF: I did rummage through them and find a few that weren't langpacks. :)
[23:17] <micahg> SpamapS: it deps on libperl5.10
[23:18] <RAOF> Yeah. :)
[23:21] <SpamapS> micahg: collectd-core does not
[23:22] <SpamapS> micahg: which is where the .so that depends on libperl lives
[23:22] <micahg> right, but collectd does and should've shown up on the transition page
=== tkamppeter_ is now known as tkamppeter
=== TheDaniel0108 is now known as Daniel0108
[23:36] <SpamapS> FTBFS on Debian too
[23:36] <SpamapS> hrm
[23:36] <Keybuk> wow
[23:37] <Keybuk> since when you can strace -p 1 ?
[23:41] <broder> you...can?
[23:41] <broder> whoa
[23:41] <infinity> Not that it's usually very exciting to watch.
[23:42] <lifeless> Keybuk: meep!
[23:48] <Keybuk> it means you can go gdb -p 1 too