[17:07] <TheLordOfTime> lol... * EeeBotu has quit (Excess Flood)
[17:07] <TheLordOfTime> that's funny, it posted so many things at once it died xD
[18:14] <TheLordOfTime> hggdh, do you manage eeebotu?
[19:09] <hggdh> TheLordOfTime: I do indeed


[08:09] <Cimi> kwwii, you should update ASAP
[08:09] <Cimi> community themes are faulty with the contrast
[12:03] <thorwil> hello!
[12:14] <kwwii> hi thorwil
[12:15] <kwwii> thorwil: btw, _MMA_ won't be around for a few days, he has some stuff to take care of
[12:15] <thorwil> kwwii: yes, got mail from him saying so :)
[12:16] <kwwii> cool
[12:17] <carciofo> hi there
[12:17] <carciofo> a question about videoediting
[12:18] <carciofo> what to an ogg theodora video get on you tube?
[12:19] <thorwil> carciofo: i'm not entirely sure, but it could be that you can submit in theora format directly
[12:19] <carciofo> or so
[12:19] <carciofo> o knbow
[12:19] <carciofo> it must be an avi
[12:19] <carciofo> i have cinelerra
[12:19] <carciofo> looking for the option export in avi
[12:20] <carciofo> what to do?
[12:22] <kwwii> I just use ffmpeg but it is quite confusing for many
[12:22] <kwwii> or mencoder perhaps, but again, quite confusing
[12:22]  * kwwii gets lunch
[12:26] <carciofo> and where in cinelerra find i the option?
[12:26] <thorwil> carciofo: http://lampcomputing.com/node/27
[12:39] <carciofo> ah tnx
[12:52] <carciofo> so ganz bin ich noch nicht schlau gfeworden
[12:52] <carciofo> is ffmpeg ein eigenes programm
[12:52] <carciofo> oder ein exportcodec in cinelerra?
[13:41] <thorwil> carciofo: ffmpeg is a separate application
[13:43] <carciofo> ah
[13:43] <carciofo> tnx
[20:16] <thorwil> what's the common observation here, does the list get the most random opinions art the start of each release cycle, or is it more towards the middle?
[20:59] <kwwii> thorwil: at the very beginning we get lots of random ideas and at the end we get random opinions
[21:00] <thorwil> ah, right. kinda forgot the ideas :)
[21:02] <thorwil> good night!


[15:47] <Laney> can I use lttng to find out which process calls a particular ioctl?
[15:47] <Laney> I know what userspace thinks the ioctl name and argument are, and I probably know the device
[15:48] <Laney> just want to find out who on earth is calling it :(
[15:50] <Laney> basically I want to track down who is putting the tty into unicode mode when you call udevadm trigger
[15:50] <Laney> it might be systemd but i can't make it admit that
[15:54] <TJ-> Laney: could you do it via dynamic_debug?
[16:05] <Laney> TJ-: ah, I just found it by old school detective work
[16:05] <Laney> "grep"
[16:05] <Laney> but thanks for the hint, nfi about dynamic_debug


[00:16] <Flare183> Any body know how to fix this: http://paste.uni.cc/17831
[00:16] <postg> could someone help me look at the error: http://paste.uni.cc/17831
[00:16] <Flare183> I have already ask
[00:16] <Flare183> ed
[00:16] <postg> I try to upgrade from 7.04 - > 7.10
[00:16] <postg> thank you
[00:16] <postg> so sad
[00:39] <pschulz02> Wahahaha!!!!!
[00:39] <fujin_> wawawwawawawa
[00:40]  * fujin_ blows up pschulz02
[00:40] <pschulz02> Wait foe it..
[00:40] <kgoetz> root@newmoon:~# ldapaddgroup --help
[00:40] <kgoetz> Successfully added group --help to LDAP
[00:40] <kgoetz> WTF!
[00:40] <pschulz02> for it.  It's part of the linux kernel capabilities framework. I am testing different methods of privisioning a tap device for use with kvm. setfcaps is  not in libcap-bin or any other package that I can find.
[02:49]  * antdedyet submitted the question to launchpad's answers section
[02:59] <fujin> You must have the Reductive build library in your RUBYLIB.
[02:59] <fujin> ergh
[03:06] <antdedyet> 'lo dendrobates
[03:07] <dendrobates> antdedyet: hi
[03:08]  * antdedyet is searching for setfcaps in Ubuntu
[03:16] <antdedyet> Nothing I've found so far in Ubuntu is both properly creating & provisioning a user owned tap device that can be used with kvm.
[03:17] <antdedyet> s/creating \& provisioning/creates \& provisions/
[03:21] <dendrobates> antdedyet: hmm, I don't use tap with kvm, but I'll look into it.
[03:26] <antdedyet> dendrobates: a basic test to run, which fails shortly (before the qemu/kvm window pops up) for me and at least for someone on the community docs is this: 'kvm -net nic -net tap -hda foobar.img -boot c'
[03:26] <antdedyet> replace whatever's proper after the tap ...
[03:28] <antdedyet> I have tunctl also that I found with uml-utilities, but kvm won't use the device I've setup with it, using 'sudo tunctl -b -u myuser'
[03:29] <antdedyet> I tracked it down to being that the tuntap kernel driver had NET_CAP_ADMIN capability required since sometime around 2.6.17
[03:30] <antdedyet> 'setfcaps' is to add the capability for any user to on the system to use tun/tap devices to some degree.
[03:31] <antdedyet> But I never found setfcaps and that's where my testing stopped about 5 minutes ago.
[03:35] <dendrobates> I use tap for vpn's without needing setfcaps.
[03:35] <dendrobates> it is probably something else.
[03:39] <antdedyet> dendrobates: There is also the ownership and mode of /dev/net/tun  ... In the beginning, I changed it's mode from 0660 to 0666.
[03:41] <dendrobates> antdedyet: are you using gutsy?
[03:41] <antdedyet> dendrobates: hardy daily ... :)
[03:42] <antdedyet> dendrobates: and of course, on the only machine my processor has the kvm extensions
[03:44] <nealmcb> antdedyet: I'm very glad to hear your thoughts and experiences - exactly what errors are you getting?  I've run into tap/kvm problems also but attributed them to never actually bringing my network down and making my regular eth0 into a bridged device or something like that, so the tap could work with it
[03:45] <nealmcb> my testing is on gutsy
[03:47] <nealmcb> e.g. "can't add tap0 to bridge eth2: Operation not supported" - which i think was because at the time my main network device (eth2) was not bridgeable
[03:49] <nealmcb> using directions like this:  http://compsoc.dur.ac.uk/~djw/qemu.html
[03:50] <dendrobates> soren just updated kvm, there may be a regression.
[03:53] <antdedyet> nealmcb: I have a multiple scenarios that I have been through. Testing one at a time, with the outcome of none of them working, I started by setting up a bridging interface slaved to either of my outgoing ethernet connections, one is cabled, the other wifi (which I use most of the time and really wanted to use - FUD aside). Also an evdo ppp interface at times.
[03:53] <antdedyet> nealmcb: basic error was this:
[03:54] <antdedyet> warning: could not open /dev/net/tun: no virtual network emulation
[03:54] <antdedyet> Could not initialize device 'tap'
[03:56] <antdedyet> nealmcb: I followed those directions too, but started with this page: https://wiki.ubuntu.com/kvm then moved on to for networking input: https://help.ubuntu.com/community/KVM
[03:56] <antdedyet> dendrobates: running an update now
[03:57] <dendrobates> it was a couple days ago, so you are probably using the newest one, but it has not been tested yet.
[03:57] <antdedyet> dendrobates: ah yes, I got that one I believe: 55
[03:58] <antdedyet> soren asked me to let him in on what I came across since I have amd hardware
[03:59] <antdedyet> although, I don't think this is cpu specific.
[03:59] <dendrobates> he uploaded 56, maybe it has hit the repo's yet.
[04:00] <antdedyet> dendrobates: ahh, ok. I use mirrors.kernel.org ... let me change my repo.
[04:05] <nealmcb> antdedyet: have you tried gutsy?
[04:07] <antdedyet> nealmcb: I don't have a gutsy box with kvm cpu extensions. I could test qemu with a bit of setup, but I haven't done that yet.
[04:07] <nealmcb> right - I forgot that
[04:07] <nealmcb> but qemu would be an interesting test
[04:07] <antdedyet> I don't see 56 on mirrors.anl.gov either.
[04:07]  * antdedyet nods
[04:08] <antdedyet> hmm: http://packages.ubuntu.com/hardy/misc/kvm-source
[04:16] <antdedyet> Is there somewhere I'm not looking at to find the 56 package?
[04:16]  * antdedyet doesn't see it in deb sid either ...
[04:31]  * antdedyet shrugs
[05:19]  * antdedyet stretches ... I can't wait to install Ubuntu on more client machines. :)
[05:22] <antdedyet> None of which are desktop machines, all servers.
[05:29] <antdedyet> nealmcb: same error for qemu on gutsy:
[05:29] <antdedyet> warning: could not open /dev/net/tun: no virtual network emulation
[05:29] <antdedyet> Could not initialize device 'tap'
[05:32] <antdedyet> ah: http://kvm.qumranet.com/kvmwiki/ChangeLog
[05:34] <antdedyet> dendrobates tells no lies!
[05:40] <antdedyet>         -net tap,vlan=0,ifname=tap0 \
[05:41] <antdedyet> after 'sudo tunctl -b -u myuser' # when no other tun/tap devices are built/present
[05:41] <antdedyet> gives this on kvm init:
[05:41] <antdedyet> SIOCSIFADDR: Permission denied
[05:41] <antdedyet> SIOCSIFFLAGS: Permission denied
[05:41] <antdedyet> SIOCSIFFLAGS: Permission denied
[05:41] <antdedyet> can't add tap0 to bridge br0: Operation not permitted
[06:17] <antdedyet> After manually populating tap0 with a static address and pointing the dhcp server's listen statement to it, my kvm session gets an IP that is reachable on the host, even with perm denied errors.
[06:34] <nealmcb> antdedyet: interesting!
[07:42] <nealmcb> jdstrand: congrats on becoming an motu!
[07:57] <kraut> moin
[08:10] <owh> nealmcb: Thanks for pointing me at the ubuntu-jeos-builder script. I'm not yet down to 90 seconds, but I'm at 180, which is a whole lot better than 15 minutes for a copy/paste/fixup or 45 minutes for a bare .ISO install. Now all I need to do is combine the options from the various versions so I can specify the hostname, directory, ip address and not have an opt drive, but so far, so good.
[08:19] <soren> antdedyet: I apparantly never got round to uploading kvm 56.. I'll do that today.
[08:23] <antdedyet> soren: nice!
[08:23] <_ruben> any vmware gurus around? .. my ubuntu guest is spamming my sles host with "host clock rate change request" messages .. i've added "clock=pit" to the ubuntu guest's grub but it doesnt seem to make a diff
[08:24] <antdedyet> however, I didn't see anything in the upstream changelog that would lessen the bootstrap aches.
[08:24] <soren> antdedyet: This was about tap devices, was it?
[08:24]  * antdedyet will be happy to test it nevertheless
[08:24] <antdedyet> soren: Yes, it was about tap devices.
[09:12] <soren> antdedyet: Uploading kvm 56.
[09:14] <antdedyet> soren: Spectacular.
[09:16] <antdedyet> I've _really_ got to get more clients on Ubuntu so I can develop more with it. It may get difficult to justify why testing out new servers settings takes awhile if they find out I'm running them all inside a Ubuntu virtual machine. :)
[09:22] <soren> :)
[10:02] <sergevn> Is it possible to configure your ubuntu server to use the smtp server of your ISP to send mail?
[10:03] <sergevn> If so, is there any good tutorial for this? Searched the web, but cant find a clear and simple tutorial.
[10:04] <avatar_> installing een mta eg exim4 wil ask you a few questions about how to configure the mailserver
[10:05] <avatar_> one of the options is, smtp with smarthost, where smarthost is the smtp-server of your  provider
[10:08] <sergevn> avatar_: Thx, that cleared up a little bit, can i paste some dutch output of the setup wizard?
[10:10] <sergevn> Im a bit confused what to fill in
[10:13] <avatar_> sergevn: lets switch to #ubuntu-nl, i'm dutch too :)
[10:24] <RCOMALTA> any one have ubutu as mail server ?
[10:28] <avatar_> RCOMALTA: we use ubuntu in our mailsetup
[10:28] <soren> RCOMALTA: Sure.
[10:30] <avatar_> 6x mx, 4x filter (virus) 6x spamd, 3x maildrop, 4x smtp
[10:30] <avatar_> all running exim
[10:30] <avatar_> configuration from ldap
[10:31] <RCOMALTA> avatar is smtp and pop 3 mail setup
[10:32] <avatar_> RCOMALTA: we are running mail voor a few thousand domains, so we use quite a bit of servers. Running mail for a single lowtraffic domain can happily run smtp/pop/imap on one singel server
[10:34] <RCOMALTA> avatar, your mail servers are all with ubuutu
[10:49] <RCOMALTA> i will do it
[10:49] <RCOMALTA> and the end computers are windows xp or vista
[11:44] <RCOMALTA> avatar the end users are with windows xp and vista
[13:14] <jdstrand> nealmcb: thanks!  :)
[14:01] <sommer> ScottK: morning, time for a question?
[14:02] <sommer> ScottK: I was wondering about https://wiki.ubuntu.com/MOTU/Clamav
[14:29] <nealmcb> wonderful news - they've finally figured out that our voting equipment is deeply flawed - http://www.bradblog.com/?p=5451
[14:30] <nealmcb> so I'll miss the server team meeting - I'll be be down at the hearing today
[14:30] <sommer> nealmcb: heh... I was just reading an article on ArsTechnica about the Ohio voting machines
[14:30] <nealmcb> I've been pointing this stuff out for 4 years now....  finally getting more traction....
[14:31] <sommer> is it too late to change before 08 elections?
[14:33] <sommer> wow actually they're talking about the same machines used in ohio
[14:33] <sommer> nealmcb: good luck with that... seems like a big mess to me
[15:00] <zul> is there a meeting going on now?
[15:00] <soren> It's in an hour, I think.
[16:00] <soren> Meeting in #ubuntu-server.
[16:00] <soren> Meeting in #ubuntu-meeting, I mean.
[16:02] <_ruben> heh
[16:41] <soren> !mta
[16:41] <ubotu> A Mail Transfer Agent (MTA) is the server software that sends and queues mail. The default MTA (and !MDA) on Ubuntu is !postfix ("exim" is also officially supported). See also !MailServer and !MUA
[16:59] <soren> Fantastic. I upload kvm 56, and 6 hours later, kvm 57 is released.
[17:21] <rodpod> who makes the best USB keyboard/mouse kvm's, w/ dvi?
[17:30] <ivoks> sorry for the meeting :/
[18:33]  * ScottK is curious if anyone has comments on the message I just sent to the Ubuntu Server ML.
[18:45] <sommer> ScottK: I'm for it... instructions have been added to the Mail Filtering seciton :-)
[18:46] <ScottK> sommer: Great.  To answer your clamav question, I haven't had much time for it recently.
[18:46] <ScottK> sommer: Now for the fun part is we are about to get libclamav3 in the version that was just released yesterday so we need to worry that library transition first.
[18:47] <sommer> cool, I was looking at packaging again and remembered the backport project
[18:47] <ScottK> OK.  We still need to do it, but we need to fix Hardy first.
[18:47] <sommer> sure
[18:48] <sommer> I also realized that I didn't understand exactly what a "backport" is
[18:48] <sommer> I actually backported the new api to the existing source instead of backporting the new package... doh
[18:48] <sommer> it was fun though... so I can't complain too much
[18:49] <ScottK> sommer: If you can figure the other way around to backport a clamav with the old API, that would solve the whole Dapper problem right away.
[18:49] <sommer> ScottK: heh... I really don't know that much C :/
[18:49] <ScottK> We can just patch the current clamav to use the old API, upload that to dapper-backports and declare victory.
[18:50] <ScottK> Well if you figured it out one way, you ought to be able to do the reverse, right???
[18:50] <sommer> mmmMMMM... that really doesn't sound too hard
[18:51] <sommer> there's documentation for the other way though :)
[18:51] <sommer> I'll do some digging and see where it takes me
[18:54] <ScottK> sommer: Cool.  That's solve a huge problem in Dapper.
[18:57] <sommer> ScottK: another question regarding python-policyd-spf.  The order of execution is postfix filters a message through dkim-milter and python-spf then sends it to Amavisd?
[18:58] <sommer> or amavisd scans it first then postfix pipes it through any other "outside" filters?
[18:58] <ScottK> sommer: It's a function of how you set up your system.
[18:58] <sommer> okay, I docuemnted it the first way
[18:58] <sommer> trying to explain how all the peices fit together
[18:59] <ScottK> Generally avamisd-new will run after queue.
[18:59] <ScottK> Running before queue filters can be tricky.
[18:59] <sommer> that's what I was thinking after reading the postfix book and amavisd docs
[18:59] <ScottK> Policy servers will run before queue as will milters (although milters are more complex).
[19:00] <sommer> cool that's the one part of documenting the postfix+amavisd+spamassassin+clamav+spf+dkim I wasn't quite sure of
[19:01] <sommer> thanks... if there are any issues with the mail filtering section you find just let me know
[19:11] <ScottK> sommer: Sure.  I guarantee you will have to keep harassing me to look at it.
[19:31] <leonel> ScottK:  for dapper clamav  as you say to backport the clamav api ..
[19:32] <leonel> ScottK:  can this be to replace  clamav's   libclamav   with    ubuntu  backported api libclamav ??
[19:32] <ScottK> I'd put it a little differently.
[19:33] <ScottK> I'd take the current libclamav and patch it to use the old API and backport that.
[19:33] <leonel> this way there won't be   dependency problems ?
[19:37] <ScottK> Exactly.
[19:40] <leonel> current  you mean   dapper's .88  or  new  .92 ?
[19:47] <Centaur5> I'm stumped here, my thin clients that have been working for a month just stopped letting me login since Sunday.  The only thing that changed is that I finished setting up a chillispot/freeradius server.
[19:47] <Centaur5> I've already tried running the ltsp-update-sshkeys and I do see the client connecting in syslog and I don't see any error messages when login is attempted.
[19:56] <ScottK> leonel: It'd be to make the current (still 0.91.2) libclamav look like the 0.8x one to the rest of the packages in the system.
[20:18] <leonel> ScottK:  Ok i got it ...
[20:23] <ScottK> leonel: Just checking to see did you get /msg I just sent you?
[20:24] <leonel> yes
[21:38] <ScottK> leonel: 0.92~dfsg-0build1 uploaded.  Now we wait for the archive admins.
[21:39] <leonel> ScottK: great !
[21:40] <leonel> ScottK: the next is do a merge to hardy then backport to gutsy   right ?
[21:40] <ScottK> Actually it looks like a sync.  I think Debian has all our needed changes now.
[21:41] <ScottK> Because of the soname change we've got the same problems backporting to Gutsy and Feisty that we've already had with Dapper/Edgy.
[21:41]  * leonel goes to read  the diff  in  merge and sync ...
[21:51] <fujin_> what's the preferred way to 'git' on Ubuntu?
[21:51] <fujin_> cogito?
[22:25] <zul> git-core package
[23:53] <owh> I need to create a gui interface for some server configuration stuff and I was wondering what the ubuntu preferred tools were.
[23:54] <owh> I've been looking at gtkdialog, but the included examples don't all work and the manual is pretty skinny.


