=== fredix [n=fredix@68.69.97-84.rev.gaoland.net] has joined #ubuntu-motu === Hirion [n=hirion@draugr.de] has left #ubuntu-motu [] [12:05] iirc the original xorg (hoary) is the one in sid [12:06] sid just got 6.9, actually === psusi [n=phreak@103.202.33.65.cfl.res.rr.com] has joined #ubuntu-motu === nimm [n=jason@216.231.61.135] has joined #ubuntu-motu === rikai [n=gtk2@pool-68-238-59-32.port.east.verizon.net] has joined #ubuntu-motu === rave_ [n=rave@84-104-9-27.cable.quicknet.nl] has joined #ubuntu-motu === keyes [n=keyes@lns-bzn-47f-62-147-143-87.adsl.proxad.net] has joined #ubuntu-motu [12:29] plop [12:29] siretart: hello ! === rave__ [n=rave@84-104-9-27.cable.quicknet.nl] has joined #ubuntu-motu [12:31] i seem to remember them saying they were going to wait for 7.0 :P [12:31] as they wanted the modular release === crimsun [i=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-motu === rikai [n=gtk2@pool-68-238-59-32.port.east.verizon.net] has joined #ubuntu-motu === rave__ is now known as rave === Hieronymus [n=jeroen@cp413115-a.tilbu1.nb.home.nl] has joined #ubuntu-motu === cyberix [n=cyberix@hoas-fe36dd00-251.dhcp.inet.fi] has joined #ubuntu-motu === thierry_ [n=thierry@modemcable234.69-131-66.mc.videotron.ca] has joined #ubuntu-motu === plugwash [i=plugwash@p10link.net] has joined #ubuntu-motu [01:19] How are ui translations synchronised between launchpad, Grumpy and the original project? === plugwash [i=plugwash@p10link.net] has joined #ubuntu-motu === trulux [n=lorenzo@unaffiliated/trulux] has joined #ubuntu-motu === Mortas [n=kris@217.148.89.121] has joined #ubuntu-motu === minghua [n=minghua@69-153-139-23.dsl.hstntx.swbell.net] has joined #ubuntu-motu [01:30] after doing a debuild in a source tree, how do you clean it back up? [01:30] debuild clean [01:30] sudo debuild -S -sa does it for me [01:30] do what crimsun says, he's better than me :) [01:30] -S will clean it, too [01:31] ahhh... [01:31] thierry_: s/better//g [01:32] hrm... is there a better way to make a new dpatch than diffing by hand then appending it to the output of dpatch patch-template? [01:32] dpatch-edit-patch? [01:32] doh ;) [01:33] yeah, the name is not that intuitive, but you create new text file with your text editor, don't you? ;-) [01:36] hrm... seems to want you to make changes after you run it... I already made the changes ;) [01:37] psusi: yes. probably you can start from a new tree, than copy your modifiled filed into the chroot [01:38] (or apply the patch inside the chroot if you have one patch already) [01:38] this is kind of annoying.... why's it need a temp area? instead of just extracting the .orig.tar.gz and diffing? [01:39] because sometimes one patch depends on another, so you can't always start from .orig.tar.gz [01:40] well, I mean start with the .orig.tar.gz then apply all patches... so it gets what you got when you apt-get source, then diff against the current dir [01:42] not all dpatches in your work dir are already in the .diff.gz, so how can dpatch know where to get all the patches [01:42] ? === Mortas [n=kris@217.148.89.121] has joined #ubuntu-motu [01:43] and nothing prevents people from using dpatch AND direct modifying the source (which will end up in .diff.gz) anyway [01:44] well yea, but if it's already using dpatch you want to continue to use it don't you? [01:44] for easier maintenance, yes [01:45] from MOTU point of view, yes, as we want to be as close as possible on packaging with Debian [01:45] like minghua said, though, there are only "best practices" [01:45] jesus... it picked up all the other patches as well.. I guess I was supposed to dpatch disable-all before exiting [01:46] or maybe dpatch enable-all before dpatch-edit-patch? [01:58] It would be great if http://tiber.tauware.de/~lucas/versions/unimultiverse.html#outdatedinB ignored syncable versions [01:58] e.g., if bochs is 2.2.5-1 in Sid and 2.2.1-2 in Dapper, that's syncable and can be ignored [01:59] whereas amule is 2.1.0-1 in Sid and 2.0.3-3ubuntu2 can't be ignored [01:59] (ok yeah, poor grammar aside) === bpuccio [n=brian@ool-457afde7.dyn.optonline.net] has joined #ubuntu-motu [02:05] BLAH. It's so hard to find out what changed in Debian revisions with packages.d.o down. === JohnnyMast [n=rave@84-104-9-27.cable.quicknet.nl] has joined #ubuntu-motu [02:07] StevenK: I end up keeping packages.qa.debian.org/x/xoo.html open [02:12] I want to be able to read the changelog without downloading the damn thing. [02:14] <\sh> StevenK: why is it down, btw? [02:14] saens is overloaded. [02:14] ugh, no one ever talk to marcin on gimpnet [02:15] ;P === StevenK tries to figure out why moin is insisting on Depending on python2.3 [02:18] <\sh> StevenK: for debian or for ubuntu? [02:18] is there a way to get pbuilder to use a local directory as an apt source, or does it do the update from inside the chroot? [02:18] <\sh> it does the update from inside the chroot [02:19] hrm... let's see... maybe a bind mount? [02:19] <\sh> also not... [02:19] <\sh> but you can inject the package via pbuilder login [02:19] <\sh> and tell him to not clean up [02:20] <\sh> s/him/it/ [02:20] \sh: Ubuntu [02:20] looks like you can pbuilder --bindmounts to get it to bind mount a dir inside the chroot to the real dir holding the .debs [02:20] <\sh> hmm.apt-cache show moin give me but the 2.4 deps [02:20] but how can you tell pbuilder login to not clean up? [02:20] <\sh> (dapper) [02:21] \sh: Yes, but it's 1.2.4-1ubuntu2, I'm preparing 1.4.99+1.5.0rc1-1ubuntu1. [02:22] <\sh> --save-after-exec [02:22] <\sh> Save the chroot image after exiting from the chroot instead of deleting changes. Effec [02:22] <\sh> tive for login and exec session. [02:22] <\sh> StevenK: ah [02:23] is /var/cache/pbuilder/result mounted inside the chroot? [02:24] <\sh> well..I don't use it...I use the pbuilder- example commands to build everything in my home dir :) === StevenK wrote a wrapper. [02:27] So I can call pdebuild{,-breezy,-dapper} [02:28] <\sh> /usr/share/doc/pbuilder/examples/pbuilder-distribution.sh is very nice...very very nice :) [02:28] hrm... it looks like pbuilder keeps a deb cache in /var/cache/pbuilder/aptcache... maybe I can drop the .deb in there? [02:30] <\sh> hmmm [02:30] <\sh> libglade-gnome0 is gtk1.2 or gtk2 and gnome? === hub [n=hub@toronto-hs-216-138-231-194.s-ip.magma.ca] has joined #ubuntu-motu [02:33] former [02:33] just looking at its depends [02:47] wow. [02:47] I have traceroute6 but not traceroute === marcin [n=user@194.114.146.58] has joined #ubuntu-motu [02:50] hm, I see zope 2.9 now required python >= 2.4.2 [02:51] compared to 2.8 requiring >= 2.3.3 [02:51] which will remove the major reason to keep python2.3 packages around [02:54] <\sh> hub: traceroute doesn't exists anymore ...it now named tracepath [02:54] <\sh> moins btw [02:54] hey \sh [02:54] \sh: it does. it is in main as separate package [02:54] that [02:54] was === wjb [n=warren@c220-237-173-120.lowrp1.vic.optusnet.com.au] has joined #ubuntu-motu === ajmitch hopes we can get zope 2.9 & 3.2 in dapper [02:54] wan not installed [02:55] <\sh> hub: bsd traceroute ? [02:55] \sh: yeah [02:55] hello hub [02:55] <\sh> hub: but linux distros changed a long time ago from traceroute to tracepath [02:55] ii traceroute 1.4a12-20 traces the route taken by packets over a TCP/IP network [02:55] \sh: old habits die hard [02:55] <\sh> well...I don't like it (tracepath) [02:55] <\sh> hub: that is right :) [02:55] I didn't even know about tracepath [02:56] <\sh> oh wow...why is anybody bugging me now because of the bloody wesnoth patch...and upstreams proposed patch...is nobody reading bugreports? [02:56] \sh: people don't read bugreports [02:57] <\sh> ajmitch: devels should do [02:57] doesn't mean they do [02:57] sadly [02:58] <\sh> well..to state this in public: [02:59] <\sh> If I patch a source, then I know I am right, even if debian or upstream says different...and if I say: Please don't merge the upcoming rev of a debian package because it includes a broken patch....then I mean it [03:00] <\sh> because on 64bit a calculation like (int)(pointer - pointer) is not always 32bit [03:00] <\sh> bah [03:00] <\sh> [03:02] <\sh> more to read on http://gna.org/bugs/?func=detailitem&item_id=4992 [03:02] <\sh> grmp [03:02] <\sh> f === ajmitch is trying to setup a zope instance & running into all sorts of evil bugs === slomo_ [n=slomo@ubuntu/member/slomo] has joined #ubuntu-motu [03:18] \sh, yea... code like that is broken... you fixed it and the upstream maintainers rejected your fix? [03:19] <\sh> psusi: no..they see that they were wrong :) === marcin [n=user@194.114.146.58] has joined #ubuntu-motu [03:19] of course... in reality, it isn't likely to cause a problem... because subtracting two pointers would only make sense to get the count of how far appart the two objects are, if they are in an array... and it isn't very likely that the array will contain > 4 billion objects ;) [03:19] wait... nevermind. [03:19] wait a second [03:20] it isn't legal to add or subtract two pointers iirc [03:20] only add/subtract integers to them, which has much the same effect as [] [03:20] now you've done it... now I'm confused [03:27] hrm.... e2fsprogs fails to build from source... looks like everything compiles and all, but then it says this: [03:27] <\sh> psusi: no..but pointers in 64bit are 64bit..and typecasting pointers should held the length properly on 64bit a pointer is 64bit an int but is 32bit on 64bit systems...forget the special case named intel 32bit [03:27] install: cannot stat `/tmp/buildd/e2fsprogs-1.38/debian/BUILD-STD/doc/libext2fs_*.html': No such file or directory [03:28] \sh, why is int 32 bit on 64 bit systems? shouldn't it be the CPU's native word size? [03:29] <\sh> psusi: no [03:29] <\sh> a pointer is the native word size...but int is 32bit and long is 64bit on 64bit systems. [03:29] <\sh> psusi: it's only on 32bit systems that int and long are sharing the same size. [03:30] <\sh> there are some documents from AMD out on google...search for "porting 32bit to 64bit linux" [03:30] <\sh> or porting to amd64 and linux :) [03:30] <\sh> well...a lot of stuff :) [03:30] I don't see how that should be... I work on a 24 bit extended version of the 16 bit z80 at work... a short is 16 bits, a long is 32 bits, an int and a pointer are both 24 bits... isn't the point of int that it should be the native size? if you cared about how big it was, you'd use short or long [03:34] <\sh> psusi: it's not :) [03:35] <\sh> psusi: this was our alltime war during breezy to fix those mistakes... [03:35] <\sh> psusi: and I read all the stuff I can.. [03:37] what is the reason int was kept as 32 bits on 64 bit compilers? you're not supposed to use int if you actually care about how big it is... the idea being that it will be a different size on a different arch... did they just do it to support a lot of broken code that assumed int was 32 bit? [03:37] can you get pbuilder to only build one binary-arch target of a source package, instead of all of them? [03:39] <\sh> psusi: most of the code is ritten for x86 machines [03:39] <\sh> psusi: you mean only one package out of N in debian/control? [03:39] in other words, there's a ton of broken code that assumes int is 32 bit and you would rather not fix it all right? [03:40] \sh, exactly [03:40] e2fsprogs has a ton of target binary packages... I just need one... and for some reason, it fails to build from source... might be able to build the package I need though [03:40] <\sh> psusi: via chroot you can build the package and then don't clean up the object files [03:41] <\sh> and call make -f debian/rules build from there...so it's starts only from where it stopped [03:42] <\sh> psusi: lets say it like this: there is a lot of code, that thinks int is int..but int is not a pointer and typecasting a pointer into int is correct for x86 but not for amd64 or emt64 [03:43] <\sh> anyways..I'm going to sleep now [03:43] <\sh> good night :) [03:45] night === jcape [i=jcape@71.194.176.102] has joined #ubuntu-motu === ealden [n=ealden@219.90.91.51] has joined #ubuntu-motu === Mez [n=Mez@ubuntu/member/mez] has joined #ubuntu-motu === Yagisan [n=jamie@60-240-125-87.tpgi.com.au] has joined #ubuntu-motu === Arrogance [n=aks@ottawa-hs-64-26-167-38.d-ip.magma.ca] has joined #ubuntu-motu === joe_alf [n=joe_alf@pcd302172.netvigator.com] has joined #ubuntu-motu [05:12] what is a udeb? [05:14] psusi: it's used for the installer [05:14] psusi: it's a micro deb package for d-i [05:15] hrm... what's it do? I thought the installer just installed all the .debs [05:16] no, d-i usually only install .udebs [05:17] psusi: the installer needs them for it's runtime environment IIRC [05:17] yeah, what Yagisan said [05:18] (only install .udebs) for its own functioning [05:18] G'day minghua - how are you today ? [05:18] Yagisan: hello, I am good, what about you? [05:19] minghua: not bad - got some interest in the x264 package on revu, so I'm updating it and doing some cleanup, then will send it back to revu [05:20] Yagisan: glad to hear that [05:20] I still don't understand how the .udeb differs from the normal .deb for a given package [05:20] and why both are needed [05:21] psusi: .debs need a fully installed environment to work - they are also rather large [05:21] psusi: udebs, are rather slimmed down, contain only bare functionality needed, and can run from the d-i minimal environment [05:22] psusi: udebs are only ever used by the installer - hence eg no wesnoth udeb [05:22] so what kind of things are stripped out from the normal deb to thin them down? [05:24] documentations and man pages, for exapmle [05:24] psusi: check the source for the particular package you are interested in, but basically it's whatever is not essential [05:25] wait... are the udebs used to build the setup cd, or they are what the installer installs to your hd? [05:26] no, .udebs are never installed on harddrive [05:26] psusi: setup cd == installer cd [05:26] right... so the setup cd is itself built using the udebs... because it doesn't need docs [05:26] psusi: the installer runs from the udebs, and installs normal debs to your system [05:26] but when you go and install, it installs all the .debs and you get the docs on your hd, right? [05:26] ok... yea... I get it now... [05:27] :) [05:27] ;) [05:27] anyone have a link to the dpatch for dummies page ? [05:28] I prefer patchsys [05:28] in cdbs [05:28] less crack [05:28] Yagisan, I've been figuring that out all day ;) [05:28] I just want something simple to strip out crack in an upstream configure file [05:29] they have cflags that don't exist in it ?!? [05:29] ok... I have fixed the defrag package to build on amd64... but I also had to fix e2fsprogs-dev... now how can I make defrag build-depend on a version of e2fsprogs-dev that is at least the version I just fixed? [05:30] I could just diff it out, but then it would be a pain to revu [05:30] psusi: defrag ??? [05:30] Yagisan, yea... === rikai-2 [n=gtk2@pool-68-238-59-32.port.east.verizon.net] has joined #ubuntu-motu [05:31] psusi: we actually need a defrag ?? for a non fat or ntfs based filesystem ? [05:31] my fixex version is this: e2fsprogs_1.38-2ubuntu2.dsc so does that mean I want to change the build-depends line in defrag to: e2fslibs-dev (>= 2ubuntu2)? [05:31] Yagisan, need is a relative term... [05:31] in defrag's debian/control:Build-Depends, you'd have e2fsprogs-dev (>= 1.38-2ubuntu2) [05:32] psusi: Build-Depends e2fslibs-dev (>= 1.38-2ubuntu2) [05:32] ext2 does a very good job of avoiding fragmentation... but some people really want things to be perfect ;) [05:32] too slow [05:32] plus it can be handy to pack all the files you need at boot in sequence at the start of the disk [05:32] speed up boots [05:32] psusi: have one for my jfs filesystems ? [05:32] well, Yagisan's is correct === womble [n=mpalmer@eth359.nsw.adsl.internode.on.net] has joined #ubuntu-motu [05:33] I thought I read somewhere that jfs has an online defragger? or maybe that was xfs? I dunno [05:33] unfortunately, reiserfs does not have one... [05:33] but again, it isn't _really_ needed [05:34] I used the frag checker in the defrag package to see what kind of fragmentation I have on reiserfs... there's some, but not much [05:34] psusi: It was just idle curiosity. I don't let my drives get full enough to worry about fragmentation myself [05:34] it's nice to know though... and I also want to try packing all the files that readahead-list precaches at the start of the disk, so it can read them in faster... right now it only gets about 1/4 of my disk's maximum sustained throuhput [05:34] psusi: will it eat data ? what if was run on ext3 ? [05:35] well, right now it refuses to run on ext3... but you can tune2fs it back to ext2... I think I'm also going to reverse the dpatch that makes it refuse to work on ext3 [05:35] since as long as it is cleanly unmounted, there's no reason not to [05:35] as for eating data... not sure if the power goes out... but otherwise... no [05:35] but I have a UPS anyhow :) [05:36] psusi: so the filesystem needs to be unmounted ? that may make it interesting to defrag / then [05:38] oh absolutely [05:38] you could use a live cd [05:38] there's two ways to defrag the root fs... 1) from a livecd or something and 2) build a custom initramfs with the defragger built into it ;) [05:38] psusi: frag checker work on any filesystem ? [05:38] yea... the frag checker works on any filesystem.. it is done online by using the GETBLKS ioctl [05:39] psusi: thought I'd ask, as most pepole tend to have just 2 partitions, / and swap, so you'll need to document it for the users [05:39] psusi: could you make a boot entry for it, like memtest86 ? [05:40] Yagisan, sure === Yagisan can't spell today [05:40] have a boot entry for "Defrag" [05:40] psusi: does it quit if run on a non ext2/ext3 partition ? === joe_alf [n=joe_alf@n219077165128.netvigator.com] has joined #ubuntu-motu [05:42] psusi: and is it on revu - I'd like to run frag-checker over my large filesystems [05:43] Yagisan, the frag checker runs on any fs... defrag will only run on a cleanly unmounted ext2 fs [05:43] actually, I think it also supports ext ( 1 ) and minix... but who the hell still uses those? ;) [05:44] no... it's an existing package in universe... I just fixed it to build on amd64 [05:44] it was i386 only [05:44] psusi: I have amd64 ... [05:44] psusi: would you like to check an amd64 package on revu for me :) [05:45] hrm... someone said that was only for brand new packages? [05:45] but hell... why not? [05:45] psusi: details details - I send stuff there for peer revu [05:45] I tried that the other day and clobbered things up ;) [05:47] let me just make sure it compiles ok ;) [05:47] then the hard part is getting the new version of the e2fsprogs into pbuilder so it can build defrag [05:48] psusi: was it really required to adjust fsprogs ? [05:48] psusi: I find having my own repo on the pbuilder sources list helps getting things in :) [05:49] s/fsprogs/e2fsprogs [05:49] yes... e2fsprogs had a header file that redefined 64 bit data types differently than asm/types.h does on amd64, so the compiler puked when both headers were used === freeflying [n=freeflyi@61.190.65.9] has joined #ubuntu-motu [05:50] heh... I just copied the new .deb to /var/cache/pbuilder/aptcache, then did a pbuilder login --save-after-login and installed the new version with dpkg -i by hand from /var/cache/apt/archives [05:50] hrm... I don't think I did this right [05:50] previously, defrag's control file listed i386 as the binary target platform [05:50] I changed this to all... only it generated a _all .deb... [05:51] psusi: e2fsprogs, that's a main app right ? [05:51] what should it be to mean "builds on any platform"? [05:51] Yagisan, yea [05:51] psusi: you need any not all [05:51] ahhh ;) [05:51] psusi: but does it really work on ppc etc ? [05:52] psusi: is main ok with the fixed e2fsprogs ? [05:52] hell if I know, I got it working on amd64 ;) [05:52] no idea... they don't know about it yet [05:52] and it doesn't have an official maintainer with ubuntu either [05:53] psusi: I'd try to get them to ok it, before uploading the new defrag. [05:53] sweet... the new defrag package is installed [05:54] Yagisan, I am not authorized to upload to anywhere but revu ;) [05:54] ok... now I guess I can put them there for you to take a look at [05:54] let's see... how did you do that again? [05:54] psusi: dput [05:55] also, e2fsprogs did not build from source... there were some problems with texi2html converting the docs... [05:55] I don't know jack about texi, so I just fixed the makefile to ignore errors trying to install the html docs [05:55] not good [05:55] I don't know how we have working binaries in the repository when it fails to build from source [05:58] ok... they are uploaded [05:58] simple, it was built with an older version of texi2html [06:00] then the package should build-depend on the older version ;) [06:00] hehe [06:01] I hope you weren't entirely serious there :) [06:03] G'day ajmitch [06:04] ajmitch - is it ok to just bare diff out something, or should I use a patch management system ? === LaserJock [n=mantha@ppp-69-229-206-28.dsl.renocs.pacbell.net] has joined #ubuntu-motu [06:06] Yagisan: it is acceptable [06:06] if you're meaning to just make the changes in the source tree [06:07] using a patch management system is nice for when you want to merge the patches upstream [06:07] it's also handy for things like this: [06:08] ajmitch: Upstream was smoking crack when they did their configure cflags - and as it is trivial, I was wondering is it really worth the effort [06:08] the defrag package had a patch applied once that makes it refuse to manipulate ext3... it looks like the idea was that they were planning some sort of special support for ext3 [06:08] but it never got done... I see no reason why it shouldn't be allowed to work on ext3 [06:08] so I just dpatch deapply it [06:09] Yagisan, in that case, if upstream still smokes crack next release, having a patch management system will make reapplying that change easier [06:11] psusi: you mean that delete ;) [06:12] Yagisan, you download those packages yet? [06:13] psusi: not yet - giving my pbuilder a workout atm [06:14] hehe [06:15] psusi: downloading now. Would you mind checking out http://revu.tauware.de/details.py?upid=1399 [06:16] k, dpatch now added to x264 - time to upload to revu [06:18] ahh, you're cross compiling 32bit binaries on amd64? [06:18] psusi: is defrag supposed to be a native package ? e2fsprogs has no orig.tar.gz [06:18] Yagisan, hrm... I have a .orig.tar.gz here... it didn't get uploaded? [06:19] maybe I built it wrong? I did debuild -S [06:19] psusi: Gave up cross-compiling - it fail to often. I "repack" i386 debs, and make them depend on the support libs in that package [06:19] psusi: -sa -S [06:19] what's the -sa do? [06:19] includes orig.tar.gz [06:19] psusi: makes sure you always get the orig [06:19] I'm really slow today [06:20] Yagisan, good idea... I've been wondering actually WTF someone hasn't done something like that yet... would help a lot of people trying to get things like flash working, where only 32bit binaries are availible === Mez [n=Mez@ubuntu/member/mez] has joined #ubuntu-motu [06:20] ok... rebuilding and reuploading === Yagisan waves at psusi "I've been doing it - look at me - look at me" [06:21] hehe... very cool ;) [06:21] psusi: check out zsnes on revu - it needs the ia32libs-universe package [06:22] ok... .orig.gz has been uploaded [06:22] zsnes is only availible from upstream in binary form? [06:22] psusi: nope [06:22] then why not rebuild it for amd64? [06:23] psusi: I uuencoded the i386 deb, because diff hates binaries. zsnes is mostly i386 asm [06:23] rofl... a diff on a uuencode is equally useless ;) [06:23] if you want binary diffs, use xdiff I think it was [06:24] psusi: I can't binary diff, dpkg son't like it [06:24] don't [06:24] ohh, mostly written in asm? I see [06:24] why are you mucking with diffs at all? [06:25] psusi: because I don't want to repack the orig [06:25] don't build a source package... just build a binary release package [06:25] don't put the orig in... just repackage the binaries [06:25] like there was no source [06:25] psusi: I need a source, or ubuntu won't install it. period. [06:26] psusi: hence, the large diff [06:26] psusi: Is defrag really a native package ?? [06:28] what do you mean it won't install it? you can build binary only packages... like how they do packages for win32codecs [06:28] yea... I got the source and fixed the bugs that kept it from building on amd64 [06:28] psusi: win32codecs no longer exists. anyway look at the source [06:29] psusi: I think defrag should have a .orig, and a .diff === bpuccio [n=brian@ool-457a9c38.dyn.optonline.net] has joined #ubuntu-motu [06:30] psusi: wow - have you checked out lintian on defrag [06:30] Yagisan, it does [06:30] what is lintian? [06:30] it's definitely not native according to http://packages.qa.debian.org/d/defrag.html [06:30] crimsun, what do you mean? [06:30] psusi: I mean that defrag as I see it requires an orig.tar.gz+diff.gz [06:31] Yagisan, I don't think you should respackage the way you are and include the original source... repackaged 32bit binaries for amd64 should be binary only packages [06:32] ohh... I thought native meant actually a 64 bit binary, not a 32 bit binary repackaged for amd64 [06:32] psusi: can't do that. I need the source that genrated the i386 version. [06:32] no... it was an existing package in universe, and I just fixed it to build on amd64 [06:32] it previously only wason i386 [06:32] Yagisan, what for? [06:32] it can be found in the source package [06:32] psusi: you made a mistake when doing dpkg-source -b it cant find the orig.tar.gz for defrag [06:33] I never did a dpkg-source -b... I just did a debuild -S -sa [06:33] and it said it uploaded the orig.tar.gz [06:33] the second time I did the dput [06:34] Uploading via ftp e2fsprogs_1.38.orig.tar.gz: done. [06:34] I think I confused revu again [06:34] oh, I know why revu blows up trying to perform a passwd recovery. [06:34] it's the same reason LP blows up. [06:34] what do you mean it blows up? [06:34] it fails to do anything usefl [06:34] I used the password recovery the other day [06:35] gah, can't spell. [06:35] though it was kind of difficult [06:35] my key is sign-only, therefore passwd recovery obviously won't work. [06:35] ohh... why is it sign only? [06:35] psusi: My zsnes repackage is fully compatible with both the gpl and with standard policy of incluing the source a package was built from, even if that source FTBFS on a particular arch [06:35] because the subkey portion that matters was revoked [06:36] Yagisan, the source is not included in the binary package [06:36] there is already a source package... you are just taking the existing i386 binary package and relabeling it for amd64 [06:36] the binary packages don't contain the source [06:37] psusi: please please look at the source closely - I make both i386 and amd64 from it. amd64 requires i386 to already be built [06:38] psusi: it's not a new package, its an update of the existing one [06:38] why are you making a source package at all? you shouldn't need to compile anything.. .it's already been compiled in the i386 binary packages [06:38] all you're doing is changing the platform label so you don't have to dpkg --force-arch to install it, aren't you? [06:38] psusi: if you apt-get source zsnes on amd64 and you don't get source, I'd file a RC bug on it [06:39] psusi: no, I do a bit more then that - please look at the source [06:39] Yagisan, you would get source... the same source you get when you apt-get source from i386 [06:39] hrm... [06:40] Yagisan, it looks to me like you have made a source package that contains all these other source packages [06:41] it seems to me what you should be doing is modifying the original source packages so they have a new binary target for amd64, which is just a copy of the i386 binaries [06:41] then when you build the original source package... you get two binary debs... one for i386, and one for amd64 [06:42] psusi: which package are you looking at ? ia32libs-universe or zsnes ? [06:42] ia32libs-universe [06:44] psusi: ia32libs-universe requires the libs to be extracted to /lib32. have a look at this http://revu.tauware.de/details.py?upid=1335 to see how an app would use it [06:46] right... normally the source packages are set to (look/install) in /lib... so when they are built for i386, /lib links to /lib32 [06:46] when they are build for amd64, /lib links to /lib64 [06:47] but since you want 32bit-on64bit, you need to build the binaries for /lib32 explicitly [06:48] you are creating an entirely new source package with one binary target: amd64... and you modified the original source to refer to /lib32 [06:48] psusi: no, I stick them in /lib32 and tell ldcache I have 32bit libs there. easy [06:48] what I am sugesting is instead, to modify the original source package to have a new build target that changes the build rules to refer to /lib32 [06:49] psusi: not going to happen. /lib32 does not exist on i386, where the package is built [06:49] right... the normal i386 binary target would not change [06:49] only when building for the amd64-32 target would /lib32 be used [06:51] see what I'm saying? [06:58] did I scare you away? ;) [06:58] brb - kid is puking [06:59] eww.... that sucks.... hope he's ok.... and doesn't make too much messs [07:15] it looks like you can give debdiff either the .dsc or the .changes files... which is better? [07:15] I don't know, but I usually use .dsc [07:16] works for me [07:16] shouldn't matter should it? [07:17] it doesn't matter. [07:19] now... the question is...what do I do with my shiny new packages? [07:19] how do I get them to someone who can upload to the repository after review? [07:21] you can upload to REVU, correcT? [07:21] if they're main packages (I presume so from the semantics), file bugs in bugzilla [07:21] re [07:22] psusi: It's a she, and yes, she made quite a mess - banana as far as the eye could see :( [07:22] Yagisan: ouch [07:22] Yagisan: good luck cleaning up :) [07:23] ajmitch: thanks - I'll need it. I wish I didn't have carpet right now === zakame [n=zak@ubuntu/member/zakame] has joined #ubuntu-motu [07:25] psusi: I fixed your defrag package so it is non-native - want me to dcc it to you ? [07:25] afternoon everybody :) [07:26] afternoon zakame [07:26] Yagisan, outch indeed... how about you tell me how to fix it... teach a man to fish and all ;) [07:26] crimsun, aren't we supposed to be using malone now not bugzilla? [07:26] crimsun, and what files do I need to attach to the bug? === paulproteus|lapt [n=paulprot@cpe-72-226-199-134.rochester.res.rr.com] has joined #ubuntu-motu [07:27] psusi: sure. dpkg-source -x defrag_0.73pjm1-7ubuntu1.dsc [07:27] psusi: I still use bugzilla for main; attach debdiffs [07:27] psusi: mv defrag_0.73pjm1-7ubuntu1.dsc defrag_0.73pjm1-7ubuntu1.dsc.old [07:27] psusi: apt-get source defrag (in i386 chroot) [07:28] psusi: dpkg-source -b defrag-0.73pjm1 [07:28] psusi: all done [07:28] crimsun, but the debdiffs can't be verified... they aren't signed it looks like [07:28] psusi: we read the debdiffs before applying them [07:29] Yagisan, yea... but if you apply them, then it's like you made the change... my signature isn't on it... wouldn't it be better if you had the new signed package, and could debdiff it yourself to see what changed? [07:30] no, it's easier to see the debdiff [07:30] Yagisan, why apt-get source defrag again? that's how I started... still have the orig.tar.gz [07:30] and doesn't dpkg-source -b build a binary package? [07:30] psusi: I *didn't* have the source [07:30] I wouldn't dare ask Martin to generate a debdiff himself for security-review [07:30] crimsun: I did :) but I can get away with it [07:31] Yagisan, yea... for some reason if you upload a package to revu without the source, even if you upload it again ( you had me debuild -S -sa the second time ) it won't show it [07:31] just like Martin wouldn't make Matt generate a debdiff himself [07:31] crimsun: I gave him a 3 months heads up in a sec issue [07:32] or `dpkg-source -x defrag_0.73-pjm1-7ubuntu1.dsc; cd defrag-0.73-pjm1 && pdebuild` would do, assuming you've set up pbuilder correctly ;) [07:32] if I did a debuild -S -sa from inside the modified source tree, everything should be fine right? [07:32] psusi: revu only updates every x minutes. maybe you need to wait [07:32] Yagisan: sure, I'm aware there are extenuating circumstances [07:32] Yagisan, it updated... shows the second upload... it's just confused and won't show the .orig.tar.gz... [07:34] crimsun: yep - like me stuck with dialup and unable to do it myself in a reasonable timeframe [07:34] my .changes file shows that I changed the package, and signed off on it... I'm concerend that information will be lost if I only upload a debdiff [07:34] psusi: the debian/changelog should have your name on it ;) [07:35] zakame, it does... but it doesn't have my signature on it so how do you know I really changed it? ;) [07:35] psusi: it won't matter at all [07:35] psusi: someone else has to sign it before it goes in the archive anyway [07:36] ahhh..... hrm.... well, ok.... [07:36] since you're not in the trusted keyring for uploads [07:37] psusi: at least not until you're approved by TB to be included in the keyring [07:37] ajmitch, right... which is why someone else needs to sign it too... just figured my signature should be on there somewhere as well ;) [07:38] why? [07:38] we have to review anything that's on revu :) [07:38] now... hopefully someone who understands texi will fix the texi2html breakage in e2fsprogs and re-enable the disabled docs install step of the makefile [07:38] since it's a fairly open upload policy [07:39] cause I sure as hell have no idea how to fix it... so I just disabled it so the package builds [07:40] is there someone around who can nuke the borked packages I uploaded to revu so I can do it again right? [07:41] yes [07:41] what package? [07:42] ajmitch: could you revu http://revu.tauware.de/details.py?upid=1429 [07:42] ? [07:42] Yagisan: depends on how much I get paid [07:43] ajmitch: you get a warm fuzzy feeling for helping the motumedia team [07:43] Yagisan: what an odd version number [07:44] Yagisan: you could also double is current MOTU pay ;-) [07:44] ajmitch: thanks - I took upstreams, and added ~ubuntu1 to it [07:44] Yagisan: why did you use ~ubuntu1 ? [07:44] ajmitch: I've been trying to "fix" it [07:44] since that should be lower than 0.0 alone [07:45] ajmitch, all that I have on there... [07:45] psusi: not very helpful.. [07:45] I don't see anything of yours in incoming, so what is there to nuke? [07:45] ajmitch, all packages by Phillip Susi... or... defrag and e2fsprogs... and... [07:46] psusi: can't you just upload a new version? [07:46] udftools [07:46]