#ubuntu-devel 2004-12-01 (lamont_r/#ubuntu-devel) network move. back on in a bit. <nasdaq4088> is there anyone here who has written visual basic applications? (sladen/#ubuntu-devel) nasdaq4088: have you tried #basic ? <nasdaq4088> your one fucking funny guy (sladen/#ubuntu-devel) the correct gramma would be "you're" (sladen/#ubuntu-devel) r <lamont_p> moo <ogra> elmo: are you around ? <Keybuk> A thought for all those doing merges ... http://www.lag.net/random/leisure-c.jpg <lamont_r> Keybuk: aint that the truth. <lamont_r> in a few minutes, I'll be heading home. Which is to say, offline for a day or 2... <lamont_r> time to get ready to leave. <lamont_r> right. off to home. later <mirak> hi <mirak> I have all kde menu entries in dupes <mirak> how can I fix that ? <mirak> a full kde reinstall ? <mirak> even in the kde control center <mirak> every menu is in double <Riddell> mirak: it may be because ubuntu has KDE libs 3.3 but KDE base 3.2 <mirak> ah ? <mirak> ah sorry wrong channel <mirak> I though I was in ~kde <mirak> #kde <mirak> I use ubuntu indeed, so thanks :) <mirak> Riddell: is there some command that rebuild the menu from de .desktop files ? <Riddell> mirak: kbuildsycocoa <mirak> thanks <mirak> Riddell: where is the orininal database so I could erase it ? <mirak> original (amu/#ubuntu-devel) mirak: link /usr/share/config /etc/kde3 <mirak> ok (amu/#ubuntu-devel) it will solve the problem with your double menus <mirak> in fact the problem was a .back folder in /usr/share/applications <mirak> I don't remember if it's me who crated it <mirak> maybe yes (amu/#ubuntu-devel) aaahh those "menus" ;) i thought to the window-menu's *g* (amu/#ubuntu-devel) btw. someone build libs&base against xorg ? <wasabi> Has anybody considered using binary diffs for apt upgrades? (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 <wasabi> Well, I'd say in Warty they most likely do. <wasabi> But yeah, I see your point. <wasabi> I'm wondering how much of a benefit it would have, for instance for openoffice. <wasabi> Which is a 40mb .deb <Keybuk> given the openoffice build process, it'd probably be a 40mb xdelta as well :-/ <wasabi> how so? <Keybuk> everything slightly changes <Keybuk> ELF isn't great for deltaing at the best of times <wasabi> Well, the binaries aren't the biggest parts either <Keybuk> no, I was just thinking, there's a huge amount of data in that .deb as well <wasabi> Grr. <wasabi> xdelta doesn't do dir trees? <Keybuk> wasabi: tar, tar, xdelta <wasabi> hmm. yeah. <wasabi> So, somebody is working on deb as .tar.gz support, I heard. <wasabi> THat'd solve that. <Keybuk> "deb as .tar.gz" ? <wasabi> Instead of whatever format they are in now. <Keybuk> a deb is a .tar.gz <wasabi> eh? what'd I read then <Keybuk> somebody who'd found the crackpile, by the sounds of it :p <wasabi> ahh, support for bzip2 <wasabi> Support for bzip2-compressed .debs <wasabi> <wasabi> ScottJamesRemnant <wasabi> <wasabi> Code in dpkg mainline <wasabi> Oops. sorry. <Keybuk> that would be me :) <wasabi> Didn't expect the lines. <wasabi> oh. ;) (Mithrandir/#ubuntu-devel) wasabi: Keybuk is Scott James Remnant. :) <wasabi> looky there. <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) (Mithrandir/#ubuntu-devel) Keybuk: it's fun, isn't it? :) <Keybuk> not sure whether bzip2 would help openoffice or not <Keybuk> bzip2 generally performs better on plain text than gzip <Keybuk> but usually no better on binary, at a lot higher memory and CPU cost <wasabi> So, what is a .deb? <Keybuk> an ar file containing a text file and two tar files <Keybuk> first tar file is all the meta-data, second are the contents <wasabi> Hmm. Makes it hard to diff. <Keybuk> -rw-r--r-- 1 scott scott 40M 2004-11-20 16:51 data.tar.bz2 <Keybuk> -rw-r--r-- 1 scott scott 42M 2004-11-20 16:52 data.tar.gz <Keybuk> heh <wasabi> And the contents tar file is gzipped? <Keybuk> both are gzipped <Keybuk> no real saving in bzipping openoffice <wasabi> I'm trying to find the savings by diffing it <Keybuk> well, if you take openoffice.org-bin_1.1.2-2ubuntu6 -> openoffice.org-bin_1.1.2dfsg1-2ubuntu2 as a release upgrade ... <Keybuk> -rw-rw-r-- 1 scott scott 29M 2004-11-20 16:56 test.xdelta <Keybuk> so it's not even half the size <wasabi> diffing the data.tar.gz I assume? <Keybuk> uncompressed data.tar <wasabi> I did xserver-xorg, because I happened to have two versions of it, ubuntu1 and 2 <wasabi> Orignial's about 5.3 MB, diff is 348k <Keybuk> I wouldn't generally expect a huge difference if it were just an ubuntu patch change <Keybuk> those are usually changes to things like the admin scripts <wasabi> Yeah. <Keybuk> but in a release -> release situation, you're almost looking at one or more upstream version changes <Keybuk> and then the benefit vanishes <wasabi> Even if it's a new version, similarities like images and stuff would make a big diff imo <wasabi> Well, there is always an option of only doing a diff if it matters. <Keybuk> there's more benefit for splitting those into a separate source package <wasabi> For a dialup user, 5MB to 380k is a major diff <Keybuk> sure, but dialup users probably won't be following the development cycle anyway <wasabi> Sure. <Keybuk> and if they are, they won't be following fast enough to get every releas <wasabi> haha <Keybuk> so it becomes impossible to have a set of deltas that they'll hit <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. <Keybuk> what do you diff from/to ? <wasabi> last version to current version. <Keybuk> it's very rare that anybody will get every single version <Keybuk> they're more likely to skip one or more <wasabi> So they have 3 patches. <wasabi> if size of 3 patches < size of orignal package, delete patches. <wasabi> err, > <Keybuk> this also still assumes they have the original .deb on the drive, of course <wasabi> Yes, it does. <Keybuk> which isn't unreasonable, as APT does tend to keep them around until they're out-dated <wasabi> I see a little check in apt: if current version on drive, search for patch from current version. <wasabi> repeat until there are no more patches. <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. <Keybuk> if you've got some time, it'd certainly be interesting to see it implemented <Keybuk> I don't know whether the cost of generating the deltas would be huge or not <wasabi> Here's a good example. <wasabi> Evolution 2.0 to evo 2.1 in hoary <wasabi> patch is 3.8M <wasabi> i dont know if that's worth it. =/ <wasabi> it is < 1/2 <Keybuk> how big is the evolution binary? <wasabi> 9.2M <Keybuk> there's also a worry about doubling the amount of mirror space the archive takes <wasabi> yeah. <Keybuk> if we're talking about Debian, which would benefit hugely from patching <wasabi> Well, im talking only about Ubuntu at this point. ;) <Keybuk> basically taking a 120GB archive and turning it into a 240GB archive :p <wasabi> Laying out the file names in the archive would be interesting too <wasabi> Not sure how to go about that. <Keybuk> how do you mean? <wasabi> /pool/b/blah/blah_oldversion.diff? <wasabi> Or add it to the Package file somehow? <Keybuk> pool/$component/$s/$source/$source_$version_$arch.debdelta <Keybuk> you'd need a version index for each package, to make sure you could *get* all of the deltas <wasabi> there's nothing saying what version that patch patches too. <wasabi> Which doesn't matter. <wasabi> But, it is a bit annoying <Keybuk> otherwise you could miss an important one, because a mirror ran out of disk, or hadn't sync'd it yet <Keybuk> sorry, that second $source should be $binary obviously, duh :p <wasabi> Hmm. Apt takes the file in the archive. Takes the version on it. <wasabi> Say it's 1.0.0 <wasabi> Finds 1.0.0_i386.debdelta <wasabi> which always upgrades to the "next" version. <wasabi> Don't know what the next version is. <wasabi> Perhaps .debdelta itself becomes an ar, with a control file. <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 <wasabi> Yeah, but then you'd need to do version calcs to find the next version from the current. <wasabi> Or you'd need to ls the directory. <Keybuk> can't ls an http directory <wasabi> exactly. <daniels> .listing :P <Keybuk> you could do a GNU-style <Keybuk> File: libtool-1.5.8-1.5.10.diff.gz 89 KB 19/09/04 14:00:00 <Keybuk> File: libtool-1.5.8-1.5.10.diff.gz.sig 1 KB 19/09/04 14:00:00 <Keybuk> File: libtool-1.5.8-1.5.10.xdelta 24 KB 19/09/04 13:59:00 <Keybuk> File: libtool-1.5.8-1.5.10.xdelta.sig 1 KB 19/09/04 13:59:00 <Keybuk> File: libtool-1.5.8.tar.gz 2620 KB 07/08/04 13:57:00 <Keybuk> File: libtool-1.5.8.tar.gz.sig 1 KB 07/08/04 13:57:00 <wasabi> There is nothing recording the progression from version 1.0.0 to 1.0.1 to 1.1.0 <Keybuk> File: <wasabi> old-new? <Keybuk> $binary_$old_$new_$arch.debdelta <wasabi> So which file do you grab? <wasabi> You don't know waht the new is. <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) <Keybuk> so again, you're back to putting the information in the Packages file <Keybuk> then the Packages churn bites <wasabi> User currently has lintool_1.5.8 <wasabi> lib <wasabi> It is upgrading to 1.5.10 ultimatly <wasabi> there is also a 1.5.9 patch <Keybuk> in fact, you'd need the Packages file information *anyway* to make sure you were getting a delta that applies to your branch <Keybuk> otherwise you could accidentally pick up a delta specific to testing or experimental <wasabi> yeah. <wasabi> doesn't solve my dilema though <Keybuk> so it now takes you <Keybuk> a) three times as long to download the Packages file <Keybuk> b) maybe half the time to download the packages themselves <Keybuk> c) a small eon to apply all the deltas to put together the new .deb and install it <wasabi> 3 times as long? <wasabi> Maybe... <wasabi> won't argue with c. <Keybuk> wasabi: assuming 3-4 deltas per binary, with md5sum, size, previous and next version info -- roughly triples the size of the Packages file <wasabi> =) <wasabi> Hmm. I wouldn't say triple! <wasabi> Just 2 additional lines to each Package: stanze <wasabi> ? <Keybuk> Deltas: <Keybuk> md5sum size previous next filename <Keybuk> md5sum size previous next filename <Keybuk> md5sum size previous next filename <Keybuk> etc. <Keybuk> assuming you keep the similar format to the Files: line <wasabi> Delta-Next: md5sum size filename? <wasabi> Actually... <wasabi> You're format is more righter. ;) <wasabi> Deltas:\ md5sum size fromversion filename <Keybuk> you can only have one entry per binary, and one occurance of each field <wasabi> I might say that instead. <wasabi> And apt grabs the target version and finds a path to it's current version through the fromversions. <Keybuk> yeah, you could work out if it were possible at Packages time, and download the appropriate things then <wasabi> That opens up some interseting optimization ideas that nobdoyw ould probably use. <wasabi> Have multiple patches to get you from various versions to the current. <wasabi> Progressive or not. <wasabi> Or not. You could have one delta from warty to hoary <wasabi> and another between h oary versions, for large packages only. <Keybuk> indeed, it allows for big-jump upgrade deltas if they're smaller <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 <wasabi> I've never popped open the apt source code. <wasabi> It C? <Keybuk> C++ <gicmo_> I think C++ <gicmo_> ahh damn I am slow <wasabi> Oh, so it <wasabi> s probably all OO * wasabi guessing he'll find a acquireVersionOrSomething function. <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 <Keybuk> I guess you should recompress it again, so you can use it next time without throwing it away <wasabi> Yeah. <wasabi> You would just be acquiring the cache/apt/archives files differently. <wasabi> And the same methodology to clear that folder would be in effect. <wasabi> Whatever it is. <Keybuk> I'd finger-in-the-air that there's a cut off point around half the download time of the original deb <wasabi> I'd say if you're on dialup, any time saved is a blessing. <daniels> i'd agree with wasabi <wasabi> But, it would just have to be balanced based on archive size <Keybuk> sure, but you don't want to shoot the people who can pull 100Mbps from the archive :p <Keybuk> instead of a 2s download, they get 2m of patching <wasabi> Oh sure. <wasabi> THere would be options. <wasabi> I don't know how those options would be determined automatically. <wasabi> but there would be options. ;) <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 <wasabi> Yeah. THe sizes are listed. Take all the possible paths, find the shortest one by size. <wasabi> where direct upgrades are a possible path <wasabi> I wonder what the average patching time is <Keybuk> APT's C++ is pretty readable <Keybuk> it's more of a "struct and some functions that use it" kind of OO <wasabi> Oh actually. <wasabi> Oh. <wasabi> My evolution measurement was way off. <Keybuk> rather than a Java/Smalltalk nut's crack <wasabi> It's 28M to 3M <wasabi> That's massive. <wasabi> Ahh. I see. 28M is the data.tar, 9MB is the data.tar.gz. <wasabi> the patch is 3.8M, so it isn't that good. <wasabi> Are the entries in the data.tar sorted? <Keybuk> executables are a bitch to delta, because the compiler will insist on moving damned functions around in memory :p <Keybuk> wasabi: not generally <wasabi> That might help massively <Keybuk> I think xdelta copes with that though <Keybuk> it's designed to diff tar files, after all <Keybuk> if (!(c1= m_fork())) { <Keybuk> m_dup2(p1[0] ,0); close(p1[0] ); close(p1[1] ); <Keybuk> m_dup2(p2[1] ,1); close(p2[0] ); close(p2[1] ); <Keybuk> if (chdir(directory)) ohshite(_("failed to chdir to `%.255s'"),directory); <Keybuk> execlp(TAR,"tar","-cf", "-", "-T", "-", "--null", "--no-recursion", (char*)0); <Keybuk> ohshite(_("failed to exec tar -cf")); <Keybuk> } <daniels> heh, ohsite() <daniels> er, ohshite() <Keybuk> execlp(FIND,"find",".","-path","./" BUILDCONTROLDIR,"-prune","-o","-print0", <Keybuk> and that to give the file list <Keybuk> so there's no sorting, other than it moves symlinks to the end for shits and giggles <Keybuk> daniels: ohshit() is an exception, ohshite() is an exception which errno is useful for :p <daniels> heh :) <wasabi> This could also be made efficient... threaded. <eruin> I like your style ;) <wasabi> Say you have 4 patches to reach a new version. <Keybuk> heh, that's iwj-C, not mine! <wasabi> IT could be applying the first while it downloads the 2nd <Keybuk> daniels: ya know, I've never noticed before, but that's doing a longjmp inside a child process <Keybuk> so it's the child that bungees into error handling, instead of the parent <Keybuk> CRACK! (Mithrandir/#ubuntu-devel) Keybuk: it's dpkg, what do you expect? <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 <daniels> Keybuk: heh! that's part of dpkg, is it? <daniels> http://www.freedesktop.org/~pasc/maillist.html <daniels> erk, ww <Keybuk> this explains at least three open bugs on dpkg :p (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 ;-) (pasc/#ubuntu-devel) to know what people think that is. I still haven't modified the actual message views, but that will come later <wasabi> Noooooooooooooo <wasabi> I just typed up all the stuff we talked about in the wiki <wasabi> hit submit, and it didn't work. =( and Epiphany lost it <Keybuk> d'oh <wasabi> and then the wiki went *beep beep beep* and my page was gone. +9 <eruin> why oh why does openoffice.org supply a so-called "installer" archive that just contains rpms <Kyaneos> hi <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. <Keybuk> wasabi: has some major vanishing-off-the-right-hand-side issues <wasabi> plain text. <wasabi> i dont' know any of the listed wiki languages. <Keybuk> some newlines at 70-column would be great :p <wasabi> I'd just assume figure out MoinMoin or something. <Keybuk> there's no scrollbar, it just cuts <wasabi> i have scrollbar <Keybuk> hmm, I just have a vertical one <wasabi> scroll down? <Keybuk> oh <wasabi> hehe. <Keybuk> there's a scroll page in the *page* <Keybuk> gee, that's useful <wasabi> yeah. <Keybuk> so I scroll down, scroll right, then scroll up to find I've scrolled to far <Keybuk> I swear <Keybuk> if I ever meet the designer of this new wiki, there will be words <Keybuk> and then there will be death <wasabi> it's pretty slow too. <Keybuk> it's a total chocolate teapot <Keybuk> it might fit with everything else in the chocolate store <Keybuk> but you can't make tea in it. <wasabi> haha <ogra> Keybuk: who is responsible for the old wiki still being online ? <Keybuk> ogra: no idea, someone who I shall be friends with, I suspect. is it? <ogra> there is no pointer to the new one..... <daniels> i swear, twiki is better than zwiki * Keybuk sobs for moin <Keybuk> I like moin <Keybuk> you can *gasp* use it <Keybuk> so, I can either make my font size too small to read <daniels> Keybuk: font size> in bugzilla? <Keybuk> or I can select and drag right slowly until it scrolls how far I want <daniels> oh, right <Keybuk> wasabi: hmm, your text seems to only allow for single deltas <Keybuk> "from this source version to the new version" <wasabi> yeah. <wasabi> you can have multiple lines listed. <Keybuk> so there's no way to download three or four consecutive deltas and put them together ? <wasabi> Just didn't make a note of it <wasabi> Oh, sure, you just have to trace through all the Packages entries <Keybuk> our archive churn is really too fast to expect people to only be taking one version jump <wasabi> okay, I can get 1.0.1 to 1.0.2 <Keybuk> there's only one Packages entry for a given Package <wasabi> how how can I get 1.0.1 from 1.0.0 <wasabi> oh? <wasabi> is there? <Keybuk> because there's only one version of that Package in the archive <wasabi> I thought there were multiple with different versions <Keybuk> :-o no! what would be the point? APT would just pick the latest one <wasabi> Well... ;) <wasabi> Just FYI! <Keybuk> there can be different versions in different Packages files <wasabi> Hmm./ <wasabi> That's unfortunate. THe way I imagined it would be pretty slick <Keybuk> but you certainly can't have more than one in the same file ... it breaks an assumption <Keybuk> you'd need to keep the .debs around as well <Keybuk> and then your archive gets biiig and faaat <wasabi> yeah, old .deb's are kept around. <wasabi> To an extent. <Keybuk> and people who mirror you say "fuck dial-up" <wasabi> I have two versions of xorg for instance. <wasabi> Well. Then I just add two versions into the Delta's section <wasabi> no biggy, just not as cool as I thought it was. ;) <Keybuk> and then you work out it's cheaper to send dial-up users free CDs than expect them to download an update <Keybuk> 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. <wasabi> Probably makes the code easier anyways. <Keybuk> wasabi: also don't use ".debdiff", there's already a tool called that <Keybuk> .debpatch or .debdelta is fine though <wasabi> oh. That was your example. ;) <Keybuk> no, I used .debdelta :p <wasabi> damn. foiled again. <Keybuk> mention the patches are against the uncompressed control.tar.gz and data.tar{,.gz,.bz2,.Z,*} <wasabi> Oh here's another question. <wasabi> the data.tar.gz, is there a standard compression level? <Keybuk> -z9 by default <wasabi> Can that be altered by the packager? <Keybuk> if they like <wasabi> If so, it makes generating exact copies hard. <Keybuk> deb-deb -z3 <wasabi> Since the repackaging has to know what it should be. <wasabi> Or the checksums don't match <Keybuk> yeah, you're going to need some "DON'T LOOK AT THAT CHECKSUM" fiddling anyway :p <wasabi> Hmm. Was hoping there was some way around that. ;) <Keybuk> well, gzip is theoretically deterministic <Keybuk> so if you put the .deb back together it should match the md5sum of the deb you would've downloaded anyway <wasabi> Except `ar' stores dates. <Keybuk> but, as you say, you'd need to take into account the -z and -Z flags used when putting together the .deb <wasabi> or does it. i dunno. <Keybuk> yeah it does <wasabi> well the entire thing falls apart then. <wasabi> unless i ignore checksums, which I really dont want to do <wasabi> Eh, actually. If the checksums of the .debdeltas are stored in the Packages file, it's not a security issue. <Keybuk> hmm, why not? <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. <wasabi> But if the Packages file hsa the sums of hte .debdeltas, then there's no way to sneak anything in. <Keybuk> yeah ther eis <wasabi> ? <Keybuk> you craft a Packages and set of xdeltas to attack a known version of a .deb <Keybuk> but the checksum would still match, I guess *shrug* <wasabi> Packages.gpg? <Keybuk> I'm not sure whether APT re-checks the checksums of things in its cache before installing or not <wasabi> Somebody (maybe you!) is working on signing apt I think. <Keybuk> that was Progeny <wasabi> s/apt/Packages/ <Keybuk> mdz maintains Debian's APT, and has a branch that includes that stuff <wasabi> Well, it's no more a vuln than it is currently. <wasabi> https://www.ubuntulinux.org/wiki/APTAuthentication <Keybuk> you could compromise someone's machine, replacing something in /var/cache/apt/archives with something malicious <wasabi> You could do that now. <wasabi> If you've done that, you mine as well just hack the machine while you were in it. <Keybuk> I don't think you can with Secure-APT <Keybuk> it verifies the Packages file and the Packages when it installs them <Keybuk> not just when it downloads them <Keybuk> (I think) <wasabi> I think the secure apt idea is just to verify downloads. <wasabi> I think it's just a matter of signing Packages.gz <Keybuk> largely, yeah <wasabi> /var/cache/apt is root owned. If somebody is in that, they have owned the system already. <wasabi> I think ignoring checksums of assembled .deb's is pretty decent. <wasabi> No longer worried about it <wasabi> So I guess some of this has to be in Dpkg, and some of it in Apt. <wasabi> Dpkg needs all the proper stuff to take a .deb and a .debdelta and produce a new .deb <wasabi> ANd apt needs to handle the resolution of all that and pass it to dpkg. <RubenV> Hi, i'm trying to build a .deb <RubenV> however, when issuing dpkg-buildpackage -rfakeroot <RubenV> i get a permission denied error <RubenV> fakeroot debian/rules clean <RubenV> /usr/bin/fakeroot: line 150: debian/rules: Permission denied <daniels> chmod +x debian/rules <daniels> either that, or use debuild <RubenV> oh, forgot <RubenV> :/ <RubenV> let's see if this get's me further <Keybuk> wasabi: I'd just make it a companion tool, rather than changing dpkg <Keybuk> dpkg-delta and dpkg-patch for example <Keybuk> anyway, I'm going to go and satisfy my mass-entertainment needs by watching Simon Cowell be hilariously mean to people <wasabi> enjoy. <RubenV> doesn't dpkg-buildpackage call autoconf automatically? <Keybuk> RubenV: no. <wasabi> no. <RubenV> (never done this before) <robtaylor_> mjg59: alive?# <Keybuk> not unless the package's debian/rules calls autoconf <Keybuk> which is a silly thing to do anyway <wasabi> dpkg-buildpackage does nothing except try to reach the proper targets in debian/rules. <Keybuk> if you ever need to run autoconf on source you downloaded (rather than got from CVS) you need to hurt someone <RubenV> it's a cvs checkout <RubenV> autoconf gives me horrible errors though <Keybuk> autoreconf -i <RubenV> something is horribly wrong with this source tree :) <wasabi> hmm. this leaves off the possibility of using patches to rename packages. ;) <wasabi> So I wrote a script to generate a .debdelta from two .debs <wasabi> Even small packages are getting significant savings. <RubenV> wasabi: i was thinking about the same thing a couple of days ago <RubenV> while I was slurping OO.o over a slow line <wasabi> https://www.ubuntulinux.org/wiki/APTPackageDeltas <wasabi> think about it there. <RubenV> there should be a way to delta pkgs :) <wasabi> yeah. working on that. <RubenV> great idea <RubenV> Also a Packages.bz2 delta could be usefull <RubenV> one/day or so <wasabi> that would be hard to keep track of <wasabi> since Packages does not have any sort of version indicator. <RubenV> true (haggai/#ubuntu-devel) eruin: were you looking for binaries of openoffice 1.9.x ? (smurfix/#ubuntu-devel) wasabi: you could use the md5sum of the Packages file as the "version number". <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? <mxpxpod> chrisa: ping <ggi> Is the association of every sort of text file with OpenOffice.org intentional? <Keybuk> wasabi: you can't technically rename a package anyway, so that's not exactly a problem :p <wasabi> yeah. <wasabi> I've got two scripts writte <wasabi> dpkg-gendelta, and dpkg-delta <wasabi> one creates a delta given two packages, the other takes an original package and a .debdelta and produces the new package. <wasabi> Both work. <wasabi> just bash scripts though. :0 <Keybuk> heh, all the best things are :p <wasabi> SO in theory it works. <wasabi> THe dpkg rodriguezcrystal@example.org. ;) <wasabi> And it produces a valid .deb that installs. Yay. <wasabi> epiphany goes from 2.8MB to 774k. <wasabi> that's a pretty big savings. <wasabi> woh. <wasabi> mozilla-firefox goes from 9.0M to 216k <wasabi> just this one little -4 ubuntu change <sivang> wasabi : have you used python to do this? <wasabi> bash <sivang> wasabi : ah nice, could you send me the scripts? <wasabi> dcc? <sivang> wasabi : darn, my firewall probably blocking this..strange, I added the IRC helper module to netfilter.. <wasabi> actually i probably can't sand that. <wasabi> heh forgot where i was <sivang> wasabi : mail would be also fine :) <wasabi> addy? <sivang> wasabi : sivanSpamfreeaTworkaround.org <wasabi> sent. <sivang> wasabi : thanks. so you basically compute the difference and download only the remaining parts? <wasabi> oh no. <wasabi> these are just two examples. <mxpxpod> is there a guide out there on how to make a ubuntu kernel image? <wasabi> of how feasibly it would be to do. <wasabi> feasible. <wasabi> it is not in any way shape or form functional. <wasabi> heck I just did it in 20 minutes. <sivang> wasabi : k, thanks anyways. <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 <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. <wasabi> s/installed/available/ <wasabi> heck, or just installed. And just distribute changed files. * wasabi ponder. <eruin> haggai, ooh, yes <eruin> haggai, sorry for the slow reply on ooo 1.9 debs ;) <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. <wasabi> No delta's required. <wasabi> Internal dpkg mods... <wasabi> to extract the new files in / and then run the scripts on control.tar.gz <Keybuk> SUN-like you mean? <wasabi> ? <Keybuk> SUN patches are distributed as package files that just contain the replacement files <wasabi> I'm spelunking in dpkg code now figuring out how to do that. It really sounds easy. <Keybuk> or, in some cases, just the deltas with a class to apply them rather than copy over the top <Keybuk> two problems <wasabi> deletions. <Keybuk> yup <wasabi> (file in control listing them) <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 <wasabi> what's hte other one? <Keybuk> moves <wasabi> I'll have to think thorugh how hte info files will be altered. <wasabi> moves are fine. <wasabi> doesn't matter. just gets redownloaded. <Keybuk> you can pretty much just stick an 'if (! a_patch_package)' round a large block of process_archive <wasabi> yeah. <wasabi> That's what im thinking. <wasabi> THere will have to be a few mods into the management of the db. <wasabi> In order to alter the info file, by adding the new additions to it <Keybuk> it does that anyway <Keybuk> if you look at process_archive, it adds the new files first <Keybuk> and then goes through the list to see whether it needs to delete anything <wasabi> Ahh. <wasabi> How does it tell if it needs to delete anything? If it doesn't exist in the archive? <Keybuk> yeah :) just sets a flag on the file list entry as it unpacks the file <wasabi> We only want it deleting stuff that exists in a composite of hte old and new archives. <Keybuk> then iterates the file list to see if there are any entries without flags <wasabi> does not exist that is <wasabi> Will have a different naming convention on the .deb though. <wasabi> old_new <wasabi> or, maybe something else <Keybuk> processarc.c line 586-662 (roughly) <wasabi> Okay, so that can stay as it is, but the list it operates on can be altered <Keybuk> the list it operates on is just the old file list <Keybuk> you just need some way of copying stuff from the old file list to the new one before that <wasabi> Hmm. So what the unlink? <Keybuk> you'd need to cope with an empty data.tar.gz too <Keybuk> sometimes uploads are just control-file changes <wasabi> well, that should handle itself. <Keybuk> would be nice if you could build one of those without trying too :p <Keybuk> wasabi: ever tried to make an empty tar.gz ? :p <mxpxpod> is there a kernel team for ubuntu? <wasabi> it would simply be like an upgrade that installed nothing. <wasabi> Oh. Heh. <wasabi> Suspose you can't do that? <Keybuk> descent scott% tar czf foo.tar.gz <Keybuk> tar: Cowardly refusing to create an empty archive <wasabi> Could have something like a first ignored file in it all the time <wasabi> .DEBIAN or something. <Keybuk> just stick ./ in it <wasabi> ahh you can do that? <wasabi> heh. <wasabi> That's silly in a way. <Keybuk> descent scott% tar --no-recursion -czf foo.tar.gz ./ <Keybuk> descent scott% tar tzf foo.tar.gz <Keybuk> ./ <wasabi> how big is it? <Keybuk> 111 bytes <wasabi> workable, silly, but workable. <wasabi> So this seems pretty easy actually. <wasabi> Just a few ifs really. <wasabi> All the hard stuff is really up to apt. <Keybuk> yeah, it's some neuro-surgery on dpkg to make it understand that it doesn't need to remove the old files <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 <sivang> wasabi : wow, you're gonna make it not delete the old file, and just add them the binary delta? <wasabi> no real need for delta at all <wasabi> that I see anyways. <wasabi> Interesting. <wasabi> If you have a 1.0.0 to 1.0.5 .deb patch. <sivang> wasabi : ah, just pull out the changed dependencies? <wasabi> You can upgrade 1.0.1 to 1.0.5 using the same file. <wasabi> So, the archive scripts can really optimize good upgrade paths. <Keybuk> wasabi: only if the same files were changed in each version between that <wasabi> Keybuk, a 1.0.0 to 1.0.5 patch would contain all the mods between 1.0.0 and 1.0.5 <Keybuk> oh, sorry <Keybuk> yeah, that'd work <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. <wasabi> the archive scripts could do some optimization on that. <Keybuk> this wouldn't work too well for mostly-binary packages though <Keybuk> the resulting debs would be the same as the non-patch debs <wasabi> THe deltas don't work well for those either though. <Keybuk> true <wasabi> And in that case, the archive scripts can just not make them. <wasabi> If there is no savings. <Keybuk> it's a pity that every upload is a rebuild <Keybuk> which means every upload there is a slight change to every binary :-/ <wasabi> Well, that can, and probably should, be solved in other ways. <wasabi> Why would gcc turn the same thing into a different thing two times? <Keybuk> because it's non-deterministic <wasabi> i fail to see how a compiler can be non-deterministic unless it has a random number generator in it. :0 <mxpxpod> mjg59: ping <Keybuk> memory offsets and whatnot <wasabi> or encodes times into it <wasabi> wasabi@kyoto:~ $ gcc test.c <wasabi> wasabi@kyoto:~ $ md5sum a.out <wasabi> 7e7fb7d522a047d438aa60b4a4918553 a.out <wasabi> wasabi@kyoto:~ $ rm a.out <wasabi> wasabi@kyoto:~ $ gcc test.c <wasabi> wasabi@kyoto:~ $ md5sum a.out <wasabi> 7e7fb7d522a047d438aa60b4a4918553 a.out <wasabi> ??? <Keybuk> do it on a different machine ? <wasabi> true. <Keybuk> descent scott% md5sum main-only <Keybuk> 11d9ad98f23a24f04f3365e280b3aa63 main-only <Keybuk> syndicate scott% md5sum main-only <Keybuk> 79e1a52f4e49295c11bcd29680b4661b main-only <wasabi> ahh well. <Keybuk> and that's the simplest example there is :p <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. <wasabi> but that's probably not a good idea. <wasabi> would screw md5sum's in the packages all to hell <Keybuk> heh, you wanna write it? ;) <Keybuk> but then I guess binaries are rarely the *major* component of any package <wasabi> I'm gonna try to understand this dpkg code and see what I can do. <wasabi> Hmm. <wasabi> control/md5sums in the new package lists every file. <wasabi> and it would in the upgrade package too <wasabi> Yeah, it's just a few k. <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. <wasabi> That can also be done later without any trouble. <Keybuk> control/md5sums isn't mandatory <Keybuk> dpkg itself doesn't have one, for example <wasabi> Well, if a openoffice upgrade is distributed with 1 file moded, all billion files would be listed. <Keybuk> yah <wasabi> which I think is okay <wasabi> gzipped it's nothing. <Keybuk> tricky, because dpkg doesn't touch md5sums at all <wasabi> yeah, but it has to be present. I dont think any diffs or antyhing are going to be done on control.tar.gz <Keybuk> doesn't have to be present <Keybuk> it's not part of the deb format <wasabi> i know, im just sayin. ;) <mxpxpod> how do you guys make your kernels? <Keybuk> changelogs are the killer <Keybuk> mxpxpod: kernel-package <mxpxpod> Keybuk: do you use vanilla kernels? <Keybuk> mxpxpod: yes. <mxpxpod> Keybuk: what if I want a patch that ubuntu applies... like the wlan stuff (tseng/#ubuntu-devel) apt-get linux-source (tseng/#ubuntu-devel) -800.716.0984 (tseng/#ubuntu-devel) gives you the patched tree <mxpxpod> tseng: right... I'd like to compile a 2.6.9 tree <Keybuk> mxpxpod: linux-patch-debian-800.716.0984 #ubuntu-devel 2004-12-02 <mxpxpod> Keybuk: and it's in a patch that has a bunch of stuff in it <wasabi> heh. changelogs. <wasabi> You use kernel-package? <wasabi> doesn't it generate kernel-image packages, and not linux-image? <wasabi> ANd not all those cool symlink stuff. <wasabi> Or was that fixed? :) (tseng/#ubuntu-devel) the only difference between kernel-image and linux-image is the name afaik (tseng/#ubuntu-devel) i hope someone can enlighten us otherwise <wasabi> well linux-source packages are a bit different. <wasabi> They use a symlink farm of some sort in /usr/src (tseng/#ubuntu-devel) no kidding, thats why its called -source <wasabi> make-kpkg never build those for me with kernel_source. (tseng/#ubuntu-devel) never built the linux-source? <wasabi> the symlink farms. <mxpxpod> is there a reason ubuntu hasn't upgraded to 2.6.9? <wasabi> it just makes flat dirs in /usr/src <FTTP> hi <FTTP> any hoary isos working yet? <FTTP> tried a developmental snapshot which had issues <Keybuk> what kind of issues? <eruin> the 2.6.9 I tried had some crazy issues with kswapd <FTTP> keybuk: Installer screen came out all messed up <FTTP> it was not usable <FTTP> its only a dev so.... <FTTP> keybuk: Was work done to the newest daily snapshot? <FTTP> or are there any releases which i can try for hoary which are more stable than the others? <Keybuk> not that I'm aware of ... I've not heard that bug <Keybuk> is it in Bugzilla (opened or closed?) <FTTP> keybuk: I didnt report it <FTTP> should I try the newest snapshot and report it? <Keybuk> sure <FTTP> if it occurs again <FTTP> ok <FTTP> keybuk you a developer for ubuntu? <Keybuk> ish <Keybuk> :p <FTTP> ish? (Mithrandir/#ubuntu-devel) Keybuk: pft, you're well an ubuntu dev. :) <Keybuk> I work for Canonical, but most of my time isn't working on Ubuntu itself at the moment <FTTP> ahh <FTTP> what are you responsible for? (Mithrandir/#ubuntu-devel) Keybuk: you're still an ubuntu developer, though <Keybuk> FTTP: "Special Projects", heh <FTTP> such as? <FTTP> or they cant be disclosed so they are SPECIAL :) <wasabi> assassinating high level redhet executives. <FTTP> hehe <Keybuk> Mithrandir: I didn't even have my key in the keyring until last week! <Keybuk> FTTP: heh, it's a joke ... Special Projects is the mythical dept. people get transferred to before they're made redundant (Mithrandir/#ubuntu-devel) Keybuk: you didn't? that actually surprises me :) <Keybuk> Mithrandir: nah, almost the only stuff I've uploaded have been that big match of first-run merges <daniels> Mithrandir: would *you* want him uploading to Ubuntu? <daniels> Mithrandir: mdz just has good taste ;) (Mithrandir/#ubuntu-devel) daniels: sure, I need my daily dose of crack. <sivang> Keybuk : have you spotted my BOF proposal for a python workshop? What do you think? :) (Mithrandir/#ubuntu-devel) Keybuk: I haven't uploaded much either, though. <Keybuk> sivang: I thought "cool" :) <daniels> Mithrandir: craaaaaack <Keybuk> daniels: heh, the trouble with filling mdz's shoes on Tuesday was THEY'RE TOO SMALL! :p <daniels> heh :) <sivang> Keybuk : Feel free to add your comments there, maybe a list of requested reading before it, I want to come prepared :) <FTTP> any 24 hour a day coders over at canocal? <FTTP> :P <FTTP> heh <daniels> FTTP: no, but I've hardly left my laptop in the last 5 days :P <Keybuk> sivang: "Dive into Python" :) <FTTP> daniels: u know the link for the hoary isos? <FTTP> the snapshots <sivang> Keybuk : ah, then I'm already set :) <FTTP> cant seem to find the link <daniels> FTTP: http://archive.ubuntu.com/cdimage/, I'd imagine <FTTP> ahhh <FTTP> thanks <daniels> Keybuk: speaking of Python -- http://gabe.freedesktop.org/~daniels/old-to-new-ldap.py <FTTP> ill bookmark that :P <daniels> Keybuk: check that baby out :) <daniels> Keybuk: the two password crypting functions are stolen from userdir-ldap, the rest is mine <Keybuk> daniels: what does that *do* ? <Keybuk> FTTP: we have coders in every timezone <Keybuk> and I've certainly done the odd 24+ when I've not noticed the sun come up again <daniels> Keybuk: takes an ldif of our old ldap database, generates an ldif of the new-format setup <daniels> Keybuk: lies <daniels> Keybuk: there's no-one in +1300 (NZ) <Keybuk> daniels: pedant :p you knew what I meant :p <daniels> or +0950, or +1050, or +1000 <Keybuk> daniels: aww, so it doesn't convert woody-era ldap to sarge-era ldap? :( <daniels> Keybuk: but yeah, the code is pretty horrible <stratus> -0300 ? <daniels> Keybuk: nope, just different formats of database <FTTP> keybuk: Shouldnt you be coding now ? :) <FTTP> heh <daniels> stratus: wtf is that? <FTTP> oh wait your in special projects <FTTP> i fergot <Keybuk> daniels: *cry* ... my ldap server is broke because of that <daniels> Keybuk: i.e. one from some horrid abortion called usradm to userdir-ldap <FTTP> :P <Keybuk> keeps bitching about records not being structural <daniels> Keybuk: should happen ... oh, wack <daniels> Keybuk: how many records? <stratus> daniels, BRT of course. <daniels> stratus: oh, right <daniels> stratus: is that in line with us est, or is it an hour ahead? <daniels> stratus: because we have someone in est <Keybuk> daniels: not a huge number <Keybuk> but I can't figure out what it's talking about <wasabi> oye. <Keybuk> and how I'm supposed to solve it <stratus> daniels, i guess not, checking... <daniels> Keybuk: meh, just do it by hand <wasabi> dpkg is ugly <daniels> Keybuk: probably to do with your objectClasses <Keybuk> I added a silly structural record type to them all <Keybuk> then it bitched about having two structural types in some of the fields <Keybuk> and I declared that I couldn't win <stratus> daniels, no EST is -0500 <daniels> stratus: ah. in any case, actually, we do have people there. <FTTP> keybuy: Array1 is more stable right? <FTTP> err keybuk <stratus> daniels, np but not at -0300 ! <FTTP> i tried the daily last time <daniels> Keybuk: you can never win with LDAP <daniels> Keybuk: just lose less horrendously badly <daniels> stratus: yes we do :) <daniels> stratus: i just realised we have some people in brazil <Keybuk> FTTP: *shrug* Array has Colin's hand-built touch <Keybuk> so theoretically it's more ... testable <FTTP> yep <FTTP> :P <Keybuk> daniels: tell me about it <seb128> hum, the archive is not updated ? <stratus> daniels, oh yes the guys at async? <Keybuk> from what I could tell, posixGroup is structural -- but then posixAccount *isn't* <seb128> the new gnumeric has built for hours and is still not available <wasabi> Keybuk, you know much about parsedb and pkginfo struct? <daniels> stratus: aye <Keybuk> but organization is structural ... so what if something's both an Organisation and a POSIX Group?! <stratus> daniels, i see <Keybuk> wasabi: yeah, it's just a linked list of the state file <wasabi> Posix group is messed up <wasabi> nss_ldap also reads groupOfUniqueNames <daniels> Keybuk: yeah, don't use posixAccount <wasabi> I believe. <Keybuk> well, I changed posixGroup anyway to have "gid" instead of "cn" <daniels> Keybuk: i use top/inetOrgPerson/shadowAccount/debianAccount/debianDeveloper <Keybuk> so maybe I just need to change that to be auxiliary <wasabi> posixGroup is a pretty dumb class. <Keybuk> daniels: top isn't structural :-o <daniels> Keybuk: but iirc the old stuff was top/posixAccount/shadowAccount <daniels> Keybuk: in that case, none of our records are, but sarge/warty's ldap still loves me \o/ <Keybuk> slapadd: dn="dc=netsplit,dc=com" (line=7): (65) no structural object class provided <Keybuk> objectClass: top <Keybuk> ^ yet <daniels> dn: dc=freedesktop,dc=org <daniels> objectClass: top <daniels> objectClass: dcObject <daniels> objectClass: organization <daniels> o: freedesktop.org <daniels> dc: freedesktop <Keybuk> organization is structural <Keybuk> I hate ldap * Keybuk about -> <- this far away from dumping it and going back to passwd <mojo> Good morning all fellows (kylem/#ubuntu-devel) ldap >>>>>>> nis. <FTTP> will ubuntu have enuff capital to compete with the likes of novell + redhat? <mojo> I no longer can sync with CVS from gnome.org/gnome-icons <FTTP> developers are top notch i know <FTTP> :) <FTTP> but i worry about capital <mojo> does anyone know something wrong with the CVS server? <Keybuk> FTTP: we have a similar amount of capital in the bank as RedHat, as I understand it <FTTP> keybuk: Novell has 500mil + <FTTP> it won a microsoft lawsuit <grin> <Keybuk> yeah, but Novell is a much larger business than Ximian <wasabi> yeah but redhat is making money. <daniels> kylem: represent <wasabi> =) <daniels> anyway, this is all horrifically offtopic (novell, ldap, stuff) <FTTP> anyways (kylem/#ubuntu-devel) daniels, and take it from me, i administrate both. :( <FTTP> burning dev cd <FTTP> keybuk: We will see :) <FTTP> keybuk: When hoary comes out we will know more <Keybuk> FTTP: true, but then RedHat have to go begging for more money, we just have to excite the boss <Keybuk> actually, the "plan" is to be starting to make money in 18 months time <FTTP> shuttleworth is easy? :) <Keybuk> so more perky-era <FTTP> hehe <FTTP> keybuk: From what? just support? <FTTP> keybuk: I hope your right :) seen too many distros come out and go poof <FTTP> ubuntu has so much potential <FTTP> anyways back to dev chat <FTTP> ---------pretend im not here <FTTP> :P <wasabi> So, who "makes decisions"? * Keybuk gives up and goes back to /etc/passwd <Keybuk> wasabi: it's complicated <Keybuk> the developers make decisions <Keybuk> but if they can't reach consensus, they can ask either the technical board or the community council to make a decision for them <Keybuk> and if they can't reach consensus, we ask Mark <wasabi> Otherwise it's just like Debian, people do what they think they should do whenever? <Keybuk> kinda, the tech board and sabdfl both set direction for people to head in <wasabi> Hmm. <wasabi> Dpkg is confusing me to no end. <Keybuk> it's good at that (sabdfl/#ubuntu-devel) it's usually the pointy end that gets the most confused by dpkg though <wasabi> I found parsedb(), which reads hte control file... but I have no idea what it's doing with the values. <stratus> discarding them? :) <Keybuk> puts them in the package info list <wasabi> struct pkginfo? <jdz_> Are there any plans for LTSP work in Ubuntu? <Keybuk> the package list is global, so it doesn't get passed in or out, just added to in general <Keybuk> oh, would it help to know findpackage always returns? <Keybuk> so if you try and find a package that doesn't exist, you get an empty record to fill in? <wasabi> heh. <wasabi> Right now im just trying to figure out how to expose my new control fields to the code. <Keybuk> thus pig=findpackage(newpig.name); actually makes a record <wasabi> And I don't understand the relation of the pkginfo struct to the deb and to the currently installed packages <Keybuk> add it to the fieldinfos <wasabi> if a package is currently installed, the pkginfo struct you receive makes note of it <wasabi> fieldinfos <wasabi> where? <Keybuk> top of parse.c <wasabi> oh. that. <wasabi> ;) <wasabi> f_whatever = type, w_whatever = ???, other col = ??? <Keybuk> name, read function, write function, offset in structure <Keybuk> (or some other integer you want to pass to them) <FTTP> anyone know about module hid in hoary? <sivang> FTTP : it has one? doesn't it? <FTTP> lol <FTTP> i tried the developmental daily snapshot <FTTP> it says fatal error module hid not found <FTTP> so nope it doesnt <wasabi> Keybuk, in pkginfo, struct pkginfoperfile installed; struct pkginfoperfile available; Is available the instance of hte package attempting to be installed, and installation the one that is already installed (or null)? <Keybuk> installed is the one in the status file <Keybuk> available is the one "on the FTP site" <wasabi> cool. <Keybuk> (ie. in the available file) <Keybuk> neither are the one on disk <wasabi> eh? <wasabi> oh you mean in the archive? <Keybuk> yeah <wasabi> Yeah, the archive is just for apt. <Keybuk> remember, APT is a "relatively" new invention <wasabi> but if I do dpkg -i /blah/blah.deb, available refers to that one <Keybuk> no. <Keybuk> the available file is populated by "dselect update" <Keybuk> and mucked around with by dselect <wasabi> Well im totally confused then <wasabi> What is the one "being installed right now"? <Keybuk> neither <wasabi> well im totally confused then. <wasabi> parsedb(cidir, pdb_recordavailable|pdb_rejectstatus|pdb_ignorefiles|pdb_weakclassification, &pkg,NULL,NULL); <wasabi> does that not read the control file from the .deb being installed? <Keybuk> there's a "pkginqueue" struct <wasabi> not that I can see. <FTTP> hid = Human interface device right? <FTTP> so thats the mouse, keyboard <wasabi> correct. <Keybuk> yeah, that call passes &pkg to parsedb (donep) so parsedb returns the pig <wasabi> pig stands for? <FTTP> wasabi can one submit code changes? <wasabi> FTTP, to? <FTTP> i mean suggestions <Keybuk> pig <Keybuk> piggy wiggy <Keybuk> go oink, have tails <wasabi> ... <FTTP> wasabi to fix bugs like hid not found :P <Keybuk> iwj likes calling packages pigs <wasabi> FTTP, I'd imagine so. <Keybuk> we don't ask why <wasabi> FTTP, bugzilla. <FTTP> wasabi ok <wasabi> okaaay. <FTTP> :) <wasabi> well hell. I dont get it. <Keybuk> K <wasabi> parsedb returns a pkginfo. This pkginfo has an installed and available struct. They are not representative of what is being installed. <wasabi> pkginqueue (which I cannot find) <wasabi> is. <Keybuk> ah, sorry <Keybuk> I see your confusion there <Keybuk> yeah, that parsedb call is told to fill the available pkginfoperfile struct <Keybuk> newpifp= (flags & pdb_recordavailable) ? &newpig.available : &newpig.installed <Keybuk> inside process_archive, pkg->available is the one you're processing, pkg->installed is the one you're replacing (if any) <Keybuk> I thought you were in another function (the one that calls process_archive) <wasabi> Keybuk, if the field isn't found in the control file, w/f_whatever are not called, right? <Keybuk> right <ironwolf> daniels? <daniels> sup <ironwolf> daniels: when changing s3 to vesa and removing
{'channel': 'ubuntu-devel', 'month': 12}