[04:40] <princej88> Hi,
[04:40] <princej88> how can i go about contributing to th georgia loco team?
[04:41] <princej88> the website looks like it needs to be badly updated
[04:57] <fignew> princej88: last I heard boredandblogging was in charge


[04:31] <wh1t3warri0r> hello
[04:31] <valorie> greetings, wh1t3warri0r
[04:34] <wh1t3warri0r> Do any one program?


[12:04] <Mitario> hmm, many missing packages in universe
[12:04] <Mez> "missing"
[12:05] <sistpoty> unmet deps?
[12:05] <Mitario> depending on missing packages
[12:05] <Mitario> yeah with install candidate, but no binary
[12:07] <tseng> Burgundavia: bug #1167 is upstream, not mine, and its probably too late to fix for breezy
[12:08] <Mitario> brb shower
[12:08] <Mitario> crimsun, i'll get you some more fixes in a bit ;-) be prepared for my wrath
[12:09] <crimsun> Mitario, uploaded through thoughttracker, updating wiki page.
[12:09] <Mitario> crimsun, cool ftp-master back?
[12:11] <crimsun> yup
[12:12] <Mitario> crimsun, damn, you're at least halfway trough, I should hurry ;)
[12:13] <crimsun> hehe
[12:15] <Mitario> hmm, I need to get myself a new workstation
[12:15] <Mitario> an amd64 would be nice
[12:16] <crimsun> Mitario, t1lib-dev is not available on amd64, so tex-guy will FTBFS
[12:16] <Mitario> hmm bah
[12:16] <Mitario> no it should be libt1-dev
[12:16] <Mitario> didn't I change that?
[12:16] <crimsun> not in debian/control, nope
[12:17] <crimsun> you mentioned it in debian/changelog ;)
[12:17] <Mitario> no that was the rebuild, but
[12:18] <Mitario> umm, it's changed here locally
[12:18] <Mitario> probably uploaded the wrong debdiff :)
[12:18] <Mitario> yes
[12:18] <Mitario> sec
[12:18] <Mitario> i'll upload the new one
[12:18] <crimsun> ok
[12:21] <Mitario> done, link updated
[12:21] <Mitario> at least, when the wiki saves
[12:21] <Mitario> yup now
[12:24] <Mitario> showimg fixed
[12:33] <Mitario> crimsun, is there an easy way to check wether the packages are build and installed?
[12:34] <sistpoty> Mitario: the buildlogs are at http://people.ubuntu.com/~lamont/buildLogs/
[12:35] <crimsun> Mitario, when they're installed, they'll be in archive.ubuntu.com/ubuntu/pool/
[12:49] <tseng> Mez: if you have other things to do, it seems not worth backporting mono at this point
[12:49] <tseng> Mez: its been stalling and we only have a month of hoary left
[12:50] <tseng> Mez: for breezy we wont have to backport the whole damn thing.
[12:50] <Mitario> crimsun, ahh! 2 to go, and I'm still compiling
[12:52] <sistpoty> btw.: ghc6 now building for >4 hours ... maybe i should kill that cpuburn *g*
[12:53] <slomo> sistpoty: maybe you should kill upstream ;)
[12:53] <sistpoty> hehe
[12:54] <Mitario> sistpoty, what kind of system do you have?
[12:54] <sistpoty> amd duron 1300
[12:54] <sistpoty> so i386
[12:54] <Mitario> ah
[12:54] <Mitario> yeah
[12:54] <Mitario> athlon 1800 here
[12:54] <ajmitch> someone pass round the collection plate for sistpoty
[12:54] <sistpoty> hrhr
[12:55] <Mitario> sfs is pretty big too
[12:55] <sistpoty> even my gf has a faster system than i do... :/
[12:55] <Mitario> heh
[12:57] <sistpoty> but i played doom3 all on this machine... this was almost as funny as quake1 on my 486 (frame -> turn around -> guess -> shoot -> frame -> damn, missed!)
[12:57] <ajmitch> haha
[12:58] <tseng> ajmitch: https://launchpad.net/malone/bugs/1171
[12:58] <tseng> one of the 19890 bugs daniel assigned me today
[12:58] <tseng> ive closed most of them, congrats to filers for following up but not closing their bugs
[12:59] <crimsun> Mitario, are you sure showimg -1ubuntu1 isn't sufficient? What does your -1ubuntu2 change over doko's previous cxx rebuild?
[12:59] <crimsun> -1build1 and -1build2, sorry
[01:01] <ajmitch> tseng: thanks
[01:02] <ajmitch> I should ask for sync from elmo, just uploading to sid now
[01:02] <tseng> great
[01:03] <tseng> man next week at work will be great
[01:03] <tseng> we are shipping out brand new smp xeon 64s with ubuntu
[01:03] <ajmitch> 128Kbps upload sucks for debian
[01:03] <tseng> and reclaiming all the old x86 boxes with random RH versions
[01:03] <Mitario> crimsun, just a rebuild actually
[01:03] <ajmitch> tseng: oh ship me one, please
[01:04] <Mitario> crimsun, because currently it doesn't install
[01:04] <tseng> ajmitch: only 1 spare, sorry
[01:04] <crimsun> Mitario, ok
[01:04] <tseng> ajmitch: corporate is making everyone buy the same model of server now, so we got twice the power we need
[01:04] <crimsun> Mitario, I'll note it in debian/changelog
[01:04] <tseng> ajmitch: i cant complain.
[01:04] <Mitario> crimsun, and build1 is for ABI update, build2 is actually package names
[01:04] <Mitario> crimsun, ok
[01:05] <crimsun> package names? Hmm
[01:05] <crimsun> Make sure you uploaded the correct diff
[01:05] <tseng> ajmitch: i think i will sneak a pbuilder on the spare
[01:05] <Mitario> yeah I mean, linking against the correct packages
[01:05] <crimsun> ah, ok.
[01:05] <ajmitch> tseng: sweet
[01:32] <Mitario> sffview fixed
[01:33] <sistpoty> dpkg-buildpackage -rfakeroot  14344,43s user 1290,34s system 87% cpu 4:56:57,47 total
[01:33] <sistpoty> ^^ ghc6 built :)
[01:33] <sistpoty> now I'll redo this in pbuilder *cough*
[01:33] <Mitario> it build without problems?
[01:34] <sistpoty> yesss :) finally... (took a new upstream version)
[01:35] <Mitario> get it in universe asap ;-)
[01:35] <sistpoty> hm... i think this won't get there until sunday or so... ;) but i try to get my pbuilder working tonight :)
[01:35] <Mitario> woops, that sounds a bit pushy
[01:35] <Mitario> heh great :)
[01:36] <sistpoty> i.e. get my pbuilder use the now created ghc6 *g*
[01:42] <Mitario> sfftobmp done
[01:48] <Mitario> ha Seveas
[01:53] <Seveas> hi
[01:54] <sistpoty> hi Seveas
[01:55] <Mitario> seaview fixed
[02:24] <Mitario> if some packages has buildX should I then change it to ubuntuX or just ubuntu1?
[02:26] <tseng> for a change, or antother rebuild?
[02:27] <Mitario> change
[02:28] <sistpoty> for a change use ubuntuX
[02:28] <ajmitch> I'd say ubuntu1
[02:29] <tseng> drop the build
[02:29] <ajmitch> (just to be difficult) ;)
[02:29] <sistpoty> sorry, didn't read carefully enough ;)
[02:29] <Mitario> yeah ok, I was wondering if you should continue the X from the build for instance build4 -> ubuntu5, or build4 -> ubuntu1
[02:29] <tseng> -> ubuntu1
[02:30] <sistpoty> ubuntu is higher than build? did i finally get how version names work?
[02:30] <ajmitch> sistpoty: yes, that's why we use it
[02:30] <ajmitch> all a-zA-Z are lower than numbers
[02:31] <sistpoty> hehe, i looked about 5 times at the policy and much too often get it wrong *g*
[02:31] <Seveas> sistpoty, that's what dpkg --compare-versions is for :)
[02:32] <sistpoty> thx, Seveas... didn't know that
[02:32] <Mitario> ajmitch, too keep up with my work
[02:32] <Seveas> ajmitch, to look 1337 ;)
[02:32] <ajmitch> Seveas: that's what I was thinking ;)
[02:32] <Mitario> ajmitch, so I can keep up with what's uploaded and what's not
[02:32] <Mitario> oh, and as evicence for the CC ;)
[02:33] <Mitario> but I think i'll also pass that without motu stuff
[02:33] <Seveas> ajmitch, the MOTU with the longest list gets a free ubuntu CD ;)
[02:33] <ajmitch> haha
[02:36] <ajmitch> Mitario: I mean having things like 'clustalw-mpi' on there
[02:37] <Mitario> owh, i have that one too ;)
[02:37] <Mitario>  Done
[02:37] <Mitario> clustalw-mpi
[02:37] <Mitario>
[02:37] <Mitario> fixed by ajmitch
[02:37] <ajmitch> Mitario: that's what I was pointing out :P
[02:37] <Mitario> hehe
[02:37] <ajmitch> since there was no fixing involved, and nothing really to be done
[02:38] <Mitario> I just put every package I worked on on that special wiki page
[02:38] <Mitario> but then I heard that you already fixed it, so it's just administration :)
[02:39] <ajmitch> all I did was dch, debuild -S, and dput ;)
[02:40] <Mitario> hehe :) I can't do that yet
[02:40] <Mitario> elmo's a bit busy atm :(
[02:41] <ajmitch> oh, I did make sure to run pbuilder & dpkg-deb to check dependencies before uploading, of course :)
[02:42] <Seveas> why debuild instead of dpkg-buildpackage?
[02:43] <ajmitch> because debuild does more
[02:44] <ajmitch> and is less to type
[02:44] <Seveas> hehe
[02:44] <Seveas> ok
[02:44] <ajmitch> It first runs dpkg-buildpackage, then runs lintian and/or linda on the .changes file created (assuming that lintian and/or linda is installed), and finally signs the .changes and/or .dsc files as appropriate
[02:44] <Seveas> nice
[02:45] <Seveas> lots of people do that
[02:45] <Seveas> according to breezy-changes
[02:45] <ajmitch> sure
[02:49] <Mitario> scorched3d fixed
[02:52] <slomo> waah breezy is broken for my ibook... hm, need to talk to some kernel guy tomorrow :/
[02:52] <slomo> gn8 everybody
[02:52] <Mitario> nite
[02:53] <sistpoty> gn8 slomo
[02:54] <ajmitch> Mitario: what did you do for scorched3d?
[02:55] <ajmitch> hm
[02:55] <sistpoty> Mitario: did you check it on amd64? last version worked on i386 but broke on amd64
[02:55] <ajmitch> because we were trying to get in a new openAL for it
[02:58] <Mitario> ah
[02:58] <Mitario> well I can't upload
[02:58] <Mitario> I just put my debdiff on the wiki
[02:58] <Mitario> so other MOTU's can check it out
[02:59] <Mitario> sistpoty, no, I onfortunately don't have amd64 :(
[02:59] <ajmitch> people have been working on scorched3d a bit
[02:59] <Mitario> ah right
[02:59] <ajmitch> hm
[02:59] <Mitario> I just did the GL/GLU transition with the build-deps
[03:00] <ajmitch> non-native version with native packaging
[03:00] <ajmitch> ugly
[03:00] <sistpoty> Mitario: i don
[03:00] <sistpoty> + t have amd64 as well ;) but siretart who wanted to sponsor me has
[03:00] <sistpoty> ;)
[03:01] <Mitario> :)
[03:01] <Mitario> crimsun has been checking my previous submissions out
[03:01] <Mitario> also on amd64 iirc
[03:01] <Mitario> sablevm deps also fixed
[03:02] <sistpoty> Mitario: if you want something hard, you could check rscheme (is on my list, but i don't think, i can handle it)
[03:03] <sistpoty> with gcc-4 it builds the compiler, but the compiler segfaults... and upstream didn't do anything since 4 month
[03:03] <Mitario> hrm
[03:03] <Mitario> ok
[03:03] <Yagisan> I have an amd64
[03:03] <Mitario> i'm just now gong trough the alphabet of UnmetDeps :)
[03:03] <Mitario> backwards
[03:04] <sistpoty> hehe
[03:04] <ajmitch> Mitario: I've just spent the last day or two rebuilding them all
[03:04] <Yagisan> what's the problem, does scorched3d FTBFS ?
[03:04] <Yagisan> I'm happy to run a test build if you need it
[03:05] <sistpoty> Yagisan: the current version FTBFS on amd64... but imo siretart did already do some work for it (not sure... ajmitch?)
[03:05] <Mitario> ajmitch, the whole list?
[03:06] <ajmitch> Mitario: yes
[03:06] <Mitario> and just skimmed trough it
[03:06] <ajmitch> Mitario: I generated a list & fed all of them to pbuilder
[03:06] <Mitario> and fixed some debs, and rebuilds for others
[03:06] <Mitario> ah
[03:06] <ajmitch> I've got several MB just of logfiles :)
[03:06] <Mitario> hehe
[03:07] <Mitario> umm, well, crimsun uploaded some fixes and rebuilds of mine, so am I ignoring your work now? :S
[03:07] <Mitario> or did you upload the ones you fed to pbuilder
[03:07] <ajmitch> no, I still have to go through a lot of the logs
[03:08] <Mitario> ah ok
[03:08] <ajmitch> so there's not a *lot* of stepping on toes here
[03:08] <ajmitch> it's best to check breezy-changes for any recent uploads
[03:09] <Mitario> yeah I do
[03:09] <Mitario> hehe :)
[03:10] <Mitario> hmm, ok rubrica seems to work again too now
[03:11] <Seveas> ajmitch, hint: rss :)
[03:11] <ajmitch> Seveas: requires me to run another program to read the rss
[03:12] <ajmitch> I find gmail adequate for this
[03:12] <Seveas> hehe, me has an rss reader op all the time
[03:16] <ajmitch> silly me, k3d needed build-dep changes
[03:21] <ajmitch> Mitario: but is your debdiff correct? :)
[03:22] <Mitario> ajmitch, well take a look :)
[03:22] <Mitario> I put them on the wiki page so someone else can check them if the fix is right, so someone can upload it :)
[03:22] <ajmitch> Mitario: right, I wouldn't have an explicit depends
[03:23] <ajmitch> but Build-Depends & ${shlibs:Depends}
[03:23] <ajmitch> which indicates that it's socketapi that needs fixed, rather than rsplib
[03:23] <Mitario> aaah right
[03:23] <Mitario> oki :)
[03:24] <ajmitch> a pkg that b-d's on socketapi should get the depend automagically
[03:24] <Mitario> yeah
[03:25] <ajmitch> fixing rsplib is a workaround - not wrong, but not the best way imho
[03:25] <Mitario> already thought it was odd that socketapi was defined there
[03:25] <Mitario> no I agree
[03:26] <Mitario> hehe :)
[03:27] <ajmitch> it looks like it shouldn't have been transitioned
[03:27] <Mitario> btw should we use cdbs in favor of a normal rules file?
[03:27] <Mitario> and transition the already existing
[03:27] <ajmitch> Mitario: we usually do
[03:27] <Mitario> ok
[03:27] <ajmitch> no, we don't change the existing packaging to use cdbs
[03:27] <ajmitch> that would be an evil fork
[03:28] <Mitario> ah ok
[03:29] <ajmitch> right, socketapi exports a C ABI
[03:29] <ajmitch> fun! :)
[03:29] <Mitario> wohoo!
[03:29] <Mitario> do you think universe will be 'ready' by breezy?
[03:30] <ajmitch> hah no
[03:30] <ajmitch> amazing
[03:30] <Mitario> hehe ok
[03:30] <Mitario> just curious
[03:30] <ajmitch> nothing actually reverse-depends on socketapi1c2
[03:30] <ajmitch> safe to de-transition
[03:37] <Mitario> hmm rmpi needs a rebuild
[03:38] <ajmitch> ok, will sign/upload
[03:39] <ajmitch> since I already have generated debdiffs :)
[03:39] <ajmitch> done
[03:39] <Mitario> ajmitch, if you have time/want to, could you review my debdiffs for packages you haven't worked on on that wiki page? :)
[03:39] <Mitario> thanks
[03:41] <ajmitch> I can, but the problem is that I've done a fair bit of the work automagically - and I just need to sign & upload most of the changes made :)
[03:42] <Mitario> yeah ok :)
[03:42] <Mitario> did you only check for packages that needed to rebuild, or also debian/control fixes?
[03:43] <ajmitch> so far I've just thrown everything at pbuilder & got source packages ready for upload
[03:43] <ajmitch> and I have build logs to work from
[03:43] <Mitario> ok
[03:43] <ajmitch> as well as binary debs to check with dpkg-deb
[03:43] <Mitario> hmm, do you think I should continue my list? or focus on something else..
[03:43] <ajmitch> keep going if you want
[03:44] <Mitario> yeah, but will it be useful :)
[03:44] <ajmitch> it probably will be :)
[03:45] <sistpoty> Mitario: s.th. useful to look at would be kaffe... I've also been after it ;)
[03:45] <sistpoty> Mitario: if you are interested
[03:45] <Mitario> allright
[03:45] <ajmitch> there are plenty of packages that FTBFS
[03:46] <sistpoty> Mitario: basically sync from debian, but imo autoconf-stuff (which *is* in source-tarball) must be regenerated
[03:46] <ajmitch> sistpoty: we got kaffe synced from debian
[03:46] <sistpoty> and it built?
[03:46] <ajmitch> no :)
[03:47] <ajmitch> http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/k/kaffe/2%3A1.1.5-5/kaffe_2%3A1.1.5-5_20050826-0448-ia64-failed.gz
[03:47] <sistpoty> there was some pango/cairo/freetype2 issue, but imo that all is from wrong configure (which in theory could be regenerated easily)
[03:47] <ajmitch> looks like a missing build-dep on freetype, for a start
[03:48] <ajmitch> /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory
[03:48] <sistpoty> no, gtk2 deps on freetype
[03:48] <sistpoty> (indirectly)
[03:48] <sistpoty> i checked that yesterday ;)
[03:49] <ajmitch> ok :)
[03:49] <sistpoty> but i wasn't able to get the right automake-version/autoconf-version to get anywhere near a new configure *g*
[03:49] <ajmitch> welcome back, ogra ;)
[03:49] <sistpoty> hi ogra
[03:50] <ajmitch> it's probably just dsl reconnecting
[03:50] <sistpoty> hehe
[03:54] <Mitario> hmm, have to go to bed now, 4am here :)
[03:55] <Mitario> sistpoty, kaffe is building so I'll check the errors in a few hours
[03:55] <Mitario> ajmitch, have fun with the rest of the unmetdeps good luck! :)
[03:55] <sistpoty> Mitario: ok... 4am here as well ;)
[03:55] <ajmitch> Mitario: heh, thanks ;)
[03:55] <sistpoty> gn8 Mitario
[03:55] <Mitario> nn
[03:56] <sistpoty> i still want to trigger ghc6 in pbuilder... and i forgot some build-deps on haddock :(
[03:56] <Mitario> sistpoty, those tests, are they after compiling? or in the middle of it..
[03:57] <sistpoty> Mitario: what tests do you mean?
[03:57] <Mitario> sistpoty, oh nm, it was running some test on some java examples
[03:57] <Mitario> but it's configuring another component now
[03:57] <Mitario> (building kaffe)
[03:58] <Mitario> and now I'm going to force myself to get up
[03:58] <sistpoty> the errors came up later iirc, when the library is being built (swing and stuff, by gtk2 :)
[03:58] <sistpoty> or at least awt
[04:50] <sistpoty> gn8 everybody
[05:19] <phlaegel> ajmitch: that nip2 build has issues...
[05:24] <ajmitch> phlaegel: worked for me, what are the issues?
[05:42] <phlaegel> segfaults when doing anything... opening preferences, opening and example workspace...
[05:58] <crimsun_> yeesh, Mitario certainly left me a pile o' work
[05:58] <ajmitch> crimsun_: that'll only take you a couple of minutes to process
[06:00] <crimsun_> ajmitch: I usually wget everything, pbuild it all, do the install/upgrade/remove check, sign, then upload
[06:00] <ajmitch> crimsun_: yes, but I've already got those first 2 steps done for most of that list :)
[06:01] <crimsun_> k
[06:02] <ajmitch> phlaegel: right, I can get that fixed in a couple of minutes..
[06:22] <glick> hi
[06:22] <ajmitch> hello glick
[06:22] <glick> sup ajmitch
[06:23] <ajmitch> building packages, again :)
[06:23] <glick> heh
[06:23] <glick> nice
[06:24] <glick> id like to join and help contribute but i dont kwo where to begin ive been reading the motuwannabetip site and all that
[06:24] <ajmitch> yep
[06:25] <ajmitch> there's plenty of packages to be fixed, a number of programs that users have requested be packaged
[06:25] <ajmitch> and only a few of us working on it
[06:25] <crimsun_> MOTU covers a lot. It may be easier for you if you begin by picking out a couple areas you favor, like documentation or packaging
[06:25] <glick> id like to work on packaging
[06:25] <glick> though i can do both
[06:25] <crimsun_> sure, there's a never-ending stream of packaging work - not the least of which is reviewing
[06:26] <glick> like what? what programs need packagign?
[06:27] <ajmitch> wiki.ubuntu.com/UniverseCandidates
[06:28] <ajmitch> stuff to fix is on the MOTUTodo page
[06:30] <glick> kguitar i like that
[06:32] <ajmitch> phlaegel: ok, nip2 works fine for me now, so I'll upload
[06:33] <glick> wow there is some great software there
[06:33] <glick> that should definatly be in the repos
[06:34] <ajmitch> glick: sure, but someone has to have time to package it :)
[06:35] <glick> how many packages do you guys usually manage?
[06:36] <ajmitch> umm
[06:36] <ajmitch> I think universe has well over 10000 binary  packages
[06:36] <ajmitch> so we have to get them all installable, at least
[06:36] <glick> how many people work on that?
[06:37] <ajmitch> about 20-25, part-time at best :)
[06:38] <glick> if they need packageing why are they still listed there if under status alot of them say they have develipers workin on it
[06:38] <ajmitch> because packaging something isn't a 5 minute task
[06:39] <ajmitch> and ew have to try & keep the wiki up to date as well
[06:39] <ajmitch> somone might volunteer to work on something & never get very far
[06:40] <ajmitch> or it's been done, and waiting for us to review it before upload
[06:40] <ajmitch> kguitar is like that
[06:40] <glick> i see
[07:02] <phlaegel> ajmitch: nice... thanks
[08:03] <crimsun_> thank goodness my pbuilder's amd64, cos this mess would have FTBFS horribly
[09:42] <jtan325> hi is anyone here? i have a rather "urgent" but easy-for-motus question
[09:44] <ajmitch> yes I am here
[09:45] <ajmitch> why is it urgent?
[09:46] <jtan325> we're releasing sunday, i'd like to get beta test pacakges out tonight
[09:46] <jtan325> the question is
[09:46] <jtan325> is dpkg --update-available <pkg file> the way to "upgrade" a locally installed .deb?
[09:46] <jtan325> i.e. if the beta test package is 1.2.9
[09:46] <jtan325> and when we release 1.3.0 on sunday
[09:47] <ajmitch> no, I'd never use that
[09:47] <siretart> morning
[09:47] <ajmitch> I'd always just use dpkg -i
[09:47] <ajmitch> hi siretart
[09:47] <siretart> huhu ajmitch
[09:47] <jtan325> hey siretart
[09:47] <jtan325> dpkg -i automatically does the upgrade?
[09:47] <ajmitch> that's what it's for
[09:48] <jtan325> ok awesome. thanks
[09:48] <ajmitch> --update-available is not used for installing anything
[09:48] <jtan325> haha
[09:48] <ajmitch> I don't understand why you'd want to use --update-available?
[09:48] <siretart> no, a mere user won't need that at all
[09:51] <jtan325> no i have no idea what's going on
[09:51] <jtan325> i just did man dpkg
[09:51] <jtan325> and it looked like the closest thing to what i needed :-)
[09:52] <jtan325> what's the standard versioning for a pre-release?
[09:52] <jtan325> i.e. we're releasing 1.3.0 on sunday
[09:52] <jtan325> 1.2.9 was what i could  think of
[09:52] <ajmitch> something like that, yes
[09:52] <ajmitch> or 1.2.9+1.3.0.alpha1 :)
[09:58] <siretart> nowadays, recent dpkg also support '~'
[09:59] <siretart> so you could also give your package the version 1.3.0~alpha1
[09:59] <siretart> which would be less than 1.3.0
[09:59] <siretart> note that this won't work with dpkg in sarge or earlier
[10:03] <Seveas> I love that ~ trick
[10:03] <Seveas> I'm using it for backports :)
[10:03] <ajmitch> and not with the current debian archive, iirc
[10:03] <ajmitch> since dak isn't using that code yet
[10:17] <siretart> ajmitch: ubuntu's dak seems to support it: http://archive.ubuntu.com/ubuntu/dists/hoary-backports/
[10:17] <siretart> yay! using gpg-agent has never been easier. just a 'echo use-session-pgp-agent | sudo tee -a /etc/X11/Xsession.options' and you are done
[10:18] <Treenaks> siretart: because not everyone has a pgp agent
[10:18] <Treenaks> uh
[10:18] <Treenaks> key
[10:20] <siretart> not even 1k memory is used.. hmm
[10:28] <pef> hi
[10:30] <crimsun_> hi
[10:35] <ajmitch> siretart: ubuntu's might, but I tend to like keeping things compatible with debian :)
[10:40] <jtan325> this is sorta off-topic, but what's the quickest and fastest way to keep track of really simple website statistics?
[10:40] <jtan325> on a server that you don't have root access to
[10:54] <siretart> ajmitch: can you explain me something packaging related, espc. dh_shlibs?
[10:54] <siretart> background: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276979
[10:55] <siretart> the binary package HAS a shlibs file, I can see it with dpkg -I. But why is this not sufficient for debhelper to create a versioned depend?
[10:55] <pef> anyone using OOo on breezy ?
[10:55] <siretart> pef: does OOo2 cound?
[10:55] <siretart> count?
[10:56] <pef> yes, 2, sorry :)
[10:57] <pef> siretart, can you confirm me OOo2 has a "qt" look ?
[10:57] <pef> isn't it a bug ?
[11:00] <siretart> pef: err, my openoffice has a nice gtk2 look
[11:00] <siretart> ?
[11:00] <ajmitch> siretart: the debian library packaging guide can probably answer better than I can
[11:01] <crimsun_> pef: dpkg -l gtk2-engines-gtk-qt|grep ^ii
[11:02] <ajmitch> siretart: basiclly the shlibs file needs some version info
[11:03] <ajmitch> eg: libopenal 0 libopenal0 (>=0.2005080600-1)
[11:03] <pef> crimsun_, mmm always have an ugly display
[11:04] <ajmitch> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[11:04] <ajmitch> see chapter 11 of that
[11:04] <siretart> ajmitch: thanks. Will look into it
[11:07] <pef> crimsun_, I always have the qt look & fell with this package and a new user
[11:11] <crimsun_> pef: but is that package installed?
[11:12] <pef> crimsun_, yep
[11:12] <crimsun_> pef: then uninstall it
[11:12] <pef> crimsun_, It wasn't installed before
[11:13] <crimsun_> pef: what happens when you uninstall it?
[11:14] <pef> crimsun_, no changes
[11:16] <crimsun_> pef: did you remove the gtk conffiles from ~/. ?
[11:18] <pef> crimsun_, I only have .gtkrc-1.2-gnome2
[11:18] <pef> and it doesn't change anything to remove it
[11:19] <crimsun_> pef: log out and back in after killing the caching daemons?
[11:19] <pef> crimsun_, http://img397.imageshack.us/my.php?image=cap7vv.jpg
[11:20] <pef> crimsun_, I've tried with a new user with an empty home (hidden files too), and same problem
[11:20] <crimsun_> (text-only currently)
[11:21] <\sh> moins
[11:23] <crimsun_> moin
[11:24] <\sh> hmmm...rhythmbox is crashing as well on my nc6000
[11:24] <\sh> grmpf
[11:39] <pef> does qt4-designer exists ?
[11:46] <\sh> in qt4-dev-tools eventually?
[11:49] <pef> I can't find it inside
[11:49] <pef> erf
[11:49] <pef> designer-qt4
[11:49] <pef> :D
[11:55] <herve> hello
[11:56] <pef> hello
[11:56] <pef> herve, ca fait plaisir de voir des francaise participer ;)
[11:56] <pef> s/francaise/francais/
[11:57] <herve> oui quand mme merci :-)
[11:59] <herve> hmm the new gftp package in unstable seems to have interesting bugfixes
[12:09] <siretart> ajmitch: ok. I got it. openal is calling dh_makeshlibs without option -V
[12:10] <\sh> whiprush: ping
[12:10] <siretart> hi \sh
[12:10] <ajmitch> \sh! :)
[12:10] <\sh> heheh :)
[12:10] <\sh> good morning guys
[12:10] <ajmitch> hi
[12:10] <\sh> I'm not here :)
[12:10] <\sh> not officially
[12:10] <ajmitch> ok, bye \sh ;)
[12:11] <\sh> hehe
[12:11] <\sh> whiprush: I will fix https://launchpad.net/malone/bugs/1858
[12:11] <\sh> but i can't assign it to me
[12:11] <Lathiat> i was playing with bzr yesterday
[12:11] <Lathiat> tis pretty cool
[12:12] <Lathiat> and ive used baz previously
[12:12] <ajmitch> Lathiat: yeah, bzr is quite nice ;)
[12:12] <Lathiat> bzr even does ipv6, yay :)
[12:12] <siretart> is there a bzr-buildpackage?
[12:12] <Lathiat> as ajmitch and i found out syncing our repositories
[12:13] <siretart> or will bzr-buildpackage be hct? ;)
[12:13] <Lathiat> is hct released yet?
[12:13] <ajmitch> no, it's not
[12:13] <ajmitch> and hct is tied to launchpad
[12:14] <ajmitch> siretart: it depends if you think bzr-buildpackage would be needed
[12:14] <Lathiat> ive been hearing about it for a long time but not even the sketchiest actual detail of what its goign to do :)
[12:14] <ajmitch> you can have nested trees, btw
[12:14] <ajmitch> so the debian/ dir can be copied in & branched from elsewhere
[12:14] <tseng> Lathiat: its just a nice tool to merge branches of packages together
[12:15] <tseng> every patch in every distro is a branch on the supermirror
[12:15] <tseng> hct is a frontend to merging stuff into your tree
[12:19] <siretart> sounds promising
[12:19] <siretart> :)
[12:22] <ajmitch> sure, it looks fairly useful
[12:47] <jtan325> what's the "correct way" to publish your public id on something you've signed?
[12:47] <jtan325> (i.e. on a website so every knows)
[12:47] <jtan325> do i just do it in plain text, i.e. "my public key id = blah" ?
[12:56] <\sh> *grmpf*
[12:57] <\sh> shiddy boson-base
[12:58] <\sh> ok...some real life work first...
[12:58] <\sh> bbl
[01:01] <Mez> jtan325, usually, putting it on keyservers is enough
[01:01] <jtan325> ok cool. thanks
[01:04] <Mez> jtan325, though, your best bet is to get it signed into the strong set aswell, so people can verify who you are
[01:04] <jtan325> ?? sorry i don't understand
[01:05] <Mez> well, if you want your PGP key to be trusted by people
[01:05] <Mez> so that people trust you are who you say you are, and that they have the right key for you, then you need to get it signed
[01:05] <jtan325> ah gotcha
[01:06] <jtan325> someone who knows i'm really me
[01:06] <jtan325> should sign my key
[01:06] <jtan325> ?
[01:06] <Mez> well, yes,
[01:07] <Mez> or, you should sfind someone who#s willing to meet you in person, check asspoert/identity card and take a cpopy of your fingerprint then sign it
[01:07] <Mez> http://www.biglumber.com/ is a good place for that
[01:33] <Mitario> morning everyone
[01:34] <jtan325> thanks mez
[01:35] <Mez> npo
[01:55] <siretart> hi j^ :)
[01:55] <slomo> hi j^ :) why is you package a native package? ;)
[01:57] <j^> slomo native? i packaged it for hoary http://bootlab.org/~j/NetworkManager/ and it does not work in breezy
[01:57] <siretart> j^: what did you change in comparison to thom's version?
[01:57] <siretart> j^: yes, but there is no .orig.tar.gz, this is pain for reviewing
[01:57] <j^> ah, http://bootlab.org/~j/bazaar/
[01:58] <j^> siretart because its a cvs snapshot, there is not orig.tar.gz
[01:58] <siretart> j^: you can still create an orig.tar.gz by doing a cvs export
[01:58] <j^> compared to thoms version it uses bind9 again
[01:59] <siretart> i see
[01:59] <siretart> j^: Please prepare an upload as non-native version, so that debian packaging and upstream work is clearly separated
[02:00] <slomo> j^: just notify me when you've done that and i'll look at it :)
[02:00] <siretart> really
[02:00] <j^> siretart its in bazaar, but i can do another version using .orig.tar.gz, slomo  i will let you know
[02:01] <siretart> j^: where is your archive? I'd happily have a look at it
[02:02] <j^> siretart http://bootlab.org/~j/bazaar/
[02:04] <siretart> j^: are you using tla-buildpackage?
[02:05] <j^> siretart no, did not work with baz right away
[02:05] <j^> and its still too complicated for me
[02:07] <siretart> hm
[02:07] <siretart> I
[02:07] <Mithrandir> arch-buildpackage is better crack than tla-buildpackage, IMO
[02:07] <siretart> I'm just playing with tla-buildpackage. so far no problems..
[02:07] <siretart> Mithrandir: what does it better?
[02:07] <j^> but i started to look at http://debian.madduck.net/pkg-zope/wiki/Arch/pkg-zope-20051108.edited.log
[02:07] <siretart> the dokumentation of tla-buildpackage was better than arch-buildpackage
[02:08] <Mithrandir> siretart: I never got tla-buildpackage to dtrt, arch-buildpackage works much better for me.
[02:08] <j^> arch-buildpackage depends on tla
[02:08] <j^> i use baz
[02:08] <j^> and i do not want to install tla too
[02:10] <siretart> Mithrandir: is there somewhere better documentation than /usr/share/doc/arch-buildpackage/README.Debian?
[02:10] <Mithrandir> siretart: ttbomk, no.
[02:11] <siretart> ok
[02:24] <j^> slomo new versions at http://bootlab.org/~j/NetworkManager-breezy/
[02:25] <sivang> siretart: what's tla-buildpackage?
[02:25] <sivang> (sounds interesting :) )
[02:26] <siretart> sivang: helper script to import and build sourcepackages managed by tla
[02:26] <slomo> j^: i'll look at it later :)
[02:27] <sivang> siretart: cool, since when is it available? (does it handle removing baz's specific files etc?)
[02:28] <siretart> sivang: ppl are telling here it was only written for tla. I does not even call baz, only tla
[02:28] <siretart> s/I/it/
[02:28] <Mithrandir> siretart: pft:
[02:28] <Mithrandir> : tfheen@thosu ~ > grep baz .archdeb.conf
[02:28] <Mithrandir> tla = baz
[02:29] <siretart> Mithrandir: aah. one more point for arch-buildpackage :)
[02:29] <Mithrandir> so it works for me, at least.
[02:29] <Mithrandir> I think I hacked it a little bit to DTRT for some syntax changes which baz introduced, though.
[02:31] <siretart> DTRT?
[02:33] <Mithrandir> do the right thing
[02:33] <siretart> ah
[02:34] <j^> Mithrandir but it also depends on tla, so you have tla installed too?
[02:35] <Mithrandir> yes, I have that, but I don't really care about what dependencies I have; if so, I'd just recompile the package locally and remove the dependency.
[02:37] <j^> ha, the version in debian supports bazaar http://packages.debian.org/testing/devel/arch-buildpackage
[02:39] <Mitario> could someone add me to the MOTU launchpad group?
[02:54] <j^> trying the mini howto in arch-buildpackage it fails at arch-recordpackage bar 1.0.1 with
[02:54] <j^> No configs directory found - is this really the right tree?
[03:35] <hub_> I have a debian package that works fine on ubuntu (after rebuild)
[03:35] <hub_> shall I just upload it or should I change the version ?
[03:36] <hub_> upload to REVU off course
[03:43] <siretart> hub_: just a rebuild?
[03:44] <siretart> hub_: better ask a motu to do that rebuild. It's really not worth an upload if there is nothing to review
[03:54] <hub_> based he mail, is there another to request that, like a bugzilla
[03:54] <hub_> s/he mail/e-mail/
[04:01] <siretart> j^: did you try to build network-manager in pbuilder?
[04:01] <siretart> checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
[04:01] <siretart> make: *** [config.status]  Error 1
[04:01] <siretart> :(
[04:01] <slomo> Build-Depend on intltool probably
[04:02] <siretart> j^: README.Debian tells to contact thom about the package. is that still correct?
[04:03] <j^> siretart at some point infinity said he would take over, since he did not i did not change those things
[04:04] <j^> not sure what the best way it to maintain this package
[04:04] <j^> it will be in univers for breezy and should go into main in breezy+1
[04:05] <siretart> j^: since you have done so much love to the package, I'd propose you for maintainership for this
[04:05] <siretart> and since it was dropped for breezy, I don't except any objections from thom
[04:05] <siretart> checking for dhcdbd... no
[04:05] <siretart> configure: error: dhcdbd was not installed.  See http://people.redhat.com/jvdias/dhcdbd
[04:06] <siretart> huch?
[04:06] <j^> oh
[04:06] <j^> i must have missed something rebuilding with .orig.gz
[04:06] <siretart> I rather think there are build dependencies missing
[04:06] <slomo> j^: nm isn't currently in debian, isn't it?
[04:07] <siretart> slomo: no
[04:07] <j^> slomo no, its not, right now
[04:07] <slomo> then why *-2 as version number? wouldn't something like *-0ubuntuY be more appropiate?
[04:07] <j^> siretart dhcdbd is not needed to build, but configure checks for it
[04:08] <siretart> so configure should be fixed, then
[04:08] <slomo> or you should just add dhcdbd to Build-Depends
[04:08] <siretart> if added to build depends, package building fine on pbuilder/amd64
[04:09] <j^> thom was picky about patching configure
[04:10] <slomo> siretart: for fixing configure or other autotools stuff talk to infinity... he can tell you some really nice stories about timestamps ;)
[04:10] <siretart> slomo: I guess so
[04:10] <siretart> j^: please provide a fixed package. You can remove debian/README.Debian and clean up debian/rules at this opportunity
[04:11] <slomo> j^: i would just add intltool and dhcdbd to Build-Depends... builds fine here on pbuilder/x86
[04:12] <siretart> another option would be to patch configure.in to not bail out
[04:12] <j^> siretart thats what i did and its upstream, so if it still checks i have to check why
[04:13] <siretart> j^: ok. please ping either me or slomo when you prepared a new package
[04:13] <slomo> siretart: infinity said something about that patch doesn't garantue to get the timestamps in the correct order in some cases... you have to get them right with some touches in rules then
[04:14] <siretart> slomo: so configure should be touched after patching it?
[04:14] <slomo> siretart: yes... configure needs to be "newer" than configure.in / configure.ac
[04:15] <Mitario> crimsun_, thatnks for updating the packages btw :)
[04:15] <slomo> siretart: that is... when upstream doesn't use AM_MAINTAINER_MODE in configure.in / .ac... in that case it doesn't look at timestamps (at least the docs say that)
[04:15] <siretart> I see..
[04:15] <slomo> j^: update standards version to 3.6.2 while you're at it ;)
[04:16] <siretart> j^: please don't take it personnaly. We really want to sponsor your first upload :)
[04:17] <slomo> j^: and one small cosmetical change... in copyright remove the (s) :) then the package is perfect imho ;)
[04:26] <hub_> I still have 3 upload pending on REVU :-/
[04:47] <Mitario> bah rhythmbox is broken with glitz too
[04:49] <slomo> Mitario: probably not rhythmbox itself but one of it dependencies... but as rhythmbox is main...
[04:49] <Mitario> sladen, yeah, that's what I mean
[04:49] <\sh> re
[04:49] <Mitario> hi \sh
[04:50] <Mitario> there's also a really strange problem with kaffe, it can't find /usr/include/freetype2/freetype/config/ftheaders.h, and I actually don't see a -I/usr/include/freetype2 argument in the compile rules
[04:50] <Mitario> but I can't figure out to append it
[04:53] <slomo> Mitario: i'll look at kaffe
[04:54] <Mitario> slomo, thatnks I'm also still trying to figure it out
[04:54] <Mitario> hmm, gconf seems to depend on libglitz
[04:54] <slomo> wtf... then tell seb128 about it when he's back from vacation ;)
[04:54] <Mitario> when's that? :)
[04:55] <slomo> no idea... monday maybe
[04:55] <Mitario> ok
[04:55] <Mitario> i'll e-mail him
[04:55] <Mitario> so every pkg should get rid of libglitz?
[04:56] <slomo> yes... don't add libglitz-dev to the build-depends... never ;) when it doesn't build then look where the problem lies... and when it's a library in main tell someone on #ubuntu-devel... maybe it's the best to do this for gconf too and not wait for seb128
[04:57] <Treenaks> 3
[04:57] <slomo> Treenaks?
[04:57] <Treenaks> 3! :)
[04:57] <Mitario> Treenaks, 234!
[04:57] <slomo> 3? :P
[04:58] <Treenaks> slomo: yeah.. I just hit that key by accident
[04:58] <slomo> lol
[04:59] <slomo> is the first priority: merging in the topic up to date? i think it's to late for merging now,isn't it?
[05:00] <Mitario> at least, reading the minutes of latiath
[05:01] <Mitario> why is gconf2 task edubuntu-desktop and not just ubuntu-desktop :)
[05:15] <Mitario> slomo, btw succesful build of kaffe
[05:15] <slomo> Mitario: fine :)
[05:15] <Mitario> but...
[05:15] <Mitario> with --with-includes=/usr/include/freetype2
[05:15] <Mitario> as extra config option in rules
[05:16] <Mitario> so that's not really a great solution
[05:16] <slomo> hm... not really but it works ;)
[05:16] <Mitario> i'll just put a bug in malone so I can look at it in detail after dinner :)
[05:32] <j^> slomo, siretart is it ok if i switch to using arch-buildpackage, had a look at it and like it a lot
[05:32] <j^> i put a new version of nm at http://bootlab.org/~j/NetworkManager-breezy/
[05:32] <j^> http://bootlab.org/~j/NetworkManager-breezy/arch-buildpackage.config.gz
[05:33] <j^> has the config folder used with arch-buildpackage network-manager 0.4.1+cvs20050817-ubuntu3
[05:33] <slomo> hm, i don't understand ;)
[05:34] <j^> arch-buildpackage is crack
[05:34] <slomo> maybe, i don't know anything about it ;) so i'll just look at http://bootlab.org/~j/NetworkManager-breezy/ or something else?
[05:35] <j^> thats fine
[05:58] <slomo> j^: /bin/sh: ./configure: Permission denied
[06:03] <slomo> jbailey: are you the initramfs guy? i have some problems with it on ppc and x86 ;)
[06:03] <jbailey> slomo: I am.
[06:03] <jbailey> slomo: What's up/
[06:04] <slomo> jbailey: on x86 it tells my it can't mount 301 as root partition and then jumps to busybox... when adding root=/dev/hda1 to the kernel commandline everything works
[06:05] <j^> slomo thats bad, how can i change permissions on files only in diff?
[06:05] <jbailey> slomo: What version of initramfs-tools are you using?
[06:06] <slomo> jbailey: 0.23... i haven't tried with 0.24 yet but from the changelog there wasn't changed something in that direction
[06:07] <slomo> j^: add a chmod +x configure in rules ;) don't know anything better
[06:09] <jbailey> Did you regenerate the initramfs after updating the initramfs-tools
[06:09] <slomo> jbailey: yes... for 0.23 i've done... shall i retest with 0.24?
[06:10] <slomo> jbailey: i've called mkinitramfs -o /boot/initrd.img-2.6.12-7-k7 2.6.12-7-k7
[06:10] <jbailey> No, 0.23 has everything you need.
[06:10] <whiprush> \sh: that's cool,  thanks. <3
[06:12] <\sh> whiprush: u r welcome :) I fixed it already..but fixing some other stuff as well...
[06:12] <slomo> jbailey: any ideas? or shall i tell you the ppc problem first? seems to be something related
[06:12] <whiprush> excellent!
[06:12] <whiprush> I really dig gajim.
[06:13] <jbailey> slomo: Sorry, phone rang.
[06:13] <jbailey> The question then is why isn't it triggering for you?
[06:13] <jbailey> slomo: You have a /dev/.initramfs-tools file, right?
[06:14] <slomo> jbailey: nope
[06:14] <jbailey> Then your initramfs isn't up to date.
[06:14] <jbailey> I added that file in 0.23 =)
[06:15] <jbailey> So let's figure out what's wrong there, first.
[06:15] <\sh> whiprush: there r some pitfalls in it (gpg-agent signes as well presence messages) etc. but we will fix all issues...I'm working with upstream and debian maintainer on it :)
[06:15] <jbailey> Although, FWIW, you may as well update to 0.24 in the meantime.
[06:15] <slomo> jbailey: already done... and called mkinitramfs again
[06:16] <jbailey> 'kay, so let's check your lilo config.
[06:16] <whiprush> \sh: that's awesome.
[06:16] <jbailey> Which initramfs file is it pointing to?
[06:16] <whiprush> \sh: I hadn't even noticed it did gpg
[06:16] <jbailey> Usually it's /initrd.img
[06:16] <jbailey> In which case we need to check to make sure that symlink is up to date, and rerun lilo either way.
[06:16] <xhaker> someone using wireless here that can send a file with the iwlist scan output?
[06:17] <slomo> jbailey: yes it is... und the file is up to date and i've rerun lilo after updating it in the past... hasn't helped much
[06:17] <slomo> jbailey: but when running lilo i get a warning
[06:17] <jbailey> What's the warning say? =)
[06:17] <slomo> jbailey: Warning: '/proc/partitions' does not match '/dev' directory structure.
[06:17] <slomo>     Name change: '/dev/dm-0' -> '/dev/evms/hda1'
[06:18] <jbailey> Ugh, you're using evms?
[06:18] <slomo> jbailey: no
[06:18] <jbailey> Oh good.  That won't work until next week. =)
[06:18] <jbailey> So that warning shouldn't matter.
[06:19] <jbailey> As root, please do: mkdir /tmp/initramfs; cd /tmp/initramfs; zcat /boot/initrd.img-2.6.12-7-k7 | cpio -i
[06:19] <jbailey> Let's take a look inside this thing.
[06:20] <\sh> whiprush: u can assign a gpg key to your account and to every contact
[06:20] <slomo> jbailey: wait... evms (and lvm) is in rcS.d... but i haven't configured anything in that direction... does this matter?
[06:20] <jbailey> Nope.
[06:20] <\sh> whiprush: and since -1ubuntu4 it can use gpg-agent and seahorse-agent
[06:20] <jbailey> It's just evms being enthusiastic, no worries.
[06:21] <slomo> jbailey: ok... initrd decompressed
[06:21] <jbailey> 'kay, so look in the init file, and somewhere in there you should see the command 'parse_numeric ${ROOT}'
[06:21] <slomo> jbailey: yes
[06:22] <jbailey> Do you have two machines?
[06:22] <jbailey> Like, can we chat while you reboot?
[06:22] <slomo> jbailey: yes... my ibook which can't boot because of something similar ;) and as i tried to reinstall breezy from a dayly there i don't have a backup kernel/initrd ;)
[06:23] <j^> slomo ok now with chmod +x ./configure
[06:23] <slomo> jbailey: so tell me what i have to do, what to look for etc... :)
[06:24] <jbailey> Well, I want you to reboot and get to a prompt, and we'll check to see if parse_numeric is in the init in there.
[06:25] <jbailey> Since when you boot, that file that should be there isn't, I suspect that you're updating the wrong initramfs somehow.  Now we need to prove me wrong. =)
[06:25] <slomo> jbailey: ok... i'll check it :) brb
[06:30] <slomo> jbailey: hum... it worked without problems now :/ i've just updated to 0.24 and rerun lilo... and i have done exactly the same for 0.23, 0.22 etc... weird
[06:31] <jbailey> =)
[06:31] <jbailey> So tell me about the ppc?
[06:31] <slomo> jbailey: but it tells me now, that it doesn't find chmod ;) just before starting init version bla... but as it works nothing critical ;)
[06:32] <slomo> jbailey: i had this problem for at least 2 weeks... well, ppc :)
[06:32] <slomo> jbailey: on ppc a similar problem... (even after reinstalling from yesterdays daily): it tells about RAMDISK: incomplete write (-28 != 32768) and kernal panic, unable to mount root fs on unknown-block(0,0)
[06:33] <slomo> jbailey: exactly the same happened with my install before... where i've updated to 0.23... and this now happens after the first reboot
[06:34] <slomo> jbailey: and even for 0.22... i had the problem there for at least 2 weeks too
[06:35] <jbailey> slomo: What type of PPC?
[06:36] <slomo> jbailey: ibook g4
[06:36] <jbailey> Hmm, so newworld.
[06:36] <jbailey> Oldworld I could see maybe having a problem.
[06:36] <slomo> jbailey: yes
[06:38] <jbailey> Well, let's see if it's a size thing anyway.
[06:38] <jbailey> Can you edit /etc/mkinitramfs/initramfs.conf and change "MODULES=most" to "MODULES=dep" ?
[06:39] <slomo> jbailey: ok, wait... i'll boot the rescue system from the daily ;)
[06:45] <slomo> jbailey: then rerunning mkinitramfs and reboot?
[06:48] <jbailey> Yup
[06:48] <jbailey> Well, after editting the conffile. =)
[06:49] <slomo> sure :P yaboot doesn't need to be run after updating the initrd?
[06:50] <slomo> j^: i'll look at NM again when everything works again here ;)
[06:50] <jbailey> I don't think it does.
[06:50] <jbailey> NM?
[06:51] <slomo> network-manager
[06:51] <jbailey> Sorry, I'm on the phone at the same tiem, so I'm a bit scattered.
[06:51] <jbailey> Ah.
[06:52] <slomo> jbailey: kernel panic... the same as before... BUT the stuff about the ramdisk disappeared
[06:53] <jbailey> Hrm.
[06:53] <jbailey> I can fire up my g4 box tomorrow maybe and give it a try.
[06:54] <jbailey> I know it boots fine on my g5.
[06:54] <jbailey> There's no messages before the kernel panic at all now?
[06:55] <slomo> jbailey: nothing suspect... only the stuff that was there before
[06:55] <jbailey> Hmm
[06:56] <jbailey> I would've expected something more in terms of messages.  Like a 'can't find init' or something.
[06:56] <slomo> jbailey: me too... or getting to busybox... but nothing :/
[06:57] <slomo> j^: can you give me the url for NM again ;)
[06:58] <jbailey> slomo: Can you try taking the word 'quiet' out of yaboot?>
[06:58] <jbailey> Maybe there'll be a hint in the kernel messags.
[06:58] <j^> http://bootlab.org/~j/NetworkManager-breezy/
[06:58] <j^> slomo
[06:58] <slomo> jbailey: sure... wait a moment to boot rescue again ;)
[07:02] <slomo> jbailey: yeah... it talks much more ;)
[07:02] <slomo> jbailey: but nothing relevant...
[07:02] <jbailey> *cRy*
[07:02] <slomo> jbailey: RAMDISK: compressed image found at block 0 and then the kernel panic
[07:03] <jbailey> I'm probably going to have to punt you over the BenC then.
[07:03] <jbailey> s/the/to/
[07:03] <slomo> ok... i'll talk to him... does he work on weekends? ;)
[07:03] <\sh> ok...this is really too much
[07:04] <\sh> why the heck they're shooting here in my area?
[07:04] <jbailey> slomo: Dunno.  Try hopping into #ubuntu-kernel, maybe?
[07:06] <\sh> and no...again the german national anthem during a "schuetzenfest"
[07:06] <\sh> schuetzenfest == fair with shooting matches
[07:10] <slomo> j^: fix your diff.gz... it contains changes everywhere in the sourcetree
[07:15] <j^> slomo thats arch-buildpackage, as there is not orig tar file, i have to call autogen.sh at some point
[07:15] <slomo> call i in rules then
[07:16] <j^> and make autotools a build dependency?
[07:16] <j^> im sure that is not ok
[07:17] <slomo> infinity told me it is.. you just have to call the correct versions and build-depend on the correct versions
[07:17] <slomo> when you don't want this create a dpatch for this... but in your case calling autoreconf / autogen.sh should be better
[07:30] <j^> hm i still get all the arch stuff in the diff
[07:30] <j^> its way smaller but still
[07:30] <j^> 63k
[07:31] <slomo> hm... can't you tell arch to clean its stuff?
[07:32] <slomo> btw... when you run autogen.sh / autoreconf... you don't need the chmod +x configure anymore
[07:35] <j^> yup removed the chmod part, but not sure if i should remove arch stuff, i'v seen quite some packages lately that use svn/arch/bzr and include these information in the package
[07:36] <slomo> well then just leave them... it doesn't hurt i think ;)
[07:37] <j^> whats the build depend for autotools?
[07:37] <slomo> what versions of automake / autoconf do you need?
[07:37] <crimsun_> autotools-dev
[07:37] <crimsun_> or a specific version of automake, and autoconf
[07:38] <slomo> btw... are there already avahi packages available?
[07:38] <slomo> j^: also call specific versions auf automake/autoconf... the ones you need
[07:41] <j^> all this is quite complicated
[07:43] <slomo> sadly... i needed the whole afternoon yesterday to create a build system for one of my projects with autotools :/
[07:43] <j^> and has to be streamlined to go inline with marks talk about distributed version management
[07:43] <Mitario> re
[07:43] <Mitario> ah good gconf2 rebuild in the archive :)
[07:44] <crimsun_> Mitario: scorched3d was a PITA to fix (FTBFS on amd64 in like a dozen places)
[07:44] <slomo> j^: please notify me when you've uploaded a new version :)
[07:44] <Mitario> crimsun_, yeah I heard, great you managed! :)
[07:45] <crimsun_> we need to get amd64 pbuilder accts to MOTUs
[07:45] <\sh> crimsun_: ask Mithrandir
[07:45] <slomo> crimsun_: good idea... and maybe also fast ppc ;)
[07:45] <Mitario> who was busy with kaffe yesterday? systpoty?
[07:46] <slomo> \sh: do you already have your account? i've send my ssh key but got no answer :/
[07:46] <\sh> slomo: yes..I had it renewed...
[07:46] <\sh> slomo: u asked him about an account?
[07:47] <\sh> slomo: It would be ok..if we would get some pegasos developer machines..the gentoo devs got some from them to fix some bugs for ppc
[07:48] <slomo> \sh: yes... after you told me that he can get my ssh access ;)
[07:48] <\sh> slomo: ask him again :) on monday
[07:49] <\sh> or ping maswan he can do it as well on ravel
[07:49] <slomo> \sh: when pegasos does this i'm the first who wants one =) i hate my slow ibook for fixing bugs...
[07:49] <\sh> slomo: they're doing those things...but not everytime...
[07:49] <\sh> hmmm...
[07:50] <\sh> or we can write a request to apple to send some old but fast powerpcs ,-)
[07:50] <\sh> now they don't need them anymore
[07:51] <slomo> hm, i would prefer the pegasos machines... they're much quieter ;) but a good old ppc would be fine too :)
[07:52] <slomo> \sh: did someone already ask pegasos?
[07:58] <\sh> slomo: I send a request earlier, because the debian release manager is working for pegasos
[08:01] <slomo> \sh: did you get an answer yet?
[08:04] <j^> slomo another try http://bootlab.org/~j/NetworkManager-breezy/
[08:05] <\sh> slomo: no
[08:06] <slomo> j^: please put your configure.in patch in a dpatch... in the diff.gz should be only changes to the debian directory... same for the stuff in src and gnome
[08:07] <j^> slomo i want to use bazzar.ubuntu.com and not dpatch
[08:08] <j^> the patch will be upstream by monday anyway
[08:09] <\sh> what has bazaar to do with dpatch or patch?
[08:09] <tseng> thats what i was wondering
[08:09] <slomo> j^: but anyways... changes to sources files in the diff.gz will only make updates to another upstream version more difficult... get the patches from bazaar and put them in a dpatch ;)
[08:09] <\sh> slomo: please.no dpatch...,-)
[08:09] <\sh> simple-patchsys
[08:10] <slomo> \sh: he doesn't use cdbs
[08:10] <\sh> or a simple patch/unpatch rule
[08:10] <\sh> slomo: so
[08:10] <tseng> um
[08:10] <slomo> \sh: why don't you like dpatch? ;)
[08:10] <tseng> yeah
[08:10] <\sh> it's horrible
[08:10] <j^> i see this future where you use baz to maintain the debian/ubuntu branch of a package
[08:10] <tseng> how is it more horrible than simple-patchsys
[08:10] <tseng> they do the same thing
[08:10] <j^> and there is not need to use patches
[08:10] <\sh> tseng: the format of dpatch is not "normal"
[08:11] <\sh> j^: for upstream of course when they're not using baz/bzr
[08:11] <tseng> yeah it has like 5 extra lines
[08:11] <slomo> \sh: my dpatchs are just diffs with 4 lines above ;)
[08:11] <\sh> tseng: yes :)
[08:11] <tseng> who cares?
[08:11] <\sh> but they're not applying to upstream ,-)
[08:11] <tseng> patch ignores extras anyway
[08:11] <\sh> upstream takes patch not dpatch files
[08:11] <j^> \sh true, but no patches in debian/patches
[08:12] <\sh> j^: hu? baz/bzr won't help u to avoid debian/patches
[08:12] <slomo> \sh: fine... you ask my questions :)
[08:13] <j^> in baz you create a fork of upstream, applying debian patches
[08:13] <\sh> j^: it means, you play upstream
[08:13] <j^> if you now undo this process and put them as patches in debian/patches
[08:13] <j^> you are better off not to use baz at all
[08:13] <\sh> j^: but it doesn't say, that you don't need normal patches to send upstream
[08:13] <j^> \sh i am upstream
[08:14] <j^> as much as i am the maintainer
[08:14] <\sh> j^: I don't think u know the diff between debianizing and branching
[08:14] <\sh> debian/ dir in upstream sources is a nono, even in a forked upstream
[08:14] <\sh> source
[08:14] <j^> \sh listening to mark this morning this is the same thing
[08:15] <\sh> j^: no..where did mark say that?
[08:15] <j^> http://debian.madduck.net/pkg-zope/wiki/Arch/Package/Upstream
[08:16] <slomo> \sh: btw... please notify me when you get an answer from pegasos ;)
[08:16] <j^> mark says that in all talks about distributed version control
[08:16] <j^> today that was akademy
[08:16] <j^> or http://stream.fluendo.com:8850
[08:16] <\sh> j^: hmmm..the last speech i heard of him was ata debconf..and the meaning was something else
[08:17] <\sh> no mpg file?
[08:17] <j^> theora only
[08:18] <\sh> j^: ok...wher?
[08:19] <j^> it was a live stream, i just asked for the archive, will let you know once i i do
[08:19] <j^> but that is just a sidetrack
[08:19] <j^> packages like tla-buildpackage or arch-buildpakcage or http://debian.madduck.net/pkg-zope/wiki/Arch/Package/Upstream
[08:20] <slomo> j^: but for the time beeing just put these changes in debian/patches ;)
[08:21] <\sh> j^: u read what madduck was saying in the last paragraph?
[08:21] <\sh> Now we merely need to merge the feature and debianisation branches into the integration branch, document our changes in debian/changelog and prepare a new package. Don't forget to seal the package after the upload.
[08:21] <\sh> it means, that u have source + debian dir in different repos and merging them together
[08:22] <\sh> and reading the upper explanations, all the commands are showing this as well
[08:22] <j^> \sh still you can make changes to source
[08:23] <\sh> j^: yes, but unlikely not all upstream will use baz/bzr, so you should be able to provide real unified patches
[08:23] <\sh> and send them upstream
[08:23] <j^> \sh to configure.in
[08:23] <j^> not to configure Makefile.in etc
[08:24] <\sh> so debian/patches system will apply again...even to send them to debian maintainers
[08:24] <\sh> now I'm lost
[08:24] <\sh> can u elaborate?
[08:25] <j^> if you have a tarball release of upstream it might make sence to patch the output of the buildsystem(this is quite often autotools)
[08:26] <\sh> yes
[08:26] <\sh> go further
[08:27] <j^> if upstream only tags in cvs(which is mirrored on bazaar.ubuntu.com) using a branch in baz with the changes + merging them at the next update is what i want to do
[08:27] <j^> fiddeling with patches does not help here
[08:28] <\sh> j^: send patches to upstream but...and when you fix a serious issue in upstream source, u should provide patches to upstream
[08:28] <\sh> upstream is the highest priority...
[08:28] <j^> and so far i am more upstream of networkmanager than ubuntu or debian maintainer
[08:29] <j^> and providing patches to upstream works best with baz
[08:29] <j^> not with debian/patches
[08:29] <\sh> as maintainer or ubuntu dev u fix bugs even in upstream, provide them as patches directly in .diff.gz or if their are bigger patches in debian/patches..so u can send the contents of debian/patches to upstream
[08:30] <\sh> s/their/there/
[08:30] <slomo> \sh: err... didn't we say that the only changes in the diff.gz should be in the debian directory?
[08:30] <\sh> and upstream can incorporate them in his source
[08:30] <\sh> slomo: yeah...but there r some packages where the changes are only in diff.gz.
[08:30] <\sh> (bittorrent as an example)
[08:31] <slomo> \sh: the same is the case for j^'s package... and this discussion happened as i said him to move this changes to a patch in debian/patches ;) was this wrong?
[08:31] <\sh> slomo: no
[08:32] <\sh> but actually I don't understand him...or he doesn't understand the packaging work...at least I'm lost
[08:33] <Mitario> btw why is the kaffe package a debian/ dir and a tarball? because of the size of the source?
[08:34] <slomo> \sh: hehe, me too... and i don't know enough about bazaar/arch/whatever... but anyways, the changes must be in a seperate patch...
[08:34] <slomo> Mitario: is the tarball a tar.bz2? otherwise... maybe because the packager likes it that way ;)
[08:34] <\sh> slomo: ok..baz/bzr/arch/tla is easy it's a normal VCS like CVS/SVN/bitkeeper
[08:35] <pef> hi
[08:35] <Mitario> sladen, ok, I think I know what the problem is with kaffe
[08:35] <Mitario> eh, slomo
[08:35] <\sh> slomo: but it's easier to make a checkout, patch the checkout source, and for the originator of the source it's easier to pull the sources from you, merge it back in his orig sources...
[08:35] <\sh> slomo: when he uses as well baz/bzr/arch
[08:36] <\sh> slomo: but when he uses svn/cvs or something else, he needs patches
[08:36] <Mitario> the --enable-gtk-cairo should be enabled to build with freetype2 includes
[08:37] <\sh> slomo: jblack had a nice talk at the last motu meeting...they offering all upstream opensource projects to replace their actual VCS with a baz/bzr one on bazaar.canonical.com...without a charge :)
[08:38] <\sh> hi pef
[08:38] <slomo> \sh: yeah i know... i listened to him ;) hm, well... maybe i'll look into bazaar later... but first i have to leave ;) see you later
[08:38] <\sh> slomo: have a nice evening
[08:38] <slomo> p^: please notify me when you've moved your changes to debian/patches
[08:38] <Mitario> bye slomo
[08:38] <slomo> \sh: thanks :) you too
[08:38] <\sh> slomo: I'm drinking right now also some beer instead of working ,-)
[08:39] <slomo> \sh: my first beer this evening comes in a few minutes ;)
[08:39] <j^> slomo i'm still not convinced that that is the way to go
[08:39] <slomo> j^: then let \sh convice you when he wants ;) otherwise we'll talk about it when i'm back
[08:39] <slomo> Mitario: and i'll look at kaffe when you haven't fixed it later :)
[08:40] <slomo> bye
[08:40] <\sh> j^: this is right now the way to go...put your patches in debian/patches and provide a .orig.tar.gz and patch upstream with your changes in debian/rules
[08:40] <\sh> slomo: go ,-)
[08:43] <Mitario> slomo I fixed it :)
[08:43] <Mitario> \sh, you know sistpoty right?
[08:44] <Mitario> oh right
[08:44] <Mitario> gotto go
[08:44] <Mitario> bye bye!
[08:45] <Baskerville> My sound driver doesn't work
[08:45] <Baskerville> can someone help me?
[08:46] <crimsun> Baskerville: please stop asking in the wrong channels. This is clearly a #ubuntu question.
[08:48] <j^> \sh again, the way i created the package for network-manager is like this:
[08:48] <j^> get a specific version of NetworkManager; for that i use bazaar.ubuntu.com.
[08:48] <j^> branch that version, fix two bugs so it works on ubuntu.
[08:48] <j^> update, change and fix debian folder in seperate baz archive
[08:48] <j^> use arch-buildpackage to build the debs. while discussing if this is right,
[08:48] <j^> wrong of silly, i did send a mail to the network-manager list with the
[08:48] <j^> only change i made today. i am quite sure that this change will be in
[08:48] <j^> cvs.gnome.org on monday once dan is working agian.
[08:51] <madduck> are there logs available from this channel?
[08:52] <\sh> yes
[08:53] <crimsun> fabbione keeps them on people.ubuntu.com/~fabbione/
[08:53] <\sh> http://people.ubuntu.com/~fabbione/irclogs/ubuntu-motu-current.html
[08:53] <\sh> but not all is in
[08:53] <\sh> hmmm.
[08:54] <\sh> j^: ok..explain again why you don't want to put patches into debian/patches...I asked madduck to listen or to read the backlog so he gets the point...
[08:56] <j^> i use bazzar.ubuntu.com to get upstream sources, use baz to create a branch for debian, maintain the debian folder in an extra baz archive and use arch-buildpackage to get upstream, branch, debian-dir and build the package
[08:57] <j^> *branch for ubuntu
[08:58] <j^> this way i might be able to create patches of upstream -> ubuntu branch and put them in debian/patches to use ustream + patches, but why would i use baz than in the first place. and arch-buildpackage would also be no help anymore.
[08:58] <madduck> i am reading...
[08:59] <madduck> is the issue why baz branches instead of dpatch?
[08:59] <j^> \sh argues i can only use dpatch and not a baz branch yes
[09:00] <madduck> \sh: dpatches are also part of the .diff.gz ...
[09:00] <tgall> does anyone here work on the ppc / ppc64 port ?
[09:00] <madduck> the main selling point of baz over dpatch is that baz supports star-merge while dpatch is just stupid patch.
[09:01] <madduck> so it's *much* harder to keep dpatches around across several upstream releases than it is to maintain feature branches.
[09:02] <madduck> \sh: dpatch can be fully replaced by Manoj's way of doing packages in arch.
[09:02] <\sh> madduck: but providing diff.gz instead of separated patches (or dpatches) is sometimes ok, but sometimes the changes are quite serious (security e.g.) and we should provide the patches to upstream (which are not using baz/bzr/arch) so debian/patches is sometimes comfortable
[09:02] <j^> while in this case upstream will have merged the changes to HEAD before the package will be in ubuntu
[09:03] <\sh> madduck: I'm thinking of giving back the changes (when they're not ubuntu specific or distro specific)
[09:03] <madduck> \sh: see the bottom of http://debian.madduck.net/pkg-zope/wiki/Arch/Package/Feature
[09:03] <\sh> madduck: and many sources don't use baz/bzr
[09:04] <madduck> \sh: all branches except (debian, devo, integration, upstream) are designed to go to upstream.
[09:04] <madduck> that's what makes them "feature branches"?
[09:04] <madduck> tr -d \?
[09:05] <\sh> madduck: understand, but it means, then we have created a ubuntu package with unbuntu source (so we're upstream in the way of thinking) and we're sending deltas between upstream sourceand ubuntu soure
[09:05] <\sh> to upstream
[09:05] <madduck> what's ubuntu source?
[09:05] <\sh> ok
[09:06] <\sh> elaborate
[09:06] <\sh> I'll pull the actual cvs source from pyqt
[09:06] <\sh> and create a -uptream branch on e.g. bazaar.ubuntu.com
[09:06] <\sh> now I branch it a bit further to --ubuntu-version
[09:07] <\sh> change the source
[09:07] <\sh> and create a package from this --ubuntu-version source
[09:07] <madduck> --ubuntu--version?
[09:07] <\sh> pyqt--ubuntu-version ,-)
[09:07] <madduck> ok.
[09:07] <\sh> now...
[09:07] <madduck> that branch should contain all the ubuntu specific things.
[09:07] <madduck> and only those.
[09:07] <\sh> yeah
[09:08] <madduck> go on.
[09:08] <\sh> for this branch I'm upstream
[09:08] <\sh> but only for ubuntu (not for debian nor real upstream)
[09:08] <madduck> if you want to call it that. i don't think it's very accurate to put it like that.
[09:08] <madduck> you are the maintainer of the delta between upstream and ubuntu-version.
[09:08] <\sh> well..if the patches I'm applied are not in "real upstream source", I'm responsible for the source
[09:09] <madduck> just the diff
[09:09] <madduck> but yeah, i know what you mean.
[09:09] <\sh> (happened for the pykde packages in ubuntu right now)
[09:09] <madduck> so what's the issue?
[09:10] <\sh> now I'm going to upstream and have to send the patches I made (if they're not ubuntu specific) so I create deltas
[09:10] <madduck> wait!
[09:10] <madduck> if they are not ubuntu-specific, they should be in their own branch. not in the ubuntu-version branch.
[09:10] <madduck> in fact, ubuntu-versions is a bad name.
[09:10] <madduck> just use 'ubuntu'
[09:11] <madduck> or heck, just use debian and make it such that it applies to both. :)
[09:11] <\sh> ok..what I mean is, that providing the patches only inside diff.gz is for packagers sometimes a pain
[09:12] <madduck> but packagers should use the baz repo, no? or whom are we talking about?
[09:12] <madduck> i know what you mean... dpatches are nice, contained changesets fwiw
[09:12] <\sh> because after apt-get source the diff.gz is applied and you have to create a view between orig.tar.gz source and the resulting orig.tar.gz source + diff.gz
[09:12] <madduck> and as thus make it a lot easier to keep track of a number of patches.
[09:13] <madduck> yeah, and then it's just one massive diff.
[09:13] <\sh> so if the changes in upstream orig source are more then 2-20  lines it's better to provide those changes as dpatches/unified diffs in debian/patches
[09:13] <madduck> and you prefer dpatches because they make it easier to see how the package differs from upstream.
[09:13] <madduck> my take on this is:
[09:14] <madduck> the only one that is really interested in that diff/those diffs is myself, co-maintainers, and all NMUers
[09:14] <madduck> sure, a user may look at it, but that should not be our primary focus.
[09:14] <madduck> so, for developers, what counts is that baz merging is vastly superior to dpatch
[09:15] <madduck> and thus makes package maintenance easier.
[09:15] <madduck> my goal for my phd is to make the baz method accessible and intuitive to everyone
[09:15] <madduck> so that it hopefully becomes a standard.
[09:15] <madduck> then every NMUer would just be able to branch off the baz stuff and prepare an NMU without hassle.
[09:16] <madduck> one thing i was considering all along is to put feature branches into the .diff.gz
[09:16] <madduck> similarly to dpatch
[09:16] <madduck> rather than merging them into the integration branch
[09:16] <madduck> for precisely the reason you state
[09:16] <madduck> but i have not found a good way to do this yet without requiring a baz build-dependency
[09:17] <\sh> with "feature branches" u mean: changes towards the upstream source, only applying to the distribution you create the changes for
[09:17] <\sh> aeh missing a ?
[09:18] <madduck> no. that's the debianisation or the ubuntuisation branch
[09:18] <madduck> a feature branch is what i'll send to upstream later.
[09:18] <\sh> oh ok
[09:18] <madduck> so in some way, one feature branch is one dpatch
[09:18] <madduck> or more than one dpatch
[09:19] <madduck> and when i convert my existing packages to baz, i usually just branch off upstream, apply some related dpatches, commmit, delete dpatches, branch again, apply some other dpatches, commit, delete dpatches.
[09:19] <madduck> i was doing this as part of the arch live demo on IRC.
[09:20] <\sh> that means but, that all changes someone made has to be logged in debian/changelog clearly as possible...so one of the other packagers know what happend...
[09:21] <madduck> i have started to create one changelog for each feature branch
[09:21] <madduck> and there are the VCS logs too.
[09:22] <\sh> I hope jblack is a lucky guy and can convience as many upstream authors as he can reach to change from cvs/svn to baz/bzr/arch ,-)
[09:24] <\sh> madduck: thx for clarification of all this "crazyness" :)
[09:24] <j^> madduck did you look at arch-buildpackage, the version in debian supports bazaar now
[09:25] <madduck> j^: yes, i believe i noted that at the bottom of the irc live meeting log.
[09:27] <\sh> madduck: btw...I wanted to ask you something about your book :) Will you release your work to the public, after some time, like sebastian bergmann did it with his php 5 book?
[09:28] <madduck> \sh: this is not for me to decide, but i surely pester my publisher a lot about it.
[09:28] <madduck> \sh: right now, it looks as if it will become open when i release version 2, so with etch.
[09:29] <\sh> madduck: sounds good :)
[09:32] <\sh> when I have the time
[09:44] <slomo> ree... only had a beer with my neighbour :) \sh, can you outline what madduck said? (yes, i'm lazy ;) )
[09:46] <\sh> slomo: I will write a wrapup..next week...when I tried out what madduck said..it's now clear and ok with me :)
[09:47] <slomo> \sh: lol ok, in your blog?... what about j^'s case? patch in diff.gz or in debian/patches?
[09:48] <\sh> slomo: if he document all his changes correctly in debian/changelog it's ok
[09:48] <\sh> but when his changes are going upstream anyway..we should wait with uploading
[09:49] <slomo> \sh: ok fine... but in that case i will not update the package to another upstream release when the diff.gz doesn't apply cleanly :P for such things bazaar is then the better solution?
[09:51] <\sh> slomo: the diff.gz should be the delta between orig.tar.gz and the bazaar branch...when I understand madduck correctly
[09:51] <\sh> slomo: I have to play with it.and trial and error madducks explanations :)
[09:52] <slomo> \sh: so when the package is updated to a newer upstream it get's updated per bazaar and then i do the packaging from bazaar? and not as before with uupdate for example?
[09:53] <\sh> slomo: there is a orig upstream import in bazaar and a local branch of your changes (also in as a local bazaar repos)
[09:55] <slomo> \sh: but the "local" branch has to be made public when i package something with it, right? otherwise other people can't easily update the package... or is the local branch included with the diff (all the arch directories)
[09:55] <\sh> the local branch is the diff.gz
[09:56] <slomo> so when i use bazaar i can easily update from upstream?
[09:56] <\sh> no
[09:56] <\sh> you have to import
[09:58] <slomo> hmm... but when i have imported upstream and have the unpacked package (with diff applied) lying around i can easily merge these two?
[09:58] <slomo> (hmm... we must be insane to talk about such things on a saturday evening ;) )
[09:58] <\sh> yeah phoning
[10:00] <tgall> any powerpc types around ?
[10:00] <slomo> tgall: me... but mine is currently unbootable ;)
[10:02] <tgall> slomo,  heh .. I'm trying to connect with someone that does powerpc work for both mentoring and basically to fix the install cd to it runs on IBM ppc64 hardware
[10:02] <tgall> slomo, I have linux on my ppc64 boxen but .. not exactly ubuntu :-)
[10:03] <slomo> tgall: ah ok... then i'm probably not the right address ;) i only have a normal ppc (G4)... better ask in #ubuntu-devel for such things
[10:04] <tgall> k ... thanks slomo
[10:05] <slomo> j^: /bin/sh: ./configure: No such file or directory
[10:05] <slomo> j^: please try to build your package in pbuilder ;)
[10:06] <j^> how much space does pbuilder need?
[10:06] <slomo> <200 mb
[10:06] <j^> slomo are you sure you have the latest version?
[10:07] <slomo> j^: the latest on your webspace
[10:07] <j^> yes
[10:07] <slomo> j^: and please document your changes to the sources somewhere in the changelog ;)
[10:08] <j^>  apt-get source -b network-manager works here
[10:09] <j^> http://bootlab.org/~j/NetworkManager-breezy/nm-patches/
[10:09] <slomo> 'pbuilder build network-manager_0.4.1+cvs20050817-0ubuntu3.dsc' doesn't... so it won't work on the buildds ;)
[10:09] <hub_> oh
[10:09] <hub_> a new version
[10:10] <slomo> j^: document the changes in the changelog so everyone can find them :)
[10:12] <j^> pbuilder create --distribution breezy does not work
[10:12] <crimsun> are you using the pbuilder from Hoary?
[10:12] <crimsun> (Breezy is not defined as a distro in that version)
[10:12] <j^> i am using breezy
[10:13] <slomo> j^: what doesn't work?
[10:13] <j^> sladen $ builder create --distribution breezy
[10:13] <j^> slomo
[10:14] <j^> sladen sorry, you have the wrong nic today
[10:14] <slomo> j^: i mean what error do you get ;)
[10:14] <j^>  -> running debootstrap
[10:14] <j^> I: Retrieving Release
[10:14] <j^> E: Failed getting release file http://ftp.jp.debian.org/debian/dists/hoary/Release
[10:14] <j^> s/hoary/breezy
[10:15] <slomo> j^: https://wiki.ubuntu.com/PbuilderHowto
[10:15] <slomo> well... i'll move to tv now... see you later ;)
[11:05] <tseng> whiprush: what is your google plz