[00:29] kees: hey, did you have a chance to look at uploading the branch attached to bug 538471 to karmic-security? [00:29] Launchpad bug 538471 in autokey "autokey: insecure use of temporary files (Data Corruption, Local Denial of Service)" [Medium,Fix released] https://launchpad.net/bugs/538471 [00:31] carstenh: fixed & uploaded, thanks. [00:36] Is there an easy way to do the intent of "patch -R < 1.patch > 1_reverse.patch" ? [00:37] crimsun: thanks for the quick fix :) === blueyed_ is now known as blueyed [01:26] For GPL projects, all of the project source files do not need a GPL header and authorship information, do they? (http://dev.laptop.org/ticket/6891 doesn't make sense to me) [01:26] lfaraone: they do. [01:27] jdong: mk. a "this package is free software, you may..." in README isn't enough? [01:28] no [01:28] lfaraone: https://wiki.ubuntu.com/PackagingGuide/Complete#Copyright Information [01:28] For all files it must be clear under which license they fall. Source code files should usually have a short comment at the top which points out the license. [01:51] jdong: this doesn't sound correct and your link does not justify your statement, nor does common sense [01:51] carstenh: what doesn't sound correct? that each source file should have a copyright header stating its license? [01:52] feel free to get someone else here to clarify that point, but that was always my understanding of what the archive administrators expect to see. [01:52] jdong: well, should != must [01:52] carstenh: should as in I've had several packages rejected in my 3-4 years of packaging around here for that reason :) [01:52] so should \approx must. [01:53] jdong: do you know an example (without looking it up, this wouldn't be woth the effort)? [01:55] carstenh: examples are hard to find in that archive rejections usually are handled by a private email from an archive admin, and the history is not recorded in LP [01:56] jdong: i wanted more example for a rejected source than the rejection itself [01:56] but only if you remember a name without looking it up [01:56] looking on REVU should give you plenty of examples [01:57] crimsun: Why did you change the VCS stanzas in topgit? [01:57] zcat (shell script) in bzip2 is a trivial example for a gpl source without gpl header [01:59] There are pleanty of cases where the GPL header is missing. [01:59] These are bugs and should be fixed. [02:00] As long as the upstream intent for licensing is clear and well documented, then the lack of the header won't get a package rejected from the archive. [02:00] !rejected != bug free [02:00] Error: I am only a bot, please don't think I'm intelligent :) [02:32] ScottK: pitti started me doing it some time ago [02:32] crimsun: OK. We had a discussion about it on #ubuntu-devel. I hadn't seen it before. [02:32] Seems like overkill to me for minor package changes. [02:33] apache2 is where I'd seen it before, packaging changes are a bit more in-depth there [02:33] Makes more sense to me in that kind of context. [02:33] In Kubuntu we replace the Debian ones with pointers to our own. [02:34] ScottK: I'm happy to revert it, but I do it from force-of-habit these days. [02:34] crimsun: No, it's fine. [02:40] ScottK: we don't need to subscribe -release for minor changes yet, do we? [02:40] ajmitch: Not for bug fixes in Universe, no. [02:40] great, ~ubuntu-archive it is [02:42] ajmitch: If it's an upload, you can just upload and it'll get reviewed in the queue. [02:42] it's a sync [02:42] OK [02:42] and it's just to fix a FTBFS, so probably low priority [02:43] YES!@ got e2defrag working with extents [02:44] ajmitch: No, we want those. [02:44] (I hope you were being sarcastic) [02:44] ScottK: low compared to needing to get something fixed ASAP for release [02:45] A package that works but can't be rebuilt cleanly can probably be fixed in a SRU [02:45] I think having a maintainable archive for LTS is very important. [02:45] True. [02:45] & with only a few days left to get fixes in, you probably want to make the most of that time [02:46] OTOH, the builders are sitting idle right now. [02:46] That's unusual, noone has uploaded gcc & OO.o today? [02:46] Nope. [02:46] gcc was yesterday. [02:47] * ajmitch shouldn't leave fixing stuff so late for 10.10 [02:48] Better late than never. [02:48] * micahg has a fix if a sponsor wants to upload :) [02:48] bug 562737 [02:48] Launchpad bug 562737 in libjdic-java "Update libjdic-java for xulrunner-1.9.2" [Medium,Confirmed] https://launchpad.net/bugs/562737 [02:49] ajmitch: ^^^ - If I upload it, I can't review and accept it. [02:49] * ajmitch spots java in the name & runs :) [02:50] It'll be fun. [02:50] fetching now, it may take some time to testbuild [02:50] ajmitch: it's a one line change in rules :) [02:50] ajmitch: builds fast :) [02:50] but will probably require 100MB of packages to build it [02:50] * micahg doesn't recall [02:51] and worse, it requires xulrunner-1.9.2-dev just to run the clean target [02:51] * ajmitch hates packages that do stupid stuff in clean: [02:51] ajmitch: just trying to make sure it can build :), file a bug w/debian if you don't like that [02:52] * ajmitch is not on a fast connection at the moment [02:53] I'll have to leave it until later [02:55] ajmitch: k, no rush [02:55] ajmitch: You'd have to move to fix that. [02:56] ScottK: DSL isn't too bad at home, as long as I fetch from a NZ mirror [02:56] Good point. I forgot about local mirrors [02:56] * ajmitch isn't at home right now, but will be in an hour or so [03:01] xulrunner for :clean [03:01] wow [03:03] imbrandon: it's more the use of ant for everything [03:03] * ajmitch may have misread the requirement for the xulrunner package, but ant is annoying [03:05] ajmitch: no, I think it actually uses xul inside the package [03:09] Any MOTU here who cares about syncevolution working might want to investigate Bug #528326 and make a recommendation. [03:09] Launchpad bug 528326 in libsynthesis "Sync libsynthesis 3.2.0.35+ds2-2 from debian sid" [Wishlist,Confirmed] https://launchpad.net/bugs/528326 [03:39] ScottK: makes more sense to sync syncevolution from testing. [03:40] * maco giggles at that sentence [03:42] crimsun: Please say so in the bug if you haven't. [03:42] is that still possible to do so now? [03:42] Yes. [03:42] I got yours on the list I gave to slangasek already [03:43] ah, it was libsynthesis that got synced from sid, not syncevolution [03:43] ScottK: I meant in reference to that specific case, where 3.4.0.5 got synced [03:44] but I got confused as to which package was synced :) [03:44] Ah [03:45] but thanks for passing on the other sync request [04:44] ok so i got a question that may seem a little off but google is giving me too much info [04:45] i want to format an external usb drive with a filesystem that can handle usb permissions BUT is graceful on ripping it out without unmounting it [04:45] ~320gb [04:45] extX dosnt seem like it would be graceful on a unclean dismount [04:45] hum [04:47] imbrandon: ouch, you're probably gonna have to find that next to the good tasting diet soda and fat free donuts... [04:48] hahaha [04:48] the caching semantics on USB externals are apparently horrible at guarding against any sort of unexpected disconnect [04:49] i dont really care about nthe file integrity ( wont hold anything important ) mostly just dont wanna have to fschk it every other mount because i yanked it [04:49] well the cache is blind to data vs metadata. it'll lose both without discrimination :) [04:49] and some of the kinds of corruption that'll cause will likely be irreparable via fsck even. [04:49] hum [04:50] if you really don't care, ext4 or btrfs [04:50] yeah it's not a pretty picture [04:50] I don't recommend btrfs [04:50] it still oopses all over the place with any metadata corruption [04:50] and it relies on barrier semantics to prevent said metadata corruption [04:50] hence the "if you really don't care" [04:50] And if jdong doesn't recommend something, you really don't want to use it. [04:50] HAHAHAHA [04:50] lol [04:51] I'd have to say ext4 is your best choice [04:51] physical block journaling should minimize corruption, and the fsck is one of the fastest. [04:51] fat32 does what i want as far as not having to fsck the damn thing, but no unix permissions support sux [04:52] ok, ext4 it is then [04:52] well fat32 technically needs to be fscked way more than ext3/4 [04:52] hehe well the mounter dosnt complain about it [04:52] you can have all kinds of fun structural issures with dirty fat32's [04:52] lol no the mounter doesn't complain [04:52] but it's a far more hazardous situation [04:53] 7 minutes to take advantage of the newegg 80 GB intel X25-M SSDSA2MH080G2R5 for US$214.99 ;-) [04:53] hahaa [04:53] esata is probably better [04:53] but I don't assume change-of-interface is an option [04:53] well this thing is gonna just be sneakernet use mostly , for movies and such between my wii and my laptop and desktop [04:54] jdong: and no, i have a cheap usb enclosure i'm ussing on my 2.5in sata western digital 320gb drive ;) [04:54] :) [04:54] but its easy to stick 100gb of movies on to watch on the wii [04:54] :) [04:55] yup :) [04:55] ( and the kids cant scratch the disks ) [04:56] crimsun: wow, i wish i had the money, just seen what you said about the ssd [04:56] the next laptop i purchase i'm going to get a ssd for ( even if i have to buy it seperate and replace the internal drive ) [04:59] i could just splurge on wired networking for the wii and keep the drive perm attached, lol [04:59] that would seem to easy though === ara_ is now known as ara === ara is now known as Guest45645 === Guest45645 is now known as ara_ === ara_ is now known as ara [08:24] good morning [08:25] anyone familiar with packages which include upstart scripts ? [08:31] joaopinto: I've seen a few: generally dh_installinit does the right thing. [08:32] bug 530179 needs some love [08:33] Launchpad bug 530179 in virtualbox-ose "[lucid] vboxsf mounts defined on /etc/fstab cause errors on boot" [Undecided,New] https://launchpad.net/bugs/530179 [08:33] the vboxsf support module needs to be loaded from a startup script. prior to mountall [08:34] *prior* to mountall? [08:35] Ah, reading the bug log: along with starting mountall. [08:36] OK. So have you tried with a local /etc/init/virtualbox-ose-guest-utils.conf ? [08:36] well, was trying, but failed and I was too tried to debug it [08:37] but I guess it will be easier for someone with upstart scripts experience [08:37] I find upstart scripts hard to debug [08:37] Ah. I know lots about how to deploy them correctly. I know much less about the contents/ [08:38] I will need to ping Scott [08:39] He's exceedingly rarely in this channel: -devel might be better. That said, it may just wait on him to respond to the bug, based on the last comment asking him for input. [08:41] as i understood that last comment will cover the error aspect of the bug, on the mountall, not the packaging issue :) [08:41] Oh. I read it as asking for input on the content of the upstart script that should be included. [08:42] persia, ops, you are right [08:51] still about the vboxfs issue, if there are packages providing filesystems from external modules we may get the same problem === lukjad007 is now known as lukjad86 [11:59] ScottK: ping === traveller_ is now known as traveller === ogra_ is now known as ogra === _scottl_ is now known as _scottl [14:57] gday [15:39] :) [15:54] could someone take ppa packages and get them into official ubuntu if they are perfect, lintian like? [15:55] tarzeau: packages are not included from PPAs. you want to upload them to http://revu.ubuntuwire.com/ for REVU [15:56] who is responsible for revu here?, the wiki siad I should state it here if my upload wont show up in REVU [15:57] c_korn: thanks, i'm looking at that page [15:57] c_korn: and that's for already in but newer version packages, and completely new packages? [15:58] warsocket: which package? [15:58] gsmartdimmer0.0 [15:59] gsmartdimmer_0.0-0ubuntu1 in full [16:00] warsocket: hm, can't find such a package, not even in the rejected queue [16:00] weird [16:00] warsocket: do you still have a .upload file? [16:00] yes [16:00] warsocket: can you pastebin it please? [16:00] Successfully uploaded gsmartdimmer_0.0-0ubuntu1.dsc to upload.ubuntu.com for ubuntu. [16:00] Successfully uploaded gsmartdimmer_0.0-0ubuntu1.tar.gz to upload.ubuntu.com for ubuntu. [16:00] Successfully uploaded gsmartdimmer_0.0-0ubuntu1_source.changes to upload.ubuntu.com for ubuntu. [16:01] warsocket: That went to ubuntu, not REVU... [16:01] warsocket: ah, you didn't dput to revu, but to ubuntu (it'll just get silently dropped there) [16:01] oh [16:01] the wiki siad dput automaticlly would upload it it the right oplace [16:01] but ill have a look how to change that [16:02] thank you [16:02] warsocket: dput revu [16:02] ;) [16:02] ok tmx [16:02] k, done [16:03] now I hope to see it in 5 mins, thanx for the help [16:04] yw [16:06] Package is for "Maverick" but only packages for "lucid" are currently accepted. [16:06] I thought lucid was alredy closed? [16:06] it is [16:06] archive is frozen.... [16:07] so basicly I cant upload my package to a single distro [16:07] warsocket: you have to wait for lucid to be released before uploading to maverick. [16:07] lucid is frozen maverick is not yet active [16:07] ok [16:07] warsocket: yes,what you can do is upload to your PPA [16:08] that way you can get out new packages [16:08] warsocket: then port them to maverick and upload [16:08] erm stupid question maybe [16:08] whats a PPA [16:09] !ppa | warsocket [16:09] warsocket: With Launchpad's Personal Package Archives (PPA), you can build and publish binary Ubuntu packages for multiple architectures simply by uploading an Ubuntu source package to Launchpad. See https://help.launchpad.net/PPAQuickStart. [16:10] oh ok I get it tnx [16:10] np [16:10] warsocket: support in #launchpad [16:10] you btw have soem experience with gambas [16:10] I also have a error that i cant have build depends when creating a package for all architectures [16:11] but the build depends on gambas2-dev [16:11] *was just a long shot [16:11] but tnx for the PPA will have a look === yofel_ is now known as yofel [22:21] Hi there ! [22:21] We have some last-minute bug-fixes for the Lucid package of Cairo-dock, and we need someone to ack these so that they can be pushed in Lucid. [22:21] Please see https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/568083 for the complete description of the fixes. [22:21] Launchpad bug 568083 in cairo-dock "Please update Cairo-Dock to v2.1.3-10" [Undecided,New] [22:24] this 'little' release is important because it fixes a crash with libxml [22:25] only appeared on Lucid [22:26] and this crash appears when the user changes theme, or with weather applet, etc. [22:29] So, looking at the bug, it seems all bugfixes, which typically means no barriers to upload. [22:29] The bug seems to indicate lp:ubuntu/cairo-dock should be uploaded, but the last revision there is fom 2009-10-05 [22:29] yes, it's only 3 nano versions that we wish to push into the Lucid package [22:30] Is that branch accurate, or are there updates? [22:30] persia: there was a bug with lp:ubuntu/cairo-dock [22:30] What's the bug? [22:30] Or do you mean bugs in the software in that branch? [22:31] no a bug with the branch... in fact there is no rev11 [22:31] I already have reported this bug [22:32] OK. How would rev11 get there? [22:32] Who pushed it? Where? When? [22:32] (and what's the bug you reported about the branch?) [22:32] this bug was confirmed by James Westby [22:33] I believe it's a bug :) [22:33] I'm just trying to collect enough information to 1) make sure that either processes are followed, or I can tell you what needs doing, and 2) get the necessary bits to upload something. [22:33] I don't know where is this rev :) [22:34] OK. How do you know that it existed? Do you know if it exists somewhere else? [22:34] it exists on my branch : https://code.launchpad.net/~cairo-dock-team/cairo-dock-core/ubuntu [22:34] Great! [22:35] There's a revision 12 there too. Is that also something that should be uploaded? [22:35] the rev 11 was the version 2.1.3-6 of CD => http://packages.ubuntu.com/lucid/cairo-dock [22:36] and the rev 12 fixes some other bugs (and a crash with libxml) [22:36] So rev 11 is the current state of the repository, and rev 12 is the desired state? [22:36] yes :) [22:37] OK. There's two things I'd like to see then. [22:37] 1) Please link the branch and the bug. [22:37] oh yes, sorry :) [22:37] 2) Please submit a merge proposal for lp:~cairo-dock-team/cairo-dock-core/ubuntu into lp:ubuntu/lucid/cairo-dock [22:38] Next: this also affects the cairo-dock-plug-ins source? [22:38] Err, "cairo-doc-plugins" [22:38] yes for the plug-ins, it also contains some bug-fixes [22:39] OK. Please also link that branch, and submit a merge proposal from that branch into the lucid branch. [22:39] ok, the two branches have been linked [22:40] (Yes, this is busywork since I'm going to upload, but this procedure also causes automated notification, which *should* reduce your need to come hunt folks in IRC in the future) [22:40] Great! [22:41] OK. I see both branches. Each should have a merge proposal. [22:41] *also*, the bug shoud get a cairo-doc-plugins task: "also affects distribution"..."Ubuntu"/"cairo-dock-plugins" [22:42] ok, merge proposal done [22:42] ok [22:43] Excellent. [22:43] project added! [22:43] thanks :) [22:44] Now, as soon as the branch discovery tool runs, this would show up on http://qa.ubuntu.com/reports/sponsoring/ [22:44] And if you get it on that list, the sponsors know they are supposed to upload it. [22:44] This isn't a guarantee it gets uploaded (or reviewed) sadly (lack of developers checking the list), but it can let you confirm that you've followed the right procedure to request the sponsoring. [22:45] (and most of the time should save you a visit here to catch someone). [22:45] Now, I've no idea if it will actually appear there, as I plan to try to figure out how to upload it now, and I may succeed before the sponsoring report includes it. [22:45] ok, so we just have to wait for a new sponsorship [22:45] Right. [22:46] do we have to add some tag? [22:46] s [22:46] And the sponsor should be assigning themselves when they claim it, so you will get bugmail saying that something is happening. [22:46] Nope. No tags requied. [22:47] great :) [22:48] good reminder [22:48] * Laney does some sponsoring [22:48] :) [22:49] * persia gets sick of watching bzr download at 20KB/s and does it the old way [22:49] wait [22:49] persia: Wine upstream's sound guy commented on https://bugs.launchpad.net/ubuntu/+source/openal-soft/+bug/565071 [22:49] Launchpad bug 565071 in openal-soft "[lucid] Freeze Exception Request: OpenAL minor version bump" [Undecided,New] [22:49] what are the semantics of the ubuntu branches request on https://code.edge.launchpad.net/~voronov84/ubuntu/lucid/ubuntu-dev-tools/lucid/+merge/23577 ? [22:50] Do we need to add subscribers? SRU Verification, ubuntu-sru, etc. ? [22:50] Does it mean "Uploaded to Ubuntu?" [22:50] matttbe: A merge proposal should automatically appear in the sponsors report. You can also subscribe ubuntu-sponsors if you attached a debdiff. We're currently supporting two workflows. [22:50] persia: I want to SRU wine 1.2 when it fully releases in about 2 months to Lucid. So we either put OpenAL 1.12 in now or do it then (and in the meantime I bundle openal 1.12 in the wine ppa and test it there) [22:50] (because some people find bzr easier to use, and some people like http being 100x faster) [22:51] should we be cherrypicking important fixes now? [22:52] YokoZar: Thanks for getting the testcase: I'm completely satisfied (but I'm not on the release team, so you need someone else's ACK) [22:52] Laney: We're only allowed to upload bugfix stuff now: cherrypicking may be the easiest way to do that. [22:52] persia: I mean scanning the sponsoring list for "important" bug fixes [22:53] (the sponsoring overview page doesn't make this easy) [22:53] Laney: If you like. Alternately, just go through all of it, and milestone some of it for ubuntu-later [22:53] I don't know what that milestone does, but alright [22:54] I think it means we'll do it later (post-release). [22:54] I may be mistaken. [22:54] But obviosly, pick the important stuff first (but don't fuss too much about it if it's good bugfixes) [22:55] Grrr!!! bzr is painfully slow, and LP is giving me 502s trying to make LP use bzr locally and give me diffs over http. [22:57] I'm lost [22:57] how can I subscribe to a merge request so that I can ask the submitter a question? [22:57] * persia has no idea, and just comments in bugs [22:58] persia: do you want that I add a diff a both branch? [22:58] I'm so out of touch with this stuff. [22:58] Just clicked through to the bug after asking if it should be deferred and it looks like the package has been uploaded already. [22:59] matttbe: No, I'll work around it. Thanks for the offer. [22:59] but the merge proposal is still pending [22:59] * persia routinely fights with LP, but is generally quiet about it, but 100x was too much to take today (2MB/s vs. 20KB/s) [23:00] persia: It's the libticalcs stuff that it seems you looked at. These merge requests can be close out, right? [23:00] Laney: Then just mark it merged. [23:00] I thought it was supposed to be automatic, hence the confusion [23:00] Laney: I haven't looked at them in a really long time, and I'm not sure. [23:00] ok then [23:00] I thought it was all automatic, and I wonder if kamalm submitted additional changes. [23:02] Based on what I see of merge proposal management in other projects in LP, I have the impression that updating a branch on which there is an active merge proposal ends up updating the merge proposal, so if someone doesn't purge all their branches regularly and give them new names, and the merge proposals aren't cleared regularly, there may be confusion. [23:02] Laney: merge proposol get auto marged "merged" when you push the (packaging) branch back to LP, an upload alone does only update the (packaging) branch but doesn't update the pending merges (the upload doesn't contain any info about done merges) [23:02] (note that I really like how merge proposals work in projects in LP: I just don't understand how they work in Ubuntu) [23:02] geser: So the uploader didn't push back to lp? [23:03] if the MP is still pending, then yes [23:03] ok then [23:03] Oh :( Then I'm probably breaking it by not waiting for bzr [23:04] I usually do "bzr bd -S", test-build, "bzr mark-uploaded", "bzr push", "dput" [23:05] yeah, that's the workflow [23:05] I usually forget the tag though [23:05] Someone else want 568083 then? [23:05] * persia is unwilling to download 59MB at 20KB/s [23:06] I'll see how fast it downloads [23:06] Laney: If it's slow for you, I have all the code locally, and can process it easily, just not with bzr. [23:06] bzr init-repo is the trick to make it share state isn't it? [23:06] persia: sure that you don't want the (bzr) diff :) ? [23:06] Laney: yes [23:06] matttbe: I have the diff already. [23:06] ok great [23:07] matttbe: https://code.launchpad.net/~cairo-dock-team/cairo-dock-core/ubuntu/+merge/23889/+preview-diff/+files/preview.diff is an example diff URL. [23:07] What I lack is the bzr metadata. [23:08] persia: It's fast here; I'll take it [23:11] Laney: re subscribing to MP: have you tried to add yourself as reviewer? [23:11] Laney: Thanks. [23:11] geser: No (it's not clear that that's what it does) [23:12] should "bzr diff ../branchtomerge/" work? [23:13] no, that would show the diff for the file "../branchtomerge" [23:13] can I do it like that? [23:13] what diff do you want? [23:13] between the branch I'm on and the branch I am about to merge [23:14] or do I just merge it and then check from there? [23:15] either that or as branchtomerge should have a common accestor with the branch you are on: bzr diff -r123 [23:15] yeah I thought it would be able to figure that out [23:16] perhaps "bzr diff --old a --new b" works too [23:16] bzr diff lp:... would have worked I think [23:16] that works too [23:16] which isn't too different to ../someotherbranch [23:18] if you do this often, you could branch lp:... and do "bzr diff --old ../lpbranch" to save network traffic [23:19] I usually branch the thing that needs sponsoring and the packaging branch [23:20] me too, in that case bzr diff --old ... should work [23:20] from which branch? [23:22] "cd sponsorbranch; bzr diff --old ../pkgbranch" or "cd pkgbranch; bzr diff --new ../sponsorbranch" (although I only use the 1st and never tried the 2nd) [23:22] alright [23:22] will try it in a minuet [23:33] geser: Do you know if there's a good way to make https://code.launchpad.net/~voronov84/ubuntu/lucid/ubuntu-dev-tools/lucid/+merge/23577 go away? [23:33] Do we care about not-binnmuable-all-depends-any? [23:33] Ah, Laney appears to have already fixed it. [23:34] Laney: Not enough to upload to Lucid at this point. [23:34] persia: I don't know, I think maybe that should stay open until the package is uploaded [23:34] Laney: That makes sense. [23:35] persia: but you could push to the lp:ubuntu/ubuntu-dev-tools branch to make it go away [23:36] Well, except that I merged in on top of DktrKranz's stuff, which wasn't there and doesn't share revision history. [23:37] surely there'd be some shared history that'd be used as an ancestor? [23:37] ajmitch: None whatsoever. [23:38] ajmitch: Because the one branch is where we've always done work and the other is constructed based on the history of uploads. [23:38] how annoying [23:38] and you get file conflicts when trying to merge, I suppose? [23:38] No, you can't merge. [23:39] "No common ancestor" error. [23:39] not without some forced hackery, I think [23:39] at which point you'd probably run into those conflicts [23:39] To my knowledge, bzr has no file-content-comparison merge feature directly. [23:40] Given a common ancestor, you can init a bzr branch on the common ancestor, branch that branch, apply monolithic patches to both sides, and then use bzr merge to reconnect. [23:40] This is annoying, but works nicely, if you like how bzr merges. [23:40] * persia doesn't happen to like bzr merge at all, but mostly because of the format of the conflict markers, rather than anything about how the algorithms work [23:41] merging with no common ancestor is done against revision 0..-1 or similar, I think [23:42] When I tried it, bzr gave me an error, so I constructed a series of patches that did the right things, and applied those with interim commits. [23:43] Someone with more patience or less joy in building patch series may have better luck. [23:43] much patience is required at times, I think [23:45] * persia will eventually be assimilated [23:46] * micahg gave up on bzr merge for archive merges after it didn't delete files properly [23:47] oh, bah, I forgot to do merge-package again [23:47] I hope there's not much difference between merge and merge-package [23:49] I think merge-package is upstream tarball aware or something. [23:49] persia: I've been stuck in my old-fashioned ways of not using bzr for package branches [23:50] ajmitch: Then you too, will someday, be assimilated. [23:50] ScottK: what's this about Wine being a part of Ubuntu studio seeds? I can't see any rdepends for it anywhere [23:50] I actually like using bzr and debcommit for native packages in bzr (e.g. u-d-t, installer stuff, etc.) [23:50] YokoZar: Because of the VST plugins. [23:51] persia: you mean the ones that don't build at all at the moment because we're waiting on the Wine update? [23:51] YokoZar: RC will be out *really soon now* [23:51] YokoZar: Yeah, but we're not going to get enough testers to handle a DVD respin in time for RC. [23:51] matttbe: Uploading cairo-dock [23:51] thanks for your work [23:51] (please fix that lintian error for the next upload) [23:52] many thanks Laney ! [23:52] Laney: which lintian error? [23:52] persia: what I mean is as I understand it ScottK waited on my wine1.2 package update because of ubuntu-studio, but I needed to do that update (and then another wine one) in order to prevent the VST FTBFS [23:52] the one about it not being binNMUable [23:52] matttbe: run lintian -i blah.dsc and you'll see it [23:53] ok [23:53] persia: so it's a mystery to me how the Ubuntu Studio image is being built at all if it actually depends on it [23:53] YokoZar: Right, so in fact the piece that was affeted was completely broken. That said, it's not critical enough to respin the images and make the testers test again. [23:53] Laney: don't forget 'cairo-dock-plug-ins' ;) [23:53] surely not, I'm looking at that one now [23:53] YokoZar: It fails to include that bit, which is a bug. [23:54] Laney: great! thank you very much :) [23:55] persia: ok, makes sense. I'm just a bit uneased that I didn't notice this problem before, and we're pretty much at the last possible moment here [23:55] * YokoZar should start using Ubuntu Studio... [23:56] YokoZar: No point reinstailing: the main bit you'd notice is the VST stuff: if you have *some* VST host, you'll encounter the entirety of the bugs. [23:56] matttbe: Are the plugin dependencies on cairo-dock-dev tight enough? [23:56] But the upload can surely happen as soon as RC is released. It's just that if it happens now, and the images are respun, they won7t get tested, and there will be no US RC. [23:56]