=== superm1` is now known as superm1 [03:21] what is the correct path to use when pushing a modified bzr branch back to lp as your personal branch? [03:30] lp:~psusi/ubuntu/natty// [03:33] thanks... got it... now need to figure out how to massage the bug requesting new upstream version into the right shape... [03:34] Shouldn't need much. If you're using UDD, doesn't need anything special for sponsoring. [03:34] The sponsoring report includes any outstanding merge proposals into Ubuntu branches. [03:35] what's UDD? [03:35] 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] ubuntu distributed development [03:35] what's that? [03:35] 20 upstream releases old in fact [03:37] 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] 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] 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] 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] There's N other ways to get stuff sponsored, but those are the two that the Ubuntu Sponsors team currently supports. [03:39] Just submit a merge proposal on LP. [03:39] isn't sponsors for universe? [03:39] ohh, ok... I did submit the merge proposal [03:40] Sponsors is for everyone. [03:40] There used to be separate sponsor teams for "main" and "universe", but that went away as part of ArchiveReorganisation/Permissions. [03:40] 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:40] Launchpad bug 570374 in lvm2 (Ubuntu) "add --merge functionality" [Undecided,New] https://launchpad.net/bugs/570374 [03:41] You can verify that your request is correct by making sure it appears on http://reports.qa.ubuntu.com/reports/sponsoring/ [03:41] I think that's updated every 5 minutes or so. [03:44] 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] lucidfox, Do you really want bug #92028 in queue? Why not just upload? [03:45] Launchpad bug 92028 in xchat (Ubuntu) "xchat does not do composite transparency, crashes if transparency is enabled with GTK RGBA" [Wishlist,Triaged] https://launchpad.net/bugs/92028 [03:46] 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] persia, allocate 50% of space for initial fs, leave rest to be allocated as needed [03:57] when fs gets > 90% full, extend it to use another 10% of the total space... do same with snapshots [04:02] You know what would work better? btrfs snapshots. [04:03] No need for that pesky up-front configuration; just format the whole drive (minus swap) and go nuts. [04:04] With the *tiny* problem that btfrs' write performance falls to ~0 once dpkg starts calling fsync :) [04:05] RAOF: so it'd take about a day or two to upgrade from one release to the next? :) [04:06] 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] probably a good thing that it didn't become the default then [04:08] Yeah. [04:12] persia> The bug is for xchat-gnome [04:12] as is the patch [04:13] and xchat-gnome is in main [04:15] RAOF: Only on btrfs? [04:15] StevenK: Yeah. It's a known regression in... 2.6.35, I think. [04:16] The practical effect being that on certian not-too-uncommon write loads, btrfs' write performance dropped 10x. [04:18] I can scrounge up a link if you'd like it. [04:18] RAOF: Just curious is all [04:31] RAOF, hehe, yea, but btrfs isn't stable yet... and dpkg calling sync pretty much sucks balls everywhere [04:32] really need to fix that damnit [04:32] lucidfox, Ah, I thought there was a patch for xchat there as well. [04:33] it sure makes updating during the development cycle a hell of a lot slower on my ssd [04:33] It's not just ssd. It's anything. No cache. [04:33] (also, language please) [04:34] I don't think fsync, or a functional equivalent, is going away for dpkg. [04:34] No, no patch for xchat [04:34] I doubt it: I've hit the other side of that bug without fsync, and that's exceedingly painful. [04:35] 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] it needs to.... the reason it is there is because of an ext4 bug but it makes updates painfully slow all over [04:38] Some parts of dpkg want the assurances fsync provides even in the absence of filesystem bugs. [04:41] 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] 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] didn't seem to be needed before the ext4 bug... [04:46] 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] 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] I mean if the system crashes during upgrade and leaves it in an unbootable state [04:47] 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] 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] unless there is a crash/power failure fsync should not make a difference one way or the other [04:49] Sleep gets into it more than you'd think. [04:49] 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] what does sleep have to do with it? [04:50] 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] Yes, these are race conditions, but still. [04:51] ahh, the usb disks die during suspend bug... that's a really stupid one too [04:51] 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] if they are mounted, that mount is no good anymore isn't it? as if you had removed the disk [04:52] And there's hotplug PCI, although few people actually use it, which is subject to the same set of issues. [04:52] No. I routinely sleep/wake with USB storage without needing to consider the mount. [04:52] MMC also. [04:53] Just in-flight write transactions don't always commit. [04:53] I thought that was the issue I seem to remember on lkml a while back... the usb stack makes the drive disconnect [04:53] Sure, but drive disconnect doesn't break mount for stuff in the cache. [04:54] 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] if you have an open fd on the fs, when the drive is disconnected, that handle keeps it from being unmounted [04:55] 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] Feels wider than that to me, but yeah. [04:55] Reconnection always works fine for me. [04:55] if you have a terminal open at the time sitting in a directory on the disconnected disk? [04:56] 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] You're talking about a different disc (new one) [04:56] I assumed a usb hard disk disconnecting/reconnecting due to suspend would behave the same way [04:56] I'm talking about the *same* USB/MMC storage. [04:57] but it doesn't know it's the same [04:57] I think the difference is with "eject". [04:57] 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] 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] I suspect I'll cause some interesting filesystem errors on that drive one day soon if I unplug it too early [04:58] 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] 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] psusi: except when I resume, I don't have that drive plugged in still :) [04:59] ajmitch, why not? you just said don't remove it ;) [04:59] ajmitch, That's fine: you'll get an error on resume, and force unmount. [04:59] except force unmount doesn't exist [04:59] psusi: I take my laptop to work, leave the drive at home :) [04:59] I still can't believe Linux can't do a forced unmount after all these years [04:59] persia: it's more an issue if there are pending writes & the filesystem isn't consistent, right? [04:59] NT had it figured out 15 years ago [05:00] ajmitch, Kinda. That's the only sort of corruption I've seen. [05:00] 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] 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] very frustrating... [05:10] bugs to be fixed. [05:10] Anyway, fsync for dpkg is a good thing for now: needs ways to be faster (by fixing the underlying bugs) [05:11] As I understand it, fs transaction support would be faster and provide the reliability dpkg needs. [05:15] RAOF, Mostly. Still runs into hw-access stuff (unless transactions can deal with that as well). [05:16] dpkg basically needs “this thing needs to hit the disc iff this other thing hits the disc”, right? [05:18] RAOF, Essentially, yes. [05:18] Which is what (btrfs) transactions purport to provide (IIUC). [05:21] I wonder how they handle the case where hardware is detached. [05:21] And I'm also not sure btrfs works on all hardware: doesn't it require block devices? [05:28] ceph uses btrfs transactions for its metadata db [05:28] so yes [05:28] persia: ext3 works on non block devices?! [05:30] 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] lifeless, ubifs does. [05:33] RAOF, Ah, cool. That makes it sound like it's flexible enough to extend to erase-block managed structures. [06:08] tumbleweed: patch for gnome-shell FTBFS attached [07:54] Good morning! [07:58] morning dholbach [07:58] hi ajmitch === warp11 is now known as warp10 [10:25] bug 662986 - have I done this right?? [10:25] Launchpad bug 662986 in wwwoffle (Ubuntu) "wwwoffle-2.9f FTBFS" [High,Triaged] https://launchpad.net/bugs/662986 [10:27] xteejx: I still don't see a debdiff [10:28] xteejx: also, it needs to be reported to wwwoffle upstream [10:28] tumbleweed: How do I make one? I mean I didn't have an original .dsc to diff with [10:28] I'm reporting it upstream now [10:28] xteejx: pull-lp-source can give you one [10:28] ahh right cool thanks :) [10:40] tumbleweed: When you said report upstream, did you mean the dev or Debian? [10:41] 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] Phew, I was thinking "no, why did I report it to the dev" :) [10:50] tumbleweed: bug 662986 all done :) (I think) [10:50] Launchpad bug 662986 in wwwoffle (Ubuntu) "wwwoffle-2.9f FTBFS" [High,Triaged] https://launchpad.net/bugs/662986 [10:52] 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] woohoo :) [11:06] dholbach, yes, that was an upstream change. So I guess I have to create a patch for that [11:11] ara, I guess so, with edit-patch it should be easy [11:12] dholbach, OK, will do... later today :) [11:12] :) === hanska is now known as dapal [12:48] is there a way to run strace on multable PIDs? [12:49] one strace? [12:49] yes [12:49] Would -f do what you want, or do you need something more complicated? [12:50] i keep getting http://paste.ubuntu.com/516206/ when using strace -Ff -tt -p 2>&1 | tee strace-.log [12:50] Oh, strace *does* accept multiple -p arguments. That's an interesting surprise, and exactly what you need. [12:50] * persia likes manpages [12:51] -f or -F should do the same thing these days, and they ought attach to the forked process. Hrm. [12:54] intresting thing is the output im the pastein is the same for any/all PIDs related to dpkg/xulrunner [12:55] Something odd going on there, really. [12:55] Maybe ask in -devel if nobody answers here in a while. [12:56] ill wait for Micah since he wants it, xul is not configureing for te past fewe days. thanks for your help [12:57] Alternately, try using strace -p -p -p (etc.) to see if that helps any [12:58] Although it might be tricky to get those if you've a limited time window [12:59] ill try in a few i need coffee :) [13:40] .join #kernel === lan3y is now known as Laney [14:47] hello! [14:48] 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? === jrib is now known as Guest86325 === Guest86325 is now known as jrib [15:27] does -lzlib sound right for an LDFLAG? [15:50] -lz [15:51] geser: Cool thanks :) Now just gotta find where to put it [15:52] the package is named "zlib1g" but the library is libz.so.1 => -lz for linking [15:53] geser: Is there a list of these anywhere or is it just from knowledge? [15:54] And is there an easy way to find where to put it? I'm trying to look for LDFLAGS, but not helping [15:56] 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] Fair enough, guess I'll just have to keep doing them :)_ [15:56] it's just the filename of the lib*.a, minus lib and .a ;) [15:57] IMHO LDFLAGS are are last resort as every .o gets linked to it then (perhaps unnecessarily) [15:57] or lib*.so for dynamic linking [15:57] geser: It's the ftbfs ones in natty I'm doing (or trying to) [15:57] right [15:58] specifically, vite [16:00] 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] *changing [16:09] no, LDFLAGS is an environmental variable (similar to CFLAGS) [16:09] I *think* I've found it [16:09] in LIBS += xxx it was commented out, so added lz on it [16:10] and uncommented [16:10] looks more sane as a fix [16:10] well it certainly isn't me that is sane :P [16:11] the file is pointed to as an include from the configure script to look for options, so fingers crossed! [17:16] does anybody have ideas for fix this FTBFS? http://paste.ubuntu.com/516343/ [17:17] ari-tczew: Add -ldl to LDFLAGS. [17:18] -ldl ? [17:18] omg was I right? :O [17:18] /lib/libdl.so.2: could not read symbols: Invalid operation [17:18] So, using the recently described convention, one would want to pass -ldl to the linker. [17:19] ScottK: Is that a general rule for all LDFLAGS, remove lib and add l for the name? [17:20] xteejyx: So far as I have been able to determine, yes. No promises though. [17:20] ScottK: Good enough for me :) [17:20] ScottK: d/rules could be that? http://paste.ubuntu.com/516344/ [17:21] ari-tczew: Perhaps. Sometimes you can fix it in debian/rules, sometimes you have to patch the upstream build system. [17:23] I'm on my 2nd ftbfs, both needed upstream work :( [17:23] couldn't be simple could it? lol [17:24] xteejyx: there are going to be a bunch of binutils-gold related ones this cycle [17:24] ScottK: still FTBFS :( http://paste.ubuntu.com/516349/ [17:25] tumbleweed: What happens if packages are rebased again deb/unstable? [17:25] Do we have to go do them again? [17:25] 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] this is one of the reasons why it's so imprortant to get patches upstream fast [17:26] tumbleweed: I get it :) [17:26] ari-tczew: Is the the same place it failed before? [17:26] If so, then you'll need to figure out a better way to change LDFLAGS. [17:26] but isn't this all assuming debian take from upstream quickly or do they normally anyway? [17:27] ScottK: YES, CMakeFiles/fatrat.dir/qrc_resources.cxx.o [17:27] 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] ari-tczew: I'd try it before the --as-needed. Maybe it doesn't look after that. [17:27] ScottK: So slightly less of a worry for us at the moment I take it? [17:27] Other than that, I'm not sure. [17:27] xteejyx: Yes. [17:28] Cool. Just wondered is all :) [17:28] The goal is to merge all packages needing updates from Debian at least once per cycle. [17:28] Damn, what's the line in control meant to be for MOTU maintainers? [17:29] xteejyx: Use command: update-maintainer [17:29] xteejyx: Just use the update-maintainer script in ubuntu-dev-tools. [17:29] I see [17:29] Oh, easier than doing it manually, thanks guys :) [17:30] I need to debuild -us -uc again after changing changelog and control right? [17:31] xteejyx: debuild -S to update the source package. [17:31] ScottK: Will that create a new dsc to debdiff with? [17:31] Yes. [17:31] Wow, why do I make it harder for myself?! [17:31] And it won't build the binaries which, if the clean rule is defective, will contaminate your source. [17:32] Hard way is sometimes the only way to learn. [17:32] BTW, man dpkg-buildpackage for details. [17:32] It's mostly garble to me I tried reading it already :) [17:33] ScottK: now other FTBFS message: http://paste.ubuntu.com/516356/ [17:34] Quick question, is there any way to remove all the build-deps I installed to build the source? [17:34] ari-tczew: Progress. Now add -lboost_system in the same place in debian/rules [17:34] xteejyx: If you installed with apt-get build-dep $PACKAGE, then apt-get autoremove should do it. [17:34] ScottK: I didn't :( [17:35] Then you'll have to specify the packages to remove. [17:35] manually? :( damn [17:36] 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] usually new debian revisions include bug fixes. [17:38] so rebasing a few times in the cycle is a good idea, but just creates more work? [17:38] Well I'm getting my head round all of this now so I'll def help out [17:39] 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] micahg: fakesyncs? [17:40] 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] ari-tczew: tarball mismatch in archive [17:40] ekhm, I wrote using bad words. [17:40] micahg: You mean things like our ftbfs fixes for squeeze? [17:40] I mean about merging from Debian, where is new upstream release included. [17:40] ari-tczew: oh, ok :) [17:41] ScottK, micahg: red color on http://people.ubuntuwire.org/~lucas/merges.html [17:41] OK [17:41] 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] cool! and sorry for confuse [17:45] 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] micahg: So the dev's upstream version changed? [17:47] xteejyx: no, but if the package uses a generated tarball, while the contents will be the same, the md5sum will differ [17:48] micahg: Aahhh so just the package changed, but not the contents, I get it [17:52] vite done, bug 663375 [17:52] Launchpad bug 663375 in vite (Ubuntu) "vite ftbfs in natty" [High,In progress] https://launchpad.net/bugs/663375 [17:52] ScottK: built fine! thanks! [17:52] ari-tczew: Great. Can I give you another to look at? [17:53] ScottK: another... but what another? [17:53] ari-tczew: sslsniff needs to be rebuilt so it will depend on boost1.42 instead of 1.40. [17:54] but it fails to build due to /lib/libcrypto.so.0.9.8: could not read symbols: Invalid operation [17:54] So it will need a similar fix. [17:54] Are you up for it? [17:54] ScottK: I can try. But I don't give a guarantee ok? [17:54] ari-tczew: Certainly. [17:55] heh, there are going to be quite a few ftbfs this cycle due to those changes [17:55] kklimonda: btw. what do you think about SRU your patch to g-s-d in lucid? [17:56] ari-tczew: I have no opinion. does it crash in lucid? If so, the patch is small and safe. [17:56] kklimonda: yes, but now I don't have installed lucid. [17:57] I have a 10.04 vm, I can test it later. [17:58] kklimonda: Yes. We will also have FTBFS due to python2.7 being added as a supported version for extra fun. [17:59] kklimonda: nice, but I have to upload a patch to lucid-proposed. with waiting to archive approval, it will take some days. [17:59] ScottK: should fixes for ftbfs related to changes to linker be forwerded upstream? [17:59] forwarded even [17:59] kklimonda: Yes. [18:00] Also there are often bugs open in Debian about it. The patch should also be sent there. [18:00] ok [18:00] They are minor bugs in Debian for Squeeze, but after it's released, they'll be RC for Wheezy. [18:03] debfx: heh, you could point on MoM, that you're working on this merge. [18:03] we duplicated a work [18:04] 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] ari-tczew: yeah sorry [18:06] I think that developers should loose their upload access, if they upload packages with FTBFS commonly. [18:07] though imho MoM is kind of useless for such messages because they aren't removed after the upload [18:08] hi [18:08] is there currently a discussion going on, or can I as a question regarding debhelper? [18:09] ximion_: go ahead [18:10] okay... I get the following lintian messages: [18:10] ari-tczew: 90% of the packages on the ftbfs list are auto-syncs from debian [18:10] E: packagekit-gtk-module: pkg-has-shlibs-control-file-but-no-actual-shared-libs [18:10] W: packagekit-gtk-module: postinst-has-useless-call-to-ldconfig [18:10] W: packagekit-gtk-module: postrm-has-useless-call-to-ldconfig [18:10] but I don't know how to fix this, as the shlibs-control file is added automatically [18:10] debfx: I know, but I mean about developers, who didn't test build and upload package [18:11] the pkg does not contain a public shared lib, so it does not need a control file, but one is added everytime [18:15] does someone have an idea how to disable this behavior? [18:27] ximion_: you could tell dh_makeshlibs to ignore that package [18:27] debfx: Currently trying it... [18:34] debfx: Works. Thanks! [18:50] 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] c_korn: is it a big patch? if not, do manually patch in different place based on original files [18:52] DktrKranz: ping [18:53] c_korn: depends on the patch system [18:53] quit [18:53] sorry [18:53] then just do a quilt refresh [18:54] I think the packaging guide has a link to a nice quilt howto [18:57] ScottK: Done. [18:57] Cool. [18:57] c_korn: try rediff [18:58] ScottK: do you want to get this patch, or do you want to upload through me? [18:58] ari-tczew: Just upload it. [18:58] ScottK: could you tell me why we should fix FTBFS, if binary package exist? [19:03] 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] Bachstelze: it is quilt [19:05] 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] ScottK: should do I to forward this change to Debian? [19:11] ari-tczew: Sorry. Was on the phone. [19:11] ari-tczew: The reason for the rebuild is boost1.40 to boost1.42 transition. [19:11] ari-tczew: ok [19:12] kklimonda: thanks, will try this next time [19:12] ari-tczew: The patch should be added to Debian Bug #556373. [19:12] Debian bug 556373 in src:sslsniff "FTBFS with binutils-gold" [Minor,Open] http://bugs.debian.org/556373 [19:21] tumbleweed: could you review MoM and comment, which merges are free? or maybe you are going to do all? [19:22] debfx: ping [19:23] how to call git branches for ubuntu packaging? release or ubuntu/release ? [19:24] (I wonder if it's even possible to use slash in the name of a branch) [19:27] ScottK: patch forwarded to Debian. [19:32] Thanks. [19:33] debfx: Could you have a look at Bug #663435? It seems like something that would be reasonably fixable for you. [19:33] Launchpad bug 663435 in ball (Ubuntu) "Ball FTBFS in Natty with GCC 4.5" [Undecided,New] https://launchpad.net/bugs/663435 [19:37] ScottK: these rebuilds and FTBFS fixes are necessary for maverick too? [19:38] ari-tczew: No. [19:38] The linker changes are just in Natty and the transition is for Natty too. [19:41] Why are there so many ftbfs failures for previous releases? [19:42] No one fixed them. [19:42] Things have generally been getting better in that department. [19:42] Is it pointless doing it now then? What about Lucid? Sorry for all the Q's :) [19:43] xteejyx: Here's some trends over time: http://skitterman.wordpress.com/2010/10/09/ftbfs-final-score/ [19:43] lucas: is it possible to filter your merge script, to show only 'red' merges? [19:44] ari-tczew: pong [19:44] ari-tczew: the merges are exported as json, too. so you can filter on whatever you want yourself [19:44] ScottK: still not great though is it :( [19:44] ScottK: is it caused by gcc 4.5 or maybe by changes in boost 1.42? [19:44] ari-tczew: http://udd.debian.org/cgi-bin/merges.json.cgi [19:44] 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] debfx: I suspect gcc, but didn't test the theory. [19:45] Usually this would be done by Debian I assume in their unstable? [19:45] In generaly boost1.42 -> 1.42 has been pretty smooth. [19:45] xteejyx: If they had the same toolchain changes, yes. [19:46] ScottK: where have you got the numbers from for the ftbfs stats? [19:46] ScottK: i.e. the new gcc? I see [19:46] They will do them for their next release, so they won't worry about it much until after Squeeze is released. [19:46] debfx: I used the numbers from qa.ubuntuwire.com/ftbfs. [19:46] 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] xteejyx: Yes. All three of those will be in the next Debian release. [19:48] ScottK: ubuntuwire doesn't show packages which initally built fine but can't be rebuild, right? [19:49] debfx: That's correct. [19:49] That's what we need lucas's rebuild tests for. [19:51] 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] those stats would be even more interesting but rebuilding all packages after release is kind of pointless [19:53] i.e. x11-proto-*-dev [19:53] debfx: it depends, on an LTS it can make sense for packages that will need updates during the 3/5 yr lifecycle [19:54] ScottK: can you ping me when it will be a good time to do a rebuild? [19:54] I was planning to do one on 29-30 october [19:54] 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] Or is it done via SRU> [19:56] lucas: Next week is likely good. Usually not a lot gets uploaded during UDS. [19:56] micahg: well, you'll notice that the package doesn't build when you update it :) [19:56] That's probabaly OK. [19:56] xteejyx: Removing -dev packages shouldn't hurt the system. [19:56] debfx: right, but if you need a critical security fix, you don't want to be figuring out an FTBFS issue [19:56] ScottK: Thanks Scott :) [19:57] xteejyx: If we can fix them via SRU, it's reasonable to do it. [19:57] Makes sense I suppose [19:57] 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] 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] ScottK: ok [19:58] ScottK: would you mind commenting on my MOTU application? [19:59] 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] micahg: Are you not already MOTU? [20:00] ScottK: AFAIK, not recently [20:00] micahg: OK. Link me and I'll leave a general comment about how wonderful you are. [20:00] ScottK: thanks, https://wiki.ubuntu.com/micahg/MOTUApplication [20:01] ScottK: I have something if you want to sponsor (transitional package fix for lsb-core) [20:02] Probably not today, so I'll just comment. [20:02] ScottK: Ok, thanks [20:02] I wish there was an easier way to see who sponsored what [20:06]