[12:27] (lamont_r/#ubuntu-devel) network move.  back on in a bit.
[01:21] <nasdaq4088> is there anyone here who has written visual basic applications?
[01:23] (sladen/#ubuntu-devel) nasdaq4088: have you tried #basic ?
[01:24] <nasdaq4088> your one fucking funny guy
[01:26] (sladen/#ubuntu-devel) the correct gramma would be "you're"
[01:26] (sladen/#ubuntu-devel) r
[05:50] <lamont_p> moo
[03:58] <ogra> elmo: are you around ?
[04:03] <Keybuk> A thought for all those doing merges ... http://www.lag.net/random/leisure-c.jpg
[04:04] <lamont_r> Keybuk: aint that the truth.
[04:05] <lamont_r> in a few minutes, I'll be heading home.  Which is to say, offline for a day or 2...
[04:05] <lamont_r> time to get ready to leave.
[04:34] <lamont_r> right.  off to home.  later
[04:53] <mirak> hi 
[04:53] <mirak> I have all kde menu entries in dupes
[04:53] <mirak> how can I fix that ?
[04:53] <mirak> a full kde reinstall ?
[04:54] <mirak> even in the kde control center
[04:54] <mirak> every menu is in double
[04:58] <Riddell> mirak: it may be because ubuntu has KDE libs 3.3 but KDE base 3.2
[04:59] <mirak> ah ?
[04:59] <mirak> ah sorry wrong channel
[04:59] <mirak> I though I was in ~kde
[05:00] <mirak> #kde
[05:00] <mirak> I use ubuntu indeed, so thanks :)
[05:01] <mirak> Riddell: is there some command that rebuild the menu from de .desktop files ?
[05:01] <Riddell> mirak: kbuildsycocoa
[05:02] <mirak> thanks
[05:06] <mirak> Riddell: where is the orininal database so I could erase it ?
[05:06] <mirak> original
[05:10] (amu/#ubuntu-devel) mirak: link /usr/share/config /etc/kde3 
[05:10] <mirak> ok
[05:10] (amu/#ubuntu-devel) it will solve the problem with your double menus
[05:10] <mirak> in fact the problem was a .back folder in /usr/share/applications
[05:11] <mirak> I don't remember if it's me who crated it
[05:11] <mirak> maybe yes
[05:18] (amu/#ubuntu-devel) aaahh those "menus" ;) i thought to the window-menu's *g* 
[05:20] (amu/#ubuntu-devel) btw. someone build libs&base against xorg ?
[05:25] <wasabi> Has anybody considered using binary diffs for apt upgrades?
[05:38] (Kamion/#ubuntu-devel) wasabi: there have been a number of discussions about it but it's a very hard problem; people don't generally upgrade from one version to the next in sequence, and they may not have the old packages around
[05:38] <wasabi> Well, I'd say in Warty they most likely do.
[05:38] <wasabi> But yeah, I see your point.
[05:39] <wasabi> I'm wondering how much of a benefit it would have, for instance for openoffice.
[05:39] <wasabi> Which is a 40mb .deb
[05:41] <Keybuk> given the openoffice build process, it'd probably be a 40mb xdelta as well :-/
[05:41] <wasabi> how so?
[05:43] <Keybuk> everything slightly changes
[05:44] <Keybuk> ELF isn't great for deltaing at the best of times
[05:45] <wasabi> Well, the binaries aren't the biggest parts either
[05:45] <Keybuk> no, I was just thinking, there's a huge amount of data in that .deb as well
[05:45] <wasabi> Grr.
[05:45] <wasabi> xdelta doesn't do dir trees?
[05:45] <Keybuk> wasabi: tar, tar, xdelta
[05:46] <wasabi> hmm. yeah.
[05:46] <wasabi> So, somebody is working on deb as .tar.gz support, I heard.
[05:46] <wasabi> THat'd solve that.
[05:46] <Keybuk> "deb as .tar.gz" ?
[05:46] <wasabi> Instead of whatever format they are in now.
[05:46] <Keybuk> a deb is a .tar.gz
[05:47] <wasabi> eh? what'd I read then
[05:47] <Keybuk> somebody who'd found the crackpile, by the sounds of it :p
[05:47] <wasabi> ahh, support for bzip2
[05:48] <wasabi>  Support for bzip2-compressed .debs
[05:48] <wasabi> 
[05:48] <wasabi> ScottJamesRemnant
[05:48] <wasabi> 
[05:48] <wasabi> Code in dpkg mainline 
[05:48] <wasabi> Oops. sorry.
[05:48] <Keybuk> that would be me :)
[05:48] <wasabi> Didn't expect the lines.
[05:48] <wasabi> oh. ;)
[05:48] (Mithrandir/#ubuntu-devel) wasabi: Keybuk is Scott James Remnant. :)
[05:48] <wasabi> looky there.
[05:49] <Keybuk> could be worse, trey got as far as arguing quite heavily with me about the deb format before someone pointed out that I'm the dpkg maintainer :o)
[05:50] (Mithrandir/#ubuntu-devel) Keybuk: it's fun, isn't it? :)
[05:50] <Keybuk> not sure whether bzip2 would help openoffice or not
[05:50] <Keybuk> bzip2 generally performs better on plain text than gzip
[05:51] <Keybuk> but usually no better on binary, at a lot higher memory and CPU cost
[05:53] <wasabi> So, what is a .deb?
[05:54] <Keybuk> an ar file containing a text file and two tar files
[05:54] <Keybuk> first tar file is all the meta-data, second are the contents
[05:54] <wasabi> Hmm. Makes it hard to diff.
[05:54] <Keybuk> -rw-r--r--    1 scott    scott         40M 2004-11-20 16:51 data.tar.bz2
[05:54] <Keybuk> -rw-r--r--    1 scott    scott         42M 2004-11-20 16:52 data.tar.gz
[05:54] <Keybuk> heh
[05:55] <wasabi> And the contents tar file is gzipped?
[05:55] <Keybuk> both are gzipped
[05:55] <Keybuk> no real saving in bzipping openoffice
[05:55] <wasabi> I'm trying to find the savings by diffing it
[05:56] <Keybuk> well, if you take openoffice.org-bin_1.1.2-2ubuntu6 -> openoffice.org-bin_1.1.2dfsg1-2ubuntu2 as a release upgrade ...
[05:56] <Keybuk> -rw-rw-r--    1 scott    scott         29M 2004-11-20 16:56 test.xdelta
[05:57] <Keybuk> so it's not even half the size
[05:57] <wasabi> diffing the data.tar.gz I assume?
[05:57] <Keybuk> uncompressed data.tar
[05:58] <wasabi> I did xserver-xorg, because I happened to have two versions of it, ubuntu1 and 2
[05:58] <wasabi> Orignial's about 5.3 MB, diff is 348k
[05:58] <Keybuk> I wouldn't generally expect a huge difference if it were just an ubuntu patch change
[05:58] <Keybuk> those are usually changes to things like the admin scripts
[05:58] <wasabi> Yeah.
[05:59] <Keybuk> but in a release -> release situation, you're almost looking at one or more upstream version changes
[05:59] <Keybuk> and then the benefit vanishes
[05:59] <wasabi> Even if it's a new version, similarities like images and stuff would make a big diff imo
[05:59] <wasabi> Well, there is always an option of only doing a diff if it matters.
[06:00] <Keybuk> there's more benefit for splitting those into a separate source package
[06:00] <wasabi> For a dialup user, 5MB to 380k is a major diff
[06:00] <Keybuk> sure, but dialup users probably won't be following the development cycle anyway
[06:00] <wasabi> Sure.
[06:00] <Keybuk> and if they are, they won't be following fast enough to get every releas
[06:00] <wasabi> haha
[06:00] <Keybuk> so it becomes impossible to have a set of deltas that they'll hit
[06:02] <wasabi> I'd be curious to actually stick a diff generator in katie or some such on a real archive and see what actually happens.
[06:02] <Keybuk> what do you diff from/to ?
[06:02] <wasabi> last version to current version.
[06:02] <Keybuk> it's very rare that anybody will get every single version
[06:03] <Keybuk> they're more likely to skip one or more
[06:03] <wasabi> So they have 3 patches.
[06:03] <wasabi> if size of 3 patches < size of orignal package, delete patches.
[06:03] <wasabi> err, >
[06:04] <Keybuk> this also still assumes they have the original .deb on the drive, of course
[06:04] <wasabi> Yes, it does.
[06:05] <Keybuk> which isn't unreasonable, as APT does tend to keep them around until they're out-dated
[06:05] <wasabi> I see a little check in apt: if current version on drive, search for patch from current version.
[06:05] <wasabi> repeat until there are no more patches.
[06:06] <wasabi> beyond that it's up to the archive scripts to determine if a patch is appropiate or not, and if not, it doesn't make one.
[06:07] <Keybuk> if you've got some time, it'd certainly be interesting to see it implemented
[06:08] <Keybuk> I don't know whether the cost of generating the deltas would be huge or not
[06:08] <wasabi> Here's a good example.
[06:08] <wasabi> Evolution 2.0 to evo 2.1 in hoary
[06:08] <wasabi> patch is 3.8M
[06:08] <wasabi> i dont know if that's worth it. =/
[06:08] <wasabi> it is < 1/2
[06:08] <Keybuk> how big is the evolution binary?
[06:09] <wasabi> 9.2M
[06:09] <Keybuk> there's also a worry about doubling the amount of mirror space the archive takes
[06:09] <wasabi> yeah.
[06:09] <Keybuk> if we're talking about Debian, which would benefit hugely from patching
[06:09] <wasabi> Well, im talking only about Ubuntu at this point. ;)
[06:10] <Keybuk> basically taking a 120GB archive and turning it into a 240GB archive :p
[06:10] <wasabi> Laying out the file names in the archive would be interesting too
[06:10] <wasabi> Not sure how to go about that.
[06:10] <Keybuk> how do you mean?
[06:10] <wasabi>  /pool/b/blah/blah_oldversion.diff?
[06:11] <wasabi> Or add it to the Package file somehow?
[06:11] <Keybuk> pool/$component/$s/$source/$source_$version_$arch.debdelta
[06:11] <Keybuk> you'd need a version index for each package, to make sure you could *get* all of the deltas
[06:11] <wasabi> there's nothing saying what version that patch patches too.
[06:11] <wasabi> Which doesn't matter.
[06:12] <wasabi> But, it is a bit annoying
[06:12] <Keybuk> otherwise you could miss an important one, because a mirror ran out of disk, or hadn't sync'd it yet
[06:13] <Keybuk> sorry, that second $source should be $binary obviously, duh :p
[06:13] <wasabi> Hmm. Apt takes the file in the archive. Takes the version on it.
[06:13] <wasabi> Say it's 1.0.0
[06:13] <wasabi> Finds 1.0.0_i386.debdelta
[06:13] <wasabi> which always upgrades to the "next" version.
[06:13] <wasabi> Don't know what the next version is.
[06:13] <wasabi> Perhaps .debdelta itself becomes an ar, with a control file.
[06:14] <Keybuk> I'd do it the other way around, the version indicates the version you get -- because that's what you expect from FTP sites that supply patches
[06:14] <wasabi> Yeah, but then you'd need to do version calcs to find the next version from the current.
[06:14] <wasabi> Or you'd need to ls the directory.
[06:14] <Keybuk> can't ls an http directory
[06:14] <wasabi> exactly.
[06:14] <daniels> .listing :P
[06:14] <Keybuk> you could do a GNU-style
[06:15] <Keybuk> File: libtool-1.5.8-1.5.10.diff.gz  	89 KB  	19/09/04  	14:00:00
[06:15] <Keybuk> File: libtool-1.5.8-1.5.10.diff.gz.sig 	1 KB 	19/09/04 	14:00:00
[06:15] <Keybuk> File: libtool-1.5.8-1.5.10.xdelta 	24 KB 	19/09/04 	13:59:00
[06:15] <Keybuk> File: libtool-1.5.8-1.5.10.xdelta.sig 	1 KB 	19/09/04 	13:59:00
[06:15] <Keybuk> File: libtool-1.5.8.tar.gz 	2620 KB 	07/08/04 	13:57:00
[06:15] <Keybuk> File: libtool-1.5.8.tar.gz.sig 	1 KB 	07/08/04 	13:57:00
[06:15] <wasabi> There is nothing recording the progression from version 1.0.0 to 1.0.1 to 1.1.0
[06:15] <Keybuk> File: 
[06:15] <wasabi> old-new?
[06:15] <Keybuk> $binary_$old_$new_$arch.debdelta
[06:15] <wasabi> So which file do you grab?
[06:15] <wasabi> You don't know waht the new is.
[06:16] <Keybuk> though you'd still need to unpack the debdelta to make sure it wasn't lying about it's filenames (neither dpkg nor apt trust them, currently)
[06:16] <Keybuk> so again, you're back to putting the information in the Packages file
[06:16] <Keybuk> then the Packages churn bites
[06:16] <wasabi> User currently has lintool_1.5.8
[06:16] <wasabi> lib
[06:16] <wasabi> It is upgrading to 1.5.10 ultimatly
[06:16] <wasabi> there is also a 1.5.9 patch
[06:17] <Keybuk> in fact, you'd need the Packages file information *anyway* to make sure you were getting a delta that applies to your branch
[06:17] <Keybuk> otherwise you could accidentally pick up a delta specific to testing or experimental
[06:17] <wasabi> yeah.
[06:18] <wasabi> doesn't solve my dilema though
[06:18] <Keybuk> so it now takes you
[06:18] <Keybuk> a) three times as long to download the Packages file
[06:18] <Keybuk> b) maybe half the time to download the packages themselves
[06:18] <Keybuk> c) a small eon to apply all the deltas to put together the new .deb and install it
[06:18] <wasabi> 3 times as long?
[06:18] <wasabi> Maybe...
[06:19] <wasabi> won't argue with c.
[06:19] <Keybuk> wasabi: assuming 3-4 deltas per binary, with md5sum, size, previous and next version info -- roughly triples the size of the Packages file
[06:19] <wasabi> =)
[06:20] <wasabi> Hmm. I wouldn't say triple!
[06:20] <wasabi> Just 2 additional lines to each Package: stanze
[06:20] <wasabi> ?
[06:20] <Keybuk> Deltas:
[06:20] <Keybuk>   md5sum size previous next filename
[06:20] <Keybuk>   md5sum size previous next filename
[06:20] <Keybuk>   md5sum size previous next filename
[06:20] <Keybuk> etc.
[06:20] <Keybuk> assuming you keep the similar format to the Files: line
[06:20] <wasabi> Delta-Next: md5sum size filename?
[06:21] <wasabi> Actually...
[06:21] <wasabi> You're format is more righter. ;)
[06:21] <wasabi> Deltas:\  md5sum size fromversion filename
[06:21] <Keybuk> you can only have one entry per binary, and one occurance of each field
[06:21] <wasabi> I might say that instead.
[06:22] <wasabi> And apt grabs the target version and finds a path to it's current version through the fromversions.
[06:22] <Keybuk> yeah, you could work out if it were possible at Packages time, and download the appropriate things then
[06:22] <wasabi> That opens up some interseting optimization ideas that nobdoyw ould probably use.
[06:23] <wasabi> Have multiple patches to get you from various versions to the current.
[06:23] <wasabi> Progressive or not.
[06:23] <wasabi> Or not. You could have one delta from warty to hoary
[06:23] <wasabi> and another between h oary versions, for large packages only.
[06:24] <Keybuk> indeed, it allows for big-jump upgrade deltas if they're smaller
[06:29] <Keybuk> it'd be interesting to find out where it becomes cheaper to just download the new deb than to patch up the old one
[06:30] <wasabi> I've never popped open the apt source code.
[06:30] <wasabi> It C?
[06:30] <Keybuk> C++
[06:30] <gicmo_> I think C++
[06:30] <gicmo_> ahh damn I am slow
[06:30] <wasabi> Oh, so it
[06:30] <wasabi> s probably all OO
[06:31] <Keybuk> it's a harder problem than the "is it faster to download uncompressed than compressed and decompress it" because you've actually got to decompress the original deb, then download and decompress each delta, then apply them
[06:31] <Keybuk> I guess you should recompress it again, so you can use it next time without throwing it away
[06:31] <wasabi> Yeah.
[06:32] <wasabi> You would just be acquiring the cache/apt/archives files differently.
[06:32] <wasabi> And the same methodology to clear that folder would be in effect.
[06:32] <wasabi> Whatever it is.
[06:32] <Keybuk> I'd finger-in-the-air that there's a cut off point around half the download time of the original deb
[06:33] <wasabi> I'd say if you're on dialup, any time saved is a blessing.
[06:33] <daniels> i'd agree with wasabi
[06:33] <wasabi> But, it would just have to be balanced based on archive size
[06:33] <Keybuk> sure, but you don't want to shoot the people who can pull 100Mbps from the archive :p
[06:33] <Keybuk> instead of a 2s download, they get 2m of patching
[06:33] <wasabi> Oh sure.
[06:34] <wasabi> THere would be options.
[06:34] <wasabi> I don't know how those options would be determined automatically.
[06:34] <wasabi> but there would be options. ;)
[06:35] <Keybuk> remember how long it took to download the Packages file, and its size to determine archive speed -- then use the delta sizes and deb sizes in the Packages file to calculate whether there's a benefit in getting the deltas instead
[06:36] <wasabi> Yeah. THe sizes are listed. Take all the possible paths, find the shortest one by size.
[06:36] <wasabi> where direct upgrades are a possible path
[06:36] <wasabi> I wonder what the average patching time is
[06:37] <Keybuk> APT's C++ is pretty readable
[06:37] <Keybuk> it's more of a "struct and some functions that use it" kind of OO
[06:37] <wasabi> Oh actually.
[06:37] <wasabi> Oh.
[06:37] <wasabi> My evolution measurement was way off.
[06:37] <Keybuk> rather than a Java/Smalltalk nut's crack
[06:38] <wasabi> It's 28M to 3M
[06:38] <wasabi> That's massive.
[06:38] <wasabi> Ahh. I see. 28M is the data.tar, 9MB is the data.tar.gz.
[06:39] <wasabi> the patch is 3.8M, so it isn't that good.
[06:39] <wasabi> Are the entries in the data.tar sorted?
[06:40] <Keybuk> executables are a bitch to delta, because the compiler will insist on moving damned functions around in memory :p
[06:40] <Keybuk> wasabi: not generally
[06:40] <wasabi> That might help massively
[06:40] <Keybuk> I think xdelta copes with that though
[06:40] <Keybuk> it's designed to diff tar files, after all
[06:42] <Keybuk>   if (!(c1= m_fork())) {
[06:42] <Keybuk>     m_dup2(p1[0] ,0); close(p1[0] ); close(p1[1] );
[06:42] <Keybuk>     m_dup2(p2[1] ,1); close(p2[0] ); close(p2[1] );
[06:42] <Keybuk>     if (chdir(directory)) ohshite(_("failed to chdir to `%.255s'"),directory);
[06:42] <Keybuk>     execlp(TAR,"tar","-cf", "-", "-T", "-", "--null", "--no-recursion", (char*)0);
[06:42] <Keybuk>     ohshite(_("failed to exec tar -cf"));
[06:42] <Keybuk>   }
[06:43] <daniels> heh, ohsite()
[06:43] <daniels> er, ohshite()
[06:43] <Keybuk>     execlp(FIND,"find",".","-path","./" BUILDCONTROLDIR,"-prune","-o","-print0",
[06:43] <Keybuk> and that to give the file list
[06:43] <Keybuk> so there's no sorting, other than it moves symlinks to the end for shits and giggles
[06:45] <Keybuk> daniels: ohshit() is an exception, ohshite() is an exception which errno is useful for :p
[06:45] <daniels> heh :)
[06:45] <wasabi> This could also be made efficient... threaded.
[06:45] <eruin> I like your style ;)
[06:45] <wasabi> Say you have 4 patches to reach a new version.
[06:46] <Keybuk> heh, that's iwj-C, not mine!
[06:46] <wasabi> IT could be applying the first while it downloads the 2nd
[06:47] <Keybuk> daniels: ya know, I've never noticed before, but that's doing a longjmp inside a child process
[06:47] <Keybuk> so it's the child that bungees into error handling, instead of the parent
[06:47] <Keybuk> CRACK!
[06:48] (Mithrandir/#ubuntu-devel) Keybuk: it's dpkg, what do you expect?
[06:48] <Keybuk> and I'm only noticing, because I've hit the same bug in Python -- where you end up handling the exception in the child which carries on its merry way while the parent is waiting for it to finish
[06:48] <daniels> Keybuk: heh!  that's part of dpkg, is it?
[06:48] <daniels> http://www.freedesktop.org/~pasc/maillist.html
[06:48] <daniels> erk, ww
[06:48] <Keybuk> this explains at least three open bugs on dpkg :p
[06:50] (pasc/#ubuntu-devel) but since daniel posted it here... if someone have some comments on how the indices look on that page, I'd be interested to know ;-)
[06:50] (pasc/#ubuntu-devel) to know what people think that is. I still haven't modified the actual message views, but that will come later
[06:54] <wasabi> Noooooooooooooo
[06:54] <wasabi> I just typed up all the stuff we talked about in the wiki
[06:54] <wasabi> hit submit, and it didn't work. =( and Epiphany lost it
[06:58] <Keybuk> d'oh
[06:59] <wasabi> and then the wiki went *beep beep beep* and my page was gone. +9
[07:04] <eruin> why oh why does openoffice.org supply a so-called "installer" archive that just contains rpms
[07:11] <Kyaneos> hi
[07:33] <wasabi> Keybuk, https://www.ubuntulinux.org/wiki/APTPackageDeltas   I have no experience hacking in dpkg or apt, so im looking around now. Maybe i'll come up with something.
[07:41] <Keybuk> wasabi: has some major vanishing-off-the-right-hand-side issues
[07:41] <wasabi> plain text.
[07:41] <wasabi> i dont' know any of the listed wiki languages.
[07:42] <Keybuk> some newlines at 70-column would be great :p
[07:42] <wasabi> I'd just assume figure out MoinMoin or something.
[07:42] <Keybuk> there's no scrollbar, it just cuts
[07:42] <wasabi> i have scrollbar
[07:42] <Keybuk> hmm, I just have a vertical one
[07:43] <wasabi> scroll down?
[07:43] <Keybuk> oh
[07:43] <wasabi> hehe.
[07:43] <Keybuk> there's a scroll page in the *page*
[07:43] <Keybuk> gee, that's useful
[07:43] <wasabi> yeah.
[07:43] <Keybuk> so I scroll down, scroll right, then scroll up to find I've scrolled to far
[07:43] <Keybuk> I swear
[07:43] <Keybuk> if I ever meet the designer of this new wiki, there will be words
[07:43] <Keybuk> and then there will be death
[07:43] <wasabi> it's pretty slow too.
[07:44] <Keybuk> it's a total chocolate teapot
[07:44] <Keybuk> it might fit with everything else in the chocolate store
[07:44] <Keybuk> but you can't make tea in it.
[07:44] <wasabi> haha
[07:44] <ogra> Keybuk: who is responsible for the old wiki still being online ?
[07:44] <Keybuk> ogra: no idea, someone who I shall be friends with, I suspect.  is it?
[07:45] <ogra> there is no pointer to the new one.....
[07:45] <daniels> i swear, twiki is better than zwiki
[07:45] <Keybuk> I like moin
[07:45] <Keybuk> you can *gasp* use it
[07:45] <Keybuk> so, I can either make my font size too small to read
[07:46] <daniels> Keybuk: font size> in bugzilla?
[07:46] <Keybuk> or I can select and drag right slowly until it scrolls how far I want
[07:46] <daniels> oh, right
[07:47] <Keybuk> wasabi: hmm, your text seems to only allow for single deltas
[07:47] <Keybuk> "from this source version to the new version"
[07:48] <wasabi> yeah.
[07:48] <wasabi> you can have multiple lines listed.
[07:48] <Keybuk> so there's no way to download three or four consecutive deltas and put them together ?
[07:48] <wasabi> Just didn't make a note of it
[07:48] <wasabi> Oh, sure, you just have to trace through all the Packages entries
[07:48] <Keybuk> our archive churn is really too fast to expect people to only be taking one version jump
[07:48] <wasabi> okay, I can get 1.0.1 to 1.0.2
[07:48] <Keybuk> there's only one Packages entry for a given Package
[07:48] <wasabi> how how can I get 1.0.1 from 1.0.0
[07:48] <wasabi> oh?
[07:48] <wasabi> is there?
[07:49] <Keybuk> because there's only one version of that Package in the archive
[07:49] <wasabi> I thought there were multiple with different versions
[07:49] <Keybuk> :-o no!  what would be the point?  APT would just pick the latest one
[07:49] <wasabi> Well... ;)
[07:49] <wasabi> Just FYI!
[07:49] <Keybuk> there can be different versions in different Packages files
[07:49] <wasabi> Hmm./
[07:49] <wasabi> That's unfortunate. THe way I imagined it would be pretty slick
[07:49] <Keybuk> but you certainly can't have more than one in the same file ... it breaks an assumption
[07:50] <Keybuk> you'd need to keep the .debs around as well
[07:50] <Keybuk> and then your archive gets biiig and faaat
[07:50] <wasabi> yeah, old .deb's are kept around.
[07:50] <wasabi> To an extent.
[07:50] <Keybuk> and people who mirror you say "fuck dial-up"
[07:50] <wasabi> I have two versions of xorg for instance.
[07:51] <wasabi> Well. Then I just add two versions into the Delta's section
[07:51] <wasabi> no biggy, just not as cool as I thought it was. ;)
[07:51] <Keybuk> and then you work out it's cheaper to send dial-up users free CDs than expect them to download an update
[07:51] <Keybuk> because the hardware and bandwidth upgrade to support all that extra weight costs more than shipping half a million CDs
[07:53] <wasabi> Probably makes the code easier anyways.
[07:53] <Keybuk> wasabi: also don't use ".debdiff", there's already a tool called that
[07:53] <Keybuk> .debpatch or .debdelta is fine though
[07:53] <wasabi> oh. That was your example. ;)
[07:53] <Keybuk> no, I used .debdelta :p
[07:54] <wasabi> damn. foiled again.
[07:54] <Keybuk> mention the patches are against the uncompressed control.tar.gz and data.tar{,.gz,.bz2,.Z,*}
[07:54] <wasabi> Oh here's another question.
[07:55] <wasabi> the data.tar.gz, is there a standard compression level?
[07:55] <Keybuk> -z9 by default
[07:55] <wasabi> Can that be altered by the packager?
[07:55] <Keybuk> if they like
[07:55] <wasabi> If so, it makes generating exact copies hard.
[07:55] <Keybuk> deb-deb -z3
[07:55] <wasabi> Since the repackaging has to know what it should be.
[07:55] <wasabi> Or the checksums don't match
[07:56] <Keybuk> yeah, you're going to need some "DON'T LOOK AT THAT CHECKSUM" fiddling anyway :p
[07:56] <wasabi> Hmm. Was hoping there was some way around that. ;)
[07:56] <Keybuk> well, gzip is theoretically deterministic
[07:56] <Keybuk> so if you put the .deb back together it should match the md5sum of the deb you would've downloaded anyway
[07:57] <wasabi> Except `ar' stores dates.
[07:57] <Keybuk> but, as you say, you'd need to take into account the -z and -Z flags used when putting together the .deb
[07:57] <wasabi> or does it. i dunno.
[07:58] <Keybuk> yeah it does
[07:58] <wasabi> well the entire thing falls apart then.
[07:58] <wasabi> unless i ignore checksums, which I really dont want to do
[07:59] <wasabi> Eh, actually. If the checksums of the .debdeltas are stored in the Packages file, it's not a security issue.
[07:59] <Keybuk> hmm, why not?
[08:00] <wasabi> Well, my concern was that if a bad .deb is generated from this process, then you'd have to skip checksums... and by skipping checksums there would be a way for a evil archive to sneak something in.
[08:00] <wasabi> But if the Packages file hsa the sums of hte .debdeltas, then there's no way to sneak anything in.
[08:00] <Keybuk> yeah ther eis
[08:00] <wasabi> ?
[08:01] <Keybuk> you craft a Packages and set of xdeltas to attack a known version of a .deb
[08:01] <Keybuk> but the checksum would still match, I guess *shrug*
[08:01] <wasabi> Packages.gpg?
[08:02] <Keybuk> I'm not sure whether APT re-checks the checksums of things in its cache before installing or not
[08:02] <wasabi> Somebody (maybe you!) is working on signing apt I think.
[08:02] <Keybuk> that was Progeny
[08:02] <wasabi> s/apt/Packages/
[08:03] <Keybuk> mdz maintains Debian's APT, and has a branch that includes that stuff
[08:03] <wasabi> Well, it's no more a vuln than it is currently.
[08:03] <wasabi> https://www.ubuntulinux.org/wiki/APTAuthentication
[08:03] <Keybuk> you could compromise someone's machine, replacing something in /var/cache/apt/archives with something malicious
[08:03] <wasabi> You could do that now.
[08:04] <wasabi> If you've done that, you mine as well just hack the machine while you were in it.
[08:04] <Keybuk> I don't think you can with Secure-APT
[08:04] <Keybuk> it verifies the Packages file and the Packages when it installs them
[08:04] <Keybuk> not just when it downloads them
[08:04] <Keybuk> (I think)
[08:04] <wasabi> I think the secure apt idea is just to verify downloads.
[08:04] <wasabi> I think it's just a matter of signing Packages.gz
[08:04] <Keybuk> largely, yeah
[08:04] <wasabi> /var/cache/apt is root owned. If somebody is in that, they have owned the system already.
[08:07] <wasabi> I think ignoring checksums of assembled .deb's is pretty decent.
[08:07] <wasabi> No longer worried about it
[08:08] <wasabi> So I guess some of this has to be in Dpkg, and some of it in Apt.
[08:08] <wasabi> Dpkg needs all the proper stuff to take a .deb and a .debdelta and produce a new .deb
[08:08] <wasabi> ANd apt needs to handle the resolution of all that and pass it to dpkg.
[08:14] <RubenV> Hi, i'm trying to build a .deb
[08:14] <RubenV> however, when issuing dpkg-buildpackage -rfakeroot
[08:14] <RubenV> i get a permission denied error
[08:14] <RubenV>  fakeroot debian/rules clean
[08:14] <RubenV> /usr/bin/fakeroot: line 150: debian/rules: Permission denied
[08:15] <daniels> chmod +x debian/rules
[08:15] <daniels> either that, or use debuild
[08:15] <RubenV> oh, forgot
[08:15] <RubenV> :/
[08:15] <RubenV> let's see if this get's me further
[08:18] <Keybuk> wasabi: I'd just make it a companion tool, rather than changing dpkg
[08:18] <Keybuk> dpkg-delta and dpkg-patch for example
[08:21] <Keybuk> anyway, I'm going to go and satisfy my mass-entertainment needs by watching Simon Cowell be hilariously mean to people
[08:21] <wasabi> enjoy.
[08:21] <RubenV> doesn't dpkg-buildpackage call autoconf automatically?
[08:21] <Keybuk> RubenV: no.
[08:21] <wasabi> no.
[08:21] <RubenV> (never done this before)
[08:21] <robtaylor_> mjg59: alive?#
[08:21] <Keybuk> not unless the package's debian/rules calls autoconf
[08:21] <Keybuk> which is a silly thing to do anyway
[08:21] <wasabi> dpkg-buildpackage does nothing except try to reach the proper targets in debian/rules.
[08:22] <Keybuk> if you ever need to run autoconf on source you downloaded (rather than got from CVS) you need to hurt someone
[08:22] <RubenV> it's a cvs checkout
[08:22] <RubenV> autoconf gives me horrible errors though
[08:22] <Keybuk> autoreconf -i
[08:25] <RubenV> something is horribly wrong with this source tree :)
[08:48] <wasabi> hmm. this leaves off the possibility of using patches to rename packages. ;)
[09:07] <wasabi> So I wrote a script to generate a .debdelta from two .debs
[09:07] <wasabi> Even small packages are getting significant savings.
[09:09] <RubenV> wasabi: i was thinking about the same thing a couple of days ago
[09:09] <RubenV> while I was slurping OO.o over a slow line
[09:09] <wasabi> https://www.ubuntulinux.org/wiki/APTPackageDeltas
[09:09] <wasabi> think about it there.
[09:09] <RubenV> there should be a way to delta pkgs :)
[09:09] <wasabi> yeah. working on that.
[09:09] <RubenV> great idea
[09:10] <RubenV> Also a Packages.bz2 delta could be usefull
[09:10] <RubenV> one/day or so
[09:10] <wasabi> that would be hard to keep track of
[09:11] <wasabi> since Packages does not have any sort of version indicator.
[09:11] <RubenV> true
[09:32] (haggai/#ubuntu-devel) eruin: were you looking for binaries of openoffice 1.9.x ?
[09:44] (smurfix/#ubuntu-devel) wasabi: you could use the md5sum of the Packages file as the "version number".
[10:01] <phlax> hi there - trying to use ldap auth - when I add ldap to nssswitch i can no longer get rootly powers - anyone got any ideas?
[10:18] <mxpxpod> chrisa: ping
[10:37] <ggi> Is the association of every sort of text file with OpenOffice.org intentional?
[10:47] <Keybuk> wasabi: you can't technically rename a package anyway, so that's not exactly a problem :p
[10:47] <wasabi> yeah.
[10:47] <wasabi> I've got two scripts writte
[10:48] <wasabi> dpkg-gendelta, and dpkg-delta
[10:48] <wasabi> one creates a delta given two packages, the other takes an original package and a .debdelta and produces the new package.
[10:48] <wasabi> Both work.
[10:48] <wasabi> just bash scripts though. :0
[10:49] <Keybuk> heh, all the best things are :p
[10:50] <wasabi> SO in theory it works.
[10:50] <wasabi> THe dpkg part at least. ;)
[10:51] <wasabi> And it produces a valid .deb that installs. Yay.
[10:52] <wasabi> epiphany goes from 2.8MB to 774k.
[10:52] <wasabi> that's a pretty big savings.
[10:53] <wasabi> woh.
[10:53] <wasabi> mozilla-firefox goes from 9.0M to 216k
[10:53] <wasabi> just this one little -4 ubuntu change
[10:54] <sivang> wasabi : have you used python to do this?
[10:54] <wasabi> bash
[10:55] <sivang> wasabi : ah nice, could you send me the scripts?
[10:56] <wasabi> dcc?
[10:57] <sivang> wasabi : darn, my firewall probably blocking this..strange, I added the IRC helper module to netfilter..
[10:57] <wasabi> actually i probably can't sand that.
[10:57] <wasabi> heh forgot where i was
[10:57] <sivang> wasabi : mail would be also fine :)
[10:57] <wasabi> addy?
[10:58] <sivang> wasabi : sivanSpamfreeaTworkaround.org 
[10:59] <wasabi> sent.
[10:59] <sivang> wasabi : thanks. so you basically compute the difference and download only the remaining parts?
[11:00] <wasabi> oh no.
[11:00] <wasabi> these are just two examples.
[11:00] <mxpxpod> is there a guide out there on how to make a ubuntu kernel image?
[11:00] <wasabi> of how feasibly it would be to do.
[11:00] <wasabi> feasible.
[11:00] <wasabi> it is not in any way shape or form functional.
[11:00] <wasabi> heck I just did it in 20 minutes.
[11:01] <sivang> wasabi : k, thanks anyways.
[11:01] <mxpxpod> because I'd like to make a 2.6.9 image with benh's sleep patch applied, plus the wlan-ng patches from ubuntu
[11:02] <wasabi> This has me thinking weither a new extension should be used or not... maybe these "patches" could just be ".debs" that require the previous version to be installed.
[11:02] <wasabi> s/installed/available/
[11:03] <wasabi> heck, or just installed. And just distribute changed files.
[11:03] <eruin> haggai, ooh, yes
[11:03] <eruin> haggai, sorry for the slow reply on ooo 1.9 debs ;)
[11:05] <wasabi> Keybuk, new thought process. What if these "patches" were .deb files. Exactly like normal .deb files. The difference being that the data.tar.gz only contains changed files, and they contain a control field that says they are an update to another package.
[11:05] <wasabi> No delta's required.
[11:05] <wasabi> Internal dpkg mods...
[11:05] <wasabi> to extract the new files in / and then run the scripts on control.tar.gz
[11:21] <Keybuk> SUN-like you mean?
[11:21] <wasabi> ?
[11:22] <Keybuk> SUN patches are distributed as package files that just contain the replacement files
[11:22] <wasabi> I'm spelunking in dpkg code now figuring out how to do that. It really sounds easy.
[11:22] <Keybuk> or, in some cases, just the deltas with a class to apply them rather than copy over the top
[11:22] <Keybuk> two problems
[11:22] <wasabi> deletions.
[11:22] <Keybuk> yup
[11:22] <wasabi> (file in control listing them)
[11:23] <Keybuk> basically it'd be a package that only had changed files, with a magic control field to tell dpkg not to delete anything not in the new package
[11:23] <wasabi> what's hte other one?
[11:24] <Keybuk> moves
[11:24] <wasabi> I'll have to think thorugh how hte info files will be altered.
[11:24] <wasabi> moves are fine.
[11:24] <wasabi> doesn't matter. just gets redownloaded.
[11:24] <Keybuk> you can pretty much just stick an 'if (! a_patch_package)' round a large block of process_archive
[11:24] <wasabi> yeah.
[11:25] <wasabi> That's what im thinking.
[11:25] <wasabi> THere will have to be a few mods into the management of the db.
[11:25] <wasabi> In order to alter the info file, by adding the new additions to it
[11:25] <Keybuk> it does that anyway
[11:25] <Keybuk> if you look at process_archive, it adds the new files first
[11:25] <Keybuk> and then goes through the list to see whether it needs to delete anything
[11:26] <wasabi> Ahh.
[11:26] <wasabi> How does it tell if it needs to delete anything? If it doesn't exist in the archive?
[11:26] <Keybuk> yeah :)  just sets a flag on the file list entry as it unpacks the file
[11:26] <wasabi> We only want it deleting stuff that exists in a composite of hte old and new archives.
[11:26] <Keybuk> then iterates the file list to see if there are any entries without flags
[11:26] <wasabi> does not exist that is
[11:27] <wasabi> Will have a different naming convention on the .deb though.
[11:27] <wasabi> old_new
[11:27] <wasabi> or, maybe something else
[11:27] <Keybuk> processarc.c  line 586-662 (roughly)
[11:29] <wasabi> Okay, so that can stay as it is, but the list it operates on can be altered
[11:29] <Keybuk> the list it operates on is just the old file list
[11:29] <Keybuk> you just need some way of copying stuff from the old file list to the new one before that
[11:30] <wasabi> Hmm. So what the unlink?
[11:30] <Keybuk> you'd need to cope with an empty data.tar.gz too
[11:30] <Keybuk> sometimes uploads are just control-file changes
[11:31] <wasabi> well, that should handle itself.
[11:31] <Keybuk> would be nice if you could build one of those without trying too :p
[11:31] <Keybuk> wasabi: ever tried to make an empty tar.gz ? :p
[11:31] <mxpxpod> is there a kernel team for ubuntu?
[11:31] <wasabi> it would simply be like an upgrade that installed nothing.
[11:31] <wasabi> Oh. Heh.
[11:31] <wasabi> Suspose you can't do that?
[11:31] <Keybuk> descent scott% tar czf foo.tar.gz
[11:31] <Keybuk> tar: Cowardly refusing to create an empty archive
[11:31] <wasabi> Could have something like a first ignored file in it all the time
[11:32] <wasabi> .DEBIAN or something.
[11:32] <Keybuk> just stick ./ in it
[11:32] <wasabi> ahh you can do that?
[11:32] <wasabi> heh.
[11:32] <wasabi> That's silly in a way.
[11:32] <Keybuk> descent scott% tar --no-recursion -czf foo.tar.gz ./
[11:32] <Keybuk> descent scott% tar tzf foo.tar.gz
[11:32] <Keybuk> ./
[11:32] <wasabi> how big is it?
[11:32] <Keybuk> 111 bytes
[11:32] <wasabi> workable, silly, but workable.
[11:33] <wasabi> So this seems pretty easy actually.
[11:33] <wasabi> Just a few ifs really.
[11:34] <wasabi> All the hard stuff is really up to apt.
[11:34] <Keybuk> yeah, it's some neuro-surgery on dpkg to make it understand that it doesn't need to remove the old files
[11:34] <Keybuk> you'd need the patch-deb filenames to be pretty obvious, to make sure people don't download them by accident unless they want them
[11:35] <sivang> wasabi : wow, you're gonna make it not delete the old file, and just add them the binary delta?
[11:35] <wasabi> no real need for delta at all
[11:35] <wasabi> that I see anyways.
[11:36] <wasabi> Interesting.
[11:36] <wasabi> If you have a 1.0.0 to 1.0.5 .deb patch.
[11:36] <sivang> wasabi : ah, just pull out the changed dependencies?
[11:36] <wasabi> You can upgrade 1.0.1 to 1.0.5 using the same file.
[11:36] <wasabi> So, the archive scripts can really optimize good upgrade paths.
[11:37] <Keybuk> wasabi: only if the same files were changed in each version between that
[11:37] <wasabi> Keybuk, a 1.0.0 to 1.0.5 patch would contain all the mods between 1.0.0 and 1.0.5
[11:37] <Keybuk> oh, sorry
[11:37] <Keybuk> yeah, that'd work
[11:37] <wasabi> If 1.0.0 to 1.0.5 cover 20 versions, but ends up being like one file changed 20 times, it'd be one very small patch.
[11:37] <wasabi> the archive scripts could do some optimization on that.
[11:38] <Keybuk> this wouldn't work too well for mostly-binary packages though
[11:38] <Keybuk> the resulting debs would be the same as the non-patch debs
[11:38] <wasabi> THe deltas don't work well for those either though.
[11:38] <Keybuk> true
[11:38] <wasabi> And in that case, the archive scripts can just not make them.
[11:38] <wasabi> If there is no savings.
[11:39] <Keybuk> it's a pity that every upload is a rebuild
[11:39] <Keybuk> which means every upload there is a slight change to every binary :-/
[11:39] <wasabi> Well, that can, and probably should, be solved in other ways.
[11:40] <wasabi> Why would gcc turn the same thing into a different thing two times?
[11:40] <Keybuk> because it's non-deterministic
[11:40] <wasabi> i fail to see how a compiler can be non-deterministic unless it has a random number generator in it. :0
[11:40] <mxpxpod> mjg59: ping
[11:40] <Keybuk> memory offsets and whatnot
[11:40] <wasabi> or encodes times into it
[11:42] <wasabi> wasabi@kyoto:~ $ gcc test.c
[11:42] <wasabi> wasabi@kyoto:~ $ md5sum a.out
[11:42] <wasabi> 7e7fb7d522a047d438aa60b4a4918553  a.out
[11:42] <wasabi> wasabi@kyoto:~ $ rm a.out
[11:42] <wasabi> wasabi@kyoto:~ $ gcc test.c
[11:42] <wasabi> wasabi@kyoto:~ $ md5sum a.out
[11:42] <wasabi> 7e7fb7d522a047d438aa60b4a4918553  a.out
[11:42] <wasabi> ???
[11:42] <Keybuk> do it on a different machine ?
[11:42] <wasabi> true.
[11:43] <Keybuk> descent scott% md5sum main-only
[11:43] <Keybuk> 11d9ad98f23a24f04f3365e280b3aa63  main-only
[11:43] <Keybuk> syndicate scott% md5sum main-only
[11:43] <Keybuk> 79e1a52f4e49295c11bcd29680b4661b  main-only
[11:43] <wasabi> ahh well.
[11:45] <Keybuk> and that's the simplest example there is :p
[11:46] <wasabi> not a super big deal. I supose down the road some optimization can be made there, to do some sorta more complicated diff on binaries to see if they really are different.
[11:46] <wasabi> but that's probably not a good idea.
[11:46] <wasabi> would screw md5sum's in the packages all to hell
[11:46] <Keybuk> heh, you wanna write it? ;)
[11:46] <Keybuk> but then I guess binaries are rarely the *major* component of any package
[11:46] <wasabi> I'm gonna try to understand this dpkg code and see what I can do.
[11:48] <wasabi> Hmm.
[11:49] <wasabi> control/md5sums in the new package lists every file.
[11:49] <wasabi> and it would in the upgrade package too
[11:50] <wasabi> Yeah, it's just a few k.
[11:51] <wasabi> Another optimization would be to include file deltas in the new data.tar.gz... instead of including /usr/share/blah/whatever.svg, it would include /usr/share/blah/whatever.svg.patch, and make a not in one of hte control files that this is a patch to that file.
[11:51] <wasabi> That can also be done later without any trouble.
[11:55] <Keybuk> control/md5sums isn't mandatory
[11:55] <Keybuk> dpkg itself doesn't have one, for example
[11:56] <wasabi> Well, if a openoffice upgrade is distributed with 1 file moded, all billion files would be listed.
[11:56] <Keybuk> yah
[11:56] <wasabi> which I think is okay
[11:56] <wasabi> gzipped it's nothing.
[11:56] <Keybuk> tricky, because dpkg doesn't touch md5sums at all
[11:56] <wasabi> yeah, but it has to be present. I dont think any diffs or antyhing are going to be done on control.tar.gz
[11:56] <Keybuk> doesn't have to be present
[11:56] <Keybuk> it's not part of the deb format
[11:56] <wasabi> i know, im just sayin. ;)
[11:57] <mxpxpod> how do you guys make your kernels?
[11:57] <Keybuk> changelogs are the killer
[11:57] <Keybuk> mxpxpod: kernel-package
[11:57] <mxpxpod> Keybuk: do you use vanilla kernels?
[11:57] <Keybuk> mxpxpod: yes.
[11:58] <mxpxpod> Keybuk: what if I want a patch that ubuntu applies... like the wlan stuff
[11:58] (tseng/#ubuntu-devel) apt-get linux-source
[11:58] (tseng/#ubuntu-devel) -2.6.8.1
[11:59] (tseng/#ubuntu-devel) gives you the patched tree
[11:59] <mxpxpod> tseng: right... I'd like to compile a 2.6.9 tree
[12:00] <Keybuk> mxpxpod: linux-patch-debian-2.6.8.1