=== dasenjo [~dasenjo@200.21.83.173] has left #ubuntu-devel [] [12:27] (lamont_r/#ubuntu-devel) network move. back on in a bit. === mirak [~mirak@AAubervilliers-152-1-4-133.w82-121.abo.wanadoo.fr] has joined #ubuntu-devel === nasdaq4088 [sdfsd@tkp-ip-nas-1-p224.telkom-ipnet.co.za] has joined #ubuntu-devel [01:21] is there anyone here who has written visual basic applications? [01:23] (sladen/#ubuntu-devel) nasdaq4088: have you tried #basic ? [01:24] your one fucking funny guy === wasabi_ [~wasabi@c-24-1-67-127.client.comcast.net] has joined #ubuntu-devel [01:26] (sladen/#ubuntu-devel) the correct gramma would be "you're" [01:26] (sladen/#ubuntu-devel) r === _rene__ [~rene@dsl-082-082-060-135.arcor-ip.net] has joined #ubuntu-devel === _rene__ is now known as _rene_ === robertj [~robertj@66-188-77-153.cpe.ga.charter.com] has joined #ubuntu-devel === jdz [~jdz@69.49.156.181] has joined #ubuntu-devel === Riddell [jr@jriddell.kde] has joined #ubuntu-devel === herzi [~herzi@c200053.adsl.hansenet.de] has left #ubuntu-devel [] === lamont_p [~upirc@netblock-66-159-225-126.dslextreme.com] has joined #ubuntu-devel [05:50] moo === jvw [jeroen@233pc233.sshunet.nl] has joined #ubuntu-devel === bitserf [~ljb@222-152-4-93.jetstream.xtra.co.nz] has joined #ubuntu-devel === wasabi_ [~wasabi@c-24-1-67-127.client.comcast.net] has joined #ubuntu-devel === lamont_r [~lamont@c-24-6-169-124.client.comcast.net] has joined #ubuntu-devel === cenerentola [~cenerento@84.222.39.41] has joined #ubuntu-devel === cenerentola [~cenerento@84.222.39.41] has joined #ubuntu-devel === gicmo_ [~gicmo@pD9EE16F5.dip.t-dialin.net] has joined #ubuntu-devel === martink [~martin@pD9EB24D3.dip0.t-ipconnect.de] has joined #ubuntu-devel === Fwiffo [~user@81.19.254.172] has joined #ubuntu-devel === daniels [~daniels@george.kkhotels.co.uk] has joined #ubuntu-devel === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #ubuntu-devel === cenerentola [~cenerento@84.222.38.225] has joined #ubuntu-devel === Keybuk [scott@descent.netsplit.com] has joined #ubuntu-devel === daniels_ [~daniels@george.kkhotels.co.uk] has joined #ubuntu-devel === boglot [~logbot@mentors.workaround.org] has joined #ubuntu-devel === Fwiffo [~user@81.19.254.172] has joined #ubuntu-devel === nmf [~nmf@adsl-b4-66-254.telepac.pt] has joined #ubuntu-devel === cenerentola [~cenerento@84.222.38.225] has joined #ubuntu-devel === alerios [~alerios@201.245.164.174] has joined #ubuntu-devel === Mitario [~michiel@sikkes.xs4all.nl] has joined #ubuntu-devel === ogra [~ogra@pD95F8E0B.dip.t-dialin.net] has joined #ubuntu-devel [03:58] elmo: are you around ? === seb128 [~seb128@ANancy-151-1-8-117.w83-194.abo.wanadoo.fr] has joined #ubuntu-devel [04:03] A thought for all those doing merges ... http://www.lag.net/random/leisure-c.jpg [04:04] Keybuk: aint that the truth. [04:05] in a few minutes, I'll be heading home. Which is to say, offline for a day or 2... [04:05] time to get ready to leave. === skyrider_univer [~skyrider@kid.stu.cn.ua] has joined #ubuntu-devel === lemsx1 [~lemsx1@p78-56.acedsl.com] has joined #ubuntu-devel === daniels [~daniels@george.kkhotels.co.uk] has joined #ubuntu-devel === pitti [~martin@195.227.105.180] has joined #ubuntu-devel === mirak [~mirak@AAubervilliers-152-1-4-133.w82-121.abo.wanadoo.fr] has joined #ubuntu-devel === robertj_ [~robertj@66-188-77-153.cpe.ga.charter.com] has joined #ubuntu-devel === doko [doko@dsl-082-082-071-172.arcor-ip.net] has joined #ubuntu-devel [04:34] right. off to home. later === mirak [~mirak@AAubervilliers-152-1-4-133.w82-121.abo.wanadoo.fr] has joined #ubuntu-devel === cenerentola [~cenerento@84.222.39.66] has joined #ubuntu-devel === mirak [~mirak@AAubervilliers-152-1-4-133.w82-121.abo.wanadoo.fr] has joined #ubuntu-devel [04:53] hi [04:53] I have all kde menu entries in dupes [04:53] how can I fix that ? [04:53] a full kde reinstall ? === bitserf [~ljb@222-152-4-93.jetstream.xtra.co.nz] has joined #ubuntu-devel [04:54] even in the kde control center [04:54] every menu is in double [04:58] mirak: it may be because ubuntu has KDE libs 3.3 but KDE base 3.2 [04:59] ah ? [04:59] ah sorry wrong channel [04:59] I though I was in ~kde [05:00] #kde [05:00] I use ubuntu indeed, so thanks :) [05:01] Riddell: is there some command that rebuild the menu from de .desktop files ? [05:01] mirak: kbuildsycocoa [05:02] thanks [05:06] Riddell: where is the orininal database so I could erase it ? [05:06] original [05:10] (amu/#ubuntu-devel) mirak: link /usr/share/config /etc/kde3 [05:10] ok [05:10] (amu/#ubuntu-devel) it will solve the problem with your double menus [05:10] in fact the problem was a .back folder in /usr/share/applications [05:11] I don't remember if it's me who crated it [05:11] 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 ? === wasabi [~wasabi@c-24-1-67-127.client.comcast.net] has joined #ubuntu-devel [05:25] Has anybody considered using binary diffs for apt upgrades? === sivang [~sivang@80.179.93.130.forward.012.net.il] has joined #ubuntu-devel [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] Well, I'd say in Warty they most likely do. [05:38] But yeah, I see your point. [05:39] I'm wondering how much of a benefit it would have, for instance for openoffice. [05:39] Which is a 40mb .deb [05:41] given the openoffice build process, it'd probably be a 40mb xdelta as well :-/ [05:41] how so? [05:43] everything slightly changes [05:44] ELF isn't great for deltaing at the best of times [05:45] Well, the binaries aren't the biggest parts either [05:45] no, I was just thinking, there's a huge amount of data in that .deb as well [05:45] Grr. [05:45] xdelta doesn't do dir trees? [05:45] wasabi: tar, tar, xdelta [05:46] hmm. yeah. [05:46] So, somebody is working on deb as .tar.gz support, I heard. [05:46] THat'd solve that. [05:46] "deb as .tar.gz" ? [05:46] Instead of whatever format they are in now. [05:46] a deb is a .tar.gz [05:47] eh? what'd I read then [05:47] somebody who'd found the crackpile, by the sounds of it :p [05:47] ahh, support for bzip2 [05:48] Support for bzip2-compressed .debs [05:48] [05:48] ScottJamesRemnant [05:48] [05:48] Code in dpkg mainline [05:48] Oops. sorry. [05:48] that would be me :) [05:48] Didn't expect the lines. [05:48] oh. ;) [05:48] (Mithrandir/#ubuntu-devel) wasabi: Keybuk is Scott James Remnant. :) [05:48] looky there. [05:49] 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] not sure whether bzip2 would help openoffice or not [05:50] bzip2 generally performs better on plain text than gzip [05:51] but usually no better on binary, at a lot higher memory and CPU cost [05:53] So, what is a .deb? [05:54] an ar file containing a text file and two tar files [05:54] first tar file is all the meta-data, second are the contents [05:54] Hmm. Makes it hard to diff. [05:54] -rw-r--r-- 1 scott scott 40M 2004-11-20 16:51 data.tar.bz2 [05:54] -rw-r--r-- 1 scott scott 42M 2004-11-20 16:52 data.tar.gz [05:54] heh [05:55] And the contents tar file is gzipped? [05:55] both are gzipped [05:55] no real saving in bzipping openoffice [05:55] I'm trying to find the savings by diffing it [05:56] well, if you take openoffice.org-bin_1.1.2-2ubuntu6 -> openoffice.org-bin_1.1.2dfsg1-2ubuntu2 as a release upgrade ... [05:56] -rw-rw-r-- 1 scott scott 29M 2004-11-20 16:56 test.xdelta [05:57] so it's not even half the size [05:57] diffing the data.tar.gz I assume? [05:57] uncompressed data.tar [05:58] I did xserver-xorg, because I happened to have two versions of it, ubuntu1 and 2 [05:58] Orignial's about 5.3 MB, diff is 348k [05:58] I wouldn't generally expect a huge difference if it were just an ubuntu patch change [05:58] those are usually changes to things like the admin scripts [05:58] Yeah. [05:59] but in a release -> release situation, you're almost looking at one or more upstream version changes [05:59] and then the benefit vanishes [05:59] Even if it's a new version, similarities like images and stuff would make a big diff imo [05:59] Well, there is always an option of only doing a diff if it matters. [06:00] there's more benefit for splitting those into a separate source package [06:00] For a dialup user, 5MB to 380k is a major diff [06:00] sure, but dialup users probably won't be following the development cycle anyway [06:00] Sure. [06:00] and if they are, they won't be following fast enough to get every releas [06:00] haha [06:00] so it becomes impossible to have a set of deltas that they'll hit [06:02] 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] what do you diff from/to ? [06:02] last version to current version. [06:02] it's very rare that anybody will get every single version [06:03] they're more likely to skip one or more [06:03] So they have 3 patches. [06:03] if size of 3 patches < size of orignal package, delete patches. [06:03] err, > [06:04] this also still assumes they have the original .deb on the drive, of course [06:04] Yes, it does. [06:05] which isn't unreasonable, as APT does tend to keep them around until they're out-dated [06:05] I see a little check in apt: if current version on drive, search for patch from current version. [06:05] repeat until there are no more patches. [06:06] 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] if you've got some time, it'd certainly be interesting to see it implemented [06:08] I don't know whether the cost of generating the deltas would be huge or not [06:08] Here's a good example. [06:08] Evolution 2.0 to evo 2.1 in hoary [06:08] patch is 3.8M [06:08] i dont know if that's worth it. =/ [06:08] it is < 1/2 [06:08] how big is the evolution binary? [06:09] 9.2M [06:09] there's also a worry about doubling the amount of mirror space the archive takes [06:09] yeah. [06:09] if we're talking about Debian, which would benefit hugely from patching [06:09] Well, im talking only about Ubuntu at this point. ;) [06:10] basically taking a 120GB archive and turning it into a 240GB archive :p [06:10] Laying out the file names in the archive would be interesting too [06:10] Not sure how to go about that. [06:10] how do you mean? [06:10] /pool/b/blah/blah_oldversion.diff? [06:11] Or add it to the Package file somehow? [06:11] pool/$component/$s/$source/$source_$version_$arch.debdelta [06:11] you'd need a version index for each package, to make sure you could *get* all of the deltas [06:11] there's nothing saying what version that patch patches too. [06:11] Which doesn't matter. [06:12] But, it is a bit annoying [06:12] otherwise you could miss an important one, because a mirror ran out of disk, or hadn't sync'd it yet [06:13] sorry, that second $source should be $binary obviously, duh :p [06:13] Hmm. Apt takes the file in the archive. Takes the version on it. [06:13] Say it's 1.0.0 [06:13] Finds 1.0.0_i386.debdelta [06:13] which always upgrades to the "next" version. [06:13] Don't know what the next version is. [06:13] Perhaps .debdelta itself becomes an ar, with a control file. [06:14] 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] Yeah, but then you'd need to do version calcs to find the next version from the current. [06:14] Or you'd need to ls the directory. [06:14] can't ls an http directory [06:14] exactly. [06:14] .listing :P [06:14] you could do a GNU-style [06:15] File: libtool-1.5.8-1.5.10.diff.gz 89 KB 19/09/04 14:00:00 [06:15] File: libtool-1.5.8-1.5.10.diff.gz.sig 1 KB 19/09/04 14:00:00 [06:15] File: libtool-1.5.8-1.5.10.xdelta 24 KB 19/09/04 13:59:00 [06:15] File: libtool-1.5.8-1.5.10.xdelta.sig 1 KB 19/09/04 13:59:00 [06:15] File: libtool-1.5.8.tar.gz 2620 KB 07/08/04 13:57:00 [06:15] File: libtool-1.5.8.tar.gz.sig 1 KB 07/08/04 13:57:00 [06:15] There is nothing recording the progression from version 1.0.0 to 1.0.1 to 1.1.0 [06:15] File: [06:15] old-new? [06:15] $binary_$old_$new_$arch.debdelta [06:15] So which file do you grab? [06:15] You don't know waht the new is. [06:16] 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] so again, you're back to putting the information in the Packages file [06:16] then the Packages churn bites [06:16] User currently has lintool_1.5.8 [06:16] lib [06:16] It is upgrading to 1.5.10 ultimatly [06:16] there is also a 1.5.9 patch [06:17] 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] otherwise you could accidentally pick up a delta specific to testing or experimental [06:17] yeah. [06:18] doesn't solve my dilema though [06:18] so it now takes you [06:18] a) three times as long to download the Packages file [06:18] b) maybe half the time to download the packages themselves [06:18] c) a small eon to apply all the deltas to put together the new .deb and install it [06:18] 3 times as long? [06:18] Maybe... [06:19] won't argue with c. [06:19] 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] =) [06:20] Hmm. I wouldn't say triple! [06:20] Just 2 additional lines to each Package: stanze [06:20] ? [06:20] Deltas: [06:20] md5sum size previous next filename [06:20] md5sum size previous next filename [06:20] md5sum size previous next filename [06:20] etc. [06:20] assuming you keep the similar format to the Files: line [06:20] Delta-Next: md5sum size filename? [06:21] Actually... [06:21] You're format is more righter. ;) [06:21] Deltas:\ md5sum size fromversion filename [06:21] you can only have one entry per binary, and one occurance of each field [06:21] I might say that instead. [06:22] And apt grabs the target version and finds a path to it's current version through the fromversions. [06:22] yeah, you could work out if it were possible at Packages time, and download the appropriate things then [06:22] That opens up some interseting optimization ideas that nobdoyw ould probably use. [06:23] Have multiple patches to get you from various versions to the current. [06:23] Progressive or not. [06:23] Or not. You could have one delta from warty to hoary [06:23] and another between h oary versions, for large packages only. [06:24] indeed, it allows for big-jump upgrade deltas if they're smaller === mirak [~mirak@AAubervilliers-152-1-4-133.w82-121.abo.wanadoo.fr] has joined #ubuntu-devel [06:29] 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] I've never popped open the apt source code. [06:30] It C? [06:30] C++ [06:30] I think C++ [06:30] ahh damn I am slow [06:30] Oh, so it [06:30] s probably all OO === wasabi guessing he'll find a acquireVersionOrSomething function. [06:31] 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] I guess you should recompress it again, so you can use it next time without throwing it away [06:31] Yeah. [06:32] You would just be acquiring the cache/apt/archives files differently. [06:32] And the same methodology to clear that folder would be in effect. [06:32] Whatever it is. [06:32] I'd finger-in-the-air that there's a cut off point around half the download time of the original deb [06:33] I'd say if you're on dialup, any time saved is a blessing. [06:33] i'd agree with wasabi [06:33] But, it would just have to be balanced based on archive size [06:33] sure, but you don't want to shoot the people who can pull 100Mbps from the archive :p [06:33] instead of a 2s download, they get 2m of patching [06:33] Oh sure. [06:34] THere would be options. [06:34] I don't know how those options would be determined automatically. [06:34] but there would be options. ;) [06:35] 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] Yeah. THe sizes are listed. Take all the possible paths, find the shortest one by size. [06:36] where direct upgrades are a possible path [06:36] I wonder what the average patching time is [06:37] APT's C++ is pretty readable [06:37] it's more of a "struct and some functions that use it" kind of OO [06:37] Oh actually. [06:37] Oh. [06:37] My evolution measurement was way off. [06:37] rather than a Java/Smalltalk nut's crack [06:38] It's 28M to 3M [06:38] That's massive. [06:38] Ahh. I see. 28M is the data.tar, 9MB is the data.tar.gz. === eruin [~eruin@213-145-179-140.dd.nextgentel.com] has joined #ubuntu-devel [06:39] the patch is 3.8M, so it isn't that good. [06:39] Are the entries in the data.tar sorted? [06:40] executables are a bitch to delta, because the compiler will insist on moving damned functions around in memory :p === eruin [~eruin@213-145-179-140.dd.nextgentel.com] has joined #ubuntu-devel [06:40] wasabi: not generally [06:40] That might help massively [06:40] I think xdelta copes with that though [06:40] it's designed to diff tar files, after all [06:42] if (!(c1= m_fork())) { [06:42] m_dup2(p1[0] ,0); close(p1[0] ); close(p1[1] ); [06:42] m_dup2(p2[1] ,1); close(p2[0] ); close(p2[1] ); [06:42] if (chdir(directory)) ohshite(_("failed to chdir to `%.255s'"),directory); [06:42] execlp(TAR,"tar","-cf", "-", "-T", "-", "--null", "--no-recursion", (char*)0); [06:42] ohshite(_("failed to exec tar -cf")); [06:42] } [06:43] heh, ohsite() [06:43] er, ohshite() [06:43] execlp(FIND,"find",".","-path","./" BUILDCONTROLDIR,"-prune","-o","-print0", [06:43] and that to give the file list [06:43] so there's no sorting, other than it moves symlinks to the end for shits and giggles [06:45] daniels: ohshit() is an exception, ohshite() is an exception which errno is useful for :p [06:45] heh :) [06:45] This could also be made efficient... threaded. [06:45] I like your style ;) [06:45] Say you have 4 patches to reach a new version. [06:46] heh, that's iwj-C, not mine! [06:46] IT could be applying the first while it downloads the 2nd === BradB [~bradb@modemcable202.193-131-66.mc.videotron.ca] has joined #ubuntu-devel [06:47] daniels: ya know, I've never noticed before, but that's doing a longjmp inside a child process [06:47] so it's the child that bungees into error handling, instead of the parent [06:47] CRACK! [06:48] (Mithrandir/#ubuntu-devel) Keybuk: it's dpkg, what do you expect? [06:48] 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] Keybuk: heh! that's part of dpkg, is it? [06:48] http://www.freedesktop.org/~pasc/maillist.html [06:48] erk, ww [06:48] 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] Noooooooooooooo [06:54] I just typed up all the stuff we talked about in the wiki [06:54] hit submit, and it didn't work. =( and Epiphany lost it [06:58] d'oh [06:59] and then the wiki went *beep beep beep* and my page was gone. +9 [07:04] why oh why does openoffice.org supply a so-called "installer" archive that just contains rpms === Kyaneos [~Kyaneos@80-29-41-238.adsl.nuria.telefonica-data.net] has joined #ubuntu-devel [07:11] hi === __randy__ [~randy@sclab-25-433.sclab.clarkson.edu] has joined #ubuntu-devel === seb128_ [~seb128@ANancy-151-1-8-184.w83-194.abo.wanadoo.fr] has joined #ubuntu-devel === Fwiffo_ [~user@81.19.254.172] has joined #ubuntu-devel === zul [~chuck@zul.developer.gentoo] has joined #ubuntu-devel === Fwiffo__ [~user@81.19.254.172] has joined #ubuntu-devel === ChrisH [~chaas@gw.workaround.org] has joined #ubuntu-devel [07:33] 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. === steve2 [~steve@static24-72-72-185.regina.accesscomm.ca] has joined #ubuntu-devel [07:41] wasabi: has some major vanishing-off-the-right-hand-side issues [07:41] plain text. [07:41] i dont' know any of the listed wiki languages. [07:42] some newlines at 70-column would be great :p [07:42] I'd just assume figure out MoinMoin or something. [07:42] there's no scrollbar, it just cuts [07:42] i have scrollbar [07:42] hmm, I just have a vertical one [07:43] scroll down? [07:43] oh [07:43] hehe. [07:43] there's a scroll page in the *page* [07:43] gee, that's useful [07:43] yeah. [07:43] so I scroll down, scroll right, then scroll up to find I've scrolled to far [07:43] I swear [07:43] if I ever meet the designer of this new wiki, there will be words [07:43] and then there will be death [07:43] it's pretty slow too. [07:44] it's a total chocolate teapot [07:44] it might fit with everything else in the chocolate store [07:44] but you can't make tea in it. [07:44] haha [07:44] Keybuk: who is responsible for the old wiki still being online ? [07:44] ogra: no idea, someone who I shall be friends with, I suspect. is it? [07:45] there is no pointer to the new one..... [07:45] i swear, twiki is better than zwiki === Keybuk sobs for moin [07:45] I like moin [07:45] you can *gasp* use it [07:45] so, I can either make my font size too small to read [07:46] Keybuk: font size> in bugzilla? [07:46] or I can select and drag right slowly until it scrolls how far I want [07:46] oh, right === x4m [~max@166.158-200-80.adsl.skynet.be] has joined #ubuntu-devel [07:47] wasabi: hmm, your text seems to only allow for single deltas [07:47] "from this source version to the new version" [07:48] yeah. [07:48] you can have multiple lines listed. [07:48] so there's no way to download three or four consecutive deltas and put them together ? [07:48] Just didn't make a note of it [07:48] Oh, sure, you just have to trace through all the Packages entries [07:48] our archive churn is really too fast to expect people to only be taking one version jump [07:48] okay, I can get 1.0.1 to 1.0.2 [07:48] there's only one Packages entry for a given Package [07:48] how how can I get 1.0.1 from 1.0.0 [07:48] oh? [07:48] is there? [07:49] because there's only one version of that Package in the archive [07:49] I thought there were multiple with different versions [07:49] :-o no! what would be the point? APT would just pick the latest one [07:49] Well... ;) === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #ubuntu-devel [07:49] Just FYI! [07:49] there can be different versions in different Packages files [07:49] Hmm./ [07:49] That's unfortunate. THe way I imagined it would be pretty slick [07:49] but you certainly can't have more than one in the same file ... it breaks an assumption [07:50] you'd need to keep the .debs around as well [07:50] and then your archive gets biiig and faaat [07:50] yeah, old .deb's are kept around. [07:50] To an extent. [07:50] and people who mirror you say "fuck dial-up" [07:50] I have two versions of xorg for instance. === Fwiffo__ [~user@81.19.254.172] has joined #ubuntu-devel [07:51] Well. Then I just add two versions into the Delta's section [07:51] no biggy, just not as cool as I thought it was. ;) [07:51] and then you work out it's cheaper to send dial-up users free CDs than expect them to download an update [07:51] because the hardware and bandwidth upgrade to support all that extra weight costs more than shipping half a million CDs === sivang joins Keybuk sobbing on moin. [07:53] Probably makes the code easier anyways. [07:53] wasabi: also don't use ".debdiff", there's already a tool called that [07:53] .debpatch or .debdelta is fine though [07:53] oh. That was your example. ;) [07:53] no, I used .debdelta :p [07:54] damn. foiled again. [07:54] mention the patches are against the uncompressed control.tar.gz and data.tar{,.gz,.bz2,.Z,*} [07:54] Oh here's another question. [07:55] the data.tar.gz, is there a standard compression level? [07:55] -z9 by default [07:55] Can that be altered by the packager? [07:55] if they like [07:55] If so, it makes generating exact copies hard. [07:55] deb-deb -z3 [07:55] Since the repackaging has to know what it should be. [07:55] Or the checksums don't match [07:56] yeah, you're going to need some "DON'T LOOK AT THAT CHECKSUM" fiddling anyway :p [07:56] Hmm. Was hoping there was some way around that. ;) [07:56] well, gzip is theoretically deterministic [07:56] so if you put the .deb back together it should match the md5sum of the deb you would've downloaded anyway [07:57] Except `ar' stores dates. [07:57] but, as you say, you'd need to take into account the -z and -Z flags used when putting together the .deb [07:57] or does it. i dunno. [07:58] yeah it does [07:58] well the entire thing falls apart then. [07:58] unless i ignore checksums, which I really dont want to do [07:59] Eh, actually. If the checksums of the .debdeltas are stored in the Packages file, it's not a security issue. [07:59] hmm, why not? [08:00] 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] But if the Packages file hsa the sums of hte .debdeltas, then there's no way to sneak anything in. [08:00] yeah ther eis [08:00] ? [08:01] you craft a Packages and set of xdeltas to attack a known version of a .deb [08:01] but the checksum would still match, I guess *shrug* [08:01] Packages.gpg? [08:02] I'm not sure whether APT re-checks the checksums of things in its cache before installing or not [08:02] Somebody (maybe you!) is working on signing apt I think. [08:02] that was Progeny [08:02] s/apt/Packages/ [08:03] mdz maintains Debian's APT, and has a branch that includes that stuff [08:03] Well, it's no more a vuln than it is currently. [08:03] https://www.ubuntulinux.org/wiki/APTAuthentication [08:03] you could compromise someone's machine, replacing something in /var/cache/apt/archives with something malicious [08:03] You could do that now. [08:04] If you've done that, you mine as well just hack the machine while you were in it. [08:04] I don't think you can with Secure-APT [08:04] it verifies the Packages file and the Packages when it installs them [08:04] not just when it downloads them [08:04] (I think) [08:04]