[12:02] <lucas> yep
[12:03] <LaserJock> lucas: so I want to get the list of Universe source packages from the science, math, and tex sections
[12:03] <LaserJock> lucas: I think that mdt will work nicely except for tex
[12:04] <lucas> why not for tex ?
[12:04] <lucas> you can use mdt-grep-dctrl-* to get the list of sources packages in those sections
[12:04] <LaserJock> well, maybe it will but the problem is that if I use dist-grep-dctrl- I will get both tex and text sections
[12:05] <lucas> what you are doing currently with grep-dctrl ?
[12:05] <LaserJock> hmm, maybe it wouldn't be a problem with Universe packages because I could grep for tex/universe
[12:05] <LaserJock> but then in Debian I don't know what would happen
[12:06] <lucas> what's your current syntax ? :-)
[12:07] <lucas> mdt dist-grep-dctrl-sources dapper -n -s Package -F Section -e "tex$"
[12:07] <lucas> doesn't this work ?
[12:08] <ajmitch> morning
[12:08] <LaserJock> lucas: looks like it would, let me try it
[12:10] <LaserJock> hi ajmitch and Hobbsee
[12:10] <Hobbsee> hey LaserJock :)
[12:10] <lucas> mdt dist-grep-dctrl-sources dapper -n -s Package \( -F Section -e "tex$" \) -o \( -F Section science \) -o \( -F Section math \)
[12:10] <ajmitch> hello Hobbsee, LaserJock
[12:10] <lucas> then mdt compare-versions sid dapper
[12:10] <lucas> then mdt filter
[12:10] <Hobbsee> hi ajmitch :)
[12:10] <lucas> hi ajmitch
[12:26] <theCore> does lighttpd will be include into the breezy repo, or only in dapper's one
[12:26] <tseng> only dapper
[12:26] <tseng> breezy is released, its done.
[12:28] <theCore> ok
[12:28] <irvin> theCore interested in lighttpd?
[12:28] <theCore> irvin, yeah
[12:28] <irvin> i have a debian package that can work in breezy, i'm using it myself :D
[12:29] <theCore> where can I get it ?
[12:29] <irvin> theCore pls wait, i'll rm .htaccess on the webserver
[12:30] <irvin> theCore, http://www.metawire.org/~ippfx/lighttpd
[12:31] <LaserJock> lucus: works wonderfully! For tex and science I got 1 or 2 packages less than what I got in Synaptic but that is ok for me
[12:32] <theCore> irvin, thanks
[12:33] <irvin> theCore, remembers that it is UNOFFICIAL, lighttpd from Debian unstable is broken on breezy
[12:33] <irvin> s/remembers/remember
[12:33] <theCore> irvin, it's a quite small bed file
[12:33] <irvin> yeah
[12:36] <theCore> irvin, does the dapper's deb would work with breezy ?
[12:37] <irvin> theCore, i dunno
[12:39] <irvin> the dapper deb requires a higher libssl version than the one on breezy
[12:39] <theCore> maybe I will package it myself
[12:40] <irvin> sure
[12:53] <LaserJock> lucas: ping?
[12:57] <lucas> pong
[12:58] <LaserJock> lucas: sorry, I was just making the .html files but ruby was acting up. I think I have it fixed now.
[12:58] <lucas> ok
[12:59] <LaserJock> lucas: everything is working smoothly. The only thing is that the lists of source packages are different for Debian and Ubuntu so I am using the larger of the two to filter with
[01:00] <lucas> you can use list_union and list_unify
[01:00] <lucas> it's probably better to get the largest list possible
[01:01] <crimsun> lucas: please add a note to http://tiber.tauware.de/~lucas/versions/unimultiverse.html#outdatedinB that libpng in Ubuntu does not correspond to Debian's libpng and thus should not be merged.
[01:02] <crimsun> (Debian moved libpng3 -> oldlibs and renamed it to libpng, therefore the major versions don't match)
[01:02] <LaserJock> lucas: is it possible to set what A and B when creating the html?
[01:02] <lucas> mdt versions2html --help
[01:02] <lucas> :-)
[01:03] <lucas> --titleA & --titleB
[01:03] <LaserJock> ah, thanks
[01:04] <lucas> crimsun: done, it will show up during the next update
[01:04] <lucas> good night
[01:05] <LaserJock> lucas: thanks so much
[01:25] <rbelem> g'evening people
[01:25] <LaserJock> hello
[01:25] <rbelem> hey LaserJock
[01:27] <rbelem> LaserJock: can you test a package for me?
[01:27] <rbelem> deb http://www.estudiolivre.org/videos/lives/ubuntu/breezy/ binary-i386/
[01:28] <rbelem> the package is lives
[01:28] <LaserJock> k
[01:29] <rbelem> people reported some erros under i386 but i don't have one
[01:30] <rbelem> to test
[01:31] <crimsun> LaserJock: do you have a debdiff for #5598 ?
[01:31] <crimsun> Ubugtu: 5598
[01:32] <LaserJock> crimsun: sadly no, it is a big project and I am kinda feeling in over my head
[01:32] <crimsun> I'll handle it, then.
[01:32] <LaserJock> crimsun: I have worked on it but it isn't done
[01:33] <crimsun> it's really a straight-forward merge. Most of the changes have been adopted by Debian, so you only need to check debian/control
[01:33] <LaserJock> hmm, well I got the control stuff done, are you sure that there aren't changes that need to be done in debian/rules
[01:33] <crimsun> LaserJock: just the 2.4-relevant stuff
[01:33] <LaserJock> I was having a hard time figuring out what had been done
[01:34] <LaserJock> rbelem: I ran lives-exe and it crashed on me
[01:34] <rbelem> :/
[01:34] <LaserJock> crimsun: I couldn't get it to generate control from control.in
[01:35] <\sh> LaserJock: it's a cdbs switch :)
[01:35] <LaserJock> \sh: but it doesn't use cdbs
[01:35] <rbelem> LaserJock: under amd64 it run well
[01:36] <\sh> then it's using some autotools magic :) or some magic in the rules file to sed some things in control.in
[01:36] <LaserJock> there is a rule in debian/rules but it doesn't seem to work right
[01:36] <LaserJock> at least I can't get it to work
[01:36] <crimsun> you need to rm debian/control first
[01:36] <crimsun> otherwise since debian/control exists, it will never be regenerated
[01:37] <LaserJock> I get an error - sed: -e expression #1, char 55: unterminated address regex
[01:38] <\sh> I wonder why the wine package from breezy is FTBFSing
[01:39] <\sh> something is wrong with the fonts generation..and it should never have build on breezy in the first place
[01:41] <rbelem> thanks LaserJock. i'll try to discover the problem
[01:44] <LaserJock> crimsun: you're sure that nothing needs to be changed in debian/rules?
[01:45] <crimsun> LaserJock: no, debian/rules is pretty messy. I'm hand-merging from a clean Sid package.
[01:48] <LaserJock> crimsun: so how do you know that the previous Ubuntu changes have been applied to the sid package?
[01:49] <crimsun> easy, you read the changelog.
[01:49] <crimsun> then you check the source
[01:49] <crimsun> if doko says upstream applied 'em, I tend to trust the entry.
[01:49] <crimsun> the only changes that need to be made are libGL{U} and python2.4
[01:49] <crimsun> pretty much everything else is referenced in the changelog
[01:50] <LaserJock> crimsun: ok, so what about the last Debian entry?
[01:51] <crimsun> LaserJock: the one that doko forward-references in the last entry of 2.4.4.1ubuntu1?
[01:52] <LaserJock> crimsun: I guess so, well that makes it much easier. I could've done that
[01:52] <crimsun> yep.
[01:52] <LaserJock> crimsun: I was just being cautious and making sure everything was applied and I got swamped
[01:53] <crimsun> when in doubt always revert to the Debian revision and by-hand [check-in]  the Ubuntu changes
[01:54] <LaserJock> well, I was going to do that but I got confused when I couldn't get the Debian source that the Ubuntu version was based on
[01:54] <LaserJock> crimsun: so did you upload it already?
[01:54] <crimsun> no, I'm building it right now
[01:55] <LaserJock> oh, ok. I was going to say that I could send a debdiff since I did the changes already
[01:58] <LaserJock> when I did a debdiff between 2.4.4.1.1 and 2.4.4.1ubuntu1 I did get a bunch of changes in debian/rules where := was changed to =
[01:59] <\sh> damn...I fixed the issue with breezies wine...now for the security patch
[02:01] <LaserJock> crimsun: were you able to generate the control file?
[02:31] <\sh> hmmm..someone else is now in favor of njam in debian as it looks like
[02:37] <Amaranth> gnome 326379
[02:37] <Ubugtu> Gnome bug 326379: "small leak in gweather applet" Product: gnome-applets, Component: gweather, Severity: normal, Assigned to: gnome-applets-maint@gnome.bugs, Status: RESOLVED, Resolution: FIXED http://bugs.gnome.org/show_bug.cgi?id=326379
[03:06] <crimsun> mm hackety hack.
[03:07] <Yagisan> re
[03:07] <Yagisan> crimsun: where ?
[03:10] <crimsun> Yagisan: wxwindows2.4's debian/rules triggers a sed anomaly.
[03:10] <Yagisan> crimsun: thought you were talking about my new rules file for http://revu.tauware.de/details.py?upid=1445
[03:11] <Yagisan> crimsun: makes i386 and amd64 debs out of an i386 pbuilder
[03:11] <Yagisan> bbl
[03:16] <\sh> Yagisan: as 32bit compat package for amd64?
[03:22] <Yagisan> \sh:  yes. sorry I'm rather busy today - just about to leave for the embassy
[03:23] <Yagisan> \sh: please check it out - if everyone is ok with it, I'll do the same for wine
[03:23] <\sh> Yagisan: well...first of all, I have to enable --enable-win64 or something like this to have at least a real amd64 version
[03:24] <\sh> and tweak a bit in debian/control
[03:25] <Yagisan> \sh: this is for packages that can't be built 64bit, or that need to be build 32bit for certain functionality
[03:25] <Yagisan> \sh: eg for wine, there will be wine, and wine-32 for amd64
[03:25] <\sh> Yagisan: no :)
[03:26] <\sh> Yagisan: there will be wine for 32bit, wine64 for amd64 and wine64-compat-32bit or something like this for the compat lib
[03:26] <\sh> where wine64 will only be build on 64bit archs
[03:27] <\sh> ajmitch: -EOTHERWISH
[03:27] <Yagisan> \sh: names are just details - I'll get it working first, then we can argue about names
[03:27] <ajmitch> \sh: hey, wine used to work with diablo II here :)
[03:27] <ajmitch> 0.9.4 completely broke it
[03:27] <\sh> ajmitch: try it with 0.9.5
[03:27] <\sh> which I uploaded today
[03:27] <ajmitch> ok
[03:27] <Yagisan> 0.9.4 broke every win app I used
[03:28] <ajmitch> Yagisan: it's depressing seeing those regressions
[03:29] <Yagisan> ajmitch: they have a 0.9.5, so maybe that works
[03:29] <Yagisan> ajmitch: like my hackery with zsnes ?
[03:30] <ajmitch> haven't seen it
[03:30] <ajmitch> does it work?
[03:31] <Yagisan> ajmitch: I believe so - it built :) toss it into and i386 pbuilder and marvel at how it drops packages for two arches out
[03:31] <ajmitch> impressive
[03:31] <ajmitch> what hackery was required there?
[03:32] <Yagisan> ajmitch: I had to butt heads with dpkg a lot. Check out my handiwork in the rules file here http://revu.tauware.de/details.py?upid=1445
[03:32] <\sh> ajmitch: exchaning arch names of the packages from i386 to amd64  ,)
[03:32] <\sh> rough overview that was :)
[03:32] <ajmitch> will it work for wine? :)
[03:33] <\sh> ajmitch: not exactly but somehow similar
[03:33] <Yagisan> ajmitch: should - I'll do the dapper package tonight
[03:33] <ajmitch> sigh
[03:33] <ajmitch> downloading wine is taking too long
[03:34] <\sh> ajmitch: first there has to be an amd64 native package...which means I have to ask for the arch type and if amd64/ia64/whatever and add --enable-win64 or something like this to configure
[03:35] <\sh> ajmitch: on i386 side, we have to add another binary package control description like wine64-compat32 or something
[03:35] <\sh> and toss the 32bit wine stuff into this package for amd64
[03:35] <\sh> and changing the arch type of the package to amd64
[03:35] <\sh> which is somehow tricky and i'm not sure if I want that really
[03:36] <\sh> but anyways...I just made a new 0.9.5 upload today with wmf fix
[03:36] <\sh> pitti has now breezy and hoary fixes for the respective wine versions
[03:37] <\sh> so I'm done with wine for today
[03:37] <ajmitch> I doubt it'll get diablo 2 going again, knowing the wine hackers
[03:40] <ajmitch> wow, it runs again
[04:09] <LaserJock> crimsun: so debian/rules did have a problem?
[04:23] <TheMuso> c
[04:36] <LaserJock> what app do I need to be able to send emails from a file or console via smtp?
[04:39] <hub> postfix
[04:39] <hub> sendmail
[04:39] <hub> or any mta
[04:40] <LaserJock> aren't those servers?
[04:41] <ptlo> LaserJock: most console email apps use local mta to send mails ... examples are mutt, pine, elm. although i do believe mutt can use remote smtp server
[04:41] <lifeless> simple-mail or something
[04:41] <lifeless> theres a package that just gives you a mail sender
[04:41] <ptlo> of course you can always use telnet for that, too ;-)
[04:41] <lifeless> maybe it was xmail
[04:42] <LaserJock> ok, I just want to be able to send out emails to my smtp server for the CLI without having to install an email server or something
[04:43] <lifeless> ssmtp
[04:45] <LaserJock> lifeless: ahh, I think that might be what I am looking for
[04:45] <LaserJock> everything seems to assume I have a local mail server.
[04:47] <psusi> postfix got installed for me when I installed apache I think
[04:47] <psusi> so I just use that
[04:47] <psusi> also installed dovecot on my server at work for imap access, and set up a cron job to pull the mail from lkml.org
[04:48] <psusi> imap rules
[04:48] <LaserJock> right now I'm just trying to use reportbug so I can send some stuff to BTS
[04:48] <psusi> now I just need to get dovecot to be able to 7zip compress archive folders so my 50,000 old messages only take up 10 MB instead of 100 ;)
[05:14] <mr-russ> How is decided what is in main or not?
[05:14] <hub> mr-russ: what Ubuntu is willing to provide support for
[05:15] <mr-russ> as in the paid developer people.
[05:15] <mr-russ> or anybody who gets main upload rights.
[05:16] <hub> as in "Ubuntu the project"
[05:16] <hub> they have goal and package are here to achieve the goals
[05:16] <hub> there are also security riquirements in these goals
[05:17] <ajmitch> main inclusion reports get written up & software reviewed for it to go into main
[05:17] <mr-russ> okay. that's giving a good picture thanks.
[05:18] <hub> mr-russ: universe is for the rest of the freely redistribuable sofware
[05:20] <mr-russ> how do you alter a debian package so that is has ubuntu version?
[05:20] <ajmitch> edit debian/changelog
[05:20] <ajmitch> add a new revision, so that 1.2.3-4 becomes 1.2.3-4ubuntu1
[05:20] <mr-russ> okay, so the deb gets the revision number for there.
[05:20] <mr-russ> debian/ubuntu packaging is all a bit new to me.
[05:21] <mr-russ> I always have to throw myself in at the deepend though.
[05:21] <ajmitch> each revision has the version line, with distribution (dapper in our case, unstable or experimental for most debian uploads)
[05:21] <ajmitch> :)
[05:21] <ajmitch> it's the best place to start ;)
[05:22] <hub> mr-russ: but only if you need to change something
[05:23] <mr-russ> how are security patches to universe managed?  eg updates to packages in say breezy.
[05:23] <mr-russ> hub: I've got one package that I've updated, and need to get updated in debian.
[05:23] <hub> mr-russ: if there is a security report a patch is issued, tested and the current package patched to include the fix
[05:23] <mr-russ> hub: I'm also trying to create some of my own specialized packages.
[05:23] <hub> mr-russ: what do you mean. a new version?
[05:24] <mr-russ> hub: so I'm trying to learn how to do everything :)
[05:24] <hub> https://wiki.ubuntu.com/MOTU
[05:24] <mr-russ> hub: one case is a new version been trying to merge 2 forks of a package, one maintained by me, one by the debian folk.
[05:24] <hub> if the package is in main, file a bug
[05:25] <mr-russ> I'm getting good a filing bugs :)
[05:46] <hub>  any revu admin?
[05:49] <ajmitch> yes?
[05:50] <hub> I have a dput that failed
[05:50] <hub> to to crappy internet connection
[05:50] <ajmitch> :)
[05:50] <hub> so I the file is stuck
[05:50] <hub> gopersist_0.1.1-0ubuntu1.dsc
[05:50] <ajmitch> yep
[05:51] <ajmitch> removed
[05:51] <hub> thx
[06:07] <hub> fscking hell
[06:07] <hub> this connection suck
[06:32] <hub> anyone packaging synfig?
[06:44] <crimsun> wow, so UVF is Jan 19th
[06:46] <ajmitch> very close
[06:46] <ajmitch> crimsun: still no closer with sound :)
[06:47] <LaserJock> what has to be done before then?
[06:48] <crimsun> all the merges, hopefully
[06:48] <crimsun> ajmitch: d'oh :/
[06:48] <crimsun> did you try those tree model= values?
[06:48] <ajmitch> crimsun: there are quite a few comments on the upstream alsa bugtracker though
[06:48] <ajmitch> no, I haven't tried that one
[06:50] <ajmitch> #1517 on alsa's bugtracker if you're interested
[06:50] <crimsun> err, s/tree/three/
[06:50] <crimsun> (basic, hp, fujitsu)
[06:51] <crimsun> ok, thanks
[06:53] <LaserJock> arghh, why are there so many different MTAs
[06:55] <crimsun> because there must be more than one way to break your system
[06:56] <zakame> hi MOTUs :)
[06:56] <LaserJock> all I want to do is be able to use reportbug and other CLI progs that send mail
[06:57] <crimsun> LaserJock: you can set up an ssh tunnel to punt it to an upstream MTA
[06:58] <crimsun> hi zak
[06:58] <zakame> yep, or masqmail
[06:58] <zakame> heya crimsun :)
[06:58] <LaserJock> crimsun: what would and upstream MTA be?
[06:59] <crimsun> LaserJock: I presume your ISP has one, or someone "outside" has a host running an MTA
[07:00] <LaserJock> crimsun: yeah, I'm on a department LAN. There is a smtp server but I just don't know what program to use to that reportbug etc. will be able to use
[07:00] <LaserJock> I think esmtp or ssmtp might work
[07:00] <crimsun> you could set up exim to do forwarding to your LAN's smtpd
[07:00] <zakame> LaserJock: that's a job for masqmail indeed :)
[07:00] <zakame> or yes, exim can forward too :)
[07:01] <LaserJock> zakame: will look into it
[07:01] <LaserJock> crimsun: is that relatively easy to do? I don't want to have to do a bunch of configuration when I won't be recieving any mail just sending it
[07:02] <crimsun> LaserJock: I can't speak for the others, but it was dead easy with exim in Debian Potato
[07:02] <crimsun> I can only presume that masqmail, et al. would be even more straightforward
[07:02] <LaserJock> ok, well I gotta get to bed, thanks crimsun and zakame for the suggestions
[07:02] <zakame> crimsun: I can also vouch for Woody exim :)
[07:03] <zakame> gn8 LaserJock :)
[07:11] <ajmitch> crimsun: none of those models work, sorry
[07:12] <crimsun> ajmitch: ok, thanks for testing.
[07:45] <zakame> heya jaldhar_
[07:55] <dholbach> good morning
[07:57] <zakame_> good day dholbach :)
[07:57] <dholbach> hello zakame
[10:38] <Yagisan> re
[10:41] <crimsun> re
[10:43] <Yagisan> G'day crimsun
[10:43] <crimsun> 'lo
[10:47] <zakame> hi all
[10:47] <crimsun> 'lo zak
[11:07] <zakame> heya Hobbsee
[11:07] <Hobbsee_away> hey zakame
[11:10] <crimsun> 'lo Hobbsee
[11:24] <dholbach> lifeless, ajmitch: what about uploading *sync to ubuntu's NEW queue?
[11:25] <dholbach> lifeless, ajmitch: i couldn't find the source packages to sponsor them to ubuntu
[11:25] <dholbach> lifeless, ajmitch: UVF is in 9 days
[11:25] <crimsun> yeah, that's why I've been scrambling w/ these merges
[11:26] <ajmitch> dholbach: you don't trust that they'll get through debian's NEW queue in the next 9 days?
[11:26] <ajmitch> given that the average time in the queue has been 2-4 days lately
[11:26] <lifeless> ajmitch: the plugins and guis definately wont
[11:27] <lifeless> ajmitch: unless we are extremely lucky
[11:27] <ajmitch> lifeless: not started yet?
[11:27] <dholbach> so why do we wait for debian's NEW queue? why don't we upload them as 0ubuntu1 and sync whenever they are through?
[11:27] <lifeless> dholbach: opensync is -not- ready for mainstream use anyway though
[11:27] <lifeless> dholbach: whats the rush? the software is crackful at the moment
[11:27] <dholbach> lifeless: would you consider mutilsync ready enough? :)
[11:28] <lifeless> multisync is stable, the new multisync built on opensync is painful
[11:28] <lifeless> missing gui bits, options that dont, its really quite painful.
[11:28] <dholbach> ok
[11:30] <Hobbsee_away> hi crimsun
[11:37] <azeem> have there been any complaints for multisync-0.8x in breezy/dapper?
[11:38] <azeem> I got another one that the last upload didn't fix the evo sync issues or so
[11:38] <lifeless> azeem: hey there
[11:38] <azeem> hi!
[11:38] <lifeless> ajmitch: azeem did all the plugins, its just that they cant upload until libopensync0 is available for the buildds
[11:40] <azeem> the GNOME people should just code up a decent "Syncing" Preferences capplet or something
[11:41] <azeem> or maybe somebody should help abauer with his exams, so he can hack more on opensync :)
[11:44] <\sh> grmpf...trying to fix qts immodule patch
[12:07] <Tonio_> dholbach: hi ;)
[12:07] <Tonio_> I won't be there for the CC meeting....
[12:08] <Tonio_> the scsi perc card crashed last night on our fileserver...
[12:08] <Tonio_> if I don't want to be fired today, I assume not spending time on irc is required ;)
[12:09] <Tonio_> \sh: hi, how was your interview ? was it good ?
[12:09] <dholbach> Tonio_: I'm sorry :/
[12:09] <\sh> Tonio_: moment...I'll tell you later...have to fix something asap :)
[12:09] <dholbach> Tonio_: you'll make it in the next one
[12:10] <Tonio_> dholbach: has always ;) always for the next one hehe
[12:10] <Tonio_> \sh: no pb :)
[12:10] <dholbach> :)
[12:10] <Tonio_> anyway, the most important is contributing, not especially beeing a member ;)
[12:12] <Nafallo> Tonio_: it's easier to contribute when you're a member though :-P
[12:13] <Tonio_> Nafallo: don't know what it changes exactly...
[12:13] <Tonio_> beeing a motu gives a lot of different possibilities.... but beeing a member ?
[12:13] <Nafallo> @ubuntu.com and requirement for motuness :-)
[12:14] <Tonio_> okay ;)
[12:14] <Nafallo> might even get some social stuff aswell :-)
[12:14] <Nafallo> s/get/gain/
[12:14] <Tonio_> in fact dholbach wanted me to come introducing at the CC for at least.... 6 month I think :)
[12:15] <Tonio_> and there is always a problem lol
[12:15] <Nafallo> ouch
[12:15] <Nafallo> that's like 12 times :-P
[12:15] <Tonio_> yep.....
[12:16] <Tonio_> I have a job which takes me about 55 hours a week....
[12:16] <Tonio_> so the only way to contribute is by night, and CC are most often during the day....
[12:17] <Nafallo> :-)
[12:18] <Nafallo> Yagisan: you should totally add a subpage to the PbuilderHowto! :-)
[12:19] <Yagisan> Nafallo: what - how to abuse^Wuse the build system
[12:20] <Nafallo> yea :-)
[12:20] <Nafallo> I think my girlfriend would love me to stop using her box for i386 pbuilding ;-)
[12:21] <Yagisan> Nafallo: you have amd64 ?
[12:21] <Nafallo> yepp, my laptop :-)
[12:21] <Yagisan> Nafallo: easiest way is to install pbuilder in an i386 chroot
[12:21] <Yagisan> Nafallo: least effort - but needs more disk space
[12:22] <raphink> lucas: I see you put notes on your merging page. Could you add a note to wesnoth so it's not merged?
[12:22] <Nafallo> then I have to create an i386 chroot. and I'm lazy. so I rather ssh silverfairy ;-)
[12:22] <raphink> lol
[12:22] <raphink> Nafallo: build on her comp through ssh so she doesn't notice ;)
[12:22] <Yagisan> Nafallo: amd64 boxes are quicker - even with 32bit code
[12:22] <raphink> she'll only notice it's a bit slow sometimes ;)
[12:23] <raphink> hehe
[12:23] <raphink> creating an i386 chroot takes about 10 minutes
[12:23] <Nafallo> Yagisan: yea, but then I have to use a chroot :-P
[12:23] <raphink> if you're not too fast
[12:23] <raphink> Nafallo: really setting up a chroot is very easy
[12:24] <raphink> I have 2 running on this box
[12:24] <raphink> Nafallo: https://wiki.ubuntu.com/DebootstrapChroot
[12:24] <raphink> Nafallo: that takes you through the whole settings of a chroot ;)
[12:24] <Nafallo> raphink: I know. but I would rather have pbuilder cross-compile and give me both amd64 and i386 in one go :-)
[12:24] <raphink> oh sure
[12:25] <raphink> for some reason, I use both pbuilder and dchroot ;))
[12:25] <raphink> not for the same purpose
[12:25] <raphink> different tools for different things :)
[12:25] <raphink> if you just want to build stuff for i386 then sure pbuilder is better ;)
[12:25] <Nafallo> I use pbuilder login :-)
[12:26] <Nafallo> anyway. have to go after this upgrade.
[12:29] <viviersf> guys
[12:29] <viviersf> nm
[12:56] <raphink> Riddell: are you there?
[01:03] <ajmitch> crimsun: bug reports on forums, of all places, about python-wxgtk2.4 not installing (bad postinst)
[01:07] <crimsun> ajmitch: thanks, I'll look
[01:08] <Mithrandir> Yagisan: it's not
[01:09] <Mithrandir> unless you _know_ that you want something else than -O2, you don't
[01:11] <Yagisan> Mithrandir: just idle thoughts now they are implementing directx.
[01:12] <Mithrandir> Yagisan: -O2 is generally the fastest anyway
[01:13] <\sh> Yagisan: please don't upload this package to revu...put it somewhere else where I can access it :
[01:13] <\sh> )
[01:14] <Yagisan> Mithrandir: yep, but some of the other flags are helpful too depending on the source
[01:15] <Yagisan> \sh: I'll host it on my adsl connection then - 256K up
[01:15] <\sh> brb
[01:16] <Mithrandir> Yagisan: oh, like?
[01:18] <Treenaks> Mithrandir: the CPU-specific ones! don't you read the Gentoo forums?
[01:20] <lucas> raphink:
[01:20] <lucas> the best would be to store the notes elsewhere
[01:20] <Yagisan> Mithrandir: On some sources, -fweb, -funswitch-loops, and -ftracer can have an effect. -fomit-frame-pointer is nice on i386, but you can't debug with it
[01:20] <lucas> I could easily fetch them, it's only a text file
[01:21] <Yagisan> Mithrandir: but unless you want to sit there and measure it to be sure, it may not be worth it. I also observe that optimising for size
[01:21] <Yagisan> Mithrandir: can sometimes be faster then -O2
[01:22] <\sh> Yagisan: this is gentoo logic :)
[01:22] <raphink> lucas: hi
[01:22] <raphink> lucas: to store them where then?
[01:22] <lucas> on the wiki maybe
[01:22] <Yagisan> \sh: Only some apps that are cpu bound are worth testing like that
[01:22] <lucas> I'll try to implement that later today
[01:22] <raphink> lucas: ok
[01:22] <Yagisan> \sh: on all apps, it's a waste of time
[01:23] <raphink> lucas: then the best is that you create the wiki page you want to fetch from it
[01:23] <\sh> Yagisan: well...apps like mplayer etc. are bringin in most of the time their own cflags ...
[01:23] <raphink> with something like a table to put the notes in
[01:23] <Yagisan> \sh: not my mplayer package ;)
[01:23] <\sh> Yagisan: that's why many users of gentoo were fcked while they tweaked their cflags to hell..and were wondering that mplayer never worked properly
[01:24] <Yagisan> \sh: sed is your friend :)
[01:25] <raphink> lucas: superkaramba is also to be nuked from the list
[01:25] <Yagisan> \sh: its a very bad idea to obsessively tweak cflags for all apps - things break. things like xvid, x264 tend to benefit most
[01:45] <Czessi> \sh: my package is now in revu
[01:46] <\sh> Czessi: cool
[01:46] <Czessi> http://revu.tauware.de/details.py?upid=1457
[01:46] <Czessi> but iam now away for the next hours
[01:48] <\sh> k
[01:57] <\sh> Czessi: advocated...everything is ok :) wow :)
[01:58] <\sh> I wonder how amu is managing it, to catch the right people ;)
[01:58] <Czessi> \sh: *falling down from my chair* ;)
[01:59] <\sh> Czessi: now you need a second vote...and your first package will be uploaded :)
[01:59] <Czessi> :D
[02:00] <Czessi> \sh: iam away, see you later, bye
[02:00] <\sh> Czessi: ok :) have fun :)
[02:02] <lucas> can somebody install elinks on tiber ?
[02:03] <lucas> siretart ?
[02:03] <\sh> elinks?
[02:03] <lucas> console web browser
[02:03] <lucas> I need to be able to do a links -dump on https://wiki.ubuntu.com/MOTUNotes
[02:03] <\sh> lynx -source ?
[02:04] <lucas> lynx is not installed
[02:04] <\sh> but anyways..installed
[02:04] <\sh> now
[02:04] <\sh> elinks
[02:04] <lucas> and probably doesn't support HTTPS
[02:04] <lucas> thanks, it works perfectly
[02:10] <Yagisan> but on the bright side, I did make 32bit packages for amd64 and i386
[02:12] <\sh> Yagisan: I told you :) you have to cover some things :)
[02:13] <\sh> Yagisan: first of all, we have to create a wine64 package with real win64 dlls inside...which can be done via if arch == amd64 in the rules file and adding a --enable-win64 or something like this to the configure statement...then we need a new package for wine64-compat32 or something similar where all the 32bit libs are in (which are build for amd64 on i386 buildd) but we have to make sure, that they're installed in a different place...to no
[02:14] <Yagisan> \sh: yeah, I know - but it's a start. most of the groundwork is there
[02:14] <\sh> Yagisan: let me have a look...on how I can build a wine64 package...if this is done...you can grab the package and add your 32bit compat stuff...
[02:15] <\sh> Yagisan: the most difficult part about it, it's the different location for those libs
[02:15] <Yagisan> \sh: want my current package ?
[02:16] <Yagisan> \sh: it's well documented
[02:16] <\sh> Yagisan: no...I need only the rules file...but first let me create this amd64 package :)
[02:16] <Yagisan> \sh: you'll need more then the rules file
[02:16] <sistpoty> hi folks
[02:17] <Yagisan> \sh: I'm just waiting for my amd64 dapper pbuilder to finish being created
[02:17] <sistpoty> is kubuntu@czessi.net here? (regarding kiso upload)
[02:17] <\sh> sistpoty: he is just gone...what about kiso?
[02:18] <sistpoty> the orig tarball is changed
[02:18] <sistpoty> this is a nogo for me :(
[02:18] <\sh> what?
[02:19] <tseng> sistpoty: if you update the same revision to revu why does it diff backwards
[02:19] <tseng> sistpoty: it is --- new +++ old
[02:19] <sistpoty> \sh: also it's explained in debian/changelog that the orig-tarball is modified... just to quiet lintian is no reason to do so
[02:19] <Yagisan> \sh: my current rules for wine
[02:19] <sistpoty> tseng: it shouldn't actually (checking)
[02:20] <tseng> sistpoty: look at openvpn-admin
[02:20] <\sh> Yagisan: can you send it to me via email?
[02:20] <tseng> sistpoty: in the second upload i did s/cowbell/openvpn-admin in rules
[02:20] <tseng> sistpoty: it shows the reverse (and shows the old diff.gz)
[02:20] <Yagisan> \sh: yep -  I see dcc failed
[02:21] <sistpoty> tseng: it shows it right... you need to select the latest upload first
[02:21] <tseng> oh?
[02:21] <tseng> ok
[02:21] <sistpoty> tseng: it will always debdiff between the upload you clicked on and the one of the debdiff link
[02:22] <sistpoty> (so you can do reverse or forward debdiffing to your liking)
[02:22] <\sh> oh yes...I see...
[02:23] <sistpoty> \sh: strange enough for almost every second package I reviewed the orig-tarball was changed :(
[02:23] <\sh> well...for gajim I used the tar.bz2 which I repackaged to tar.gz...but right now it doesn't matter, because we are just upstream for gajim ;)
[02:24] <lucas> ok, the comments on MOTUNotes now show up in the lists
[02:24] <sistpoty> hehe
[02:24] <lucas> now integrating sistpoty's merge info
[02:24] <sistpoty> \sh: well, repacking is sometimes necessary... ;)
[02:24] <\sh> sistpoty: I adjusted my decision...thx for pointing it out :)
[02:25] <Yagisan> \sh: emailed
[02:25] <sistpoty> \sh: you're welcome ;)
[02:25] <\sh> sistpoty: but actually it's a little mistake...the package itself is quite nice :)
[02:25] <\sh> Yagisan: thx
[02:25] <sistpoty> \sh: just building it... and it looks quite good
[02:28] <Yagisan> \sh: email arrive yet ?
[02:28] <\sh> Yagisan: yepp..
[02:29] <Yagisan> \sh: hmm - you don't seem to happy. what's wrong ?
[02:29] <bmonty> good morning everyone
[02:30] <Yagisan> G'day bmonty
[02:30] <\sh> Yagisan: the wine app (in /usr/bin) do we need a 32bit version on amd64 as well, for 32bit compatiblity, right?
[02:30] <Yagisan> \sh: yes. I think we should leave the name of the app as wine, as many (3rd party) scripts need it
[02:30] <\sh> Yagisan: or will wine (real 64bit) start up with the 32bit libs, if it finds out that the windows app I want to start is 32bit?
[02:31] <Yagisan> \sh: no. we need to write a wrapper ousrselves
[02:32] <Yagisan> \sh: I'd like to concentrate firstly on getting 32bit wine on amd64 going, then 64bit wine, and finally a wrapper
[02:32] <\sh> Yagisan: ok...so the problem is right now, to find a way to move all 32bit stuff to a new location...where we don't clash with the 64bit stuff
[02:33] <Yagisan> \sh: yes. I can just mv /lib to /lib32, but we don't have a /bin32
[02:33] <\sh> Yagisan: no, we have to do it directly...if I'm enabled wine for 64bit, the default package has the content of wine64
[02:33] <bmonty> hmm....merge page is looking really good :)
[02:34] <\sh> Yagisan: another question....do we need linux32 for it to start it in 32bit mode?
[02:35] <Yagisan> \sh: no. linux32 just makes the arch appear to be i686 when asked
[02:35] <\sh> I'm a sucker somehow...I never used wine...everytime I wanted to use it, my application I needed wasn't running with wine...
[02:35] <bmonty> \sh: that is my experience with wine as well
[02:35] <Yagisan> \sh: I know - it breaks on me too
[02:36] <Yagisan> \sh: but virtualdub can't be ported, so I keep trying
[02:37] <\sh> hmm..what I pressed now?
[02:38] <Yagisan> \sh: do you have an amd64 system there ?
[02:38] <\sh> Yagisan: let me think about a good solution...how we can deal with the clashes and the namespace
[02:38] <\sh> Yagisan: yepp...but without a monitor..so I can only run it via ssh -X
[02:38] <Yagisan> \sh: mv * *-64 ?
[02:40] <Yagisan> \sh: also need to automagically adjust debian/files based on the version number
[02:40] <\sh> no..I want to have the wine64 stuff the same way as it is on i386...but the wine32 compat stuff on amd64 must be named differently...the question is, the libs we can move to /lib32, I'm not sure, if we have to compile this beast again with the new location..or just add something to LD_LIBRARY_PATH
[02:40] <\sh> I would like to see something like this on amd64: wine (for 64bit version) and wine32 for the compat thing
[02:40] <sistpoty> \sh: kiso is really nice work... if the next upload changes only the orig-tarball, and you review it before me, you can upload it ;)
[02:40] <\sh> sistpoty: ok :)
[02:41] <Yagisan> \sh: just move the libs. ldconfig will scan the libs on install anyway
[02:41] <\sh> Yagisan: but we will have a name clash with /usr/bin/wine
[02:41] <bmonty> quick question, what are you all using for an editor/IDE for python?
[02:42] <sistpoty> bmonty: vi ;)
[02:42] <\sh> bmonty: emacs, vi, or eric :)
[02:42] <Yagisan> \sh: yes - we need to rename or move the binaries
[02:42] <sistpoty> bmonty: but apart from that I've once played with eric, which is cool for debugging. I've heard eclipse would be quite good as well
[02:42] <bmonty> I'm using vi, but I didn't know eclipse spoke python also
[02:43] <sistpoty> bmonty: didn't test it yet... just read about it
[02:43] <\sh> Yagisan: I'll think about a good way to do it...need to rest a little..
[02:43] <bmonty> sistpoty: I'll have to look in to that
[02:43] <\sh> well..eclipse is heavy stuff for python :)
[02:43] <\sh> to just edit a single source ,)
[02:44] <bmonty> \sh: yeah, but I like eclipse
[02:44] <sistpoty> \sh: you can do big projects (like revu2) in python as well :P
[02:44] <bmonty> especially when there are multiple source files
[02:44] <\sh> I like eric because it has a nice project management and only needs libqt pyqt
[02:44] <Yagisan> \sh: feel free to email me changes
[02:45] <\sh> sistpoty: hehe..I meant for "just a quick edit" ...
[02:45] <sistpoty> hehe
[02:46] <\sh> anyways...at 15:00 UTC there is CC meeting..I have to rest at least one hour or so
[02:46] <azeem> \sh: didn't you say you had an interview yesterday?  How did it work out?
[02:48] <\sh> well...I wasn't happy with myself...I started the day with stress..and during the interview, I just forgot everything I knew..the easiest questions...well..I managed somehow...and I will wait for them to call me again :)
[02:48] <\sh> I will see
[02:48] <azeem> hrm :-/
[02:50] <\sh> best thing was "how is traceroute working"...actually I explained it a couple of months ago during my juniper training to the other people....and yesterday I just forgot everything about it...my head felt empty
[02:50] <Riddell> raphink: hi
[02:50] <raphink> hi Riddell
[02:51] <azeem> \sh: you should have side-stepped the question and discuss whether traceroute should be in /bin or /sbin ;)
[02:51] <bmonty> lol
[02:51] <\sh> azeem: well..I should have told them that traceroute is not the standard on linux anymore...now it's named tracepath :)
[02:51] <bmonty> yeah, the was bugging me this morning...
[02:52] <\sh> bmonty: apt-get install traceroute and you feel home :)
[02:52] <Yagisan> \sh: I thought it was mtr ...
[02:52] <bmonty> \sh: I figured out that it is tracepath and I'm happy :)
[02:52] <bmonty> apropos is your friend
[02:54] <\sh> ok..going to sleep at least one hour...see you at the meeting
[02:54] <sistpoty> cya \sh
[02:54] <bmonty> cya later \sh
[02:54] <Yagisan> bye \sh
[02:54] <bmonty> I'm hoping my update completes before I have to leave for my plane
[02:55] <bmonty> and...doh its downloading openoffice :(
[02:55] <Yagisan> that's what 300mb ?
[02:56] <bmonty> Yagisan: its working on a 25mb file right now
[02:57] <bmonty> oh well, I'll probably have to cancel it
[02:58] <bmonty> have a great day!
[03:09] <mgalvin> hi all, i uploaded an updated gperfection icon theme package and a new the widget factory package to revu
[03:10] <mgalvin> just a heads up, in case any might have time to review them, thanks
[03:10] <mgalvin> s/any/any one/
[03:29] <lucas> http://tiber.tauware.de/~lucas/versions/unimultiverse.html now includes sistpoty's info :-)
[03:32] <thierry_> sispoty : what do you mean by you should provide/conflict libfxscintilla-dev  ?
[03:34] <sistpoty> thierry_: did you take a look at the library packaging guide?
[03:34] <thierry_> yes, but not for that, wait a minute...
[03:34] <sistpoty> thierry_: look for the -dev package section, it's explained pretty good there (probably better than i can now ;)
[03:37] <thierry_> sistpoty : and I put conflict and provides in control file?
[03:38] <sistpoty> thierry_: yes
[03:38] <thierry_> k
[03:39] <thierry_> *sigh, I think there will be a third entry for my package in REVU list...
[03:40] <thierry_> sispoty : will you be able to fix this?
[03:41] <sistpoty> thierry_: sure
[03:46] <thierry_> sistpoty : is it normal now that my package is name libfxscintilla?
[03:46] <sistpoty> thierry_: yes, the sourcepackage should be named libfxscintilla, or fxscintilla (both would be valid)
[03:49] <Yagisan> heh - wine FTBFS as 64bit
[03:59] <raphink> cc time :)
[04:12] <thierry_> sistpoty : sent the new package to REVU, you should now delete libfxscintlla1.6 and libfxscintilla17
[04:13] <sistpoty> thierry_: ok, I've archived those
[04:14] <thierry_> k
[04:44] <Yagisan> \sh: wine FTBFS on amd64 native. I reported the bug upstream here http://bugs.winehq.org/show_bug.cgi?id=4281
[04:44] <Ubugtu> Error: Unknown bugtracker
[04:45] <Yagisan> \sh: I'll do some final cleanup on the package tomorrow, I also was given a suggestion on how to fix the naming issue
[04:46] <Yagisan> \sh: if you have any changes - please email me
[04:53] <hub> anyone knows how to tell apt-get source to fetch a specific version?
[04:53] <azeem> hub: apt-get source foo=3.2.-
[04:53] <azeem> eh, 3.2-1, whatever
[04:53] <hub> nopr
[04:53] <hub> does not work
[04:54] <azeem> does apt-cache showsrc foo | grep Vers say 3.2-1?
[04:54] <dholbach> -t <distro> should work now too
[04:54] <dholbach> -t breezy or whatever you have in apt/sources.list
[04:55] <hub> -t does not work
[04:55] <hub> azeem: well, I apparently messed up with that
[04:55] <hub> works now
[04:57] <hub> azeem: thanks
[04:58] <azeem> cheers
[05:30] <dereks_> \sh: ping
[05:42] <Riddell> smurf handles all the loco stuff right?
[05:43] <tseng> yes
[05:45] <LaserJock> do you guys think it would be nice to have the package name in the Subject of Malone emails?
[05:46] <LaserJock> I get all these emails from ubuntu-bugs and a lot of the time I have to actually look at the email to find out what package the bug is in. Most of the time I like scanning for packages I know.
[05:47] <sistpoty> LaserJock: it would be good imo, but I would need to update the mail-parser from the merge list :(
[05:49] <sistpoty> d'oh.... s.th. smelling burned inside my computer
[05:49] <Riddell> what is smurf's e-mail?
[05:51] <Riddell> ah, foudn it
[05:51] <Riddell> found it
[05:51] <psusi> electronics contain magic smoke that makes them work... once they let out the magic smoke, they don't work no more ;)
[05:51] <sistpoty> hehe
[05:52] <LaserJock> man, on Saturday the laser down the hall started smoking
[05:52] <LaserJock> It blew lik 5 fuses and a hug capacitor and now we have to send the whole thing back for repair
[05:53] <LaserJock> hmmm, my e key wasn't working so well
[05:54] <LaserJock> anyway, I bet it will be ~$10K for repair :(
[05:54] <LaserJock> and my boss is gone to London for vacation
[05:55] <sistpoty> hm... maybe it's may graphic card... fan doesn't seem to be running
[06:00] <Yagisan> sistpoty: turn the pc off, and get a small brush to clean the fans. It's most likely clogged with dust
[06:00] <Yagisan> night all
[06:01] <sistpoty> Yagisan: well, I "repaired" the fan once, maybe that's a result from it... thx for the tip
[06:01] <sistpoty> gn8 Yagisan
[06:12] <segfault> anyone? http://revu.tauware.de/details.py?upid=1397 :-)
[06:24] <sistpoty> raphink: for konq-kim, do you want to wait for the next upstream version?
[06:25] <psusi> a can of compressed air goes a long way
[06:33] <raphink> yes sistpoty
[06:33] <sistpoty> raphink: ok, then I'll archive this one
[06:33] <raphink> sistpoty: I mailed the dev about that somet ime ago
[06:33] <raphink> sistpoty: sure :)
[06:35] <raphink> siretart: shall I close Malone #5214 ?
[06:35] <Ubugtu> Malone bug 5214: "superkaramba: merge new debian version" Fix req. for: superkaramba (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Unconfirmed http://launchpad.net/bugs/5214
[06:36] <raphink> siretart: it's an old one you opened months ago
[06:37] <raphink> so I think it's obsolete
[06:37] <sistpoty> raphink: please wait a moment... I think the email-parser, which sets bugs to fixed broke
[06:37] <sistpoty> (on the merge-list)
[06:37] <raphink> oh ok
[06:37] <raphink> well it's a very old one
[06:37] <raphink> from november
[06:39] <sistpoty> grml... no the email-parser seems fine. lpbugs won't set bugs to fixed any longer :(
[06:40] <sistpoty> raphink: if you've checked the buildlogs and they are fine, you can set them to fixed
[06:40] <sistpoty> set the bug to fixed, even
[06:40] <raphink> sistpoty: this source is obsolete
[06:40] <raphink> I don't really mind whether it was built or not
[06:40] <raphink> it shouldn't exist anymore
[06:40] <raphink> ;)
[06:41] <sistpoty> ah, I recall :)
[06:41] <raphink> ;)
[06:41] <sistpoty> raphink: does it still exist in debian?
[06:41] <raphink> so I should mark it as fixed?
[06:41] <lfittl> dholbach: ping
[06:41] <raphink> sistpoty: well the source yes, but it's not used imo
[06:41] <sistpoty> raphink: if the source is still in debian, don't mark it as fixed... otherwise it would have the chance to get to new back again (once i update the list)
[06:42] <dholbach> lfittl: pong
[06:42] <sistpoty> raphink: probably rejected or won't fix would be good
[06:42] <raphink> sistpoty: I've put a comment on lucas' merge list about this
[06:42] <raphink> ok
[06:42] <raphink> that's what I wanted to know
[06:42] <raphink> if I should reject it
[06:43] <raphink> sistpoty: i'll mark as rejected with an explanation
[06:43] <sistpoty> :)
[06:44] <raphink> sistpoty: https://launchpad.net/distros/ubuntu/+source/superkaramba/+bug/5214
[06:44] <Ubugtu> Malone bug 5214: "superkaramba: merge new debian version" Fix req. for: superkaramba (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Rejected http://launchpad.net/bugs/5214
[06:44] <raphink> there
[06:44] <raphink> :)
[06:44] <raphink> hmm
[06:44] <raphink> doesn't print the explanation
[06:45] <raphink> nm
[06:45] <sistpoty> never mind... siretart will get the mail with the explanation
[06:46] <raphink> ok :)
[07:14] <elektranox> in dapper - nautilus is a small bug with the rights of a file...sometimes they couldn't be changed with nautlius Oo
[07:17] <LaserJock> elektranox: have you tried finding a bug report at bugzilla.ubuntu.com or launchpad.net/malone ?
[07:20] <LaserJock> hi minghua
[07:20] <sistpoty> cya
[07:20] <LaserJock> cya sistpoty
[07:28] <minghua> hi LaserJock
[07:29] <minghua> LaserJock: thanks for your efforts on motu-science
[07:36] <LaserJock> minghua: do you think it is worth while?
[07:36] <LaserJock> minghua: I hope I am getting somewhere
[07:39] <minghua> LaserJock: yes, I think it's very worthwhile
[07:39] <Gloubiboulga> evening
[07:39] <minghua> LaserJock: I think motu-science can be a very good playground for potential science packages to eventually enter debian
[07:40] <LaserJock> minghua: I agree
[07:40] <LaserJock> minghua: I just got my first package (plotdrop) into universe and I just filed an ITP yesterday
[07:41] <minghua> LaserJock: and if we have a team, and a centralized page and repository (aka universe), there is a better chance things will happen
[07:41] <minghua> LaserJock: yes I saw your ITP :-)
[07:41] <LaserJock> minghua: you did?
[07:42] <LaserJock> minghua: sistpoty got me an account on tiber.tauware.de so now I can host some cool pages with package versions etc.
[07:43] <minghua> LaserJock: yes, on debian-devel list
[07:43] <LaserJock> minghua: check out the links on wiki.ubuntu.com/MOTUScience
[07:43] <LaserJock> minghua: under "Ubuntu and Debian Packages"
[07:45] <LaserJock> minghua: and I found out from Keybuk that packages.qa.debian.org links to the Ubuntu patches so everthing is right there for DDs to get the Ubuntu patches
[07:48] <minghua> LaserJock: ok, will look at them, quite busy recently though
[07:49] <LaserJock> minghua: np, I think I will email debian-science an overview of what is available for DDs to get Ubuntu patches
[07:50] <LaserJock> minghua: maybe a little info will help the situation a bit
[08:03] <psusi> how would backporting a package differ from patching it?
[08:03] <psusi> if I want to backport a package from dapper to breezy, could it be as simple as getting the dapper sources and pbuildering it?  ( assuming that actually works ) or is there some special way to version it?
[08:09] <Mithrandir> psusi: your fix for e2fsprogs would break ia64, so upstream considers it not a good idea.
[08:10] <psusi> Mithrandir: how would it break ia64?
[08:10] <psusi> I just made it compatible with the kernel header, which works on ia64, so it should too?
[08:10] <Mithrandir> psusi: __s64 is signed long on ia64, not signed long long.
[08:10] <psusi> ohh...
[08:11] <psusi> in the kernel headers that's how it is defined?
[08:11] <psusi> strange that it woul be long long on amd64 and just long on ia64
[08:11] <psusi> btw... does malone not distinguish between releases?  it doesn't seem to have anywhere ot specify weather it is a bug in dapper or breezy
[08:12] <psusi> Mithrandir: isn't there a #define that tells you which platform you are being built on?
[08:12] <Mithrandir> psusi: eww.
[08:13] <psusi> maybe the e2fsprogs header should be changed to use that instead of picking based on sizeof()?
[08:13] <Mithrandir> psusi: there is, but I don't think that's a very nice way to go about
[08:13] <psusi> well, if it really is defined differently on amd64 and ia64, I see no other way to get the correct definition
[08:13] <Mithrandir> change it to use uint64_t and int64_t
[08:14] <psusi> that isn't correct either because that's not how the kernel headers do it
[08:14] <Mithrandir> *shrug*, so?  As long as it's correct and __s64 is the same as int64_t, always, I don't see the problem.
[08:15] <psusi> the problem it caused for me was that defrag was including both e2fsprogs and kernel headers... and they differed in how they defined the those types, which causes a compiler error
[08:16] <psusi> so however it gets defined, it needs to be the same in both places
[08:18] <Mithrandir> not if e2fsprogs doesn't define it and doesn't use it.
[08:19] <psusi> huh?  it does define it
[08:20] <psusi> it just defines it in a different way than the kernel headers
[08:20] <Mithrandir> in the hypotetical case that e2fsprogs were fixed to not define it and not use it.
[08:20] <psusi> ahh... well, that would work too I suppose
[08:23] <psusi> but that's not going to happen any time soon
[08:23] <Mithrandir> why not?
[08:24] <psusi> that would take a fair amount of work from upstream
[08:24] <psusi> much simpler to just get the existing definition to jive with the kernel definitions
[08:24] <Mithrandir> it's two lines of sed, not that hard.
[08:25] <psusi> well... heck.. ok.... propose both to upstream and as long as they do one of them soonish, I'm happy ;)
[08:25] <Mithrandir> I've mailed tytso this morning, so..
[08:26] <psusi> now... question... the p7zip in breezy segfaults left and right for me... I just got the dapper version and it built fine on breezy and appears to be working much better... how would I go about getting that into backports?
[08:39] <LaserJock> azeem: ping?
[08:40] <azeem> pong
[08:42] <azeem> LaserJock: ^^
[08:42] <LaserJock> azeem: did you see malone bug 5643
[08:42] <Ubugtu> Malone bug 5643: "[patch]  Ghemical .desktop file is not so good (absolute path, missing stuff, invalid stuff)" Fix req. for: ghemical (Ubuntu), Severity: Minor, Assigned to: MOTU Reviewers Team, Status: Unconfirmed http://launchpad.net/bugs/5643
[08:42] <azeem> hrm, yeah I think I saw that
[08:43] <bmonty> hey LaserJock
[08:43] <azeem> I'm at the uni still though, so I can't commit anything to my local package
[08:44] <LaserJock> hi bmonty
[08:45] <LaserJock> azeem: but do you want to have us sync it from Debian?
[08:46] <azeem> well, I guess I'll fix it with the next upload (if I do not forget), but I wanted to have amd64 back first
[08:47] <azeem> if you need it fixed now, that's fine as well, and I'll sync back to Debian
[08:47] <bmonty> LaserJock: do you have a patch?
[08:48] <LaserJock> azeem: well it isn't a big issue I was just trying to clean up the ghemical malone bugs
[08:49] <LaserJock> azeem: there are a couple about AMD64, are you working on that or is that going to take a new release?
[08:49] <azeem> upstream said they would, but it might take a while
[08:49] <bmonty> I can upload the desktop patch now if there aren't any other issues
[08:49] <azeem> I should try to fix them, but I didn't get around doing so yet
[08:51] <LaserJock> bmonty: the patch is on malone bug #5643
[08:51] <Ubugtu> Error: Could not parse data returned by Malone: Connection to Malone bugtracker failed: The read operation timed out
[08:51] <bmonty> got it
[08:52] <LaserJock> also, I am not sure what to do with malone bug 5632
[08:53] <Ubugtu> Malone bug 5632: "Ghemical won't start up (breezy amd64)" Fix req. for: ghemical (Ubuntu), Severity: Normal, Assigned to: MOTU Science, Status: Unconfirmed http://launchpad.net/bugs/5632
[08:54] <LaserJock> I mean, the apparently the ATI driver was the problem
[08:58] <bmonty> LaserJock: I think malone 5632 will require upstream to fix
[08:58] <Ubugtu> Malone bug 5632: "Ghemical won't start up (breezy amd64)" Fix req. for: ghemical (Ubuntu), Severity: Normal, Assigned to: MOTU Science, Status: Unconfirmed http://launchpad.net/bugs/5632
[09:00] <bmonty> LaserJock: we should also open a bug in Debian's BTS to have them push this patch into the debian version of the package
[09:01] <LaserJock> bmonty: the .desktop patch?
[09:01] <bmonty> LaserJock: yes
[09:03] <LaserJock> bmonty: ok, I can do that. That way azeem will remember better ;-)
[09:03] <bmonty> k, I uploaded the patch to ubuntu
[09:04] <bmonty> this is fun....bugfixing in an airport :)
[09:04] <LaserJock> lol
[09:05] <zakame> bmonty: w00t
[09:08] <zakame> ooh free (speech) flash, finally
[09:10] <jamessan> zakame: wasn't that what libflash-* was? this is just promoted by the FSF and funded so it's actually made it further than previous projects
[09:11] <zakame> jamessan: hmm, indeed :)
[09:15] <Treenaks> it doesn't Work?
[09:20] <bmonty> gnash doesn't look ready for primetime yet though...no firefox plugin working yet
[09:21] <LaserJock> anybody know of a simple way of testing if exim4 is working?
[09:22] <bmonty> telnet to it
[09:22] <LaserJock> you can telnet to it?
[09:22] <bmonty> yup...telnet host 25
[09:22] <LaserJock> isn't that kindof a security problem
[09:24] <zakame> not really
[09:24] <bmonty> LaserJock: no, it is essentially the same as what your SMTP client does minus the telnet control stuff
[09:24] <LaserJock> I just wanted to test if I can send out mail to my smtp server. I don't want to be able to receive mail.
[09:24] <zakame> wb siretart :)
[09:25] <bmonty> LaserJock: you asked for any easy why to test it :)
[09:25] <bmonty> you could also look at the logs on the server and see if it shows the connections
[09:25] <LaserJock> ok, well I think I am blocking telnet because I get a connections refused
[09:25] <LaserJock> if I installed mutt would I be able to send a test email out?
[09:26] <bmonty> did you put the 25 on the end of the telnet command?
[09:26] <LaserJock> yeah
[09:26] <bmonty> then you are blocking the default port for SMTP or your server isn't running
[09:27] <LaserJock> well, is it ok to block the SMTP port? Will I still be able to send mail out?
[09:28] <bmonty> not if you block smtp in both directions
[09:28] <LaserJock> ok, so when I do /etc/init.d/exim4 status I get "19952 daemon: -q30m, listening for SMTP on [127.0.0.1] :25"
[09:30] <bmonty> ok, so it is only listening on the loopback, so it will only accept connections from the local machine
[09:30] <LaserJock> ok, well that sounds good
[09:30] <bmonty> probably what you want :)
[09:34] <LaserJock> OK, I installed mutt and sent a quick email out and it worked.
[09:35] <LaserJock> bmonty: I sent a bug report to Debian about the .desktop and referenced the malone bug. Does that sound right?
[09:36] <bmonty> yeah, you should also reference the BTS bug in the malone bug report
[09:36] <zakame> yep
[09:36] <LaserJock> bmonty: k
[09:38] <bmonty> LaserJock: you might want to add a link to malone in case the debian dev doesn't know what malone is
[09:39] <LaserJock> bmonty: the Debian maintainer is azeem ;-)
[09:39] <bmonty> ahhh, nevermind :)
[09:43] <Mez> psusi - email the backprts mailing list about it - ubuntu-backports@lists.ubuntu.com
[09:43] <LaserJock> now that I got the mail thing figured out I gotta go see if I can get my package into Debian and work on the Ubuntu Packaging Guide :-)
[09:44] <zakame> wb Kyral
[09:44] <LaserJock> Kyral: Hi!
[09:44] <LaserJock> Kyral: haven't seen you for a while
[09:44] <bmonty> hey Kyral
[09:45] <zakame> gaah
[09:50] <bmonty> they just called my flight....so gotta go, cya all later!
[09:52] <dholbach> bye bmonty - good flight :)
[10:10] <zakame> heya luk , Hobbsee :)
[10:10] <Hobbsee> hey zakame :)
[10:17] <LaserJock> hi Hobbsee
[10:17] <Hobbsee> hi LaserJock :)
[10:24] <Czessi> Hi, can anyone review my package, pls? http://revu.tauware.de/details.py?upid=1464
[10:25] <thierry_> anyone who would like to review my package? http://revu.tauware.de/details.py?upid=1459
[10:34] <Kyral> Is anyone working on this right now http://everygui.sourceforge.net/?
[10:36] <LaserJock> Kyral: is EasyChem in the universe repo yet?
[10:36] <Kyral> LaserJock: yah
[10:36] <Kyral> has been
[10:36] <LaserJock> Kyral: do you want to get it into Debian?
[10:37] <Kyral> LaserJock: yah
[10:38] <LaserJock> Kyral: azeem (Michael Banck) offered to sponsor chemistry related packages you should file and ITP and let him know when you have it ready to go
[10:38] <Kyral> okay
[10:38] <Kyral> Lemme settle back to school ;P
[10:38] <LaserJock> Kyral: fine, I just wanted to let you know
[10:39] <Kyral> hooo
[10:39] <Kyral> its a Python thing
[10:39] <Kyral> I think I can use cdbs python-distutils
[10:42] <Kyral> I'm gonna send an email to the author asking if he would be alright with me packing it
[10:43] <zakame> w00t
[10:47] <thierry_> I want to package something but dependencies doesn't get reviewed :(
[10:48] <Kyral> heh
[10:48] <Kyral> meh...how do I force a version
[10:48] <zakame> set it in debian/changelog
[10:48] <Kyral> like the origiinal tarball is 0.99.b and dh_make is throwing a fit
[10:49] <zakame> how come, what's the previous ver?
[10:49] <Kyral> i guess .a?
[10:51] <zakame> hm, doesn't uupdate -v 0.99.b work (if its a new upstream version)
[10:51] <Kyral> It isn't packaged
[10:51] <Kyral> at all
[10:52] <zakame> ah :(
[10:53] <Kyral> can I just rename the tarball?
[10:53] <zakame> what's the original name?
[10:53] <Kyral> everygui-0.99.b.tar.gz
[10:54] <zakame> ooh, so that's why
[10:54] <Kyral> Yah I know its why lol
[10:56] <Kyral> How do I make DH_Make behave
[10:56] <zakame> can you pastebin the err?
[10:58] <Kyral> http://paste.ubuntu-nl.org/6919
[11:00] <zakame> hm can you unpack the source first, cd to it, then dh_make -c gpl -e kyral@ubuntu.com? skipping -f ...
[11:01] <Kyral> ah
[11:01] <Kyral> Same error
[11:01] <Kyral> and I have to go to dinner
[11:01] <Kyral> leave it in a PMSG mkay?
[11:02] <zakame> sure :( I'll try myself
[11:02] <zakame> where can I find easygui btw?
[11:10] <mr-russ> is the wiki available to anybody here, it's not working for me atm.
[11:11] <zakame> 'tis down, and so is LP
[11:11] <mr-russ> lp?
[11:12] <Nafallo> database is down
[11:12] <Nafallo> launchpad
[11:12] <LaserJock> bummer
[11:13] <mr-russ> it is a bit, just started the work day here.
[11:14] <LaserJock> does BTS usually take forever to register a bug?
[11:15] <Nafallo> yes
[11:15] <Nafallo> :-)
[11:20] <psusi> what is the 'debian way' to build a package with debug syms not stripped?
[11:21] <dholbach> cd build-tree; DEBUILD_OPTIONS="nostrip" debuild
[11:23] <psusi> ahhh... I wish there was some equivalent to --help for finding environment variables you can tweek
[11:25] <Nafallo> hmm
[11:26] <Seveas> psusi, it's called poke_dholbach
[11:26] <Seveas> :)
[11:26] <zakame> hehe
[11:27] <psusi> heh
[11:27] <Hobbsee> hehe
[11:27] <psusi> OPTIONS=tellmeallyoursecrets command
[11:27] <Nafallo> hmm
[11:27] <zakame> wb ogra_
[11:27] <psusi> hehe
[11:28] <Nafallo> I might try that poke_dholbach
[11:28] <Nafallo> what was it for comparing what ARCH I'm on? :-)
[11:28] <Nafallo> DEB_BUILD_ARCH?
[11:28] <dholbach> poke_dholbach: connection to  dholbach  lost.
[11:28] <Nafallo> and x86_64 is the proper for adm64?
[11:28] <Nafallo> :-)
[11:28] <Nafallo> NOOOO! :-
[11:29] <Nafallo> :-P
[11:29] <dholbach> Nafallo: https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS knows
[11:29] <Nafallo> CDBS, hmpf! ;-)
[11:30] <dholbach> it has the variables as well
[11:30] <ajmitch> morning
[11:31] <LaserJock> hi ajmitch
[11:31] <Hobbsee> morning ajmitch
[11:31] <zakame> morning ajmitch
[11:32] <ajmitch> looks like I  missed another meeting, CC this time?
[11:32] <zakame> yep
[11:32] <zakame> I missed it too, I thought it was 2000
[11:32] <ajmitch> no big loss then
[11:33] <zakame> haha
[11:33] <Nafallo> it does?
[11:33] <Nafallo> dholbach: thanks, but I can't see what if x86_64 is valid for DEB_BUILD_ARCH :-)
[11:34] <ajmitch> dpkg-architecture
[11:36] <ajmitch> we really need a decent place to make requests for universe software
[11:37] <Nafallo> agreed
[11:37] <Nafallo> call sistpoty :-)
[11:38] <Nafallo> oh
[11:38] <Nafallo> changed name to amd64 :-P
[11:40] <ajmitch> launchpad dead again?
[11:40] <Nafallo> emperor died
[11:40] <Nafallo> znarl contacted I think :-)
[11:41] <ajmitch> ah right
[11:41] <ajmitch> SPOF
[11:43] <zakame> bye all, breakfast :D
[11:50] <lifeless> znarl has been contacted
[11:50] <lifeless> eta 30 minutes - some
[11:50] <Nafallo> :-)
[11:50] <ajmitch> yes, I'd be surprised if noone had noticed & starting working on it
[11:51] <dholbach> I'm off guys - have a nice evening.
[11:51] <ajmitch> bye daniel
[11:52] <LaserJock> cya dholbach
[11:52] <psusi> does pbuilder not respect DEBUILD_OPTIONS?
[11:52] <ajmitch> sigh, yet more f-spot bugs rolling in :)
[11:53] <tseng> eh
[11:53] <tseng> ill trade you for beagle bugs
[11:53] <ajmitch> debian
[11:53] <tseng> eh
[11:53] <tseng> ill trade you for fighting with jose
[11:53] <ajmitch> heh
[11:55] <psusi> hrm... this program I'm debugging keeps getting signal 32... how do you tell gdb to ignore it and let the program handle it?
[11:57] <psusi> there we go... figured it out
[12:00] <dholbach> Please remember: BUG DAY tomorrow! :)
[12:00] <dholbach> errr NOW :)
[12:00] <ajmitch> heh
[12:00] <ajmitch> yes, you're meant to be sleeping
[12:01] <dholbach> SIR, ajmitch, YESSIR!
[12:01] <ajmitch> bed! now!