[03:21] <psusi> what is the correct path to use when pushing a modified bzr branch back to lp as your personal branch?
[03:30] <lifeless> lp:~psusi/ubuntu/natty/<package>/<branchname>
[03:33] <psusi> thanks... got it... now need to figure out how to massage the bug requesting new upstream version into the right shape...
[03:34] <persia> Shouldn't need much.  If you're using UDD, doesn't need anything special for sponsoring.
[03:34] <persia> The sponsoring report includes any outstanding merge proposals into Ubuntu branches.
[03:35] <psusi> what's UDD?
[03:35] <psusi> I've updated lvm2 to the new upstream version... the one we've been using has been around for like 3 releases now and is quite old
[03:35] <lifeless> ubuntu distributed development
[03:35] <psusi> what's that?
[03:35] <psusi> 20 upstream releases old in fact
[03:37] <psusi> I requested a merge, but don't I also need a bug report to ask a core developer to do the merge?  I could have sworn there was a wiki page describing the process but now I can't find it
[03:38] <persia> psusi, If you're working with packaging branches, you're using the Ubuntu Distributed Development methods, even if you aren't aware of them by that name :)
[03:38] <persia> The current sponsoring report system collects data from two sources: 1) bugs that are subscribed to "ubuntu-sponsors", and 2) merge proposals against Ubuntu branches.
[03:39] <psusi> hehe... ok... well yea... I checked out the existing bzr branch, imported a new branch of the new upstream release, merged them, comitted, and now have pushed my changes back to lp... so now I just need to get the right procedure for requesting a core dev to review the changes and do the merge
[03:39] <persia> There's N other ways to get stuff sponsored, but those are the two that the Ubuntu Sponsors team currently supports.
[03:39] <persia> Just submit a merge proposal on LP.
[03:39] <psusi> isn't sponsors for universe?
[03:39] <psusi> ohh, ok... I did submit the merge proposal
[03:40] <persia> Sponsors is for everyone.
[03:40] <persia> There used to be separate sponsor teams for "main" and "universe", but that went away as part of ArchiveReorganisation/Permissions.
[03:40] <psusi> though there is an existing bug report that has been around for some time.. but #570374 that requests updating to a new upstream to get the new snapshot merge support... should I modify it in any way other than link to my branch?  it's bug #570374 btw
[03:41] <persia> You can verify that your request is correct by making sure it appears on http://reports.qa.ubuntu.com/reports/sponsoring/
[03:41] <persia> I think that's updated every 5 minutes or so.
[03:44] <psusi> I've been excited about getting this bloody snapshot merge support for a year now... will be really neat to be able to dist-upgrade and have the option to roll back if things don't go well
[03:45] <persia> lucidfox, Do you really want bug #92028 in queue?  Why not just upload?
[03:46] <persia> psusi, Indeed, although the next target would be finding a sane way to integrate basic one-size-fits-most LVM profiles in ubiquity.
[03:56] <psusi> persia, allocate 50% of space for initial fs, leave rest to be allocated as needed
[03:57] <psusi> when fs gets > 90% full, extend it to use another 10% of the total space... do same with snapshots
[04:02] <RAOF> You know what would work better?  btrfs snapshots.
[04:03] <RAOF> No need for that pesky up-front configuration; just format the whole drive (minus swap) and go nuts.
[04:04] <RAOF> With the *tiny* problem that btfrs' write performance falls to ~0 once dpkg starts calling fsync :)
[04:05] <ajmitch> RAOF: so it'd take about a day or two to upgrade from one release to the next? :)
[04:06] <RAOF> There's a launchpad bug where installing from the alternate cd takes upwards of 8 hours.  A day for upgrade wouldn't be out of the question.
[04:07] <ajmitch> probably a good thing that it didn't become the default then
[04:08] <RAOF> Yeah.
[04:12] <lucidfox> persia> The bug is for xchat-gnome
[04:12] <lucidfox> as is the patch
[04:13] <lucidfox> and xchat-gnome is in main
[04:15] <StevenK> RAOF: Only on btrfs?
[04:15] <RAOF> StevenK: Yeah.  It's a known regression in... 2.6.35, I think.
[04:16] <RAOF> The practical effect being that on certian not-too-uncommon write loads, btrfs' write performance dropped 10x.
[04:18] <RAOF> I can scrounge up a link if you'd like it.
[04:18] <StevenK> RAOF: Just curious is all
[04:31] <psusi> RAOF, hehe, yea, but btrfs isn't stable yet... and dpkg calling sync pretty much sucks balls everywhere
[04:32] <psusi> really need to fix that damnit
[04:32] <persia> lucidfox, Ah, I thought there was a patch for xchat there as well.
[04:33] <psusi> it sure makes updating during the development cycle a hell of a lot slower on my ssd
[04:33] <persia> It's not just ssd.  It's anything.  No cache.
[04:33] <persia> (also, language please)
[04:34] <RAOF> I don't think fsync, or a functional equivalent, is going away for dpkg.
[04:34] <lucidfox> No, no patch for xchat
[04:34] <persia> I doubt it: I've hit the other side of that bug without fsync, and that's exceedingly painful.
[04:35] <psusi> ohh, here's the wiki page on how to do this... it says to use bzr merge-upstream to get a new upstream version... I just downloaded the tarball, extracted it, added it, tagged it with upstream-revno, committed, then merged that into the current development version pulled from lp... is that the same thing?
[04:36] <psusi> it needs to.... the reason it is there is because of an ext4 bug but it makes updates painfully slow all over
[04:38] <RAOF> Some parts of dpkg want the assurances fsync provides even in the absence of filesystem bugs.
[04:41] <psusi> at the very least there needs to only be one big sync after all packages have been partially unpacked, then do the renames... rather than sync on every package
[04:41] <psusi> of course, if you are doing a snapshot upgrade, then you don't need any sycning at all... since if it gets interrupted you just roll back
[04:42] <psusi> didn't seem to be needed before the ext4 bug...
[04:46] <persia> I'd not want "just roll it back" to be the answer.  I've had interruptions as a result of postinsts, and appreciated being able to dig through the issues.
[04:46] <persia> But I've also encountered *uninterrupted* cases where reading from a file installed by dpkg happened too soon, and returned empty contents, resulting in problems.
[04:46] <psusi> I mean if the system crashes during upgrade and leaves it in an unbootable state
[04:47] <persia> I suspect that we just dealt with the fsync issues before, but once the ext4 bug appeared, and it hit *everyone*, we got around to fixing the old.bug.
[04:48] <persia> psusi, Sure, but you can also have system poweroff, certain issues with certain classes of sleep/wake arrangements, cache pressure with OOM, etc.
[04:48] <psusi> unless there is a crash/power failure fsync should not make a difference one way or the other
[04:49] <persia> Sleep gets into it more than you'd think.
[04:49] <psusi> and really, the fs should make sure that either the old version or the new version of the file are there after a crash... the fact that you can end up with a zero byte file with ext4 is a bug.. and using fsync to solve that has a horrible cost
[04:49] <psusi> what does sleep have to do with it?
[04:50] <persia> sleep/wake cycles can often detach storage, especially storage on busses that power down (USB, FW, etc.).  The local system will maintain a cached instance of a working filesystem, but may lose state in resync.  This might make a system unbootable, but is more likely just to corrupt /var/lib/dpkg/* with fairly extensive and unexpected consequences.
[04:50] <persia> Yes, these are race conditions, but still.
[04:51] <psusi> ahh, the usb disks die during suspend bug... that's a really stupid one too
[04:51] <persia> They don't really die, just lose session for a bit and don't always reattach well.  If you have no in-flight transactions, it's not an issue.
[04:52] <psusi> if they are mounted, that mount is no good anymore isn't it?  as if you had removed the disk
[04:52] <persia> And there's hotplug PCI, although few people actually use it, which is subject to the same set of issues.
[04:52] <persia> No.  I routinely sleep/wake with USB storage without needing to consider the mount.
[04:52] <persia> MMC also.
[04:53] <persia> Just in-flight write transactions don't always commit.
[04:53] <psusi> I thought that was the issue I seem to remember on lkml a while back... the usb stack makes the drive disconnect
[04:53] <persia> Sure, but drive disconnect doesn't break mount for stuff in the cache.
[04:54] <psusi> well, that is another semi-related kernel broken-ness that has been around forever and I still can't believe has not been fixed
[04:54] <psusi> if you have an open fd on the fs, when the drive is disconnected, that handle keeps it from being unmounted
[04:55] <psusi> so you can continue to see whatever is cached in ram... but until you release that handle, the device is not unmounted, which means if you put in another disk or reconnect the drive... you're stuck using a half broken mount instead of mounting the new media or correctly mounting the drive for normal read/write access
[04:55] <persia> Feels wider than that to me, but yeah.
[04:55] <persia> Reconnection always works fine for me.
[04:55] <psusi> if you have a terminal open at the time sitting in a directory on the disconnected disk?
[04:56] <psusi> when I eject a cd like that and throw another one in, the new disc won't mount until I leave the old mount directory in the terminal
[04:56] <persia> You're talking about a different disc (new one)
[04:56] <psusi> I assumed a usb hard disk disconnecting/reconnecting due to suspend would behave the same way
[04:56] <persia> I'm talking about the *same* USB/MMC storage.
[04:57] <psusi> but it doesn't know it's the same
[04:57] <persia> I think the difference is with "eject".
[04:57] <psusi> it just knows the drive vanished, so the mount now gets IO errors trying to access anything not already in the cache
[04:57]  * ajmitch should probably not suspend the laptop & unplug the external drive without unmounting it
[04:57] <persia> I think some SD can eject, and some other MMC storage can't (as I've seen differing behaviour for different SD/MMC environments).
[04:58] <ajmitch> I suspect I'll cause some interesting filesystem errors on that drive one day soon if I unplug it too early
[04:58] <psusi> ajmitch, yes, you shouldn't... but the problem is that the kernel assumes you did, so when you resume, it does  a surprise removal and reinesertion
[04:58] <persia> Dunno.  I had one machine with a SD that suspended ~15 times a day for a few months without reboot or issues with SD access.
[04:58] <ajmitch> psusi: except when I resume, I don't have that drive plugged in still :)
[04:59] <psusi> ajmitch, why not?  you just said don't remove it ;)
[04:59] <persia> ajmitch, That's fine: you'll get an error on resume, and force unmount.
[04:59] <psusi> except force unmount doesn't exist
[04:59] <ajmitch> psusi: I take my laptop to work, leave the drive at home :)
[04:59] <psusi> I still can't believe Linux can't do a forced unmount after all these years
[04:59] <ajmitch> persia: it's more an issue if there are pending writes & the filesystem isn't consistent, right?
[04:59] <psusi> NT had it figured out 15 years ago
[05:00] <persia> ajmitch, Kinda.  That's the only sort of corruption I've seen.
[05:00] <ajmitch> I only got it last week, so it's still a 1.5TB NTFS volume
[05:01]  * ajmitch should repartition & put a different fs on there, fuse & ntfs-3g aren't the best to rely on
[05:03] <psusi> I was playing some mp3s on a cd with thythmbox recently and paused the playback... and forgot I left rhhythmbox open... hit the eject button, put in another disk... and couldn't use the new disk... because the old mount could not be removed while open fds still exist, though it was detached from the namespace so you couldn't see it was still mounted
[05:03] <psusi> very frustrating...
[05:10] <persia> bugs to be fixed.
[05:10] <persia> Anyway, fsync for dpkg is a good thing for now: needs ways to be faster (by fixing the underlying bugs)
[05:11] <RAOF> As I understand it, fs transaction support would be faster and provide the reliability dpkg needs.
[05:15] <persia> RAOF, Mostly.  Still runs into hw-access stuff (unless transactions can deal with that as well).
[05:16] <RAOF> dpkg basically needs “this thing needs to hit the disc iff this other thing hits the disc”, right?
[05:18] <persia> RAOF, Essentially, yes.
[05:18] <RAOF> Which is what (btrfs) transactions purport to provide (IIUC).
[05:21] <persia> I wonder how they handle the case where hardware is detached.
[05:21] <persia> And I'm also not sure btrfs works on all hardware: doesn't it require block devices?
[05:28] <lifeless> ceph uses btrfs transactions for its metadata db
[05:28] <lifeless> so yes
[05:28] <lifeless> persia: ext3 works on non block devices?!
[05:30] <RAOF> btrfs certainly doesn't require a physical block device; loop-mounting a btrfs filesystem in stored in a file on ext4 works fine (indeed, I've preserved a broken btrfs filesystem for later analysis by just that mechanism)
[05:32] <persia> lifeless, ubifs does.
[05:33] <persia> RAOF, Ah, cool.  That makes it sound like it's flexible enough to extend to erase-block managed structures.
[06:08] <micahg> tumbleweed: patch for gnome-shell FTBFS attached
[07:54] <dholbach> Good morning!
[07:58] <ajmitch> morning dholbach
[07:58] <dholbach> hi ajmitch
[10:25] <xteejx> bug 662986 - have I done this right??
[10:27] <tumbleweed> xteejx: I still don't see a debdiff
[10:28] <tumbleweed> xteejx: also, it needs to be reported to wwwoffle upstream
[10:28] <xteejx> tumbleweed: How do I make one? I mean I didn't have an original .dsc to diff with
[10:28] <xteejx> I'm reporting it upstream now
[10:28] <tumbleweed> xteejx: pull-lp-source can give you one
[10:28] <xteejx> ahh right cool thanks :)
[10:40] <xteejyx> tumbleweed: When you said report upstream, did you mean the dev or Debian?
[10:41] <tumbleweed> xteejyx: it needs to get all the way upstream. With any luck debian never need to know about it, so I'd consider reporting to debian optional, here. If you do report to debian, tag the bug with the same usertag as the other binutils-gold fixes
[10:42] <xteejyx> Phew, I was thinking "no, why did I report it to the dev" :)
[10:50] <xteejyx> tumbleweed: bug 662986 all done :) (I think)
[10:52] <tumbleweed> xteejyx: cool. Please mention in the bug report that you forwarded it upstream (normally you would link it to the upstream bug, but wwwoffle doesn't have a bugtracker). And then subscribe ubuntu-sponsors
[10:53] <xteejyx> woohoo :)
[11:06] <ara> dholbach, yes, that was an upstream change. So I guess I have to create a patch for that
[11:11] <dholbach> ara, I guess so, with edit-patch it should be easy
[11:12] <ara> dholbach, OK, will do... later today :)
[11:12] <dholbach> :)
[12:48] <gnomefreak> is there a way to run strace on multable PIDs?
[12:49] <persia> one strace?
[12:49] <gnomefreak> yes
[12:49] <persia> Would -f do what you want, or do you need something more complicated?
[12:50] <gnomefreak> i keep getting http://paste.ubuntu.com/516206/ when using strace -Ff -tt -p <PID> 2>&1 | tee strace-<program>.log
[12:50] <persia> Oh, strace *does* accept multiple -p arguments.  That's an interesting surprise, and exactly what you need.
[12:50]  * persia likes manpages
[12:51] <persia> -f or -F should do the same thing these days, and they ought attach to the forked process.  Hrm.
[12:54] <gnomefreak> intresting thing is the output im the pastein is the same for any/all PIDs related to dpkg/xulrunner
[12:55] <persia> Something odd going on there, really.
[12:55] <persia> Maybe ask in -devel if nobody answers here in a while.
[12:56] <gnomefreak> ill wait for Micah since he wants it, xul is not configureing for te past fewe days. thanks for your help
[12:57] <persia> Alternately, try using strace -p <PID> -p <PID> -p <PID> (etc.) to see if that helps any
[12:58] <persia> Although it might be tricky to get those if you've a limited time window
[12:59] <gnomefreak> ill try in a few i need coffee :)
[13:40] <dupondje> .join #kernel
[14:47] <Gippa> hello!
[14:48] <Gippa> I'm trying to package an application that is released as tar.gz off the internet. Packaging is (quite) ok, but I'd wish to import into bazaar/launchpad to leverage it for maintaining the patches to the original code. Is there any best practice about it?
[15:27] <xteejyx> does -lzlib sound right for an LDFLAG?
[15:50] <geser> -lz
[15:51] <xteejyx> geser: Cool thanks :) Now just gotta find where to put it
[15:52] <geser> the package is named "zlib1g" but the library is libz.so.1 => -lz for linking
[15:53] <xteejyx> geser: Is there a list of these anywhere or is it just from knowledge?
[15:54] <xteejyx> And is there an easy way to find where to put it? I'm trying to look for LDFLAGS, but not helping
[15:56] <geser> the first part (the package name) is knowledge and the second part is knowledge too (of how to specify libraries for linking). I assume it's documented somewhere but I don't know of any right now.
[15:56] <xteejyx> Fair enough, guess I'll just have to keep doing them :)_
[15:56] <Bachstelze> it's just the filename of the lib*.a, minus lib and .a ;)
[15:57] <geser> IMHO LDFLAGS are are last resort as every .o gets linked to it then (perhaps unnecessarily)
[15:57] <geser> or lib*.so for dynamic linking
[15:57] <xteejyx> geser: It's the ftbfs ones in natty I'm doing (or trying to)
[15:57] <Bachstelze> right
[15:58] <xteejyx> specifically, vite
[16:00] <xteejyx> It's not something really simple for this, like hanging debian/rules from 	./configure --enable_otf in configure-stamp section to 	./configure --enable_otf --LDFLAGS lz is it??
[16:00] <xteejyx> *changing
[16:09] <geser> no, LDFLAGS is an environmental variable (similar to CFLAGS)
[16:09] <xteejyx> I *think* I've found it
[16:09] <xteejyx> in LIBS += xxx it was commented out, so added lz on it
[16:10] <xteejyx> and uncommented
[16:10] <geser> looks more sane as a fix
[16:10] <xteejyx> well it certainly isn't me that is sane :P
[16:11] <xteejyx> the file is pointed to as an include from the configure script to look for options, so fingers crossed!
[17:16] <ari-tczew> does anybody have ideas for fix this FTBFS? http://paste.ubuntu.com/516343/
[17:17] <ScottK> ari-tczew: Add -ldl to LDFLAGS.
[17:18] <xteejyx> -ldl ?
[17:18] <xteejyx> omg was I right? :O
[17:18] <ScottK> /lib/libdl.so.2: could not read symbols: Invalid operation
[17:18] <ScottK> So, using the recently described convention, one would want to pass -ldl to the linker.
[17:19] <xteejyx> ScottK: Is that a general rule for all LDFLAGS, remove lib and add l for the name?
[17:20] <ScottK> xteejyx: So far as I have been able to determine, yes.  No promises though.
[17:20] <xteejyx> ScottK: Good enough for me :)
[17:20] <ari-tczew> ScottK: d/rules could be that? http://paste.ubuntu.com/516344/
[17:21] <ScottK> ari-tczew: Perhaps.  Sometimes you can fix it in debian/rules, sometimes you have to patch the upstream build system.
[17:23] <xteejyx> I'm on my 2nd ftbfs, both needed upstream work :(
[17:23] <xteejyx> couldn't be simple could it? lol
[17:24] <tumbleweed> xteejyx: there are going to be a bunch of binutils-gold related ones this cycle
[17:24] <ari-tczew> ScottK: still FTBFS :( http://paste.ubuntu.com/516349/
[17:25] <xteejyx> tumbleweed: What happens if packages are rebased again deb/unstable?
[17:25] <xteejyx> Do we have to go do them again?
[17:25] <tumbleweed> xteejyx: as soon as we've modified a package, we have to manually merge it to carry changes forward. Look for Merging on the wiki
[17:26] <tumbleweed> this is one of the reasons why it's so imprortant to get patches upstream fast
[17:26] <xteejyx> tumbleweed: I get it :)
[17:26] <ScottK> ari-tczew: Is the the same place it failed before?
[17:26] <ScottK> If so, then you'll need to figure out a better way to change LDFLAGS.
[17:26] <xteejyx> but isn't this all assuming debian take from upstream quickly or do they normally anyway?
[17:27] <ari-tczew> ScottK: YES, CMakeFiles/fatrat.dir/qrc_resources.cxx.o
[17:27] <ScottK> xteejyx: Debian is in pre-release freeze for Squeeze right now, so the pace of updates from Debian will be slower than usual.
[17:27] <ScottK> ari-tczew: I'd try it before the --as-needed.  Maybe it doesn't look after that.
[17:27] <xteejyx> ScottK: So slightly less of a worry for us at the moment I take it?
[17:27] <ScottK> Other than that, I'm not sure.
[17:27] <ScottK> xteejyx: Yes.
[17:28] <xteejyx> Cool. Just wondered is all :)
[17:28] <ScottK> The goal is to merge all packages needing updates from Debian at least once per cycle.
[17:28] <xteejyx> Damn, what's the line in control meant to be for MOTU maintainers?
[17:29] <ari-tczew> xteejyx: Use command: update-maintainer
[17:29] <ScottK> xteejyx: Just use the update-maintainer script in ubuntu-dev-tools.
[17:29] <xteejyx> I see
[17:29] <xteejyx> Oh, easier than doing it manually, thanks guys :)
[17:30] <xteejyx> I need to debuild -us -uc again after changing changelog and control right?
[17:31] <ScottK> xteejyx: debuild -S to update the source package.
[17:31] <xteejyx> ScottK: Will that create a new dsc to debdiff with?
[17:31] <ScottK> Yes.
[17:31] <xteejyx> Wow, why do I make it harder for myself?!
[17:31] <ScottK> And it won't build the binaries which, if the clean rule is defective, will contaminate your source.
[17:32] <ScottK> Hard way is sometimes the only way to learn.
[17:32] <ScottK> BTW, man dpkg-buildpackage for details.
[17:32] <xteejyx> It's mostly garble to me I tried reading it already :)
[17:33] <ari-tczew> ScottK: now other FTBFS message: http://paste.ubuntu.com/516356/
[17:34] <xteejyx> Quick question, is there any way to remove all the build-deps I installed to build the source?
[17:34] <ScottK> ari-tczew: Progress.  Now add -lboost_system in the same place in debian/rules
[17:34] <ScottK> xteejyx: If you installed with apt-get build-dep $PACKAGE, then apt-get autoremove should do it.
[17:34] <xteejyx> ScottK: I didn't :(
[17:35] <ScottK> Then you'll have to specify the packages to remove.
[17:35] <xteejyx> manually? :( damn
[17:36] <ari-tczew> ScottK, xteejyx: about reducing merges in development cycle: I encourage to merge new upstream releases first, but new debian revisions leave for FeatureFreeze.
[17:36] <ari-tczew> usually new debian revisions include bug fixes.
[17:38] <xteejyx> so rebasing a few times in the cycle is a good idea, but just creates more work?
[17:38] <xteejyx> Well I'm getting my head round all of this now so I'll def help out
[17:39] <micahg> ari-tczew: you increase the risk of fakesync's that way
[17:39]  * ScottK agrees with micahg
[17:39]  * xteejyx doesn't know what micahg is on about ;)
[17:40] <ari-tczew> micahg: fakesyncs?
[17:40] <micahg> also this time around, if we can help Debian release, there will be a flood of new upstream versions that we can merge
[17:40] <micahg> ari-tczew: tarball mismatch in archive
[17:40] <ari-tczew> ekhm, I wrote using bad words.
[17:40] <xteejyx> micahg: You mean things like our ftbfs fixes for squeeze?
[17:40] <ari-tczew> I mean about merging from Debian, where is new upstream release included.
[17:40] <micahg> ari-tczew: oh, ok :)
[17:41] <ari-tczew> ScottK, micahg: red color on http://people.ubuntuwire.org/~lucas/merges.html
[17:41] <ScottK> OK
[17:41] <micahg> ari-tczew: in that case, I agree with you, since a new upstream is more likely to take more work and not get a freeze exception :)
[17:42] <ari-tczew> cool! and sorry for confuse
[17:45] <micahg> xteejyx: a fakesync is necesssary when we import a new upstream version and debian imports a new upstream version and the tarballs don't match
[17:47] <xteejyx> micahg: So the dev's upstream version changed?
[17:47] <micahg> xteejyx: no, but if the package uses a generated tarball, while the contents will be the same, the md5sum will differ
[17:48] <xteejyx> micahg: Aahhh so just the package changed, but not the contents, I get it
[17:52] <xteejyx> vite done, bug 663375
[17:52] <ari-tczew> ScottK: built fine! thanks!
[17:52] <ScottK> ari-tczew: Great.  Can I give you another to look at?
[17:53] <ari-tczew> ScottK: another... but what another?
[17:53] <ScottK> ari-tczew: sslsniff needs to be rebuilt so it will depend on boost1.42 instead of 1.40.
[17:54] <ScottK> but it fails to build due to /lib/libcrypto.so.0.9.8: could not read symbols: Invalid operation
[17:54] <ScottK> So it will need a similar fix.
[17:54] <ScottK> Are you up for it?
[17:54] <ari-tczew> ScottK: I can try. But I don't give a guarantee ok?
[17:54] <ScottK> ari-tczew: Certainly.
[17:55] <kklimonda> heh, there are going to be quite a few ftbfs this cycle due to those changes
[17:55] <ari-tczew> kklimonda: btw. what do you think about SRU your patch to g-s-d in lucid?
[17:56] <kklimonda> ari-tczew: I have no opinion. does it crash in lucid? If so, the patch is small and safe.
[17:56] <ari-tczew> kklimonda: yes, but now I don't have installed lucid.
[17:57] <kklimonda> I have a 10.04 vm, I can test it later.
[17:58] <ScottK> kklimonda: Yes. We will also have FTBFS due to python2.7 being added as a supported version for extra fun.
[17:59] <ari-tczew> kklimonda: nice, but I have to upload a patch to lucid-proposed. with waiting to archive approval, it will take some days.
[17:59] <kklimonda> ScottK: should fixes for ftbfs related to changes to linker be forwerded upstream?
[17:59] <kklimonda> forwarded even
[17:59] <ScottK> kklimonda: Yes.
[18:00] <ScottK> Also there are often bugs open in Debian about it.  The patch should also be sent there.
[18:00] <kklimonda> ok
[18:00] <ScottK> They are minor bugs in Debian for Squeeze, but after it's released, they'll be RC for Wheezy.
[18:03] <ari-tczew> debfx: heh, you could point on MoM, that you're working on this merge.
[18:03] <ari-tczew> we duplicated a work
[18:04] <ari-tczew> debfx: don't forget about forward changes to Debian
[18:05]  * ari-tczew looks on QA/FTBFS page and is afraid, that developers don't test build before upload to archive.
[18:05] <debfx> ari-tczew: yeah sorry
[18:06] <ari-tczew> I think that developers should loose their upload access, if they upload packages with FTBFS commonly.
[18:07] <debfx> though imho MoM is kind of useless for such messages because they aren't removed after the upload
[18:08] <ximion_> hi
[18:08] <ximion_> is there currently a discussion going on, or can I as a question regarding debhelper?
[18:09] <ari-tczew> ximion_: go ahead
[18:10] <ximion_> okay... I get the following lintian messages:
[18:10] <debfx> ari-tczew: 90% of the packages on the ftbfs list are auto-syncs from debian
[18:10] <ximion_> E: packagekit-gtk-module: pkg-has-shlibs-control-file-but-no-actual-shared-libs
[18:10] <ximion_> W: packagekit-gtk-module: postinst-has-useless-call-to-ldconfig
[18:10] <ximion_> W: packagekit-gtk-module: postrm-has-useless-call-to-ldconfig
[18:10] <ximion_> but I don't know how to fix this, as the shlibs-control file is added automatically
[18:10] <ari-tczew> debfx: I know, but I mean about developers, who didn't test build and upload package
[18:11] <ximion_> the pkg does not contain a public shared lib, so it does not need a control file, but one is added everytime
[18:15] <ximion_> does someone have an idea how to disable this behavior?
[18:27] <debfx> ximion_: you could tell dh_makeshlibs to ignore that package
[18:27] <ximion_> debfx: Currently trying it...
[18:34] <ximion_> debfx: Works. Thanks!
[18:50] <c_korn> if a patch only applies with an offset it is not accepted by source format 3.0 (quilt). how can I quickly refresh this patch?
[18:51] <ari-tczew> c_korn: is it a big patch? if not, do manually patch in different place based on original files
[18:52] <ari-tczew> DktrKranz: ping
[18:53] <Bachstelze> c_korn: depends on the patch system
[18:53] <Bachstelze> quit
[18:53] <Bachstelze> sorry
[18:53] <Bachstelze> then just do a quilt refresh
[18:54] <Bachstelze> I think the packaging guide has a link to a nice quilt howto
[18:57] <ari-tczew> ScottK: Done.
[18:57] <ScottK> Cool.
[18:57] <kklimonda> c_korn: try rediff
[18:58] <ari-tczew> ScottK: do you want to get this patch, or do you want to upload through me?
[18:58] <ScottK> ari-tczew: Just upload it.
[18:58] <ari-tczew> ScottK: could you tell me why we should fix FTBFS, if binary package exist?
[19:03] <c_korn> ari-tczew: how does the patch size matter? currently I do a; quilt pop -a ; quilt delete patch ; quilt new patch ; quilt shell ; patch -p1 --no-backup-if-mismatch < debian/patches/patch ; exit ; quilt refresh
[19:03] <c_korn> Bachstelze: it is quilt
[19:05] <ari-tczew> c_korn: I just don't trust these scripts. I prefer to patch manually in different location, then copy ready .patch file to /debian/ directory.
[19:08] <ari-tczew> ScottK: should do I to forward this change to Debian?
[19:11] <ScottK> ari-tczew: Sorry.  Was on the phone.
[19:11] <ScottK> ari-tczew: The reason for the rebuild is boost1.40 to boost1.42 transition.
[19:11] <c_korn> ari-tczew: ok
[19:12] <c_korn> kklimonda: thanks, will try this next time
[19:12] <ScottK> ari-tczew: The patch should be added to Debian Bug #556373.
[19:21] <ari-tczew> tumbleweed: could you review MoM and comment, which merges are free? or maybe you are going to do all?
[19:22] <ari-tczew> debfx: ping
[19:23] <kklimonda> how to call git branches for ubuntu packaging? release or ubuntu/release ?
[19:24] <kklimonda> (I wonder if it's even possible to use slash in the name of a branch)
[19:27] <ari-tczew> ScottK: patch forwarded to Debian.
[19:32] <ScottK> Thanks.
[19:33] <ScottK> debfx: Could you have a look at Bug #663435?  It seems like something that would be reasonably fixable for you.
[19:37] <ari-tczew> ScottK: these rebuilds and FTBFS fixes are necessary for maverick too?
[19:38] <ScottK> ari-tczew: No.
[19:38] <ScottK> The linker changes are just in Natty and the transition is for Natty too.
[19:41] <xteejyx> Why are there so many ftbfs failures for previous releases?
[19:42] <ScottK> No one fixed them.
[19:42] <ScottK> Things have generally been getting better in that department.
[19:42] <xteejyx> Is it pointless doing it now then? What about Lucid? Sorry for all the Q's :)
[19:43] <ScottK> xteejyx: Here's some trends over time: http://skitterman.wordpress.com/2010/10/09/ftbfs-final-score/
[19:43] <ari-tczew> lucas: is it possible to filter your merge script, to show only 'red' merges?
[19:44] <debfx> ari-tczew: pong
[19:44] <lucas> ari-tczew: the merges are exported as json, too. so you can filter on whatever you want yourself
[19:44] <xteejyx> ScottK: still not great though is it :(
[19:44] <debfx> ScottK: is it caused by gcc 4.5 or maybe by changes in boost 1.42?
[19:44] <lucas> ari-tczew: http://udd.debian.org/cgi-bin/merges.json.cgi
[19:44] <ScottK> xteejyx: Because we have some tool chain changes this cycle (due to no indirect linking, the move to gcc 4.5 as default, and the addition of python2.7) we know there will be a lot of FTBFS and since Debian is frozen for Squeeze it's unlikely much will get fixed there, so we should start now to fix stuff.
[19:45] <ScottK> debfx: I suspect gcc, but didn't test the theory.
[19:45] <xteejyx> Usually this would be done by Debian I assume in their unstable?
[19:45] <ScottK> In generaly boost1.42 -> 1.42 has been pretty smooth.
[19:45] <ScottK> xteejyx: If they had the same toolchain changes, yes.
[19:46] <debfx> ScottK: where have you got the numbers from for the ftbfs stats?
[19:46] <xteejyx> ScottK: i.e. the new gcc? I see
[19:46] <ScottK> They will do them for their next release, so they won't worry about it much until after Squeeze is released.
[19:46] <ScottK> debfx: I used the numbers from qa.ubuntuwire.com/ftbfs.
[19:46] <ari-tczew> debfx: I forgot what I wanted from you. but if we are talking, could you create a filter to merge script, which will show only new upstreams releases?
[19:46] <ScottK> xteejyx: Yes.  All three of those will be in the next Debian release.
[19:48] <debfx> ScottK: ubuntuwire doesn't show packages which initally built fine but can't be rebuild, right?
[19:49] <ScottK> debfx: That's correct.
[19:49] <ScottK> That's what we need lucas's rebuild tests for.
[19:51] <xteejyx> Am I right in thinking that removing *-dev packages will not affect the system, as long as they're not removing other stuff apart from -dev packages?
[19:52] <debfx> those stats would be even more interesting but rebuilding all packages after release is kind of pointless
[19:53] <xteejyx> i.e. x11-proto-*-dev
[19:53] <micahg> debfx: it depends, on an LTS it can make sense for packages that will need updates during the 3/5 yr lifecycle
[19:54] <lucas> ScottK: can you ping me when it will be a good time to do a rebuild?
[19:54] <lucas> I was planning to do one on 29-30 october
[19:54] <xteejyx> What about the packages for Lucid, since it's an LTS, shouldn't ftbfs be fixed for that too if there's time?
[19:55] <xteejyx> Or is it done via SRU>
[19:56] <ScottK> lucas: Next week is likely good.  Usually not a lot gets uploaded during UDS.
[19:56] <debfx> micahg: well, you'll notice that the package doesn't build when you update it :)
[19:56] <ScottK> That's probabaly OK.
[19:56] <ScottK> xteejyx: Removing -dev packages shouldn't hurt the system.
[19:56] <micahg> debfx: right, but if you need a critical security fix, you don't want to be figuring out an FTBFS issue
[19:56] <xteejyx> ScottK: Thanks Scott :)
[19:57] <ScottK> xteejyx: If we can fix them via SRU, it's reasonable to do it.
[19:57] <xteejyx> Makes sense I suppose
[19:57] <ScottK> micahg: For lucid it's a little different.  We removed all the binaries we ~couldn't build, so the primary issue is making the archive more complete.
[19:58] <ScottK> In some cases where we didn't remove it and it won't build, then it's definitely good to get the fix now in case of a security issue later.
[19:58] <micahg> ScottK: ok
[19:58] <micahg> ScottK: would you mind commenting on my MOTU application?
[19:59] <ScottK> micahg: Have I sponsored you (I'll comment either way, but if you let me know what I've uploaded of yours I could do a better one)?
[19:59] <xteejyx> micahg: Are you not already MOTU?
[20:00] <micahg> ScottK: AFAIK, not recently
[20:00] <ScottK> micahg: OK.  Link me and I'll leave a general comment about how wonderful you are.
[20:00] <micahg> ScottK: thanks, https://wiki.ubuntu.com/micahg/MOTUApplication
[20:01] <micahg> ScottK: I have something if you want to sponsor (transitional package fix for lsb-core)
[20:02] <ScottK> Probably not today, so I'll just comment.
[20:02] <micahg> ScottK: Ok, thanks
[20:02] <micahg> I wish there was an easier way to see who sponsored what
[20:06] <micahg> xteejyx: no, I just have upload rights for the Mozilla packageset at teh moment
[20:07] <kklimonda> btw, is there some magic one can use to get a list of his packages sponsored by someone?
[20:10] <ScottK> Not currently.
[20:10] <ScottK> LP tracks it, so in theory it's possible, but IDK if the API exports it or not.
[20:11] <kklimonda> we need the ultimate ubuntu database ;)
[20:13] <xteejyx> micahg: Ohh. Thougth you would be MOTU you seem to know a hell of a lot about everything :)
[20:13] <ScottK> We have it.  We just need better access to it (LP)
[20:13] <ScottK> kklimonda: ^^^
[20:14] <kklimonda> ScottK: I'm afraid the hell is going to freeze before we get an access to the (subset of) LP database.
[20:14] <kklimonda> the best we can hope for is another API but for some reason I like the idea of UDD
[20:16] <kklimonda> hmm.. abbreviation collision, trouble ahead.
[20:17] <micahg> kklimonda: bug 614948
[20:20] <kklimonda> micahg: thanks
[20:25] <kklimonda> micahg: you are keeping packaging for ubuntu in the same git repository as packaging for debian?
[20:25]  * ajmitch has seen that quite often
[20:26] <kklimonda> well, I'd like to get my hands on such a repository so I can play with it and see how does the workflow look like.
[20:27] <ajmitch> http://git.debian.org/?p=pkg-cli-apps/packages/banshee.git;a=summary
[20:27] <kklimonda> thanks
[20:28] <micahg> kklimonda: http://git.debian.org/?p=pkg-multimedia/vlc.git
[20:28] <ajmitch> hyperair has the details of how it's used
[20:28] <hyperair> ajmitch: hrmm?
[20:28] <ajmitch> hyperair: ubuntu branches in banshee git repo
[20:28] <hyperair> ajmitch: ah yes. that's right.
[20:29] <hyperair> it's not too hard, really, just dump a debian/gbp.conf file with [DEFAULT]\ndebian-branch = ${branch}
[20:29] <hyperair> makes it really easy to merge things.
[20:31] <kklimonda> thanks, I'll take a look at both
[20:31] <Rhonda> Does that mean that a git talk in ubuntu-classroom isn't needed anyway? ;)
[20:31] <ajmitch> Rhonda: oh we'd love it :)
[20:31]  * Rhonda . o O ( damn )
[20:32] <ajmitch> helps document it for the rest of us, and those who read the logs
[20:32] <Rhonda> I don't use git-buildpackage, so it would rather be a more general git talk anyway.
[20:33] <Rhonda> I don't like how it forces one to have the upstream sources included.
[20:33] <Rhonda> That just doesn't work out for packages like wesnoth or wormux at all.
[20:33] <ajmitch> because you work with large sources?
[20:34] <Rhonda> ajmitch: But even for "small" sources it's troublesome. You can't regulate what upstream pushes into it and one might have to rewrite history at big to get rid of certain undistributable files.
[20:36] <micahg> Rhonda: a session on git would be great
[20:36] <Rhonda> Anyway, this is still on my agenda and I'm sure that nig-elb will nag-elb me about the git session again. :)
[20:36] <debfx> kklimonda: you probably want to use dpkg-mergechangelogs so debian/changelog is merged automatically
[20:36] <Rhonda> I just finished my slides for the talk on thursday. ;)
[20:37] <Rhonda> Subject: Your Classrooms Await
[20:37] <ari-tczew> xteejyx: as I wrote in the bug, please forward changes to Debian.
[20:37] <Rhonda> wtf, topic spam. :)
[20:38] <ajmitch> Rhonda: great, when is it on thursday?
[20:38] <Rhonda> ajmitch: 14.15, at the openSUSE conference. Unfortunately they neither do recordings nor streaming.
[20:38] <ajmitch> ah
[20:38] <ajmitch> that's a shame
[20:38] <Rhonda> I think they have a lot to learn from Debconf and UDS. :)
[20:39] <ajmitch> or any conference really
[20:39] <ScottK> Rhonda: I think that's generally true of opensuse, not just conferences ;-)
[20:39]  * ajmitch has sometimes watched talks from previous years' pycon or LCA
[20:39]  * Rhonda . o O ( <rumours type="unjustified">novell can't afford</rumours> )
[20:41] <Rhonda> ScottK: At FrOSCon they had this talk about their build system where they also bragged around being able to build Debian packages in it. They though weren't able to answer questions with respect to that, especially what they do with versions when they build the same sources for different releases. :)
[20:42] <DktrKranz> ari-tczew: pong
[20:42] <ScottK> Rhonda: I didn't look at it for a few years, but it was scary the last time I looked.
[20:42] <Rhonda> Anyway, looking forward to it, will report about it in my blog (and at least offer the slides)
[20:42] <kklimonda> can I disable make check for some subdirectories?
[20:42] <kklimonda> with dh compact rules
[20:42] <ajmitch> kklimonda: that may require some makefile hacking, depending on the project
[20:42] <Rhonda> I guess parts of the talk is also interested to Ubuntu.
[20:42] <ajmitch> since make check is usually just run once from the top level
[20:42] <Rhonda> Anyway, off to bed for now.
[20:43] <ajmitch> Rhonda: anything debian tends to be interesting for ubuntu
[20:43] <ajmitch> night
[20:43] <Rhonda> ajmitch: It's about resources that Debian offers that are useful for other distributions, too.
[20:43] <ajmitch> certainly important for ubuntu :)
[20:43] <Rhonda> Like the screenshots site that Ubuntu already uses in the software center - way better use of it within Ubuntu already than within Debian. :)
[20:44] <ari-tczew> DktrKranz: could you check whether can we sync package gnustep-base ?
[20:48] <DktrKranz> ari-tczew: IIRC, that patch has been included in latest package from Debian. If you're going to sync, be sure to also consider -back and -gui (if not autosynced already)
[20:48] <DktrKranz> and have fun with the rdeps ;)
[20:50] <ari-tczew> DktrKranz: a lot of rdepends ... all have to be rebuild?
[20:51] <DktrKranz> most of them
[20:51] <DktrKranz> there are four stages
[20:52] <DktrKranz> ari-tczew: http://release.debian.org/transitions/GNUstep.html (show all of them)
[21:02] <xteejx> bug 663375 - I already forwarded the patch to the developer, should I still inform Debian?
[21:03] <ScottK> xteejx: Yes.
[21:03] <ScottK> debfx: How's ball looking?
[21:03] <xteejx> Ok
[21:03] <ScottK> shadeslayer: You want in on the fun?  Maybe you could look at Bug #663485?
[21:04] <ScottK> ari-tczew: Do you do C++?
[21:05] <debfx> ScottK: haven't looked at it yet
[21:06] <ScottK> OK.  plee-the-bear needs fixing too if no one else grabs it ...
[21:08] <ajmitch> with a name like that, it has to be a game
[21:09] <ajmitch> so whoever fixes it has to play through the whole game, just to test that it works?
[21:10] <debfx> I won't touch it then ;D
[21:13] <kklimonda> hmm.. how to use dpkg-mergechangelog?
[21:14] <kklimonda> when I do dpkg-mergechangelog maverick debian natty (where release codenames are changelogs) I don't get old entries for ubuntu-related changes
[21:15] <debfx> kklimonda: man dpkg-mergechangelogs (integration with git)
[21:16] <debfx> you need to put this file into the package: http://git.debian.org/?p=pkg-virtualbox/virtualbox-ose.git;a=blob;f=debian/.gitattributes;hb=HEAD
[21:17] <debfx> and add some magic to ~/.gitconfig
[21:21] <kklimonda> hmm.. ok, looks like I'll spend some more time with it :)
[21:23] <ScottK> \o/ - First removal bug of the cycle filed.
[21:25] <debfx> I hope it's a kde3 package :)
[21:25] <ScottK> No such luck.
[21:26] <ScottK> Description: Unbelievably inflexible build tool <-- Great description (not the one I asked removal)
[21:26] <ajmitch> why, did you ask for yada to be removed?
[21:28]  * StevenK prepares to purge it from the archive, and then NEW it, just so he can kill it again.
[21:29] <ajmitch> I swear he's got it on highlight in his IRC client, just so he can stomp on it some more
[21:29]  * StevenK will never tell.
[21:32] <ari-tczew> ScottK: no, why you ask?
[21:33] <ScottK> ari-tczew: A lot of these boost rebuild failures have C++ issues and I don't code in C++, so if you did, I would point them out to you.
[21:34] <ari-tczew> ScottK: do you mean about ftbfs such as we explained today, or do you mean about merge gnustep-base?
[21:34] <ScottK> ari-tczew: Not related to gnu-step.  Like 663485 I mentioned a bit ago.
[21:36] <ari-tczew> ScottK: I would like to help, but I'm pretty weak soldier to fight with FTBFS.
[21:37] <ScottK> ari-tczew: OK.  No problem (was just checking).
[21:38] <kklimonda> ScottK: 663485 (same with mumble btw) looks like a bug in boost 1.42, similar to http://bugs.gentoo.org/show_bug.cgi?id=317969
[21:45] <kklimonda> or not, the way gcc prints those errors makes my eyes bleed
[21:47] <xteejx> libchamplain ftbfs: I tried it locally and the problem is with libgirepository not installing
[21:47] <xteejx> locally that package won't install at all
[21:52] <geser> error message?
[21:53] <xteejx> 1 sec
[21:53] <xteejx> geser:  Package: hello
[21:53] <xteejx>   Version: 1.3-16
[21:53] <xteejx>   When I invoke `hello' without arguments from an ordinary shell
[21:53] <xteejx>   prompt it prints `goodbye', rather than the expected `hello, world'.
[21:53] <xteejx>   Here is a transcript:
[21:53] <xteejx>   $ hello
[21:53] <xteejx>   goodbye
[21:53] <xteejx>   $ /usr/bin/hello
[21:53] <xteejx>   goodbye
[21:53] <xteejx>   $
[21:53] <xteejx>   I suggest that the output string, in hello.c, be corrected.
[21:53] <xteejx>   I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13
[21:54] <xteejx>   and libc6 2.1.3-10.
[21:54] <xteejx> oh god sorry!!
[21:54] <ajmitch> heh
[21:54] <xteejx> damn clipboard
[21:54] <ajmitch> now that must be an old bug report :)
[21:54] <xteejx> lol The actual error WAS:
[21:55] <xteejx> Errors were encountered while processing: \\ /var/cache/apt/archives/libgirepository1.0-dev_0.9.12-0ubuntu1_i386.deb
[21:55] <xteejx> Sub process dpkg returned error code
[21:55] <xteejx> What is wrong with me, that's not it
[21:56] <xteejx> It failed to overwrite /usr/share/gir-1.0/DBus-1.0-gir, also in pkg gir-repository-dev 0.6.5-6ubuntu0
[21:58] <xteejx> geser: Ahh I see the problem, debian/control, libgirepository1.0-dev and gir-repository-dev want to install, but both provide the same file
[21:58] <geser> than that error needs to get resolved first
[21:58] <xteejx> geser: But which one do I remove? :S
[21:58] <geser> ask in #ubuntu-desktop
[21:59] <xteejx> oh ok :)
[22:02] <xteejx> How do I remove packages installed with apt-get build-deps ?
[22:03] <geser> like any other package
[22:04] <xteejx> apt-get remove build-deps?
[22:04] <geser> I hope you have a list of build-dependencies you installed (searching for -dev packages might help)
[22:05] <xteejx> yeah press up in the terminal lol
[22:12] <xteejx> Hi guys, is anyone working on the ftbfs for gir-repository in main?
[22:26] <ScottK> kklimonda: Sounds interesting.  Can you find what Gentoo's fix was?
[22:54] <kklimonda> ScottK: libclaw has to be fixed first. But I think I can see the problem there.
[23:21] <kklimonda> ok, got libclaw (bug 663485) and working on the plee-the-bear
[23:22] <kklimonda> argh
[23:24] <ScottK> kklimonda: Cool.
[23:25] <kklimonda> fixed libclaw - bug 663560
[23:29] <ScottK> kklimonda: These changes should be sent to Debian as wishlist bugs (if there isn't one already).  They'll be RC in Debian for Wheezy.
[23:30] <kklimonda> ScottK: yes, I'll do it once I get plee-the-bear built and tested
[23:30] <ScottK> Great.
[23:31] <kklimonda> oh, joys of cmake
[23:31] <micahg> Debian actually has some DSO bugs already: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=no-add-needed;users=peter.fritzsche@gmx.de
[23:33] <ScottK> micahg: Yes, but I've hit some that aren't bugged already.
[23:34] <kklimonda> yeah, so did I
[23:35] <kklimonda> actually every package I touch for natty fails to link ;)
[23:35] <ScottK> For me it's ~half.
[23:35] <ScottK> kklimonda: Can you upload libclaw or do you need sponsorship?
[23:35] <ScottK> LP has confused me.
[23:36] <kklimonda> ScottK: I can't upload, I've attached both debdiff and the updated branch to 663560
[23:37] <ScottK> kklimonda: Thanks.  Looking.
[23:37] <kklimonda> ok, got plee-the-bear to build
[23:38] <kklimonda> ScottK: should I split patch to fix two different ftbfs: one related to dso and another to gcc 4.5 changes?
[23:38] <ScottK> kklimonda: For Ubuntu, don't worry about it.  For Debian, it's two different bugs with different patches I think.
[23:58] <ScottK> kklimonda: libclaw uploaded.   Thank you for your contribution to Ubuntu.  Please let me know when plee-the-bear is ready.