[00:01] csilk: here you have an example of how such a rule looks (this one is to package a bzr snapshot instead of repackaging, though): http://paste.ubuntu.com/68134/ [00:02] Yeah that looks simple [00:02] much cleaner than making manual changes [00:04] well, I'm off [00:04] see you tomorrow === asac_ is now known as asac [00:34] RAOF: so I'm using the grab-merge.sh script to pull miro [00:34] and the .patch files seem empty [00:35] should I gunzip the diffs and compare those? [00:38] Yasumoto: Looking on merges.ubuntu.com there are conflicts in the merge; thus you'll need to actually look at the various diffs and unpacked tarballs, yes. [00:38] cool [00:38] and for the bug I'm filing, something like "Please merge miro 1.2.8-1 from Debian unstable" would work? [00:40] Yeah. You could possibly title it as "I'm merging miro 1.2.8-1 from Debian unstable" and retitle it once you're done, but that title looks fine. [00:40] will do [00:41] RAOF: thanks :) [00:50] If source comes from CVS should I remove CVS specific dirs and files before packaging? [00:50] if so, do I just do this by rm'ing the said failes/dirs [00:52] cvs export is cleaner than running through with rm [00:55] ajmitch, by export do you mean a specific flag that doesn't include cvs specific files? [00:55] iirc the command is just cvs export [00:55] it's been a long time since I've used it [00:56] people still use cvs? [00:57] I did a simple export, as axpected, it included all the cvs files [00:57] zul, yeah sourceforge do [00:57] zul: apparantly [00:57] *expected === woody86_ is now known as woody86 [01:12] come to think of it the version control system used makes no difference as they all leave their own dirs and files in the source === Pici` is now known as Pici [02:01] Anyone awake? [02:01] sort of [02:04] "Non-native packages must have verifiable cryptographic path to upstream source " [02:04] Could you possibly elaborate on that? [02:05] it's form the new package review guidelines [02:05] *from [02:05] lol [02:05] like upstream have a monopoly on safety? [02:06] verifiable? how? [02:06] That strikes me as overly paranoid [02:06] Verifiable by checking the md5sum of the tarball, perhaps. [02:06] do I have to drive and check the upstream author's passport? [02:06] james_w: it may help [02:06] wgrant, if an md5sum isn't provided by upstream then what? [02:06] wgrant: But then you need check the signature on the md5sum, and have a trust path to his key === santiago-ve is now known as Guest94206 [02:07] * ajmitch is surprised that it's written as 'must have' === Guest94206 is now known as santiago-ve [02:07] csilk: Then your upstream needs to be hit with something very spiky. [02:08] hey wgrant [02:08] Hi NCommander. [02:08] wgrant, I'm sure alot of apps have this issue in the repositories, that's alot of upstream beating ;) [02:09] Doesn't mean we need to add more. [02:09] That takes away alot of potential software then [02:10] everything packaged from svn becomes inadmissible [02:10] and cvs [02:10] even then, StevenK had a good point about untrusted sigs [02:10] and rcs [02:10] etc etc [02:10] Well given the current state of DNS technology believing you got what you asked for when DNS is involved is optimistic. [02:10] true [02:10] so [02:11] If you pull via ssh and know the distant end's key, you still have a good trust path. [02:11] we can only package content with either a gpg web of trust signed md5 of the content or dnssec end to end to identify the web host + https w/ good certificate [02:11] ScottK: only if the far end key was given to you securely [02:11] True. [02:12] do these guidelines get reviewed? [02:12] lifeless, so package A, a requested package, maintainer manages to get upstream to include signed md5sum, this signiture is not part of a web of trust, would this app have a chance? [02:13] Where are the guidelines? [02:13] I think that they should remain as prohibitively difficult as possible. [02:13] csilk: we don't normally go nearly as far as that to check [02:13] csilk: sounds like it wouldn't because you can't be sure that upstream made the signature [02:13] csilk: only someone that claimed to be upstream [02:14] its also more than slightly insane that this rule only apply to non-native packages [02:14] native is *not* special [02:14] So it sounds like we need to write a better rule. [02:14] lifeless: There is no other upstream for native packages... [02:14] It sounds like this rule is probably ignored for n anount of current packages [02:14] It'd also be handy if all the source in our own archive were signed. [02:14] i dont believe all current packages have verifiable links to upstream [02:15] wgrant: you misunderstand what native really means I think. It really means 'a tarball is uploaded on every change' [02:15] wgrant: it has *no* deeper implications than that [02:15] wgrant: for all that some people may wish it idid [02:15] csilk: I think it's more important recently because it's easier to fake stuff than it used to be. [02:15] lifeless: I'm aware, but if there is another upstream then being native is *wrong*. [02:15] And should be punishable. [02:15] which is where we get things like the wxwidgets packaging from [02:15] wgrant: It happens though. [02:15] wgrant: which has nothing to do with the security/relevance here [02:16] ScottK, so this pretty much invalidates a large portion of package-requests [02:16] wgrant: also, under that approach, nothing in ubuntu that is native in debian should be native in ubuntu [02:16] wgrant: because, there is another upstream - debian. [02:16] csilk: I think we need a reasonable definition of what needs to be done. [02:16] lifeless: True. [02:16] the brutal reality is that native is just a bad way to upload any package, but its enshrined due to history [02:17] ScottK: Yes, "Go to Debian" [02:17] ScottK, are we going to get that any time soon? [02:17] Dunno. [02:17] csilk: this discussion is probably the start of one [02:17] * ScottK only volunteers here. [02:17] ScottK: so does just about everyone else [02:18] I have two packages I would like to submit for REVU very soon, they suffer from this issue, shall I just not bother submitting them then? [02:18] I do, thats for sure [02:18] csilk: submit them [02:18] ajmitch: Sure, but don't turn to me to be the authority on what'll happen when. [02:18] csilk: in general, ignore insanity in the process [02:18] haha [02:18] ok [02:18] Odds are most other people are too. [02:20] While people have their eyes on irc.... When packaging something pulled from cvs/svn etc I assume all version control based files and dirs are to be removed from the source? [02:21] csilk: its inefficient to include a lot of metadata [02:21] so yes [02:21] see the $vcs-buildpackage scripts, which know how to do that for you [02:21] Any prefered method or can I just rm? [02:21] ok [02:21] thanks [02:21] Also, a generally better plan is to package a release rather than a random VCS snapshot. [02:22] RAOF: depending on sanity of upstream [02:22] yeah I agree with that RAOF but sometimes that's not possible/desirable [02:22] Right. [02:22] We'd be waiting a _long_ time to package ffmpeg, for example :P [02:22] when did it last release? [02:22] Never? [02:23] heh, fun [02:23] releases are more important the more destabilising changes outside a release may be [02:23] when did it ever have a stable API? [02:23] for instance libraries are a problem [02:23] A[PB]I stability in ffmpeg? Hahahaha. [02:24] "If you are looking for a formal release, stop now, there are none. Maybe we will have some in the future, but don't hold your breath." [02:24] I think this is why there have been so many copies of ffmpeg source bundled [02:24] Abolutely. [02:24] I really wish that there was an alternative to ffmpeg. [02:24] That's the way the ffmpeg devs recommend, since providing API/ABI stability would inhibit their ability to perform micro-optimisations. [02:25] That way we could tell upstream go to fsck themselves and get out of our distro. [02:25] wgrant: You can have a pretty reasonable gstreamer-based system without a trace of ffmpeg. [02:25] RAOF: Right, but lots of apps need ffmpeg. [02:25] its a complete strawman though [02:25] change api - bump soname [02:25] change abi - bump soname [02:26] ITS NOT THAT HARD [02:26] lifeless: These are ffmpeg developers... [02:26] lifeless: Also, if they made a release they'd feel obliged to support it in some way. They don't want to do that. [02:26] * RAOF spent an instructive year or so on the ffmpeg-devel list. [02:27] well, thats in their heads [02:27] :P [02:27] There's something wrong with multimedia that rots people's brains. [02:28] There's a lot of overlap between mplayer & ffmpeg developers, and mplayer famously changed 1/3 of their codebase (or something like 300KLOC) between rc1 and rc2 of mplayer 1.0 :) [02:28] * StevenK whispers "Quicktime" [02:29] yah [02:29] * wgrant murders StevenK. [02:30] there is a multimedia fragments http wg [02:30] RAOF: It was more then 300KLOC... I did that merge. [02:30] more than slight oddity sometimes in their thinking [02:30] That was insane. [02:30] RAOF: because 300KLOC was obviously all release-critical fixes [02:30] * StevenK burns an Anhk and self-resurrects [02:30] StevenK: :P [02:30] They rewrote so much stuff it wasn't funny. [02:30] heh [02:30] Shifted things around, embedded more upstream projects. [02:30] It was a wonderful release candidate. [02:32] * ajmitch wonders if ubuntu could learn from such releases [02:32] It's like Gentoo, but without masking. [02:32] Only if the lesson is "How NOT to do things" [02:32] have the jaunty RC be a nice, normal release [02:33] & then a week later put out an untested desktop with E17 & the hurd [02:33] I think a year's gap between RC1 and RC2 would allow for a significant increase in bugfixing, yes :P [02:34] * RAOF watches as gnome-do slowly but surely inches its way to the top of mem usage. [02:34] Hmm. [02:34] It has been almost a year since rc2. [02:34] I wonder what the diff is now. [02:34] So it's about time for rc3 to drop? :) [02:35] Yep. [02:35] * RAOF will leave that little bundle of joy right where it lies. [02:35] 1.0 will be upon us RSN? [02:35] I presume they did it just to stop people from complaining they never get close to a release... [02:36] obviously they're going to commit to a 1.0 release at some point, right? [02:36] They should just have the courage of their convictions and tell everyone to run from SVN. [02:46] wgrant: Any suggestions on where I find the binaries for this upload: https://launchpad.net/ubuntu/intrepid/+source/libspf2/1.2.9-0ubuntu0.1 [02:48] ScottK: Ahahahaha. 3 links that look like they might go somewhere, but all link to that page. Let's see if it's possible to get there without going via /ubuntu [02:49] ScottK: Aha. You can click on "Intrepid" in the SPP section, then look down the bottom. [02:49] But that's only because it's currently published in Intrepid. [02:49] If you wanted an old one, you'd need to click on Intrepid, click on a release in the portlet, click on a build, click on a resulting binary. [02:51] You know, I would report bugs on this, but I could just wait 8 months and fix them in an hour myself when LP is Freed. That will get them fixed faster. [02:52] ;-} [02:52] wgrant: In 8 months you can make patches. It doesn't mean they'll actually get used. [02:53] ScottK: True. [02:59] wgrant: you're optimistic if you think that it'd only take 1 hour to fix :) [03:00] ajmitch: It's just shuffling around a few links in the TAL. [03:00] it's still zope [03:00] Heh. [03:01] I shouldn't be such a pessimist, but it comes from having worked with plone again this week [03:02] Fortunately LP is not Plone. Nor Zope 2. [03:02] I know [03:19] james_w: That UEHS change shouldn't take too much code, but I won't be able to get to it for a couple of weeks [03:20] what is the change needed? [03:20] ajmitch: See http://jameswestby.net/weblog/ubuntu/04-revu.html [03:21] wgrant: yeah, didn't think it would, and I would be happy to do it, but I would want to talk to you first. [03:22] It could even easily be done just by running two instances, only changing a couple of lines. [03:22] running two instances seems like a bit of a waste [03:22] ajmitch: Why? [03:23] just more duplication [03:23] Slightly. [03:23] * ajmitch is still reading through to see just what changes james_w wants made to UEHS [03:26] bother, hard to do test builds of syncs & merges on this laptop [03:27] the infamous "No space left on device" problem [03:27] Aha. [03:29] ajmitch: bind mount to /dev/null [03:31] * ajmitch just deleted some old WoW patches instead [03:31] hi. I'm trying to package concordance, which is a library and utility to manage Logitech Harmony remotes, and I'd like to add a udev rules file (not provided from upstream), so that using sudo to run the utility wouldn't be necessary.. is that the right way to do things? also I'm wondering just how to add the file... [03:34] * StevenK still has 2.5GB free on his WoW partition [03:35] I suspect the WotLK installer will want a fair bit more [03:36] I don't run it on the laptop [03:37] StevenK: the 3.0.2 patch should be the bulk of it [03:37] lifeless: BC was still 4 CDs [03:37] StevenK: yes, but it could upgrade direct from 1.x [03:37] Ah [03:38] if you didn't buy BC you got the net upgrader to 2.0, which was a couple gb === Marce_ is now known as Marce [04:38] I'm not sure if this is an MOTU question but here goes. A buddy of mine installed his printer, a Toshiba eStudio2500c, and the driver that Ibex downloads has some dependencies. One of them being lsb-core which has postfix as a dependency. Is it *right* that postfix is installed and listening after installing a simple printer driver?! [04:54] So would something like meld be useful for visualizing changes to merge? === woody86_ is now known as woody86 [05:13] man, #ubuntu is wild [06:20] hello persia :) [06:26] Hi SUNWjoejaxx [06:28] persia: do you have a minute for a pm? [06:30] well actually an email would probably be better [06:38] If an email would be better, just send an email :) [06:42] persia: which email address would be best? your default one on lp? [06:43] * persia checks LP [06:44] SUNWjoejaxx, The first listed would be fine. [06:44] alright [06:44] persia: i will send you an email off tomorrow :D i am going to retire for the evening [06:44] persia: goodnight [08:35] james_w, Just FYI, UEHS contains not only Ubuntu-local packages, but also packages orphaned in Debian. [08:39] persia: His blog post says "The [08:39] UEHS page also lists packages maintained by the Debian QA team " [08:39] Without that bad linebreak/ [08:40] But my brain failed to process that bit :) [09:12] morning [09:12] hi [09:13] i'm looking for a sponsor [09:13] :) [09:17] verwilst, In what sense are you seeking a sponsor? [09:17] morning persia [09:17] evening NCommander [09:17] persia, how goes it? [09:17] * NCommander is looking for a toolchain guru [09:17] morning persia and NCommander [09:18] persia: well, i'm maintaining a zabbix package in my ppa [09:18] and the "official" zabbix package kinda sucks.. bigtime.. [09:19] so i would like to get my package into ubuntu [09:19] verwilst, OK. How different is your package now? [09:20] well, it seems that the debian guys just did a "cp 1.4 1.6" [09:20] while a few new subpackages were introduced [09:20] i also updated the config files, and reworked the rules a bit to take the new subpackages into account [09:21] So you have the same upstream version, with just some packaging changes? [09:21] yeah [09:21] it's not from scratch :) [09:22] In that case, prepare a version for upload to jaunty (mostly just changelog adjustments: you want to clean up the PPA versions, etc.). Collect a debdiff between that and the current version in Jaunty, and attach it to a bug against zabbix describing the improvements. [09:23] persia: excellent [09:23] persia: thanks, i will do tht [09:23] that [09:24] Subscribe ubuntu-universe-sponsors to the bug, and someone will review it. The queue is often reviewed in FIFO order, so it may be a while. [09:31] persia: 1.6 isnt in ubuntu yet though [09:31] only 1.4 [09:32] persia: do i need to debdiff the debian 1.6 then? [09:32] verwilst, It would be better to debdiff against the Debian one then. In that case, process it also as a merge. [09:32] !merge [09:32] https://wiki.ubuntu.com/UbuntuDevelopment/Merging [09:35] persia: hm, the jaunty package is rejected [09:36] Rejected: Cannot build any of the architectures requested: any [09:36] i don't see it on my ppa [09:36] and it's identical to my intrepid and hardy packages, only the changelog is changed [09:37] None of Jaunty's archs are enabled for PPAs yet. [09:37] that explains it :) [09:37] Needs an ~admin to flip a checkbox on a couple of DAS. [09:37] verwilst, Don't worry about not being able to upload to the PPA, just attach the debdiff. [09:39] persia: it's 2.5M [09:39] persia: is that big or normal? :) [09:39] (uncompressed ) [09:42] verwilst, That's a *lot* of changes. Is all of that intentional? [09:44] well it's a new version.. [09:44] 1.6 > 1.6.1 [09:44] maybe that has something to do with it? [09:44] and new sql files [09:44] and so on [09:47] Yeah. That would do it. If you're packaging 1.6.1, just attach your diff.gz to the bug. Make sure the watch file works, so your sponsor can download the tarball from upstream. [09:50] hm, i don't have a diff.gz actually [09:50] zabbix_1.6.1~hardy2.dsc and zabbix_1.6.1~hardy2.tar.gz [09:50] same for intrepid [09:51] built it with debuild -S -sa [09:52] persia: https://bugs.launchpad.net/ubuntu/+source/zabbix/+bug/294604 looks fine to you? [09:53] Launchpad bug 294604 in zabbix "Request to import zabbix 1.6.1 from my PPA to universe" [Undecided,New] [09:54] verwilst, Well, we don't import directly from PPAs, except in very unusual circumstances. [09:54] oh [09:55] You'll want to attach your diff.gz, and I'd recommend titling the bug "Please upgrade zabbix to 1.6.1" [09:55] persia: any idea why i don't have a diff.gz? [09:56] verwilst, Did you create the orig.tar.gz file in the parent directory before you built the source package? [09:56] yeah [09:56] maybe it's the -sa? [09:57] Also, looking at your debdiff, you'll want to use 1.6.1-0ubuntu1 as the version, and consolidate all the PPA changelog entries into one changelog entry for inclusion. [09:57] Cold be the version number : you don't have a hyphen in your versions. [09:58] i don't have a hyphen(~)? [09:58] Right. [09:58] 1:1.6.1~intrepid2 ? [09:59] Typically, package versions in Ubuntu consist of $(upstream_version)-$(Debian revision)ubuntu$(Ubuntu revision) [09:59] yeah [09:59] When there's no hyphen, I think dpkg-source thinks you're building a native package. [09:59] but not for ppa's i guess [10:00] hm, so i should create another package ( outside of my ppa ) with -0ubuntu1 [10:00] and attach that debdiff to the bugreport [10:00] Well, for PPAs, it's usually $(upstream-version)-$(Debian revision)ubuntu$(ubuntu-revision)~ppa$(PPA revision) or something. [10:00] oh [10:00] Right. Don't upload this version to your PPA : it's for the primary repository. Clean up the changelog, and when you get the diff.gz, attach that. [10:01] gah @ ~ppa [10:01] don't use ~ppa, people! [10:02] directhex: i switched from ppa to ~intrepid/... :) [10:02] * directhex hands verwilst cake [10:02] directhex: https://help.launchpad.net/Packaging/PPA [10:02] directhex: i guess this is the culprit then [10:02] it says "To do this, increase the Ubuntu version number and add a suffix of ~ppan (where n is your package's revision number). " [10:02] That's just bad advice. [10:03] "For example: you're creating an experimental version of the myapp_1.0.1 package. Your PPA package would be named myapp_1.0.2~ppa1. " [10:03] it's filled with WRONG! [10:03] Well, the text is good, but the example is poor. [10:03] Just changing "myapp_1.0.1" to "myapp_1.0-1" would probably address 90% of the confusion. [10:04] which is the versioning i kept :) [10:04] yeah apparently [10:04] ~ppa1 will be an acceptable suffix only when Quaint Quail is released [10:04] after that, ~ppa1 is fine [10:05] doc FAIL? [10:05] :) [10:06] directhex, Um, are you confusing '-' and '~' ? [10:06] persia, what version is given to ubuntu-backports versions? [10:07] foover~${CODENAME}1 [10:07] directhex, anyone who enables PPAs presumably prefers a PPA to a backport. [10:08] persia, for the same foover? [10:09] persia, if someone's using a PPA to try out a backport, before that backport goes "official", i'd take an official backport of the same version for preference. obviously the ppa would take precedence if it had genuinely newer packages [10:10] ppa new ver > ubuntu backport > ppa backport > ubuntu update > ubuntu release [10:10] directhex, I guess. Personally, I don't have a lot of sympathy for anyone using a PPA. [10:10] I find it useful for complex build-dependency chains to detect packages that won't build if a library is updated, but end-user installation is fraught with peril. [10:11] verwilst, Documentation marginally improved. Thanks for pointing that out. [10:12] persia, strictly speaking, isn't an experimental version of myapp_1.0-1 a job for myapp_1.0-1+ppa1, snice your package is NOT based on myapp_1.0-2? [10:14] directhex, That's a fairly convincing argument. [10:16] bureaucrat directhex, you are technically correct. the best kind of correct! [10:16] directhex, Actually, thinking about it, no, I don't think it's a job for +ppa1. I might have thought so had you suggested that last year, but with so much time of people using ~ppa1, it's probably hard to change now. [10:16] Consider that it's a ppa candidate for 1.0-2. [10:17] persia, if it's a genuine candidate, then i agree [10:17] While this is exceedingly rarely actually true, but let's pretend. [10:17] persia, if you're not in Uploaders:, then i agree rather less [10:17] given we're talking about a debian versioned package here, Uploaders is relevant ^_^ [10:18] god, i'm such an asshole :) [10:20] !ohmy | directhex [10:20] directhex: Please watch your language and topic to help keep this channel family friendly. [10:20] :P [10:20] sebner objects to donkeys? [10:20] the rare burrowing donkey of kuala lumpur, which lives in holes? [10:20] lol [10:23] o_o; [10:24] directhex, +1 on how explaining asshole is not indeed fowl language [10:24] * NCommander runs from the horrible pun [10:25] NCommander, added bonus: the avatar i use on forums is a feral chicken [10:25] Well, thats just foul [10:25] :-) [10:26] directhex, Yeah, well, let's ignore Debian/Ubuntu for PPAs for now :) [10:30] NCommander: I think you won't be added as long as the official announcement is missing [10:31] -ENOCONTEXT [10:32] sebner, Well, it's more waiting on two more of us to send comments. One of those should be there in the next few hours. I don't know about the other. [10:33] persia: dunno, NCommander said that the got this final +1 :P [10:33] persia, three, unless the MOTU council has five members [10:35] NCommander: but don't worry I never thought something else than everybody gives you a +1 [10:35] sebner, you are much more optimistic than I am ;-) [10:36] NCommander: not optimistic but realistic ;) [10:38] MOTU Council does have 5 members. [10:38] * NCommander thought it was six [10:39] SInce TB - 5 = 1 [10:39] er [10:39] TB + 5 = 8 [10:39] But there are 9 active members in the group [10:41] No, it's 5. [10:43] 3 + 5 = 8, but the team has 9 [10:43] Am I missing something? [10:47] NCommander: The team itself counts. [10:47] A subteam counts as a member in that count, [10:48] So $(MC members) + TB + $(TB members) = 9. [12:36] A package has deviated from Debian wrt an init script, which may be ok for Ubuntu. Should we just sync for now to align with Debian and fix problems after, or should I test deb package and try merge? [12:38] It's always best to preserve any change in Ubuntu unless you are 100% certain that it has no end-user effect. [12:39] I'd recommend merging. If the change is an improvement that would also be useful in Debian, it's worth checking the BTS to make sure there's already a bug filed with a patch for that improvement. [12:40] Note that some sponsors will expect you to work with the Debian maintainer to get it into Debian before accepting the merge if the fix is useful in Debian. I'm not sure how strongly that attitude will prevail while Debian is mostly frozen though. [12:40] persia: mm. in this case the package upstream went from 1.1.2 to 1.2.3 - i have a feeling that things changed with the program internally and the debian script is not that far off. but ok, i think i'll just test the .deb as is against the old bug and see if they address the same things [12:40] (note for those with an interest in new packages : fixing RC bugs in Debian is the fastest way to get new upstreams right now). [12:41] stefanlsd, Ah, if you've two separate changes to the same code, then yes, check against the bug, and if it's fixed, prefer the Debian solution to the Ubuntu solution. [12:41] persia: all of my merge packages, if its useful to debian i've been in contact with maintainers to fix and upload into unstable so we can sync. Would way rather do that then do the same silly merges every cycle :) [12:42] especially so early in the cycle [12:43] stefanlsd, Then you've learned the secrets to having a small set of changes to merge :) [12:43] hehe. does anyone have those need to merge maintained in bzr packages i could look at. I would like to start playing with those... [12:44] james_w claimed to have most packages in bzr a couple days ago. Dunno if it's somewhere accessible. If you just want to play, you might look at some of the packages that are bzr-maintained. [12:45] they are not accessible yet, and unfortunately you won't be able to merge in bzr this cycle [12:46] james_w, The former I understand. The latter confuses me. As much as bzr doesn't match my personal workflows very closely, is there some reason that one can't merge a bzr-maintained package where there is a vcs.imports branch in LP? [12:47] because there is no shared revision history yet [12:48] next cycle the aim is to be able to merge from Debian, but you won't be able to merge from upstream [12:48] that is a cycle 3 or 4 target [12:50] james_w, Hrm? If I look at a package like grub-installer, it's maintained in bzr. There's a vcs.imports branch that comes from alioth SVN. The ubuntu branch is based off the alioth branch. Why can't this merge? [12:50] well you can do that now [12:50] I'm talking about the general case [12:51] Ah, so it's about having it for every package, as opposed to the current 30-40 packages already set up? [12:51] yeah [12:51] james_w: ok, so with packages already in bzr, we can branch - manually merge, push, debuild and then debdiff like normal? [12:51] OK. Now I understand why I was confused :) [12:51] those 30-40 packages took a reasonable amount of effort each to set up [12:52] scaling that to 15000 packages hasn't worked, so we're working the other way round [12:52] Yeah. Took me a few hours to organise one of them a couple months ago. Not something I'd like to repeat. === LucidFox_ is now known as LucidFox [14:26] I'm not sure if this is the correct place but I noticed when I installed a Toshiba driver in ubuntu Ibex 64bit. I noticed that I later had postfix installed on my box and listening. [14:26] rrittenhouse: That's because lsbbase requires it and that's one of the requirements of your driver. [14:27] =x thats horrible [14:27] Well, it's at least a bug worth filing. Probably not that hard to fix : it just requires determining what LSB features the driver actually needs. [14:33] hey [14:33] * RainCT is happy as he may get a proper Internet connection soon \o/ [14:35] ScottK, persia: i'm not over-reacting but isn't it dangerous for the unsuspecting user to have postfix installed just because they need to print? =/ [14:35] RainCT, Really? Congratulations! [14:36] rrittenhouse, that's why it's worth filing a bug :) [14:36] haha, ok :) [14:36] I just wanted to make sure I wasnt over-reacting or something. [14:38] persia: yep, there's now WiMAX available in our town :) [14:38] RainCT: Nice. We all deserve a proper Internet connection :P [14:38]