[12:05] <Amaranth> iirc the original xorg (hoary) is the one in sid
[12:06] <tseng> sid just got 6.9, actually
[12:29] <keyes> plop
[12:29] <keyes> siretart: hello !
[12:31] <Amaranth> i seem to remember them saying they were going to wait for 7.0 :P
[12:31] <Amaranth> as they wanted the modular release
[01:19] <cyberix> How are ui translations synchronised between launchpad, Grumpy and the original project?
[01:30] <psusi> after doing a debuild in a source tree, how do you clean it back up?
[01:30] <crimsun> debuild clean
[01:30] <thierry_> sudo debuild -S -sa does it for me
[01:30] <thierry_> do what crimsun says, he's better than me :)
[01:30] <crimsun> -S will clean it, too
[01:31] <psusi> ahhh...
[01:31] <crimsun> thierry_: s/better//g
[01:32] <psusi> 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] <minghua> dpatch-edit-patch?
[01:32] <psusi> doh ;)
[01:33] <minghua> yeah, the name is not that intuitive, but you create new text file with your text editor, don't you? ;-)
[01:36] <psusi> hrm... seems to want you to make changes after you run it... I already made the changes ;)
[01:37] <minghua> psusi: yes.  probably you can start from a new tree, than copy your modifiled filed into the chroot
[01:38] <minghua> (or apply the patch inside the chroot if you have one patch already)
[01:38] <psusi> this is kind of annoying.... why's it need a temp area?  instead of just extracting the .orig.tar.gz and diffing?
[01:39] <minghua> because sometimes one patch depends on another, so you can't always start from .orig.tar.gz
[01:40] <psusi> 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] <minghua> 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] <minghua> ?
[01:43] <minghua> and nothing prevents people from using dpatch AND direct modifying the source (which will end up in .diff.gz) anyway
[01:44] <psusi> well yea, but if it's already using dpatch you want to continue to use it don't you?
[01:44] <crimsun> for easier maintenance, yes
[01:45] <minghua> from MOTU point of view, yes, as we want to be as close as possible on packaging with Debian
[01:45] <crimsun> like minghua said, though, there are only "best practices"
[01:45] <psusi> jesus... it picked up all the other patches as well.. I guess I was supposed to dpatch disable-all before exiting
[01:46] <psusi> or maybe dpatch enable-all before dpatch-edit-patch?
[01:58] <crimsun> It would be great if http://tiber.tauware.de/~lucas/versions/unimultiverse.html#outdatedinB  ignored syncable versions
[01:58] <crimsun> 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] <crimsun> whereas amule is 2.1.0-1 in Sid and 2.0.3-3ubuntu2 can't be ignored
[01:59] <crimsun> (ok yeah, poor grammar aside)
[02:05] <StevenK> BLAH. It's so hard to find out what changed in Debian revisions with packages.d.o down.
[02:07] <crimsun> StevenK: I end up keeping packages.qa.debian.org/x/xoo.html open
[02:12] <StevenK> 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] <StevenK> saens is overloaded.
[02:14] <Amaranth> ugh, no one ever talk to marcin on gimpnet
[02:15] <marcin`> ;P
[02:18] <\sh> StevenK: for debian or for ubuntu?
[02:18] <psusi> 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] <psusi> 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] <StevenK> \sh: Ubuntu
[02:20] <psusi> 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] <psusi> but how can you tell pbuilder login to not clean up?
[02:20] <\sh> (dapper)
[02:21] <StevenK> \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] <psusi> is /var/cache/pbuilder/result mounted inside the chroot?
[02:24] <\sh> well..I don't use it...I use the pbuilder-<dist> example commands to build everything in my home dir :)
[02:27] <StevenK> 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] <psusi> 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?
[02:33] <crimsun> former
[02:33] <crimsun> just looking at its depends
[02:47] <hub> wow.
[02:47] <hub> I have traceroute6 but not traceroute
[02:50] <ajmitch> hm, I see zope 2.9 now required python >= 2.4.2
[02:51] <ajmitch> compared to 2.8 requiring >= 2.3.3
[02:51] <ajmitch> 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] <ajmitch> hey \sh
[02:54] <hub> \sh: it does. it is in main as separate package
[02:54] <hub> that
[02:54] <hub> was
[02:54] <hub> wan not installed
[02:55] <\sh> hub: bsd traceroute ?
[02:55] <hub> \sh: yeah
[02:55] <ajmitch> hello hub
[02:55] <\sh> hub: but linux distros changed a long time ago from traceroute to tracepath
[02:55] <hub> ii  traceroute            1.4a12-20             traces the route taken by packets over a TCP/IP network
[02:55] <hub> \sh: old habits die hard
[02:55] <\sh> well...I don't like it (tracepath)
[02:55] <\sh> hub: that is right :)
[02:55] <hub> 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] <ajmitch> \sh: people don't read bugreports
[02:57] <\sh> ajmitch: devels should do
[02:57] <ajmitch> doesn't mean they do
[02:57] <ajmitch> 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> <rant />
[03:02] <\sh> more to read on http://gna.org/bugs/?func=detailitem&item_id=4992
[03:02] <\sh> grmp
[03:02] <\sh> f
[03:18] <psusi> \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 :)
[03:19] <psusi> 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] <psusi> wait... nevermind.
[03:19] <psusi> wait a second
[03:20] <psusi> it isn't legal to add or subtract two pointers iirc
[03:20] <psusi> only add/subtract integers to them, which has much the same effect as [] 
[03:20] <psusi> now you've done it... now I'm confused
[03:27] <psusi> 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] <psusi> install: cannot stat `/tmp/buildd/e2fsprogs-1.38/debian/BUILD-STD/doc/libext2fs_*.html': No such file or directory
[03:28] <psusi> \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] <psusi> 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] <psusi> 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] <psusi> 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] <psusi> 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] <psusi> \sh, exactly
[03:40] <psusi> 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] <psusi> night
[05:12] <psusi> what is a udeb?
[05:14] <Yagisan> psusi: it's used for the installer
[05:14] <Yagisan> psusi: it's a micro deb package for d-i
[05:15] <psusi> hrm... what's it do?  I thought the installer just installed all the .debs
[05:16] <minghua> no, d-i usually only install .udebs
[05:17] <Yagisan> psusi: the installer needs them for it's runtime environment IIRC
[05:17] <minghua> yeah, what Yagisan said
[05:18] <minghua> (only install .udebs) for its own functioning
[05:18] <Yagisan> G'day minghua - how are you today ?
[05:18] <minghua> Yagisan: hello, I am good, what about you?
[05:19] <Yagisan> 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] <minghua> Yagisan: glad to hear that
[05:20] <psusi> I still don't understand how the .udeb differs from the normal .deb for a given package
[05:20] <psusi> and why both are needed
[05:21] <Yagisan> psusi: .debs need a fully installed environment to work - they are also rather large
[05:21] <Yagisan> psusi: udebs, are rather slimmed down, contain only bare functionality needed, and can run from the d-i minimal environment
[05:22] <Yagisan> psusi: udebs are only ever used by the installer - hence eg no wesnoth udeb
[05:22] <psusi> so what kind of things are stripped out from the normal deb to thin them down?
[05:24] <minghua> documentations and man pages, for exapmle
[05:24] <Yagisan> psusi: check the source for the particular package you are interested in, but basically it's whatever is not essential
[05:25] <psusi> wait... are the udebs used to build the setup cd, or they are what the installer installs to your hd?
[05:26] <minghua> no, .udebs are never installed on harddrive
[05:26] <Yagisan> psusi: setup cd == installer cd
[05:26] <psusi> right... so the setup cd is itself built using the udebs... because it doesn't need docs
[05:26] <Yagisan> psusi: the installer runs from the udebs, and installs normal debs to your system
[05:26] <psusi> but when you go and install, it installs all the .debs and you get the docs on your hd, right?
[05:26] <psusi> ok... yea... I get it now...
[05:27] <Yagisan> :)
[05:27] <psusi> ;)
[05:27] <Yagisan> anyone have a link to the dpatch for dummies page ?
[05:28] <hub> I prefer patchsys
[05:28] <hub> in cdbs
[05:28] <hub> less crack
[05:28] <psusi> Yagisan, I've been figuring that out all day ;)
[05:28] <Yagisan> I just want something simple to strip out crack in an upstream configure file
[05:29] <Yagisan> they have cflags that don't exist in it ?!?
[05:29] <psusi> 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] <Yagisan> I could just diff it out, but then it would be a pain to revu
[05:30] <Yagisan> psusi: defrag ???
[05:30] <psusi> Yagisan, yea...
[05:31] <Yagisan> psusi: we actually need a defrag ?? for a non fat or ntfs based filesystem ?
[05:31] <psusi> 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] <psusi> Yagisan, need is a relative term...
[05:31] <crimsun> in defrag's debian/control:Build-Depends, you'd have e2fsprogs-dev (>= 1.38-2ubuntu2)
[05:32] <Yagisan> psusi: Build-Depends e2fslibs-dev (>= 1.38-2ubuntu2)
[05:32] <psusi> ext2 does a very good job of avoiding fragmentation... but some people really want things to be perfect ;)
[05:32] <Yagisan> too slow
[05:32] <psusi> plus it can be handy to pack all the files you need at boot in sequence at the start of the disk
[05:32] <psusi> speed up boots
[05:32] <Yagisan> psusi: have one for my jfs filesystems ?
[05:32] <crimsun> well, Yagisan's is correct
[05:33] <psusi> I thought I read somewhere that jfs has an online defragger?  or maybe that was xfs?  I dunno
[05:33] <psusi> unfortunately, reiserfs does not have one...
[05:33] <psusi> but again, it isn't _really_ needed
[05:34] <psusi> 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] <Yagisan> psusi: It was just idle curiosity. I don't let my drives get full enough to worry about fragmentation myself
[05:34] <psusi> 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] <Yagisan> psusi: will it eat data ? what if was run on ext3 ?
[05:35] <psusi> 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] <psusi> since as long as it is cleanly unmounted, there's no reason not to
[05:35] <psusi> as for eating data... not sure if the power goes out... but otherwise... no
[05:35] <psusi> but I have a UPS anyhow :)
[05:36] <Yagisan> psusi: so the filesystem needs to be unmounted ? that may make it interesting to defrag / then
[05:38] <psusi> oh absolutely
[05:38] <crimsun> you could use a live cd
[05:38] <psusi> 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] <Yagisan> psusi: frag checker work on any filesystem ?
[05:38] <psusi> yea... the frag checker works on any filesystem.. it is done online by using the GETBLKS ioctl
[05:39] <Yagisan> 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] <Yagisan> psusi: could you make a boot entry for it, like memtest86 ?
[05:40] <psusi> Yagisan, sure
[05:40] <psusi> have a boot entry for "Defrag"
[05:40] <Yagisan> psusi: does it quit if run on a non ext2/ext3 partition ?
[05:42] <Yagisan> psusi: and is it on revu - I'd like to run frag-checker over my large filesystems
[05:43] <psusi> Yagisan, the frag checker runs on any fs... defrag will only run on a cleanly unmounted ext2 fs
[05:43] <psusi> actually, I think it also supports ext ( 1 ) and minix... but who the hell still uses those? ;)
[05:44] <psusi> no... it's an existing package in universe... I just fixed it to build on amd64
[05:44] <psusi> it was i386 only
[05:44] <Yagisan> psusi: I have amd64 ...
[05:44] <Yagisan> psusi: would you like to check an amd64 package on revu for me :)
[05:45] <psusi> hrm... someone said that was only for brand new packages?
[05:45] <psusi> but hell... why not?
[05:45] <Yagisan> psusi: details details - I send stuff there for peer revu
[05:45] <psusi> I tried that the other day and clobbered things up ;)
[05:47] <psusi> let me just make sure it compiles ok ;)
[05:47] <psusi> then the hard part is getting the new version of the e2fsprogs into pbuilder so it can build defrag
[05:48] <Yagisan> psusi: was it really required to adjust fsprogs ?
[05:48] <Yagisan> psusi: I find having my own repo on the pbuilder sources list helps getting things in :)
[05:49] <Yagisan> s/fsprogs/e2fsprogs
[05:49] <psusi> 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
[05:50] <psusi> 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] <psusi> hrm... I don't think I did this right
[05:50] <psusi> previously, defrag's control file listed i386 as the binary target platform
[05:50] <psusi> I changed this to all... only it generated a _all .deb...
[05:51] <Yagisan> psusi: e2fsprogs, that's a main app right ?
[05:51] <psusi> what should it be to mean "builds on any platform"?
[05:51] <psusi> Yagisan, yea
[05:51] <Yagisan> psusi: you need any not all
[05:51] <psusi> ahhh ;)
[05:51] <Yagisan> psusi: but does it really work on ppc etc ?
[05:52] <Yagisan> psusi: is main ok with the fixed e2fsprogs ?
[05:52] <psusi> hell if I know, I got it working on amd64 ;)
[05:52] <psusi> no idea... they don't know about it yet
[05:52] <psusi> and it doesn't have an official maintainer with ubuntu either
[05:53] <Yagisan> psusi: I'd try to get them to ok it, before uploading the new defrag.
[05:53] <psusi> sweet... the new defrag package is installed
[05:54] <psusi> Yagisan, I am not authorized to upload to anywhere but revu ;)
[05:54] <psusi> ok... now I guess I can put them there for you to take a look at
[05:54] <psusi> let's see... how did you do that again?
[05:54] <Yagisan> psusi: dput
[05:55] <psusi> also, e2fsprogs did not build from source... there were some problems with texi2html converting the docs...
[05:55] <psusi> I don't know jack about texi, so I just fixed the makefile to ignore errors trying to install the html docs
[05:55] <Yagisan> not good
[05:55] <psusi> I don't know how we have working binaries in the repository when it fails to build from source
[05:58] <psusi> ok... they are uploaded
[05:58] <ajmitch> simple, it was built with an older version of texi2html
[06:00] <psusi> then the package should build-depend on the older version ;)
[06:00] <psusi> hehe
[06:01] <ajmitch> I hope you weren't entirely serious there :)
[06:03] <Yagisan> G'day ajmitch
[06:04] <Yagisan> ajmitch - is it ok to just bare diff out something, or should I use a patch management system ?
[06:06] <ajmitch> Yagisan: it is acceptable
[06:06] <ajmitch> if you're meaning to just make the changes in the source tree
[06:07] <psusi> using a patch management system is nice for when you want to merge the patches upstream
[06:07] <psusi> it's also handy for things like this:
[06:08] <Yagisan> 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] <psusi> 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] <psusi> but it never got done... I see no reason why it shouldn't be allowed to work on ext3
[06:08] <psusi> so I just dpatch deapply it
[06:09] <psusi> Yagisan, in that case, if upstream still smokes crack next release, having a patch management system will make reapplying that change easier
[06:11] <Yagisan> psusi: you mean that delete ;)
[06:12] <psusi> Yagisan, you download those packages yet?
[06:13] <Yagisan> psusi: not yet - giving my pbuilder a workout atm
[06:14] <psusi> hehe
[06:15] <Yagisan> psusi: downloading now. Would you mind checking out http://revu.tauware.de/details.py?upid=1399
[06:16] <Yagisan> k, dpatch now added to x264 - time to upload to revu
[06:18] <psusi> ahh, you're cross compiling 32bit binaries on amd64?
[06:18] <Yagisan> psusi: is defrag supposed to be a native package ? e2fsprogs has no orig.tar.gz
[06:18] <psusi> Yagisan, hrm... I have a .orig.tar.gz here... it didn't get uploaded?
[06:19] <psusi> maybe I built it wrong?  I did debuild -S
[06:19] <Yagisan> 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] <Yagisan> psusi: -sa -S
[06:19] <psusi> what's the -sa do?
[06:19] <ajmitch> includes orig.tar.gz
[06:19] <Yagisan> psusi: makes sure you always get the orig
[06:19] <Yagisan> I'm really slow today
[06:20] <psusi> 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
[06:20] <psusi> ok... rebuilding and reuploading
[06:21] <psusi> hehe... very cool ;)
[06:21] <Yagisan> psusi: check out zsnes on revu - it needs the ia32libs-universe package
[06:22] <psusi> ok... .orig.gz has been uploaded
[06:22] <psusi> zsnes is only availible from upstream in binary form?
[06:22] <Yagisan> psusi: nope
[06:22] <psusi> then why not rebuild it for amd64?
[06:23] <Yagisan> psusi: I uuencoded the i386 deb, because diff hates binaries. zsnes is mostly i386 asm
[06:23] <psusi> rofl... a diff on a uuencode is equally useless ;)
[06:23] <psusi> if you want binary diffs, use xdiff I think it was
[06:24] <Yagisan> psusi: I can't binary diff, dpkg son't like it
[06:24] <Yagisan> don't
[06:24] <psusi> ohh, mostly written in asm?  I see
[06:24] <psusi> why are you mucking with diffs at all?
[06:25] <Yagisan> psusi: because I don't want to repack the orig
[06:25] <psusi> don't build a source package... just build a binary release package
[06:25] <psusi> don't put the orig in... just repackage the binaries
[06:25] <psusi> like there was no source
[06:25] <Yagisan> psusi: I need a source, or ubuntu won't install it. period.
[06:26] <Yagisan> psusi: hence, the large diff
[06:26] <Yagisan> psusi: Is defrag really a native package ??
[06:28] <psusi> what do you mean it won't install it?  you can build binary only packages... like how they do packages for win32codecs
[06:28] <psusi> yea... I got the source and fixed the bugs that kept it from building on amd64
[06:28] <Yagisan> psusi: win32codecs no longer exists. anyway look at the source
[06:29] <Yagisan> psusi: I think defrag should have a .orig, and a .diff
[06:30] <Yagisan> psusi: wow - have you checked out lintian on defrag
[06:30] <psusi> Yagisan, it does
[06:30] <psusi> what is lintian?
[06:30] <crimsun> it's definitely not native according to http://packages.qa.debian.org/d/defrag.html
[06:30] <psusi> crimsun, what do you mean?
[06:30] <crimsun> psusi: I mean that defrag as I see it requires an orig.tar.gz+diff.gz
[06:31] <psusi> 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] <psusi> ohh... I thought native meant actually a 64 bit binary, not a 32 bit binary repackaged for amd64
[06:32] <Yagisan> psusi: can't do that. I need the source that genrated the i386 version.
[06:32] <psusi> no... it was an existing package in universe, and I just fixed it to build on amd64
[06:32] <psusi> it previously only wason i386
[06:32] <psusi> Yagisan, what for?
[06:32] <psusi> it can be found in the source package
[06:32] <Yagisan> psusi: you made a mistake when doing dpkg-source -b it cant find the orig.tar.gz for defrag
[06:33] <psusi> I never did a dpkg-source -b... I just did a debuild -S -sa
[06:33] <psusi> and it said it uploaded the orig.tar.gz
[06:33] <psusi> the second time I did the dput
[06:34] <psusi> Uploading via ftp e2fsprogs_1.38.orig.tar.gz: done.
[06:34] <psusi> I think I confused revu again
[06:34] <crimsun> oh, I know why revu blows up trying to perform a passwd recovery.
[06:34] <crimsun> it's the same reason LP blows up.
[06:34] <psusi> what do you mean it blows up?
[06:34] <crimsun> it fails to do anything usefl
[06:34] <psusi> I used the password recovery the other day
[06:35] <crimsun> gah, can't spell.
[06:35] <psusi> though it was kind of difficult
[06:35] <crimsun> my key is sign-only, therefore passwd recovery obviously won't work.
[06:35] <psusi> ohh... why is it sign only?
[06:35] <Yagisan> 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] <crimsun> because the subkey portion that matters was revoked
[06:36] <psusi> Yagisan, the source is not included in the binary package
[06:36] <psusi> there is already a source package... you are just taking the existing i386 binary package and relabeling it for amd64
[06:36] <psusi> the binary packages don't contain the source
[06:37] <Yagisan> 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] <Yagisan> psusi: it's not a new package, its an update of the existing one
[06:38] <psusi> 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] <psusi> 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] <Yagisan> 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] <Yagisan> psusi: no, I do a bit more then that - please look at the source
[06:39] <psusi> Yagisan, you would get source... the same source you get when you apt-get source from i386
[06:39] <psusi> hrm...
[06:40] <psusi> Yagisan, it looks to me like you have made a source package that contains all these other source packages
[06:41] <psusi> 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] <psusi> then when you build the original source package... you get two binary debs... one for i386, and one for amd64
[06:42] <Yagisan> psusi: which package are you looking at ? ia32libs-universe or zsnes ?
[06:42] <psusi> ia32libs-universe
[06:44] <Yagisan> 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] <psusi> 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] <psusi> when they are build for amd64, /lib links to /lib64
[06:47] <psusi> but since you want 32bit-on64bit, you need to build the binaries for /lib32 explicitly
[06:48] <psusi> 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] <Yagisan> psusi: no, I stick them in /lib32 and tell ldcache I have 32bit libs there. easy
[06:48] <psusi> 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] <Yagisan> psusi: not going to happen. /lib32 does not exist on i386, where the package is built
[06:49] <psusi> right... the normal i386 binary target would not change
[06:49] <psusi> only when building for the amd64-32 target would /lib32 be used
[06:51] <psusi> see what I'm saying?
[06:58] <psusi> did I scare you away? ;)
[06:58] <Yagisan> brb - kid is puking
[06:59] <psusi> eww.... that sucks.... hope he's ok.... and doesn't make too much messs
[07:15] <psusi> it looks like you can give debdiff either the .dsc or the .changes files... which is better?
[07:15] <minghua> I don't know, but I usually use .dsc
[07:16] <psusi> works for me
[07:16] <LaserJock> shouldn't matter should it?
[07:17] <crimsun> it doesn't matter.
[07:19] <psusi> now... the question is...what do I do with my shiny new packages?
[07:19] <psusi> how do I get them to someone who can upload to the repository after review?
[07:21] <crimsun> you can upload to REVU, correcT?
[07:21] <crimsun> if they're main packages (I presume so from the semantics), file bugs in bugzilla
[07:21] <Yagisan> re
[07:22] <Yagisan> psusi: It's a she, and yes, she made quite a mess - banana as far as the eye could see :(
[07:22] <ajmitch> Yagisan: ouch
[07:22] <ajmitch> Yagisan: good luck cleaning up :)
[07:23] <Yagisan> ajmitch: thanks - I'll need it. I wish I didn't have carpet right now
[07:25] <Yagisan> psusi: I fixed your defrag package so it is non-native - want me to dcc it to you ?
[07:25] <zakame> afternoon everybody :)
[07:26] <Yagisan> afternoon zakame
[07:26] <psusi> Yagisan, outch indeed... how about you tell me how to fix it... teach a man to fish and all ;)
[07:26] <psusi> crimsun, aren't we supposed to be using malone now not bugzilla?
[07:26] <psusi> crimsun, and what files do I need to attach to the bug?
[07:27] <Yagisan> psusi: sure. dpkg-source -x defrag_0.73pjm1-7ubuntu1.dsc
[07:27] <crimsun> psusi: I still use bugzilla for main; attach debdiffs
[07:27] <Yagisan> psusi: mv defrag_0.73pjm1-7ubuntu1.dsc defrag_0.73pjm1-7ubuntu1.dsc.old
[07:27] <Yagisan> psusi: apt-get source defrag (in i386 chroot)
[07:28] <Yagisan> psusi: dpkg-source -b defrag-0.73pjm1
[07:28] <Yagisan> psusi: all done
[07:28] <psusi> crimsun, but the debdiffs can't be verified... they aren't signed it looks like
[07:28] <Yagisan> psusi: we read the debdiffs before applying them
[07:29] <psusi> 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] <crimsun> no, it's easier to see the debdiff
[07:30] <psusi> Yagisan, why apt-get source defrag again?  that's how I started... still have the orig.tar.gz
[07:30] <psusi> and doesn't dpkg-source -b build a binary package?
[07:30] <Yagisan> psusi: I *didn't* have the source
[07:30] <crimsun> I wouldn't dare ask Martin to generate a debdiff himself for security-review
[07:30] <Yagisan> crimsun: I did :) but I can get away with it
[07:31] <psusi> 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] <crimsun> just like Martin wouldn't make Matt generate a debdiff himself
[07:31] <Yagisan> crimsun: I gave him a 3 months heads up in a sec issue
[07:32] <zakame> 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] <psusi> if I did a debuild -S -sa from inside the modified source tree, everything should be fine right?
[07:32] <Yagisan> psusi: revu only updates every x minutes. maybe you need to wait
[07:32] <crimsun> Yagisan: sure, I'm aware there are extenuating circumstances
[07:32] <psusi> Yagisan, it updated... shows the second upload... it's just confused and won't show the .orig.tar.gz...
[07:34] <Yagisan> crimsun: yep - like me stuck with dialup and unable to do it myself in a reasonable timeframe
[07:34] <psusi> 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] <zakame> psusi: the debian/changelog should have your name on it ;)
[07:35] <psusi> zakame, it does... but it doesn't have my signature on it so how do you know I really changed it? ;)
[07:35] <ajmitch> psusi: it won't matter at all
[07:35] <ajmitch> psusi: someone else has to sign it before it goes in the archive anyway
[07:36] <psusi> ahhh..... hrm.... well, ok....
[07:36] <ajmitch> since you're not in the trusted keyring for uploads
[07:37] <zakame> psusi: at least not until you're approved by TB to be included in the keyring
[07:37] <psusi> 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] <ajmitch> why?
[07:38] <ajmitch> we have to review anything that's on revu :)
[07:38] <psusi> 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] <ajmitch> since it's a fairly open upload policy
[07:39] <psusi> cause I sure as hell have no idea how to fix it... so I just disabled it so the package builds
[07:40] <psusi> is there someone around who can nuke the borked packages I uploaded to revu so I can do it again right?
[07:41] <ajmitch> yes
[07:41] <ajmitch> what package?
[07:42] <Yagisan> ajmitch: could you revu http://revu.tauware.de/details.py?upid=1429
[07:42] <Yagisan> ?
[07:42] <ajmitch> Yagisan: depends on how much I get paid
[07:43] <Yagisan> ajmitch: you get a warm fuzzy feeling for helping the motumedia team
[07:43] <ajmitch> Yagisan: what an odd version number
[07:44] <LaserJock> Yagisan: you could also double is current MOTU pay ;-)
[07:44] <Yagisan> ajmitch: thanks - I took upstreams, and added ~ubuntu1 to it
[07:44] <ajmitch> Yagisan: why did you use ~ubuntu1 ?
[07:44] <Yagisan> ajmitch: I've been trying to "fix" it
[07:44] <ajmitch> since that should be lower than 0.0 alone
[07:45] <psusi> ajmitch, all that I have on there...
[07:45] <ajmitch> psusi: not very helpful..
[07:45] <ajmitch> I don't see anything of yours in incoming, so what is there to nuke?
[07:45] <psusi> ajmitch, all packages by Phillip Susi... or... defrag and e2fsprogs... and...
[07:46] <ajmitch> psusi: can't you just upload a new version?
[07:46] <psusi> udftools
[07:46] <Yagisan> ajmitch: he did - but the orig never showed up
[07:46] <psusi> ajmitch, I uploaded the first one without the .orig.tar.gz... that seems to have confused revu... forcing the upload again this time with the .orig.tar.gz still doesn't get it to show up
[07:47] <ajmitch> it was mentioned in the .dsc?
[07:47] <psusi> Yagisan, you get it to build?
[07:47] <ajmitch> & the .changes file?
[07:47] <psusi> ajmitch, yes... it's in the .dsc and .changes
[07:47] <psusi> and dput said it uploaded it
[07:47] <Yagisan> psusi: not yet - I have a large queue on my pbuilder
[07:47] <ajmitch> psusi: what package was this?
[07:48] <psusi> ajmitch, all 3... udftools, defrag, and e2fsprogs
[07:48] <Yagisan> ajmitch: e2fsprogs
[07:48] <ajmitch> and how long ago was this?
[07:48] <zakame> er aren't those main pkgs?
[07:48] <psusi> udftools was the other day... defrag and e2fsprogs were about an hour or two ago
[07:48] <ajmitch> e2fsprogs has orig.tar.gz there
[07:48] <psusi> e2fsprogs is main I believe... the other two are universe
[07:49] <psusi> ajmitch, http://revu.tauware.de/details.py?upid=1428 shows no .orig.tar.gz
[07:49] <psusi> wait
[07:49] <psusi> now it does
[07:49] <psusi> hrm...
[07:49] <ajmitch> revu doesn't process uploads instantly
[07:49] <psusi> Yagisan, does that still look broken to you?
[07:50] <psusi> ajmitch, I know... I gave it a few... and the second upload appeared at the bottom... but not the .orig.tar.gz
[07:50] <Yagisan> psusi: e2fsprogs looks ok now
[07:50] <psusi> cool!
[07:50] <ajmitch> defrag still looks like it has no orig.tar.gz
[07:51] <ajmitch> especially as the .dsc & .changes files haven't changed at all
[07:51] <psusi> defrag still has no .orig.tar.gz
[07:51] <psusi> heh ;)
[07:51] <ajmitch> so why did you ask me to fix it for you?
[07:51] <psusi> no... it is missing on revu... but it should be there
[07:52] <psusi> it's in my .changes and .dsc, and dput showed it uploaded
[07:53] <psusi> wait... nevermind.
[07:53] <Yagisan> ajmitch: I need to be a motu to review packages on revu don't I
[07:53] <ajmitch> Yagisan: at the moment, yes
[07:53] <psusi> it appears I have gremlins
[07:53] <Yagisan> ajmitch: thanks for confirming
[07:56] <psusi> ok... there we go
[07:56] <psusi> now if I screwed this up AGAIN, I'm taking my ball and bat and going home
[07:57] <Yagisan> psusi: I don't see your .orig for defrag
[07:57] <psusi> Yagisan, give it a few
[07:57] <Yagisan> psusi: you made it native again
[07:58] <ajmitch> Yagisan: no, that's the same old one as earlier
[07:58] <psusi> nope... debuild -S -sa just like the e2fsprogs... and the .orig.tar.gz is in the .dsc and .changes
[07:58] <ajmitch> at least from what I can see
[07:58] <psusi> just give revu a few to process it
[07:58] <psusi> Yagisan, now back to where we were earlier...
[07:58] <psusi> Yagisan, a source package can have several binary target packages... like e2fsprogs source package is used to build half a dozen binary packages
[07:59] <ajmitch> ah, it's there in incoming
[07:59] <zakame> gaah
[07:59] <Yagisan> psusi: I see, it's still in incoming
[07:59] <Yagisan> psusi: yes - but I will not create a new "arch" amd64-32 for something that is easier done by repacking
[08:00] <psusi> Yagisan, for 32bit on amd64, I propose adding a new binary target package that modifies the make rules to refer to /lib32... the new target would only build on amd64... but would actually use the i386 binaries
[08:00] <psusi> or rather... build i386 binaries
[08:00] <Yagisan> psusi: I did try something like that, but you *will* get header collision, and it *will not* find the /lib32 before /lib
[08:00] <psusi> Yagisan, repacking = adding new binary package target... e2fsprogs is compiled once... and bits and pieces of it are then packaged into a half dozen different binary packages
[08:01] <Yagisan> psusi: lets use zsnes as an example, because it's easy and self contained
[08:01] <psusi> Yagisan, actually... you would want to build the target as i386... then just make the package say it's for amd64
[08:02] <Yagisan> psusi: could you show me what you would do to the rules to get this to happen ?
[08:02] <psusi> and when the makefile sees it's buidling for the foo-32 target, replace /lib with /lib32
[08:02] <psusi> Yagisan, I'm not sure exactly... just got the general idea... the control file right now only specifies a single binary target that builds on only the i386 arch right?
[08:03] <Yagisan> psusi: I did try something similar, but it always tried to link to /lib rather then /lib32, and /lib was 64bit so it failed
[08:03] <psusi> Yagisan, right... you need to change the makefile so that it replaces /lib with /lib32
[08:04] <Yagisan> psusi: I called configure with a path with no /lib in it, onlt /lib32, but it still FTBFS
[08:04] <psusi> trying to build it on amd64?
[08:04] <Yagisan> psusi: yep
[08:04] <psusi> right... because it's going to try compiling a 64bit binary
[08:05] <psusi> you need to build it on i386
[08:05] <Yagisan> psusi: nope -m32 to build i386
[08:05] <psusi> ohh, yea... you told the ocmpiler to cross compile... ok... then you have dependency issues
[08:05] <psusi> would be easier I think to just build it on i386
[08:05] <psusi> and tell configure to use /lib32
[08:05] <Yagisan> psusi: If I change it to /lib32 for an i386 package, it has nothing to link too
[08:06] <psusi> then force the binary package to say it's amd64 arch
[08:06] <psusi> no no...
[08:06] <psusi> you have two different binary targets in the source package
[08:06] <psusi> one is the current one... znes
[08:06] <psusi> builds on i386 arch only
[08:07] <psusi> add a new one... znes-lib32... that also builds only on the i386 arch... but uses /lib32 and the built binary package gets forced to say it's for amd64
[08:07] <psusi> alternatively, you could actually get it to build on amd64 but you'd have to fix up all the build depends which could be a pain
[08:07] <psusi> and the cross compiling
[08:08] <Yagisan> psusi: I don't think that will work. Feel like giving it a try ?
[08:08] <psusi> possibly ;)
[08:09] <Yagisan> psusi: of course, when multi-arch is done, this is all moot anyway
[08:09] <psusi> what's multi-arch?
[08:09] <Yagisan> psusi: native running of eg i386 packages on amd64
[08:10] <psusi> I was thinking about a way to do that too... need to get the 32bit ld.so to do some slight of hand and fill requests for /lib with /lib32 instead
[08:11] <psusi> then get dpkg and apt and friends to understand that they can install an i386 binary package... but need to meet the depends with i386 packages
[08:12] <Yagisan> psusi: Mithrandir is the multi-arch god. I'm just doing the hack I need to get my apps going for dapper
[08:12] <psusi> and when dpkg actually installs an i386 package, needs to substitute /lib32
[08:12] <psusi> ohh, multi-arch isn't going in dapper?
[08:13] <Yagisan> psusi: no - it's a very big project. Debian was planning it before sarge, and it may end up being ready at etch + 1
[08:13] <psusi> ajmitch, hrm... the .orig.tar.gz still isn't there
[08:13] <psusi> Yagisan, wow
[09:54] <psusi> Yagisan, you build defrag yet? ;)
[09:57] <psusi> I think this is the most efficient defragmenter I've ever seen too
[09:57] <psusi> once you tell it you have more than 2 megs of ram for it to play with ;)
[09:58] <psusi> it goes nice and fast... uses very large block IO to minimize disk thrashing
[09:59] <psusi> now... to see if it made booting faster! bwahah!
[11:48] <lifeless> FWIW I've reuploaded opensync
[11:51] <ajmitch> thanks for doing that
[11:54] <lifeless> and armin has fixed the sources for HEAD to be LGPL everywhere
[11:54] <lifeless> well, for the two problem files
[11:54] <lifeless> theres about a dozen that have no (C) statement at akk
[11:54] <lifeless> *all*
[11:54] <ajmitch> I appreciate having the source in bzr
[11:56] <lifeless> ;)
[11:59] <ajmitch> it's not fair when I have to go off & use cvs or subversion now - I just can't bring myself to like them :)
[11:59] <dholbach> \sh_away: ping
[11:59] <ajmitch> hey dholbach
[11:59] <dholbach> hey ajmitch
[12:00] <lifeless> ajmitch: lol
[12:00] <zakame> hello dholbach
[12:00] <dholbach> \sh_away: I don't want to be a pain in the ass, but you don't seem to have realized, that you didn't only mess with the python2.3 <-> python2.4 {Build-,}Depends, but you overwrote my complete packaging for the istanbul package
[12:01] <dholbach> \sh_away: this is no urgent problem or anything, I just wanted to point this out - I'm going to revert this
[12:08] <ajmitch> sleep time, night all
[12:09] <dholbach> bye ajmitch :)
[12:09] <dholbach> hey zakame
[01:07] <dholbach> http://freeride.rubyforge.org/wiki/wiki.pl seems interesting for the ruby guys
[01:08] <dholbach> Korean MOTU: http://ubuntu.or.kr/wiki.php/MOTU
[01:25] <dholbach>  plus tard
[01:25] <dholbach> *wave*
[01:25] <crimsun> cya daniel
[02:24] <thierry_> raphink : you are the cdbs guru here right?
[02:25] <thierry_> raphink : is there anyway I can pass the option --enable-shared to the configure script with cdbs, or do I need to change my package to debhelper?
[02:28] <chninkel> thierry_: DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared
[02:29] <chninkel> thierry_: after inclusion of autotools.mk
[03:00] <zakame> evening all
[03:02] <slomo_> thierry_: in general you can do almost everything with cdbs... https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS
[03:02] <rbelem> thierry_: wiki.ubuntu.com/MOTUDocumentationDraft
[03:02] <ivoks> hi slomo_
[03:02] <slomo_> hi ivoks :)
[03:03] <rbelem> zakame: morning ;-)
[03:03] <rbelem> hi slomo_
[03:03] <ivoks> i'll quit my job :/
[03:03] <zakame> heya rbelem , slomo_ , ivoks :)
[03:03] <ivoks> i don't have time for ubuntu :)
[03:03] <zakame> waah
[03:03] <slomo_> hi rbelem
[03:05] <rbelem> hey slomo_, my first package was uploaded yesterday =)
[03:05] <slomo_> rbelem: cool, which one? :)
[03:05] <rbelem> darksnow
[03:05] <zakame> w00t
[03:07] <Yagisan> rbelem: new version of x264 at revu
[03:07] <slomo_> rbelem: :)
[03:07] <rbelem> slomo_: i feel very well after that. my first uploaded packages =) ehehehe
[03:08] <rbelem> Yagisan: cool
[03:08] <rbelem> thanks Yagisan
[03:08] <slomo_> rbelem: is it already in the archives? or in the NEW queue?
[03:09] <rbelem> slomo_: not in archives yet, i guess
[03:13] <rbelem> hey slomo_ maybe i'll get a job at mandriva
[03:14] <rbelem> they are calling people that work with freesoftware
[03:14] <ivoks> heh
[03:14] <slomo_> rbelem: cool :) what exactly would you do there?
[03:14] <ivoks> i got at redhat partner
[03:14] <ivoks> and since then no time for ubuntu :/
[03:14] <ivoks> so i'll quit :)
[03:14] <rbelem> ivoks: ehheheehe
[03:14] <ivoks> seriously... i will
[03:14] <rbelem> slomo_: test analyst
[03:16] <ivoks> ah, even now they call me :(
[03:16] <rbelem> if mandriva accept me, i'll quit my currently job, that sometimes have to fix some windows servers :'(
[03:16] <ivoks> :)
[03:16] <zakame> in cdbs, can I usr tarball.mk and simple-patchsys.mk simultaneously?
[03:19] <chninkel> rbelem: what will be your job at mandriva ?
[03:19] <azeem> zakame: yes
[03:19] <rbelem> chninkel: test analyst
[03:19] <rbelem> :)
[03:19] <chninkel> nice
[03:19] <chninkel> :)
[03:20] <zakame> azeem: hm, well I just tried doing so, {,p}debuild ran, but the patch failed :(
[03:20] <rbelem> i sent my curriculum, just waiting to be called
[03:21] <rbelem> there is not many people here that work with free software
[03:21] <azeem> zakame: maybe you need to include tarball before patchsys
[03:22] <zakame> hmm, lemme try
[03:23] <chninkel> rbelem: I don't know, I think there more and more people involved in free software nowadays no ?
[03:23] <ivoks> chninkel: true
[03:23] <ivoks> i work only with free software
[03:24] <rbelem> here at my city there are few people :/ I know almost everyone
[03:25] <chninkel> where do you live ?
[03:25] <rbelem> Manaus - Amazonas - Brazil
[03:26] <Yagisan> night all
[03:26] <rbelem> Yagisan: g'night
[03:26] <chninkel> night Yagisan
[03:27] <zakame> gn8 Yagisan
[03:27] <chninkel> rbelem: how is mandriva doing in Brazil ?
[03:28] <rbelem> chninkel: mandriva bought the major brazilian linux distribution, which is called conectiva
[03:29] <rbelem> chninkel: i guess the things are going well for then
[03:30] <rbelem> chninkel: they are working with embedded at my city
[03:30] <chninkel> chninkel: they were pretty bad at some time, but it seems they're getting better
[03:32] <rbelem> chninkel: sometime ago they almost close the doors :/
[03:39] <zakame> I don't get this, cdbs-edit-patch applies the patch cleanly, but it fails upon debuild...
[05:02] <dholbach> hello
[05:02] <dholbach> lifeless, ajmitch: how's open/multi-sync coming on?
[05:03] <dholbach> lifeless, ajmitch: we have UVF (which 'd apply for multisync) in less than two weeks - just as a heads-up.
[05:15] <chninkel> dholbach: merging question, should python package depends on python2.4 or python ?
[05:16] <dholbach> depends or build-depends?
[05:16] <dholbach> chninkel: the most sensible way is to have python-dev (>= 2.4) in the Build-Depends and ${python:Depends} in the Depends: line - but you have to run dh_python in debian/rules for that.
[05:18] <chninkel> dholbach: depends only
[05:18] <tseng> depends should be done with dh_python
[05:18] <chninkel> but is it worth applying a ubuntu specific patch for that ?
[05:19] <dholbach> yes.
[05:19] <chninkel> ok
[05:19] <tseng> (oh man what the hell is that Internet icon in tango 0.6.4)
[05:20] <hub> is it that hard to package opensync?
[05:20] <dholbach> something blue with a crack-pipe
[05:20] <tseng> yeah
[05:20] <hub> oh
[05:20] <tseng> it looks like a background from DeviantArt
[05:20] <dholbach> hub: ajmitch and lifeless are working on it for some time now. i'm not sure how the state is.
[05:21] <dholbach> hub: but i'm keen on having it in before uvf.
[05:21] <hub> dholbach: yeah, that why I'm asking.
[05:33] <andi5> hi. is there a way to accelerate a debian<->ubuntu pkg merge? the launchpad bug is 6 weeks old (for me this is nontrivial, but maybe i am just impatient)
[05:37] <bmonty> andi5: what is the package or bug?
[05:37] <andi5> bmonty: it is g-wrap, #5069
[05:38] <bmonty> andi5: \sh is doing the merge on that package
[05:49] <chninkel> how frequently are auto-sync with debian done ?
[05:52] <Nafallo> daily
[05:53] <chninkel> Nafallo: I was told lesstif2 would be removed from sync blacklist and put in universe
[05:53] <hub> anyone with dapper can access a sourceforge CVS repository over SSH?
[05:53] <chninkel> Nafallo: but it's still not there
[05:53] <chninkel> Nafallo: who can I ask about this ?
[05:54] <Nafallo> sounds like elmo-land ;-)
[05:54] <chninkel> Nafallo: ok, thks
[05:54] <hub> looks like openssh 4.2 is causing problems
[05:54] <Nafallo> but best to ask in #ubuntu-devel after the weekend probably
[05:55] <chninkel> Nafallo: ok
[07:14] <d4ft> how do i add a package?
[07:18] <jpatrick> d4ft: to what?
[07:18] <d4ft> add the package i just compiled
[07:18] <jpatrick> to universe?
[07:19] <d4ft> yup
[07:19] <d4ft> or contrib
[07:19] <d4ft> either one^^
[07:20] <jpatrick> d4ft: you have to get an MOTU to review and upload the package
[07:20] <d4ft> ok
[08:10] <ajmitch> morning all
[08:11] <tseng> hi ajmitch
[08:11] <sistpoty> hi folks
[08:12] <ajmitch> hello tseng, sistpoty
[08:18] <ajmitch> sistpoty: if you're bored & looking at the merge updates again, look at my updated ~/scripts/srcpkgs2merge.py
[08:18] <ajmitch> runs in about 15 seconds now, half of that being download time
[08:19] <sistpoty> ajmitch: I'm not really bored ;) and as long as the old version works, I guess I won't change it (because we only need it for a few days *g*)
[08:19] <ajmitch> sistpoty: it uses britneymodule.so, which I'll also use for unmet deps :)
[08:19] <ajmitch> only a few lines added
[08:19] <sistpoty> cool :)
[08:20] <ajmitch> so I'll work on tiber trying to get a list of unmet deps on dapper universe :)
[08:20] <sistpoty> ajmitch: I'm not quite sure about it, but imo siretart has already some list-generator of unmet deps in his home on tiber
[08:20] <ajmitch> probably from apt-cache unmet
[08:21] <ajmitch> britney is what debian uses for the purpose, and it's a little more accurate (and memory hungry)
[08:22] <ajmitch> yep, looks to just use that
[08:28] <sistpoty> ajmitch: if I want to add a patch to BTS for an already reported bug, what do I have to do?
[08:28] <sistpoty> ajmitch: (and tag it as patch available)
[08:28] <ajmitch> send in a mail with attachment, and tag it as patch
[08:29] <sistpoty> ajmitch: only as a mail to somebugnum@bugs.debian.org? or do I need to cc control@bugs?
[08:30] <ajmitch> I think you'd send a separate mail to control@
[08:30] <ajmitch> but I use the bts util for that :)
[08:30] <sistpoty> ajmitch: k, thx :)
[08:41] <psusi> anyone feel like revuing my e2fsprogs and defrag package fixes?
[08:42] <Mithrandir> uhm, e2fsprogs isn't universe, it's main, so it shouldn't go through revu
[08:43] <psusi> I know... but Yagisan wanted to take a look at it... and I wanted someone to tell me how I screwed it up, and that's the only place I can put it ;)
[08:43] <sistpoty> psusi: please add a comment to state that it's in main
[08:43] <Mithrandir> heh, 'k.  I'd like it not to be uploaded until I hear back from tytso, though
[08:43] <psusi> hrm... just say "This is in main, so do not upload, just comment"?
[08:44] <sistpoty> psusi: or s.th. like "S.o. with main privs needs to review this"
[08:44] <sistpoty> ;)
[08:44] <psusi> ok...
[08:44] <Mithrandir> sistpoty: it shouldn't be uploaded until we hear back from upstream.
[08:44] <Mithrandir> is there any way to tell revu that?
[08:45] <sistpoty> write a comment stating it ;)
[08:45] <Mithrandir> uhm, what login should I use?
[08:46] <psusi> commented
[08:46] <psusi> so anyone feel like looking at it though and telling me how I screwed up the packaging? ;)
[08:46] <psusi> or defrag... but it depends on that version of e2fsprogs
[08:46] <sistpoty> Mithrandir: do you have review rights on revu? otherwise you won't be able to comment
[08:47] <Mithrandir> sistpoty: probably not.  Or maybe.
[08:47] <Mithrandir> sistpoty: I tend to just upload and not use revu, as I can upload to main
[08:47] <Nafallo> Mithrandir: you probably don't even have an account then ;-)
[08:47] <Mithrandir> I probably don't.
[08:47] <Nafallo> iirc you get an account on the first upload or something like that...
[08:47] <Mithrandir> I've uploaded a lot of stuff. :-P
[08:48] <Nafallo> to revu silly ;-)
[08:48] <Mithrandir> oooh. :-P
[08:48] <psusi> yea.. have to get your gpg key on the ring, then first upload creates your account with a random password which you can get by choosing password recovery... which sends you a gpg encrypted message with your password... heh
[08:48] <Mithrandir> about what?
[08:48] <Nafallo> Mithrandir: anything you like :-)
[08:50] <psusi> so... are new bugs supposed to go in malone now or what?  I need to file a bug against the .25 i386 breezy kernel and don't know if it should go in malone or bugzilla
[08:50] <psusi> damn thing dies hard core about once a day on my server at work... won't even magic sysreq
[08:51] <Nafallo> fwiw, I always use malone and assign it to the person who should have it these days ;-)
[08:51] <Nafallo> my girlfriend does aswell ;-)
[08:52] <sistpoty> Mithrandir: what email did you use for packages, which you uploaded to revu?
[08:53] <ajmitch> sistpoty: he said he hasn't uploaded to revu, right? :)
[08:53] <Mithrandir> sistpoty: I haven't uploaded any packages to revu.
[08:53] <sistpoty> oh, misunderstood that *g*
[08:53] <psusi> there doesn't happen to be a less.... foofy... ui to malone does there?
[08:54] <sistpoty> Mithrandir: then what email (login) do you want as an account for revu? (should be same that you use for uploading packages)
[08:54] <Mithrandir> sistpoty: tfheen@ubuntu.com
[08:55] <Mithrandir> (please)
[08:57] <sistpoty> Mithrandir: account created... just use try to login with that email-addy and some random pw, then there should be s.th. for pw recovery ;)
[08:58] <Mithrandir> http://pastebin.com/496782
[09:00] <sistpoty> lol, I'm stupid *g* (need to import your key as well)
[09:00] <Mithrandir> haha :-)
[09:00] <Mithrandir> 817a996a
[09:00] <Mithrandir> is the key id
[09:00] <Mithrandir> (as you can verify on launchpad too)
[09:02] <sistpoty> Mithrandir: there is no @ubuntu adress for this key, however I found 2C0753E3 for your ubuntu addy
[09:02] <ajmitch> morning Mez
[09:02] <ajmitch> ;)
[09:02] <Mez> evening :D
[09:02] <Mez> lol
[09:02] <Mithrandir> sistpoty: yes, that is my smart card.  Please don't use that yet, look at https://launchpad.net/people/tfheen for my key ids.
[09:03] <Mithrandir> hiya ajmitch
[09:03] <ajmitch> hi Mithrandir
[09:03] <Mithrandir> sistpoty: else, I'll have to go into the room next door to find the smart card and reader, and I'm lazy. :-P
[09:04] <ajmitch> Mithrandir: I think I still have yours to sign here
[09:04] <Mithrandir> ajmitch: I think I signed yours already, didn't I?
[09:04] <sistpoty> Mithrandir: hm... then I'll need to change your login to match one from the first key ;)
[09:04] <Mithrandir> sistpoty: that's a really silly restriction in revu, but feel free to use tfheen@err.no then
[09:05] <sistpoty> Mithrandir: revu 1 has even more of these silly stuff ;)
[09:05] <ajmitch> Mithrandir: yes, you've signed mine
[09:06] <ajmitch> ah, found your business card
[09:07] <sistpoty> Mithrandir: done... hope this works now ;)
[09:08] <Mithrandir> sistpoty: yay, worked
[09:08] <sistpoty> ajmitch: if I want to tag a patch in debian, I get: 550 Administrative prohibition :(
[09:08] <Mithrandir> ooh, I'm logged in as admin as well.  Shiny.
[09:10] <Mez> does the linux-source packages come with a config file already - or not ?
[09:11] <Mithrandir> sistpoty: it would be useful if revu recognized urls as such and made them clickable.
[09:12] <sistpoty> Mithrandir: already considered this for revu2... for this version you can still write plain html code
[09:12] <Mithrandir> ouch
[09:13] <Mithrandir> that's actually quite bad, since you can XSS and steal cookies that way
[09:13] <sistpoty> yep... but whoever tries that must be in the keyring (otherwise no login) and thus it's easily tracable
[09:15] <psusi> hrm.... malone doesn't appear to know about any linux-image packages
[09:29] <sistpoty> anyone with amd64 here, who might help me test a fix?
[09:35] <siretart> huhu sistpoty
[09:35] <sistpoty> hi siretart
[09:36] <siretart> sistpoty: I just arrived at home, but I think I can help you in a couple of minutes. what to test?
[09:36] <sistpoty> siretart: u++
[09:36] <chninkel>  /LOAD proxy
[09:37] <chninkel> oups, sorry
[09:37] <siretart> u++?
[09:38] <siretart> interesting. it doesnt work on amd64?
[09:38] <sistpoty> siretart: it FTBFS'd due to changed dpkg-architecture (the makefile is quite funny)
[09:38] <sistpoty> siretart: and I did it right only for i386 :(
[09:39] <siretart> sistpoty: ok, I'll take a look at it
[09:39] <sistpoty> siretart: I'll put a patch on tiber in a minute ;)
[09:40] <sistpoty> siretart: upp_debian_rules.patch (in my home)
[09:42] <siretart> ok
[09:43] <lucas> hi siretart
[09:43] <lucas> how was snowboarding ?
[09:44] <\sh> moins
[09:44] <sistpoty> hi \sh
[09:45] <rbelem> hi sistpoty
[09:45] <rbelem> i have amd64
[09:46] <sistpoty> hi rbelem:
[09:46] <sistpoty> rbelem: I think siretart is already on it
[09:46] <lucas> is thierryn at videotron.ca around ?
[09:46] <rbelem> sistpoty: ok ;-)
[09:48] <ajmitch> ah, siretart lives :)
[09:48] <Nafallo> hehe
[09:48] <ajmitch> good to see he's not lying unconscious in a hospital ;)
[09:49] <Nafallo> they don't allow laptops + wireless on hospitals? :-)
[09:49] <ajmitch> unconscious, I said ;)
[09:49] <Nafallo> baah
[09:49] <Nafallo> :-P
[09:49] <ajmitch> though siretart would probably be in irc even in a coma
[09:50] <Nafallo> hehe
[09:51] <lucas> hey, could somebody open a revu reviewer account for me ? (or set my existing account to reviewer ?)
[09:51] <siretart> ajmitch: hehe, I'm not thaat crazy ;)
[09:51] <siretart> lucas: snowboarding in france is great! :) - I just arrived 2h ago, and I'm really tired from 10h driving ;)
[09:51] <sistpoty> lucas: are you motu yet? (we usually give away reviewer accounts only to motu's)
[09:51] <ajmitch> siretart: what are we deciding on having non-MOTUs reviewing?
[09:52] <lucas> sistpoty: member, not motu
[09:52] <lucas> siretart: where were you ?
[09:52] <siretart> ajmitch: we have afaik only on non motu reviewer, based on that he gives really good comments
[09:52] <ajmitch> right
[09:52] <Nafallo> hmm
[09:52] <sistpoty> lucas: you can post reviews to the reviewer ml... if they are good, we can set up an reviewer account, ok?
[09:53] <Nafallo> but I'm not certain ;-)
[09:53] <lucas> ok
[09:53] <ajmitch> Nafallo: I can't remember when you were made MOTU
[09:53] <Nafallo> ajmitch: not me either :-P
[09:53] <ajmitch> it was long enough ago now :)
[09:53] <Nafallo> after we visited Mithrandir :-)
[09:53] <Nafallo> so sometime this last summer ;-)
[09:54] <ajmitch> aha
[09:55] <Nafallo> baah. people think I'm a core-dev anyway :-P
[09:55] <ajmitch> dunno why
[09:55] <ajmitch> maybe because you seem wise & all-knowing
[09:55] <ajmitch> desrt: that's just because you speak up a lot :)
[09:55] <Nafallo> :-)
[09:56] <desrt> ajmitch; not being a member of the MOTU probably helps too :p
[09:56] <Nafallo> probably because I make people upload my stuff to main now and then ;-)
[10:03] <sistpoty> btw: desrt: ghc6 ftbfs due to new make :(
[10:05] <sistpoty> (it actually doesn't ftbfs but just sit running make forever)
[10:06] <chninkel>  /set bell_beeps on
[10:08] <raphink> sistpoty: that's not very convenient indeed ;)
[10:09] <sistpoty> raphink: well I tried to build it on tiber and rechecked after 24h... only hot air produced *g*
[10:10] <raphink> :s
[10:10] <raphink> you mean you let it build for 24h ? ;)
[10:10] <sistpoty> sure... it usually takes 6 hours on my slow machine
[10:10] <raphink> haha
[10:10] <sistpoty> s/takes/took :P
[10:12] <ajmitch> slomo_: bug for you: https://launchpad.net/distros/ubuntu/+source/service-discovery-applet/+bug/6510
[10:12] <Ubugtu> Malone bug 6510: "discovery-applet (Ubuntu) - Sometimes doesn't show any discovered services" Fix req. for: service-discovery-applet (Ubuntu), Severity: Normal, Assigned to: Avahi Team, Status: New http://launchpad.net/bugs/6510
[10:12] <\sh> gnarf..."I should not post to debian-devel, I should not post to debian-devel, I never post to debian-devel again"
[10:13] <slomo_> ajmitch: i already noticed it ;)
[10:13] <slomo_> \sh: what happened?
[10:13] <ajmitch> \sh: it's never a good idea to
[10:13] <\sh> slomo_: nothing
[10:13] <ajmitch> slomo_: he went into a thread about launchpad
[10:13] <ajmitch> and he dared to reply to asuffield :)
[10:14] <\sh> well, I'm just an asshole...
[10:14] <\sh> ajmitch: whoever mr. suffield is
[10:15] <ajmitch> notorious flamer :)
[10:15] <\sh> ajmitch: thats why I quoted the last 2 lines of their code of conduct...
[10:15] <ajmitch> that didn't go down well :)
[10:15] <ajmitch> I didn't even know there was a code of conduct for debian lists
[10:16] <\sh> ajmitch: well..I can use lynx :)
[10:16] <\sh> ajmitch: and I'm not afraid of using google, even it can disappear with a big bang, because it's free but non-free sourcecode service
[10:18] <ajmitch> but it's a very important point for debian to have freely available tools - launchpad & google are apples & oranges
[10:18] <ajmitch> launchpad is designed to be central to distro development, google is not
[10:18] <\sh> ajmitch: well...how many people from debian are using sf.net?
[10:18] <ajmitch> for developing debian? very few, I'd say
[10:19] <\sh> I think there are some, no for developing oss software :)
[10:19] <ajmitch> for fetching upstream tarballs from? a much higher number
[10:19] <siretart> huhu \sh!
[10:19] <\sh> siretart: how was the holiday? :)
[10:19] <ajmitch> and that developing floss software is not developing debian, the distribution
[10:19] <siretart> \sh: the week was great! thank you! :)
[10:20] <raphink> hmm
[10:20] <\sh> ajmitch: it has everything in it. If they stand for what they
[10:20] <\sh> 're saying, they would never use sf.net
[10:21] <ajmitch> sure, and those developers that speak up probably don't use sf.net
[10:21] <\sh> even for non debian work :)
[10:21] <ajmitch> we're talking about using launchpad for all debian developers, or even a major part
[10:22] <raphink> looking at the enlightenment package because there's a sync/merge required
[10:23] <raphink> it seems there's a slight problem with it with last merged version
[10:23] <raphink> it didn't build the enlightenment binary package from source
[10:23] <ajmitch> so fix that with the next merge :)
[10:23] <lucas> maybe we should start a "How to talk to Debian developers" wiki page
[10:23] <raphink> so enlightenment_1:0.16.7.2-2 is available as source and not as binary
[10:24] <raphink> ajmitch: sure
[10:24] <raphink> lucas: ?
[10:24] <raphink> ;)
[10:24] <ajmitch> raphink: it was probably fixes in the last debian upload - it was missing build-depends
[10:24] <raphink> UsefulDebianVocabulary
[10:24] <raphink> ;)
[10:24] <\sh> lucas: it's nothing compared to my early days in usenet :)
[10:24] <lucas> raphink: the launchpad thread on debian-devel@lists.d.o didn't go very well
[10:24] <lucas> \sh: yes, but it's a missed opportunity
[10:25] <lucas> anyway, you didn't start the thread, I think
[10:25] <ajmitch> lucas: did you expect it to?
[10:25] <raphink> rationale : if you don't understand "checking BTS, found it was FTBFS so just uupdate", you have to study the Debian language
[10:25] <lucas> ajmitch: not really ;)
[10:25] <ajmitch> lucas: I don't push for other DDs to use launchpad for those reasons :)
[10:25] <\sh> raphink: you mean something like "morons", or "you suck", well if I would stick to those behaviour, I would have to switch to windows ;)
[10:26] <ajmitch> lucas: and what would you put on this 'how to talk to debian developers'?
[10:26] <raphink> hehe
[10:26] <lucas> 'free software is important to them. It isn't always for us.' ;)
[10:26] <ajmitch> raphink: hm? what's so hard to understand about that sentence?
[10:26] <ajmitch> raphink: you forgot to check the WNPP
[10:26] <raphink> ajmitch: nothing for me since I wrote it ;)
[10:26] <raphink> oh yeah ajmitch that's right
[10:26] <\sh> lucas: well, it's useless in any sense..but sometimes my strong focus to make the world a better place comes through...
[10:27] <raphink> but the WNPP is in the BTS
[10:27] <ajmitch> yes, but it's a specific way of using the BTS
[10:27] <ajmitch> with particular rules on bug titles, etc
[10:27] <raphink> yes
[10:28] <raphink> so a good sentence to introduce the necessity of knowing such a language
[10:28] <lucas> \sh: can you point me to a location explaining why the LP code is not free ?
[10:28] <ajmitch> \sh: some of your comments could be taken as very inflammatory :)
[10:28] <raphink> would be to asked for ITP to be filed for WNPP in the BTS cause last vers is FTBSF
[10:28] <raphink>  ?
[10:28] <ajmitch> raphink: that would be utter crack
[10:28] <raphink> ;)
[10:28] <ajmitch> raphink: you'd file a wishlist bug on the existing source package
[10:29] <raphink> oh yes that's right
[10:29] <raphink> hmm not a good example, still , then
[10:29] <Amaranth> -ETOOMANYACRONYMS
[10:29] <raphink> ;)
[10:29] <ajmitch> Amaranth: exactly what we're talking about :)
[10:30] <slomo_> ajmitch: FTBFS is not wishlist imho... but i'm probably missing the context ;)
[10:30] <ajmitch> true, it's a serious bug
[10:30] <ajmitch> but you'd file a wishlist for new upstream version
[10:31] <raphink> slomo_: ajmitch meant you wouldn't file an ITP for a FTBFS
[10:31] <raphink> instead you would file a bug on the existing package, not against WNPP
[10:31] <slomo_> yes
[10:31] <ajmitch> raphink: slomo_ is an experience debian maintainer also :)
[10:31] <raphink> :)
[10:32] <slomo_> ajmitch: while we're at debian... you still didn't get the advocation mail? :(
[10:32] <ajmitch> no, dunno why..
[10:32] <ajmitch> I'll check my spam folders
[10:33] <raphink> ;)
[10:33] <\sh> lucas: because canonical said so, and they licensed launchpad in this way. There was somehow a talk or a document explaining why...but well, it's even said, that if canonical is disappearing from the market, lp source will be released as oss
[10:34] <lucas> ok
[10:34] <ajmitch> lucas: and thus you see why many DDs keep away from it
[10:34] <Mez> ajmitch, you're advocating slomo for DD?
[10:34] <ajmitch> Mez: yes, why?
[10:34] <lucas> ajmitch: :-)
[10:34] <\sh> ajmitch: why? because I'd compare non-elite and elite people? ,)
[10:34] <ajmitch> \sh: because you call us DDs 'arrogant elitists' ;)
[10:34] <Mez> lol - cause i think slomo would make a good addition :D
[10:34] <Mez> lol
[10:35] <ajmitch> Mez: sure, and it'll mean less sponsoring for me in a year or two ;)
[10:35] <\sh> ajmitch: but you are ;)
[10:35] <ajmitch> \sh: of course
[10:35] <Mez> ajmitch, lol :D yeah - :P
[10:35] <\sh> ajmitch: i mean I'm one of them as well...I never said something against it :)
[10:35] <slomo_> ajmitch: i bet it will be around january 2008 ;)
[10:35] <ajmitch> slomo_: optimist
[10:36] <raphink> looool
[10:37] <\sh> ajmitch: anyways...I'm just an asshole...but I will change, and not post to debian-devel again :)
[10:38] <ajmitch> slomo_: it's listed me as advocate on the page but not verified your application - since I still haven't seen any mail :)
[10:39] <lucas> \sh: you are not an asshole, but you failed to talk to DDs the way you have to talk to them if you want them to listen
[10:39] <slomo_> ajmitch: weird... can you re-request the mail?
[10:39] <ajmitch> nope
[10:40] <ajmitch> I might be able to put myself as advocate again
[10:40] <lucas> ajmitch: ask paulvt (Mozillion) about this, I think he had the same problem when he advocated me
[10:40] <ajmitch> and how did that get fixed?
[10:41] <slomo_> ajmitch: hmmm or write a mail to new-maintainer@debian.org and ask them where your mail was sent to ;)
[10:41] <lucas> I dunno, that's what you should ask to him :)
[10:41] <\sh> lucas: that's why i'm an asshole...I refuse to lick their feet
[10:41] <lucas> it's not about feet-licking, it's about understanding that others sometimes think differently
[10:42] <\sh> hope my dapper update is working somehow
[10:43] <raphink> debian #346160
[10:43] <Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
[10:43] <raphink> Ubugtu: debian bug #346160
[10:43] <Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
[10:43] <raphink> hmm
[10:43] <raphink> works when you don't want it to, and doesn't work when you need it ;)
[10:44] <slomo_> raphink: it's only this bug, others work fine ;)
[10:44] <raphink> haha
[10:44] <raphink> yeah yeah sure
[10:44] <slomo_> debian bug 346161
[10:44] <Ubugtu> Debian bug 346161: "serial card (fourport) stopped working" Package: linux-source-2.6.15, Severity: wishlist, Maintainer: Debian Kernel Team  http://bugs.debian.org/346161
[10:44] <slomo_> :P
[10:45] <raphink> :p
[10:45] <\sh> lucas: I understand that very well, because we all think differently. But why should I think I'm better because others don't know how to use vi for writing html files? or why should I think I'm better because I know the manpage of tar and find and can use it quite fast, but others who don't are useless and shouldn't be involved in contributing to the project?
[10:45] <lucas> debian bug 346160
[10:45] <Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
[10:46] <raphink> heh
[10:46] <raphink> no luck
[10:46] <lucas> they don't think they are better. they just don't like hearing : "a command line interface ? ah ah ! look guys, the world has changed !"
[10:46] <lucas> which is basically what you told them
[10:47] <ajmitch> slomo_: hm, mail from that debian.org box reaches me fine.. retrying advocacy
[10:48] <slomo_> ajmitch: thanks :)
[10:50] <\sh> lucas: yes, because it's the truth. There is a new generation coming up, which don't want to use those tools anymore...they want it shiny, mouse-move-ish and translucent, and we should sit in our hobbit holes and denying that. But we can try to teach them, and if they're interested they can learn from us. Same applies to the old guys, they should not be afraid of this change towards shinyness etc. Actually, we have a choice, but others don't
[10:50] <\sh> ting.
[10:50] <\sh> "...,and we shouldn't sit..."
[10:51] <lucas> then provide an old interface using web services from the command line
[10:51] <lucas> so the old guys get to know your tool
[10:51] <ajmitch> slomo_: the other option given on the newmaint list is that I send a signed email to there, and front desk will change it manually :)
[10:51] <\sh> lucas: that's what we will do for launchpad e.g. that's what google was doing with their xmlrpc api
[10:52] <lucas> great.
[10:52] <lucas> then, before this is implemented, don't expect debian developers to get interested in LP
[10:52] <ajmitch> even after that, there's still a tight dependency on a non-free tool
[10:53] <\sh> lucas: no, it has nothing to do with "not interested", it has to do with "non-open-source", but as I said, nobody is refusing to use google :)
[10:53] <\sh> lucas: and to be honest, many people are depending on google :)
[10:53] <lucas> DDs are not forced to use google
[10:53] <ajmitch> that's because, as I said before, debian developers would not be tied to google
[10:53] <lucas> \sh: I find it disturbing that we all rely on google
[10:53] <\sh> lucas: nobody is forced to use LP :)
[10:54] <lucas> \sh: if a debian team starts using LP
[10:54] <lucas> chances are high that new members of the team will have to use LP too
[10:54] <ajmitch> lucas: and some have
[10:54] <\sh> lucas: then they made a choice, and they have to live with it.
[10:55] <lucas> they made the choice to become tied up with proprietary software
[10:55] <lucas> not much better than being forced to use MS word to read complex .doc
[10:56] <raphink> argh FTBFS :s
[10:56] <\sh> lucas: if they choose to work with lp, then they weren't forced to use it.
[10:57] <lucas> how easy is it to get out of LP currently ?
[10:57] <lucas> like exporting data ?
[10:57] <\sh> lucas: rosetta - very easy
[10:58] <lucas> malone ?
[10:58] <ajmitch> currently quite hard
[10:58] <lucas> ok
[10:58] <ajmitch> and I wouldn't want to try & do a full dump of it via xml-rpc
[10:58] <ajmitch> when that interface is added
[10:58] <lucas> anyway, </discussion on LP>
[10:58] <lucas> \sh: I can't find your updated package from launchpad bug 6556
[10:59] <\sh> lucas: was it wesnoth?
[10:59] <lucas> yes
[10:59] <\sh> then you will find the changes already in the latest upload of wesnoth.
[10:59] <\sh> -2 of debian has the old patch and stuff inside, so I'm refusing to merge
[11:00] <\sh> that's what I wrote on -motu
[11:00] <lucas> ok, I understand
[11:00] <\sh> -3 will be different
[11:00] <raphink> hehe
[11:00] <raphink> or you could merge and modify it
[11:00] <raphink> instead of just synching -2
[11:00] <raphink> syncing
[11:01] <\sh> raphink: that makes no sense...I have to revert a patch and include my patch again, instead of waiting for -3 and sync
[11:01] <raphink> ok
[11:01] <raphink> thats' a point of veiw
[11:01] <raphink> but yes given that -2 has older patches than -1ubuntu2 to fix the same bugs
[11:01] <raphink> it's better to keep -1ubuntu2 obviously
[11:01] <\sh> raphink: that
[11:02] <raphink> \sh: I think the best thing about the amd64 bug might just be that you talk with isaac
[11:02] <lucas> \sh: I can't find your patch on the debian BTS
[11:02] <raphink> lol
[11:02] <Q-FUNK> would anybody please be so kind as to sync rus-ispell from unstable?  the rus-ispell in dapper right now is hopelessly outdated and none of those diffs are needed.
[11:02] <\sh> lucas: isaac has it already, because I filed my change upstream, and he has it in his svn tree (remembering what luk said(
[11:03] <\sh> lucas: upstream == wesnoth bts
[11:03] <lucas> mmh ok
[11:03] <raphink> can't sync enlightenment
[11:03] <raphink> doesn't build on dapper
[11:04] <\sh> lucas: all this was discussed earlier on :) and there were some really nice mails and irc statements about it :)
[11:04] <lucas> ok
[11:04] <\sh> lucas: the last 3 days?
[11:05] <lucas> I left after raphink did the first merge
[11:05] <lucas> \sh could you file a bug on launchpad saying that wesnoth shouldn't be merged ?
[11:05] <lucas> chances are quite high that somebody will start working on one ...
[11:05] <\sh> lucas: well...why? it's not on the merge list anymore...it will show up again when -3 will come :)
[11:06] <lucas> it's on the lists on http://tiber.tauware.de/~lucas/versions/ for example ;)
[11:06] <\sh> lucas: yes, but this is not the tool, which I'm using to keep track of the merges.
[11:06] <lucas> that you are using.
[11:06] <raphink> but other people are using it \h
[11:07] <\sh> raphink: sure, but other people reading as well -motu ML :)
[11:07] <lucas> the lowest common denominator
[11:07] <raphink> hopefully
[11:07] <lucas> is malone
[11:07] <lucas> anyway, if you don't want to, I'll file a malone bug about this.
[11:08] <\sh> lucas: no...I'll write a comment to 6556
[11:09] <lucas> I posted a new bug
[11:09] <\sh> whatever...
[11:09] <lucas> a comment on #6556 has very few chances to be found by the potential merger ...
[11:10] <\sh> lucas: that's why we have the central station named revu in sistpoties home. to see the new, accepted and done merges...and as well attached to it the bugreports.
[11:11] <lucas> the problem is that this central station currently misses some merges
[11:11] <\sh> lucas: that's why a auto-generated list without a bit of more information from another source is no good. if you can hack your list code into sistpotys source, would be more useful instead of having two different versions
[11:11] <lucas> I will
[11:12] <raphink> ok well
[11:12] <raphink> we have to sync/merge xlibs-data before enlightenment can be merged
[11:12] <\sh> why/
[11:13] <raphink> enlightenment -3 builds on some files provided by xlibs-data 6.9
[11:13] <raphink> but not present in xlibs-data 6.8
[11:13] <\sh> raphink: xlibs-data is daniels area :)
[11:13] <raphink> he's gone :(
[11:14] <raphink> I guess the new enlightenment activates new functions based on new xlibs-data
[11:14] <raphink> so I just can't merge it, unless I deactivate these options and then there's no point in merging I guess ;)
[11:14] <raphink> I'll update the bug with these infos and wait for xlibs-data to be upgraded I guess
[11:14] <raphink> is that fine \sh ?
[11:15] <lucas> /whois sistpoty
[11:15] <lucas> oops
[11:15] <lucas> /whois sistpoty
[11:15] <lucas> rah
[11:15] <raphink> lol
[11:15] <\sh> raphink: well...xlibs-data is belonging to the xorg source package...so it should be done by daniels....
[11:15] <sistpoty> I'm Stefan Potyra :P
[11:15] <\sh> raphink: so the best think is we have to wait
[11:16] <raphink> \sh: yes but I'll put this info in the bug I opened to merge enlightenment
[11:16] <lucas> sistpoty: thank you, but I was looking for your idle time :)
[11:16] <raphink> so people don't work on merging it before xlibs-data is ready
[11:16] <\sh> raphink: sure :)
[11:16] <sistpoty> lucas: hehe, was quite some time
[11:17] <sistpoty> \sh: did you actually upload a newer version of wesnoth?
[11:18] <\sh> sistpoty: -1ubuntu2 is the latest with all patches from debian and my amd64 bit patch applied...that's why I wanted to not merge/sync the latest -2 package from debian..I'm waiting for 3
[11:18] <sistpoty> \sh: then you shouldn't have the bug marked as fixed... thus way it will move to new once I update the merge list
[11:19] <\sh> sistpoty: well...I hope the package will come soon of isaac...I'm just optimistic...
[11:20] <\sh> how long until the stupid update is finished here
[11:20] <sistpoty> hehe, in case I update the list earlier on, just file a merge bug but don't mark it as fixed yet... thus the merge will stay on the assigned side
[11:21] <\sh> sistpoty: I wonder if your tool can handle reopenings of bugs? :)
[11:21] <sistpoty> \sh: not a chance :P
[11:22] <\sh> sistpoty: ok :)
[11:22] <sistpoty> \sh: but feel free to use update_status.py in /home/sistpoty/merge_offline ;)
[11:23] <\sh> sistpoty: hmm...or I adjust your regexp to filter as well re-opened bugs :)
[11:24] <sistpoty> hehe
[11:24] <\sh> sistpoty: and update the db accordingly :)
[11:24] <\sh> but first, the dist-upgrade must be finished :)
[11:24] <\sh> can't even start a new browser or something else...
[11:26] <ajmitch> ah that's better, pqm includes the right files on make dist now
[11:26] <raphink> actually... I can't even build the _current_ enlightenment version in dapper !!
[11:26] <\sh> raphink: what does the build log say?
[11:27] <raphink> \sh: http://pastebin.com/497001
[11:28] <raphink> X11/bitmaps/{flipped_gray,gray,gray3} are provided by xlibs-data
[11:28] <\sh> ah
[11:28] <raphink> and the current xlibs-data in ubuntu doesn't provide them
[11:28] <raphink> I guess it provided it before
[11:29] <raphink> since the -2 was synced in Ubuntu fine a few weeks ago
[11:29] <\sh> yes..but not it's xbitmap
[11:29] <\sh> s/not/now/
[11:29] <\sh> i think
[11:29] <raphink> oh ok
[11:29] <raphink> sure?
[11:30] <\sh> moment...just updating apt-file :)
[11:30] <raphink> ok
[11:30] <\sh> yes...xbitmaps
[11:30] <raphink> ok
[11:30] <raphink> so enlightenment should depend on it
[11:30] <\sh> yepp
[11:30] <raphink> ok
[11:30] <\sh> build-dep
[11:30] <raphink> yet -2 didn't depend on it
[11:30] <\sh> you need it while you are building it :)
[11:30] <raphink> it was just synced
[11:31] <raphink> yes
[11:31] <\sh> did -2 ever get build?
[11:31] <raphink> yes
[11:31] <raphink> I think so
[11:31] <\sh> Version: 1:0.16.7.2-1ubuntu2
[11:31] <\sh> of enlightenment
[11:31] <raphink> but maybe it got build before xbitmaps was released
[11:31] <raphink> actually yes
[11:32] <raphink> -2 got synced but not build it seems
[11:32] <raphink> so that might be the reason why
[11:32] <raphink> we have to merge it with xbitmaps in Build-Depends
[11:32] <raphink> I'll try that
[11:33] <raphink> :)
[11:34] <raphink> https://launchpad.net/distros/ubuntu/+source/enlightenment
[11:34] <raphink> it says : pending ;)
[11:35] <Nafallo> baah!
[11:35] <Nafallo> ^w isn't ^q
[11:35] <raphink> Nafallo_away: sorry?
[11:36] <raphink> ;)
[11:37] <\sh> oh tomorrow i have my second interview
[11:37] <raphink> \sh: while I'm merging it, shall I update the standards version too?
[11:37] <raphink> it has  3.5.9.0 currently
[11:37] <\sh> raphink: why not :) we will see this package actually again :)
[11:37] <psusi> can you get cut to give you only the LAST field on a line?
[11:37] <raphink> ok :)
[11:40] <raphink> lintian also shouts about the changelog file, for a good reason
[11:40] <raphink> \sh: http://pastebin.com/497023
[11:40] <raphink> do you think that should be fixed ??
[11:40] <raphink> like removed or so
[11:40] <raphink> we can't know what version this lines refer to
[11:40] <raphink> s/this/these/
[11:41] <raphink> given that previous version was -6.1 I guess this one is -6.2 but can't be sure
[11:41] <\sh> raphink: what says the orig debian package?
[11:42] <raphink> that's what's in the debian package
[11:42] <raphink> ;)
[11:42] <raphink> latest version of the debian package that is
[11:42] <\sh> raphink: well...vorlon made an NMU so it should be something with a dot in the revision
[11:42] <raphink> I didn't change it
[11:42] <raphink> yes
[11:43] <raphink> and since previous version was also an NMU : -6.1
[11:43] <raphink> this one must have been -6.2
[11:43] <raphink> I guess
[11:43] <\sh> raphink: or file a bug in debian bts, complaining that they b0rked the changelog :)
[11:43] <raphink> hehe
[11:43] <raphink> ;)
[11:43] <raphink> yes that's an idea
[11:43] <\sh> well...he should have used dch instead of vi directly ,)
[11:43] <ajmitch> enlightenment?
[11:44] <raphink> ajmitch: yes
[11:44] <\sh> yes the old shiny wm :)
[11:44] <\sh> which has no use but funny themes :)
[11:44] <raphink> ajmitch: line 96 in -3 version in sid
[11:44] <Seth> Seveas, if you get a chance could you change my hostmask to just u/m/seth now that I own the proper nick :) thanks
[11:44] <raphink> misses the package name & version
[11:44] <raphink> line
[11:45] <raphink> just fetching the lintian output
[11:45] <raphink> which is quite verbose on this package ;)
[11:45] <Seveas> Seth, you can poke array_random($FREENODE_STAFF) yourself :)
[11:45] <raphink> E: enlightenment: wrong-path-for-interpreter #!/usr/sbin/install-menu != /usr/bin/install-menu (./etc/menu-methods/enlightenment)
[11:45] <Seth> Seveas, ah, will do :)
[11:45] <ajmitch> raphink: you know where to file bugs :)
[11:46] <raphink> well I don't even have install-menu on my system
[11:46] <raphink> I don't know what this is
[11:46] <raphink> nevermind
[11:47] <raphink> ajmitch: shall I file a bug for the changelog stuff?
[11:48] <ajmitch> changelog was screwy before the last upload
[11:48] <raphink> yes
[11:49] <raphink> so I don't bother with it?
[11:49] <raphink> or what?
[11:49] <ajmitch> do it if you wish, but it'd probably be a minor bug at most
[11:49] <raphink> yes
[11:49] <raphink> well it makes lintian shouts
[11:49] <raphink> otherwise it's surely not anything important ;)
[11:49] <ajmitch> yep
[11:53] <raphink> ooo there never was an -ubuntu version of enlightenment yet?
[11:53] <raphink> hmmm
[11:53] <raphink> yes there was ...
[12:00] <psusi> what was the dpkg switch to find out from which package a file comes from?
[12:00] <raphink> -S
[12:01] <psusi> this is frigging weird
[12:02] <raphink> what?
[12:02] <psusi> the pktsetup that is installed from the binary deb is NOT built from the source deb
[12:02] <psusi> for udftools
[12:02] <raphink> how do you mean?