[00:00] <s1024k1> soren: i grab-merge the package "yappy". my teacher norsetto told me to modify the changelog and add my name and e-mail address. but i don't know how to do.
[00:00] <soren> s1024k1: It's a textfile. Open it in an editor and go nuts. :)
[00:00] <soren> Either that or use "dch -e"
[00:01] <s1024k1> soren: what does "dch -e" do?
[00:01] <soren> Open the changelog in an editor and changes the e-mail adress to yours.
[00:02] <s1024k1> soren: okay. thanks. so after i modify the file, must i re-compile the package?
[00:02] <soren> You could just try it or look at the man page if you think I'm trying to trick you into something evil :)
[00:03] <soren> s1024k1: Depends on what you want to do.
[00:03] <s1024k1> soren: i want to upload it of course, after the job has been done...
[00:03] <soren> s1024k1: Then you just need to create the source package.
[00:04] <soren> I suppose you could say "compile the source package".
[00:04]  * ajmitch usually forgets about the various things that dch does
[00:05] <ajmitch> mostly because emacs spoils me :)
[00:05] <soren> "spoils" is not quite the word I'd use.
[00:05] <soren> :)
[00:05] <s1024k1> soren: i used "grab-merge" to grab and merge the package already. and then i modify the changelog and the control file, add my messages in the files. and what next?
[00:05] <ajmitch> treats me to a gourmet meal with fine wine? :)
[00:06] <soren> ajmitch: Rather something that starts with a b and rhymes with cutpuck.
[00:07] <ajmitch> s1024k1: build the source package with something like 'debuild -S'
[00:07]  * ajmitch tries to think of a word that fits
[00:08] <slangasek> "backpacker potluck"
[00:08] <s1024k1> ajmitch: thank you. after i building the package again i can get something final for upload already?
[00:08] <ajmitch> that builds a source package - you can use that to build binaries using pbuilder, if you have that setup
[00:09] <s1024k1> ajmitch: thank you.
[00:09]  * ajmitch wonders why soren is even still awake & on irc :)
[00:09]  * soren wonders the same thing
[00:10] <ajmitch> too busy with server stuff, I'm sure
[00:10] <slangasek> because he's DEDICATED
[00:10] <ajmitch> that's one word for it
[00:16] <Pici> hm
[00:24] <s1024kb> just now i want to get a new account in irc.freenode.net, but i found that my nick name in irc.ubuntu.com was changed... strange. does anyone know why?
[00:24] <StevenK> irc.ubuntu.com == irc.freenode.net
[00:26] <freakabcd> hi all
[00:26] <freakabcd> Fujitsu, is octave2.9.17 in the repos?
[00:26] <s1024kb> StevenK: okay, thanks. but i want to use the same nickname to login because people know me as that nick name... but when i use pidgin just now, i saw my nick name was changed...
[00:27] <s1024kb> StevenK: now i am in window, using Xchat. I am afriaid that when i comeback to Pidgin the same thing happen...
[00:27] <StevenK> If you try and sign in using both xchat and pidgin the same thing will happen
[00:28] <freakabcd> how do i find the latest version of a package?
[00:28] <freakabcd> i think its some ! trigger and ubotu or someone responds
[00:28] <StevenK> !info libc6 hardy
[00:28] <ubotu> libc6: GNU C Library: Shared libraries. In component main, is required. Version 2.6.1-6ubuntu2 (hardy), package size 4093 kB, installed size 10136 kB
[00:28] <freakabcd> !info octave2.9 hardy
[00:28] <s1024kb> StevenK: no, i am using one tool each time.
[00:28] <ubotu> octave2.9: GNU Octave language for numerical computations (2.9 branch). In component universe, is optional. Version 1:2.9.12-2ubuntu1 (hardy), package size 7869 kB, installed size 26840 kB
[00:29] <freakabcd> umm.. seems like its not in yet
[00:29] <freakabcd> thanks StevenK
[00:29] <StevenK> s1024kb: Shrug. Ask in #freenode?
[00:29] <Fujitsu> freakabcd: Nice timing. The sources are, but something strange happened with wx 2.6, so it was uninstallable.
[00:29] <freakabcd> wx 2.6 ?
[00:29] <freakabcd> whats the deps with wx ?
[00:31] <Fujitsu> It needs the development packages to build, and they are currently uninstallable.
[00:31] <freakabcd> Fujitsu, ok. i know what you mean. but you said '...wx 2.6...'
[00:31] <freakabcd> what is this dependency? i don;t think octave needs this
[00:33] <freakabcd> Fujitsu, is it possible to have the src package backported to gutsy _before_ getting it ready for hardy? i'm pretty sure we can get it going on gutsy
[00:33] <Fujitsu> It is against policy to backport it before it's known to work in the development release, for good reason.
[00:33] <Fujitsu> For what reason do you need it so absolutely urgently?
[00:35] <freakabcd> well, i've already got octave and octave-forge compiled and installed on my machine (manually, no debs). just thought it would be nice to have packages. Also, octave-forge packaging is being discussed actively right now, so i thought i might be able to contribute.
[00:35] <freakabcd> but i don;t run hardy and can work only in gutsy.
[00:40] <freakabcd> Fujitsu, were there non-trivial changes to be made changing the src package from 2.9.12 to current(2.9.17?)
[00:40] <freakabcd> if not, i want to have a go at building a package for octave2.9.17 (obviously this is not to be made for universe, just personal use)
[00:41] <bddebian> Heya gang
[00:41] <Fujitsu> freakabcd: You could always grab the source package from Debian and build it for your own system. That should work, and is fairly trivial.
[00:41] <Fujitsu> Hi bddebian.
[00:42] <bddebian> Heya Fujitsu
[00:43] <superm1_> imbrandon, you here still?
[00:54] <freakabcd> Fujitsu, i've got another question: why is g77 still noted in deps for some packages? i thought gfortran was a drop in replacement
[01:01] <Fujitsu> freakabcd: I'm pretty sure it's not a drop-in replacement, as there were/are migration issues.
[01:07] <freakabcd> Fujitsu, fair enough. would there be some webpage mentioning/discussing the issues encountered?
[01:09] <Fujitsu> Possibly, but I really have very little idea.
[01:14] <freakabcd> Fujitsu, is there a way to find out which packages depend on g77 ?
[01:15] <freakabcd> i'd like to see this list and find out the reasons (if any) they fail to work with gfortran
[01:15] <Stemp> Is there an howto about "ubuntise" a debian package ?
[01:16] <Fujitsu> Stemp: Nothing should be necessary, other than rebuilding it in an Ubuntu environment.
[01:16] <bddebian> Shouldn't need to if it's in Debian
[01:17] <alvinc> aren't there changelog naming conventions to adhere to?
[01:17] <alvinc> with regard to Stemp's question
[01:17] <bddebian> Only if it needs to differ from Debian
[01:17] <alvinc> well, the repos are named differently, yes?
[01:18] <alvinc> main/restricted/universe/multiverse versus main/contrib/unstable, etc
[01:18] <Stemp> and gutsy/hardy
[01:18] <alvinc> i had built some source the other day, tried to upload it to PPA and it complained to me for the changelog naming
[01:18] <changelog> changelog? where? :P
[01:19] <alvinc> lol
[01:19] <Stemp> :D
[01:19] <changelog> changelogs don't complain, they bitch and wine :-|
[01:19] <alvinc> Rejected:
[01:19] <alvinc> Unable to find distroseries: unstable
[01:19] <alvinc> Further error processing not possible because of a critical previous error.
[01:19] <alvinc> is what PPA sent to me
[01:19] <alvinc> red wine?
[01:19] <alvinc> with cheese?
[01:19] <alvinc> j/k
[01:19] <Fujitsu> alvinc: You could have just uploaded to /hardy or /gutsy or similar.
[01:20] <Fujitsu> Most of our packages have unstable in the changelog, because they're taken bit-identically from Debian.
[01:20] <alvinc> ah.  as my PPA ignorance shines through
[01:20] <alvinc> Fujitsu:  If you wouldn't mind pointing me at the correct procedure for that, I'd be much obliged
[01:20] <alvinc> I tried doctoring it in changelog
[01:21] <alvinc> it got a little further
[01:21] <Fujitsu> alvinc: There's a bug open about the lack of documentation.
[01:21] <Fujitsu> I think that if you upload to ~username/ubuntu/somerelease it should override.
[01:21] <alvinc> here was the second round of PPA giving me the finger:
[01:21] <alvinc> Rejected:
[01:21] <alvinc> Upload is binaryful, but policy refuses binaryful uploads.
[01:21] <alvinc> Upload is source/binary but policy refuses mixed uploads.
[01:21] <alvinc> PPA uploads must be for the RELEASE pocket.
[01:21] <alvinc> lol
[01:21] <Stemp> so it should be easy, just dch -i and dbuild -S -sa right ?
[01:22] <alvinc> I really need a motu mentor, by the way.  :(  Been trying to get one for a month now.
[01:22] <alvinc> I wonder if I can get one on EBay
[01:22] <Fujitsu> alvinc: You didn't build with -S.
[01:22] <alvinc> just kidding
[01:22] <alvinc> Exactly.  :)
[01:22] <Fujitsu> You tried to upload _i386.changes, when you needed _source.changes.
[01:22] <alvinc> But it got past the distro error
[01:22] <alvinc> My final attempt worked
[01:22] <alvinc> but, as i said, i had doctored the changelog to make it work
[01:22] <alvinc> (with all due respect to changelog)
[01:23] <alvinc> here is what i put:
[01:23] <alvinc> iscsitarget (0.4.15-ubuntu1) gutsy-backports; urgency=low
[01:23] <alvinc>   * Added initd.ubuntu, due to Ubuntu using /bin/ash as the default target
[01:23] <alvinc>     of /bin/sh, changed debian/iscsitarget.init (Fixes: #160106)
[01:23] <alvinc>   * Fix build failure on feisty and gutsy (Fixes: #160104)
[01:23] <alvinc>  -- Alvin Cura <alvin.cura@gmail.com>  Wed, 14 Nov 2007 21:32:37 -0800
[01:23] <alvinc> i bet i'm not supposed to do that.  :)
[01:23] <Fujitsu> You can't upload to backports.
[01:24] <Fujitsu> THat's the RELEASE pocket error. -backports is the BACKPORTS pocket.
[01:24] <alvinc> ah ha...
[01:24] <alvinc> *sigh* so much to learn
[01:24] <Stemp> ubuntu1 not 0ubuntu1 ?
[01:24] <RAOF> (And that would be the wrong version number if you were uploading to backports)
[01:24] <Fujitsu> This isn't actually documented anywhere, of course.
[01:24] <Fujitsu> Stemp: Why are you changing the versioning?
[01:24] <alvinc> Now I am *really* going to cry
[01:24] <alvinc> I googled a lot trying to find docs on it
[01:24] <alvinc> Then I started hack-n-slashing
[01:25] <Fujitsu> And there is a bug open about allowing uploads to the various other pockets.
[01:25] <Stemp> Fujitsu: because on my package (midori) Debian packager changed the home page to debian.org
[01:25] <Fujitsu> Ah.
[01:25] <Fujitsu> What is the Debian version?
[01:26] <Stemp> actuelly 0.0.10
[01:26] <Stemp> actually
[01:26] <Stemp> but the source is since yesterday 0.0.11
[01:26] <alvinc> i really need to get this stuff all figured out
[01:26] <Fujitsu> That's the whole Debian version? No -1 or anything?
[01:26] <alvinc> i've got various fixes for several bugs ready to go, but i'm a moron on uploading.  :(
[01:27] <alvinc> lots of stuff that broke in linking /bin/sh to dash, you see.
[01:27] <alvinc> easy fixes
[01:27] <Fujitsu> alvinc: Why are you uploading them to a PPA?
[01:27] <Fujitsu> Wouldn't it be better to have them in the Ubuntu archive?
[01:27] <alvinc> Don't they need to be evaluated first?
[01:27] <slangasek> Fujitsu: nah, the Debian version for midori is 0.0.10-1
[01:27] <Stemp> Fujitsu : 0.0.10-1
[01:27] <alvinc> I was going to have a friend apt-get my work, test it on his boxes
[01:27] <Fujitsu> slangasek: Thanks.
[01:27] <alvinc> and then annotate the bug
[01:28] <Fujitsu> Stemp: Right, so the version with Ubuntu changes would be 0.0.10-1ubuntu1.
[01:28] <alvinc> I don't know how to upload to the actual archive anyway.  ROFL
[01:28] <alvinc> I can't even upload to PPA
[01:28] <alvinc> lol
[01:28] <Fujitsu> alvinc: You can't upload to the actual archive; you need to attach a debdiff to a bug and get it sponsored.
[01:28] <Stemp> Thanks Fujitsu, it's so obvious, i feel dumb :D
[01:28] <alvinc> Thought so.
[01:29] <alvinc> So that was why I was trying to put it in my PPA and make notes in the bug
[01:29] <alvinc> So that someone could read it
[01:29] <Fujitsu> You will need to attach a debdiff and subscribe ubuntu-universe-sponsors. We don't review from PPAs.
[01:29] <alvinc> I really was about to make a repo at home and make notes in the bug
[01:29] <alvinc> ah ha.....
[01:30] <alvinc> googling ubuntu-universe-sponsors now
[01:30] <alvinc> thanks Fujitsu.  :)
[01:30] <Fujitsu> Damn, one less word I can tab-complete :(
[01:30] <Fujitsu> alvinc: Why googling?
[01:30] <Fujitsu> !sponsor
[01:30] <ubotu> Sorry, I don't know anything about sponsor - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[01:30] <Fujitsu> !sponsorship
[01:30] <ubotu> Sorry, I don't know anything about sponsorship - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[01:30] <Fujitsu> Must be here somewher.e
[01:30] <Fujitsu> !uus
[01:30] <ubotu> Sorry, I don't know anything about uus - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[01:30] <alvinc> lol
[01:31] <Fujitsu> See https://wiki.ubuntu.com/MOTU/Contributing.
[01:31] <Fujitsu> That has useful information on what you're trying to do.
[01:31] <alvinc> so...  communication here is done in a mailing list?  not in launchpad?
[01:32] <Fujitsu> What gives you that idea?
[01:32] <alvinc> You said to subscribe to the list?
[01:32] <alvinc> I'm sorry, did I misunderstand?
[01:33] <Fujitsu> Attach a debdiff to the bug, and subscribe the ubuntu-universe-sponsors team to the bug.
[01:33] <alvinc> Oh.....
[01:33] <alvinc> Thanks Fujitsu
[01:38] <Stemp> I have another dumb question, I get the debian package source from midori. I don't want the change (google.com to debian.org).  So I remove the patche directory, run dhc -v 1ubuntu1, add to changelog New upstream ? is that all ?
[01:40] <Fujitsu> It's not a new upstream...
[01:40] <Fujitsu> You would say `Dropped patch to change homepage to debian.org' or similar.
[01:40] <Stemp> ok
[01:41] <Stemp> and if there is nothing to change ?
[01:42] <Fujitsu> Then you don't make any changes, and it should be synced automatically.
[01:42] <alvinc> Fujitsu, for updating a bug in Launchpad....
[01:42] <Stemp> thanks Fujitsu
[01:43] <alvinc> If I attach a debdiff, do I check "This attachment is a patch"?
[01:43] <Fujitsu> alvinc: You should yes.
[01:43] <Fujitsu> +,
[01:43] <alvinc> Thank you
[01:48] <alvinc> Thanks again Fujitsu.  I attached debdiffs and subscribed ubuntu-universe-sponsors to the bug
[01:48] <Fujitsu> alvinc: Thanks.
[01:52] <alvinc> Fujitsu, what is the criteria for differentiating universe from multiverse, I'm curious?
[01:53] <imbrandon> universe is free software, multiverse is not
[01:54] <imbrandon> btw heya
[01:54] <alvinc> oh...
[01:54] <alvinc> okay, so better question:  the difference between restricted and multiverse?  ;)
[01:54] <alvinc> or partner and multiverse?
[01:55] <imbrandon> partner is software that is not redistributable except by the vendor , multiverse can be distributed but is not OSS
[01:56] <imbrandon> restricted is binary blobs required to run the system, like frirmware
[01:56] <Fujitsu> restricted is like multiverse, but supported.
[01:56] <Fujitsu> Like main to universe.
[01:57] <alvinc> thanks.  :)
[01:57] <LaserJock> restricted doesn't have software does it?
[01:57] <LaserJock> only drivers and firmware
[01:58] <imbrandon> afaik yes
[01:58] <LaserJock> doh, should have looked at imbrandon's response first
[01:58] <Tm_T> :-p
[01:59] <Fujitsu> LaserJock: It has MySQL documentation too.
[01:59] <Stemp> I don't know if it's the right channel to post my question but how do you get some extras packages into your pbuilder system ?
[01:59] <Fujitsu> And probably some other things.
[02:00] <imbrandon> Stemp: one way is to "sudo pbuilder login --save-after-login" and install them, but that will taint your pbuilder for further use and you should make a backup of the tgz first
[02:00] <imbrandon> and restore it once finished
[02:01] <Stemp> I want to include libwebkitgtk and I hope it will be in Hardy ;)
[02:01] <Fujitsu> We have webkit in Gutsy...
[02:01] <Fujitsu> !info libwebkitgdk0d
[02:02] <Fujitsu> !info libwebkitgdk0d gutsy
[02:02] <Fujitsu> !ping
[02:02] <Stemp> that's the problem
[02:02] <ubotu> pong
[02:02] <Stemp> gdk not gtk
[02:03] <imbrandon> Web content engine library for Gtk+
[02:03] <imbrandon> looks gtk to me
[02:03] <Fujitsu> It is the GTK+ variant.
[02:03] <Fujitsu> What do you want it for?
[02:03] <imbrandon> http://packages.ubuntu.com/gutsy/libs/libwebkitgdk0d
[02:04] <Stemp> for epiphany-webkit and midori
[02:04] <Fujitsu> epiphany-webkit builds with the aforementioned package.
[02:04] <Stemp> http://packages.debian.org/sid/libwebkitgtk0d
[02:04] <Fujitsu> (I know because I've done it multiple times)
[02:05] <Fujitsu> We have that in Hardy.
[02:05] <ajmitch> hey Hobbsee
[02:05] <imbrandon> Stemp: its in hardy
[02:06] <imbrandon> http://packages.ubuntu.com/hardy/libs/libwebkitgtk0d
[02:06] <Stemp> yes it's probably in Hardy but in my pbuilder (hardy) it is not :(
[02:06]  * ajmitch chased hobbsee away
[02:06] <imbrandon> you probably need to run "sudo pbuilder update" then
[02:07] <Stemp> I did it
[02:07] <Fujitsu> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445060
[02:07] <ubotu> Debian bug 445060 in libwebkitgdk0d "webkit: should be renamed to libwebkitgtk0d" [Minor,Fixed]
[02:07] <alvinc> *snicker*
[02:08] <Fujitsu> alvinc: ?
[02:08] <alvinc> sorry, spelling error, i found it funny
[02:08] <alvinc> gdk versus gtk
[02:08] <imbrandon> Stemp: if you ran pbuilder update and its still not avail then you have other issues
[02:08] <Fujitsu> It's not a spelling error.
[02:08] <Stemp> ok imbrandon
[02:08] <Fujitsu> Upstream renamed it.
[02:09] <imbrandon> either your not running hardy pbuilder or dont have universe enabled
[02:09] <imbrandon> the latter is more likely
[02:09] <Stemp> universe for webkit ?
[02:09] <imbrandon> libwebkitgtk0d is in universe
[02:09]  * ajmitch tries not to chase Hobbsee away this time
[02:10] <RAOF> It's certianly not officially supported by Cannonical :)
[02:10] <Stemp> why ? not free software ?
[02:10] <Fujitsu> universe is unsupported free software.
[02:11] <Fujitsu> Canonical can't support *everything*...
[02:11] <ajmitch> unsupported or community-supported
[02:11] <RAOF> *Especially* libraries that haven't even been released.
[02:11] <alvinc> speaking of Canonical...  what's the name of the team that takes care of main?
[02:11] <Stemp> but webkit ~= khtml ? no ?
[02:11] <alvinc> is there stuff to read?
[02:11] <imbrandon> alvinc: ubuntu-core-dev
[02:11] <Fujitsu> Stemp: It forked quite some time ago...
[02:12] <alvinc> frankly i'm still interested in the varrun varlock drama that causes all kinds of headaches when I FAI a new box.  :)
[02:12] <imbrandon> Stemp: no, its a fork of khtml but != khtml
[02:12] <Hobbsee> ajmitch: sorry.  konvi borked.
[02:12] <imbrandon> apple forked the code quite some time ago
[02:12] <ScottK2> Heya Hobbsee.
[02:12] <Hobbsee> greetings ScottK2
[02:12] <imbrandon> ello Hobbsee
[02:12] <ajmitch> Hobbsee: ok, so you're not running away?
[02:12] <Hobbsee> ajmitch: afraid not.
[02:12] <ScottK2> Hobbsee: How goes the battle against the evil corporate consipiracy?
[02:13] <Hobbsee> ScottK2: erm...i cant talk about it :)
[02:13] <ScottK2> Ah.  Right, wouldn't want to dampen the mood.
[02:13]  * ScottK2 holds big smile and thinks happy thoughts
[02:15] <Hobbsee> hehe
[02:15] <ScottK2> So I came back to my hotel for lunch today and found the building next door to be on fire.  Hopefully the evening will be quieter.
[02:15] <Hobbsee> as in, i did not get a gag order - i'm just choosing not to talk about various bits, related to canonical.
[02:15] <TheMuso> Fun.
[02:16] <Hobbsee> yay, fire!
[02:16]  * ajmitch takes the matches& petrol away from Hobbsee 
[02:16]  * Hobbsee still has teh sparklers and looks for an aerosol can.
[02:16] <ScottK2> It had really great big billowing clouds of black smoke, but actually got put out pretty quickly.
[02:16] <joejaxx> Good Evening Everyone
[02:17] <joejaxx> ScottK2: from the build daemons?
[02:17] <joejaxx> :P
[02:17] <ScottK2> joejaxx: No, the building next to my hotel.
[02:17] <joejaxx> interesting
[02:17] <ScottK2> Business travel is fun!
[02:17] <joejaxx> :)
[02:17] <RAOF> Fire is more fun.
[02:17] <RAOF> But combining the two...
[02:17] <tritium> ScottK2: no it's not!
[02:18] <ScottK2> Ah.  forgot the </sarcasm>
[02:20] <alvinc> gah.  i suspect my question was already answered, but my scroll buffer is full
[02:20] <alvinc> i'm sorry
[02:21] <alvinc> here goes:  how does one submit a package from debian experimental for consideration for ubuntu universe?
[02:21] <zul> the leperchaun told me to burn things
[02:22] <RAOF> alvinc: You ask for it to be sync'd, after you're really sure that the reason it's in experimental doesn't matter :)
[02:22] <imbrandon> alvinc: there isnt a strict policy, it could be a sync or could go through REVU, i'd push the REVU way, its in expirmental for a reason
[02:23] <ScottK2> imbrandon: Why not a sync?
[02:23] <alvinc> well, it's new, for sure
[02:23] <ScottK2> If it needs a change to deal with whyever it's in experimental, then merge it.
[02:23] <alvinc> lzma-dev and friends for squashfs
[02:23] <imbrandon> ..... , its in expirmental for a reason
[02:23] <ScottK2> imbrandon: Right, but REVU doesn't help that.
[02:23]  * Fujitsu would strongly advise against touching squashfs stuff.
[02:23] <alvinc> Fujitsu: ?
[02:24] <imbrandon> ScottK2: it dosent? Reviewing new software before it hits the arcive never hurt either
[02:24] <Fujitsu> The Canonical distro team will likely deal with that, and get annoyed if you meddle in it.
[02:24]  * ScottK2 has only sync'ed from Expermental twice. One of those experiences convinced him to be very careful.
[02:24] <alvinc> Scottk2:  Do tell?
[02:24] <ScottK2> imbrandon: Sure, but a sync bug sent to UUS would accomplish the same goal.
[02:25] <alvinc> Fujitsu:  Annoyed?  Did I step in a steaming pile with this one?  ;)
[02:25] <Fujitsu> alvinc: What are you wanting to do with squashfs? No sponsor is going to go near that, as it's very touchy and prone to breaking on a lot of systems.
[02:25] <alvinc> Ah...
[02:25] <ScottK2> alvinc: Yeah, I didn't understand why something was in experimental, needed it to fix something else, and then it took 3 or 4 uploads to fix why it was in experimental, including having to Tom Sawyer nixternal into fixing some stuff I couldn't figure out.
[02:26] <ajmitch> no wonder he went to vista...
[02:26] <alvinc> I'll try to be brief.  Kind of hard to do.
[02:26] <StevenK> Having to Tom Sawyer? Is that like volutold?
[02:26] <alvinc> AMD low power hardware comes cheaply here in Silicon Valley these days
[02:26] <alvinc> Cisco hardware is still very spendy
[02:26] <pwnguin> fixing bug is so fun!
[02:26] <alvinc> But use of aufs, squashfs with lzma, and friends....
[02:26] <alvinc> I can fit a Quagga router onto a compact flash
[02:26] <ScottK2> StevenK: No, it's convincing someone that work you are supposed to do will be fun/interesting so you won't have to do it.
[02:26] <alvinc> And run it reliably drawing 47 Watts
[02:27] <alvinc> very very useful
[02:27] <pwnguin> 47 sounds like a lot
[02:27] <StevenK> ScottK2: Haha
[02:27] <ScottK2> StevenK: In Tom Sawyer, he gets told to paint a fence and does such a great job convincing other people painting the fence is fun, he avoids having to do it himself.
[02:27] <imbrandon> 47 watts is kinda high for low power stuff :)
[02:27] <alvinc> So with the combination of google, and some headache in finding the right concoction of sources.list.....  I got a kernel to build which boots squashfs/lzma off a compact flash, does the AUFS thing, and voila
[02:28] <pwnguin> ScottK2: they dont read american classics in australia i guess
[02:28] <alvinc> Well, of course imbrandon...  But this is off-the-shelf parts
[02:28] <ScottK2> pwnguin: I guess not.
[02:28] <pwnguin> alvinc: So is ARM
[02:28] <alvinc> You can Newegg yourself an OSPF router this way, without funky cases and MiniITX boards and stuff
[02:28] <ScottK2> StevenK: You should read some Mark Twain.  Very good stuff.
[02:28] <StevenK> I have read Tom Sawyer - it was just over ten years ago
[02:28] <ScottK2> StevenK: Ah.  OK then.
[02:29] <alvinc> pwnguin:  I have a little Buffalo Terastation which I believe has an embedded ARM processor
[02:29] <StevenK> ScottK2: You'll let me off with that, then? :-)
[02:29] <imbrandon> alvinc: heh or i can just load openwrt on a off the shelf router, but i see your point ( kinda )
[02:29] <alvinc> I'm a little less than impressed at its RAID-5 performance
[02:29] <pwnguin> heh
[02:29] <ScottK2> StevenK: No.  I was just about to mention that's probably 15 years more recently than I've read it.
[02:30] <pwnguin> well, raid5 involves xoring massive amounts of data
[02:30] <alvinc> But seriously, at today's cheap RAM  prices...  I cheaply scored a MicroATX mobo, and Antec Minuet case, 2G of ECC RAM, la la la
[02:30] <StevenK> ScottK2: Hah
[02:30] <alvinc> no moving parts
[02:30] <alvinc> Compact Flash booting
[02:30] <alvinc> Anyhow, it was nifty
[02:30] <pwnguin> alvinc: there's also gumstix ;)
[02:30] <alvinc> pwnguin:  You're gonna make me google that now?  lol
[02:30] <pwnguin> alvinc: and the nlsu2
[02:30] <imbrandon> gumstix or nano-itx
[02:31] <imbrandon> w/ cf cards
[02:31] <pwnguin> alvinc: the nlsu2 should have better raid5
[02:31]  * pwnguin wonders if anyone ever got a gumstix to commect to a usb keyboard, mouse and CRT
[02:31] <pwnguin> because that would be l33t
[02:31]  * nixternal remembers ScottK2's intentions
[02:32] <alvinc> wow, that's slick.  but pwnguin...  that gumstix mobo costs the same as all the parts i picked up new...  with a hole lot less RAM
[02:32] <nixternal> cvc cook ScottK2.recip
[02:32] <nixternal> +e
[02:32] <pwnguin> alvinc: well, you're ignoring the power costs, but point taken ^_^
[02:32] <nixternal> cvc add ScottK2.recipe && cvc ci
[02:32] <pwnguin> alvinc: size costs
[02:32]  * ajmitch throws a copy of vista at nixternal 
[02:32] <alvinc> :-D
[02:32]  * nixternal throws a copy of Foresight at Ubuntu!
[02:32] <imbrandon> alvinc: you can build a nano-itx x86 with the same specs much smaller and just as cheap
[02:32] <nixternal> :p
[02:32] <alvinc> size, power, and parts to break
[02:32] <alvinc> also your gumstix thing means less spares to keep
[02:32] <imbrandon> plus less watts
[02:33]  * nixternal wants PICO!
[02:33] <pwnguin> less spares of what?
[02:33]  * nixternal needs PICO MONEY!
[02:33] <nixternal> well, mucho money
[02:33] <alvinc> things that break.  RAM sticks, spare mobo, spare cpu, etc etc etc
[02:33] <imbrandon> yea the pico-itx are sweet, just a bit pricy
[02:33] <nixternal> yup
[02:33] <zul> whoever uses pico should be shot
[02:33] <nixternal> imbrandon: you got me addicted sauce lapper
[02:33] <imbrandon> nixternal: lol
[02:34] <alvinc> If I were to propose using such a thing at work, I'd definitely get the book thrown at me for spares and stuff
[02:34] <nixternal> with that damn c64 keyboard
[02:34] <alvinc> I had to sneak in a Quagga router as it was
[02:34] <imbrandon> zul: a MB CHIP RAM , basicly everything in a pack of smokes == pico-itx
[02:34] <alvinc> I wanted to subnet, and they didn't want to spend on a Cisco, and I didn't want to wait
[02:34] <zul> imbrandon, ah i thought you were talking about the text editor
[02:34] <pwnguin> alvinc: spare RAM?
[02:34] <pwnguin> nonsense
[02:35] <alvinc> I don't know about you, but DDR2 has been pretty finicky for me
[02:35] <alvinc> 240 pins, more stuff to screw up
[02:35] <pwnguin> well its soldiered on pretty good and designed to be compatible
[02:35] <imbrandon> alvinc: either way , back to the real topic, yes you can do the expirmental thing, but you will have to bug the right people in core-dev as it will be tricky
[02:35] <alvinc> I've had 3 different guys at work break several boxes by He-Man(tm)-ing the RAM into slots
[02:35] <nixternal> [       zul] imbrandon, ah i thought you were talking about the text editor
[02:35] <nixternal> gahahah!
[02:36] <nixternal> zul: so people who use nano should be shot as well right?
[02:36] <nixternal> :)
[02:36] <nixternal> lets get um!
[02:36] <pwnguin> nano's nice when emacs isnt installed
[02:36] <pwnguin> :P
[02:36] <alvinc> vi 4tw
[02:36] <alvinc> sorry.  :)
[02:36] <imbrandon> cant nano run IN emacsOS ?
[02:36] <nixternal> vi vi vi - the mark of the beast!
[02:36] <crimsun> nixternal uses notepad.exe from Vista.
[02:36] <zul> nixternal: oh hell yes
[02:36] <pwnguin> imbrandon: of course. but why?
[02:37] <nixternal> I am using Emacs in Foresight :)
[02:37] <pwnguin> imbrandon: it also can run vim :P
[02:37] <imbrandon> any text editor that i can start but not close without reading a manual ( vi AND emacs ) isnt for me
[02:37] <nixternal> lol
[02:37] <alvinc> so embarassing.  am i the only person who doesn't live their whole life in emacs?
[02:37] <nixternal> imbrandon: emacs manual? you mean bible?
[02:37] <alvinc> i've seen some people do crazy stuff in emacs.  lol
[02:38] <imbrandon> nano for life!
[02:38] <nixternal> I don't think I have seen any emacs documentation smaller than an entire encyclopedia index
[02:38] <alvinc> nano comes from pico, doesn't it?  the editor that came with pine?
[02:38]  * pwnguin wrote a small guide ages ago, just enough to write ML programs
[02:38] <imbrandon> i even used up 100k of my 1.1mb space on my router to install nano ;)
[02:38] <pwnguin> nano and pico are related, yes. one is not GNU free enough I gather
[02:39] <imbrandon> alvinc: no it works like pico but no code is the same, pico/pine are non-free
[02:39] <alvinc> you know, it tried using emacs on my ibm 3170 terminal in 89.  it crashed a lot.
[02:39] <alvinc> and i never used it since.  lol
[02:39] <pwnguin> any editor that decides deleting a new line is a different mode than writing text gets a -- in my book :P
[02:39] <imbrandon> nano == pico emulator so to speak, no code in common
[02:40] <alvinc> ah.  it is the OSS descendant, i get it
[02:40] <alvinc> although funny, i didn't realize pico/pine wasn't free
[02:40] <Flannel> I'd use the term 'clone' not emulator
[02:40] <alvinc> we downloaded it and built it all the time
[02:40] <imbrandon> alvinc: sure but you cant distribute binarys of it per the Uni Wash lic
[02:40] <pwnguin> alvinc: Free Enough.
[02:40] <alvinc> well, on SunOS 4.1.1_U1 through Solaris 2.5.1, anyway.  ROFL
[02:40] <ScottK2> alvinc: IIRC you aren't free to modify it and distrubute.
[02:40] <alvinc> oh...  that's right
[02:41] <alvinc> i remember it now.  you're right.  U-Dub didn't let you do that.  but you could download it and make at reckless abandon
[02:41] <imbrandon> only source, and un-modified source at that
[02:41] <Stemp> Bye all, thanks a lot for your help. But I'm sure I will be back soon :D
[02:41] <pwnguin> hmm. i wish i could use yahoo pipes to make a diff between rss feeds
[02:42] <imbrandon> heh
[02:42] <imbrandon> y?
[02:42] <pwnguin> ive got a pipe set up to nab from 4 feeds and union/uniq them
[02:42] <imbrandon> you know, i have noticed, fluxbox + small apps isnt any slower on this computer than a full blown gnome or kde desktop
[02:43] <pwnguin> i wanna know which elements don't have a corresponding one in another feed
[02:43] <pwnguin> ie, the elements with only one source
[02:43] <imbrandon> err faster
[02:44] <pwnguin> also, i'd like to add an enclosure to the feeds
[02:45] <pwnguin> so liferea can automatically launch a torrent on new episodes ;)
[02:48] <alvinc> have a good one folks, thanks for the q&a
[02:52] <pwnguin> awesome. compiz locked up my desktop again
[02:53] <crimsun> echo $?
[02:53] <crimsun> err, sorry
[03:30] <tritium> crimsun: you're fond of aptitude, yes?
[03:32] <crimsun> "fond" is imprecise; I would rather be disconnected from the package manager completely.
[03:32] <crimsun> (I tend to use it more often than apt-get, however.)
[03:33] <tritium> As do I.  It typically works well for me, but not tonight.  I was expected it to remove the dependencies of xubuntu-desktop.  It did not, however.
[03:33] <tritium> s/expected/expecting
[03:33] <crimsun> right, that symptom appears to have struck numerous times
[03:34] <tritium> Is that so?
[03:34] <crimsun> for that particular metapackage, yes.  I can't speak for others.
[03:35] <tritium> Okay, thanks for the info.
[03:37] <tritium> Not that I didn't love xfce.  I did, after all.  But I was just checking it out.
[03:47] <freakabcd> i am getting an error when i try to build refblas3 using gfortran-4.1 instead of g77
[03:48] <freakabcd> i modified the dsc file, the control file and rules file. everything is built and the tests pass as well. just at the end dh_gencontrol says:
[03:48] <freakabcd> warning: can't parse dependency ${gfortran-4.1}
[03:49] <freakabcd> error: error occurred while parsing Depends
[03:49] <freakabcd> how do i correct this?
[03:49] <freakabcd> the resulting debs will be for personal use only
[03:57] <LaserJock> phew, got that done
[03:57] <LaserJock> now I've got a new gutsy box
[03:57] <Hobbsee> yay!
[03:57] <Hobbsee> LaserJock: must be hardy time, then.
[03:58] <LaserJock> hmm, possibly
[03:58] <StevenK> LaserJock: Ponies!
[03:58] <LaserJock> ah, right
[03:58] <LaserJock> geeze, I'm still feeling so crappy
[03:58] <LaserJock> but I'll try
[03:59] <ajmitch> hey LaserJock
[03:59] <ajmitch> good to see you're still alive enough for irc
[03:59] <crimsun> freakabcd: incorrect syntax & semantics.
[04:00] <ajmitch> though I suspect that they'd have to prise a laptop out of your coffin ;)
[04:00] <StevenK> Muahaha
[04:00] <crimsun> freakabcd: that is, if that's precisely what you have in your modified debian/control
[04:00] <freakabcd> crimsun, i was kinda expecting that you would be the one to respond
[04:01] <crimsun> (I have no idea how to interpret that.)
[04:01] <freakabcd> heh, anyway i changed ${g77} to ${gfortran-4.1} in the Depends line for the dev package
[04:01] <freakabcd> shouldn;t that have been just gfortran-4.1 instead?
[04:01] <crimsun> right, the ${} is wrong
[04:02] <freakabcd> great. i did that and built the debs already and was waiting for someone to respond
[04:06] <LaserJock> ajmitch: you know it
[04:06] <freakabcd> one interesting question: why would installing ubuntustudio-sounds would uninstall ubuntu-desktop and ubuntu-sounds ?
[04:07] <StevenK> Probably because ubuntu-sounds and ubuntustudio-sounds conflict, due to having the same files
[04:07] <freakabcd> i can understand it removing(replacing rather) ubuntu-sounds, but why would it want to uninstall ubuntu-desktop as well?
[04:07] <crimsun> what StevenK said
[04:07] <freakabcd> what i just said
[04:07] <crimsun> (see `apt-cache show ubuntustudio-sounds|awk '/^Conf/'`)
[04:07] <LaserJock> ubuntu-desktop deps on ubuntu-sounds I think
[04:07]  * StevenK beats crimsun with grep
[04:07] <crimsun> and what LaserJock just said.
[04:07] <freakabcd> lol
[04:08] <LaserJock> we tag team it here
[04:08]  * StevenK high fives LaserJock and crimsun 
[04:08] <freakabcd> i understand it from the package point of view. but don;t understand it from a user point of view
[04:08] <TheMuso> Yes, ubuntu-sounds and ubuntustudio-sounds share the same filename space, so must conflict.
[04:08] <crimsun> and there's the man who packaged it.
[04:08] <freakabcd> if i want a different sound 'theme' why would my desktop metapackage need to be uninstalled so that further upgrades might create problems?
[04:09] <TheMuso> For UbuntuStudio, we wanted different sounds to what are on offer for Ubuntu.
[04:09] <freakabcd> TheMuso, sure. and i love the ubuntustudio-sounds compared to ubuntu-sounds
[04:09] <TheMuso> freakabcd: Because ubuntustudio-desktop depends on ubuntustudio-sounds, which conflicts with ubuntu-sounds, which is depended on by ubuntu-deskto.
[04:09] <StevenK> freakabcd: Because ubuntu-desktop Depends on ubuntu-sounds. If ubuntu-sounds gets removed ubuntu-desktop needs to be
[04:09] <TheMuso> desktop
[04:09] <freakabcd> grr.. i'm not talking about the package point of view!
[04:10] <TheMuso> Well theres not much more to it.
[04:10] <freakabcd> i mean, you guys allow various GDM themes to exist, various usplash themes to exist.
[04:10] <TheMuso> So far as I see it.
[04:10] <freakabcd> why not various sound 'themes' ?
[04:10] <crimsun> freakabcd: well, the "user" frustration is due to some packaging issues.
[04:10] <TheMuso> freakabcd: Because the architecture in GNOME does not yet allow this.
[04:10] <TheMuso> I wrote a spec to try and address this, at least from a packaging perspective, but that spec hasn't been considered for a development summit yet.
[04:10] <freakabcd> TheMuso, really? it should be pretty trivial to work around. maintaining symlinks and all
[04:11] <TheMuso> This is something I'd like to see addressed also.
[04:11] <TheMuso> freakabcd: Unfortunately, its not quite that easy.
[04:11] <TheMuso> And its all got to do with how GNOME stores sound event configurations.
[04:11] <TheMuso> Which, might I add, is separate to gconf, and, the config files also store sound event translations.
[04:11] <freakabcd> really? afaik all gnome needs is to have the right filenames for the various sounds.
[04:11] <TheMuso> So, things are very much nontrivial.
[04:12] <freakabcd> so symlinking the right files shouldn;t be a non-trivial *workaround*
[04:12] <TheMuso> freakabcd: But if you want multiple schemes, you want different filenames, to be able to set a scheme by default, etc.
[04:12] <TheMuso> freakabcd: Doing that gets you into the apckaging trap we are already in.
[04:12] <TheMuso> packaging
[04:12] <crimsun> (which arguably KDE does properly)
[04:12] <freakabcd> crimsun, how does kde the sound theme thingamajiggy?
[04:12] <crimsun> I think we lamented this at the pizza place during UDS-Boston
[04:13] <TheMuso> crimsun: We did.
[04:13] <ajmitch> mmm, pizza
[04:13] <TheMuso> I'd work on it, but it requires desktop team/GNOME colaboration.
[04:13] <crimsun> freakabcd: it's not so much sounds but themes in general in KDE.
[04:13]  * TheMuso ate a lot of pizza in Boston...
[04:14] <freakabcd> crimsun, so entirety of themes are b0rken in gnome?
[04:14] <TheMuso> GNOME simply does not allow a custom sound theme mechanism.
[04:14] <freakabcd> i don;t think so. just the sounds aren't part of the themes yet. which i believe is true for kde too!
[04:14] <TheMuso> s/allow/have/
[04:14] <crimsun> freakabcd: no, not the /entirety/
[04:15] <TheMuso> IMO whats needed is something like what Windows has, where you can create custom themes, load, and save presets etc.
[04:15]  * TheMuso is unaware as to whether KDE has such a setup.
[04:15] <freakabcd> TheMuso, yes. and for the moment we can do it as a workaround with symlinks
[04:15] <tonyyarusso> eww
[04:15] <TheMuso> freakabcd: If you want to package the themes, no you can't.
[04:15] <tonyyarusso> Shouldn't there just be a gnome/themes/sound/somesoundtheme kind of setup?
[04:16] <TheMuso> And also note, that by default, only the startup and shutdown themes are enabled by default.
[04:16] <TheMuso> tonyyarusso: Yes.
[04:16] <nand`> Hiya!
[04:16] <freakabcd> sure you can. just put the themes in their own directories. then just synlink the right directory to 'default'
[04:16] <freakabcd> or 'current'
[04:16] <tonyyarusso> TheMuso: Would that be very difficult to do?
[04:16] <crimsun> freakabcd: yes, that's akin to what already is done.
[04:17] <nand`> I have a question : when I'm triaging, how do I close bug which are obviously non bug? "Invalid" ?
[04:17] <TheMuso> tonyyarusso: No, once we decide where else to put the sound event name translations.
[04:17] <freakabcd> crimsun, which is why i said it is a non-trivial *workaround*
[04:17] <crimsun> freakabcd: now to do it all properly, the alternatives system could be used.
[04:17] <freakabcd> crimsun, yes. thats a step further. but still a non-trivial *wordaround*
[04:17] <TheMuso> crimsun: WHich is what I proposed in my spec. Atm, ubuntustudio has to use dpkg-divert...
[04:17] <crimsun> freakabcd: right, what TheMuso just said.
[04:18] <freakabcd> err.. wait a minute./.
[04:18] <TheMuso> The UI and architecture changes can come later.
[04:18] <freakabcd> i've been using the complete opposite word!
[04:18] <freakabcd> it is a *trivial* workaround
[04:18] <freakabcd> is what i meant to say
[04:18] <freakabcd> grr.. head's not working after lunch
[04:18] <crimsun> you may have meant "trivial," but it's currently "non-trivial."
[04:19]  * Fujitsu notes that crimsun and TheMuso do really know what they're doing, so should probably be trusted on this matter.
[04:19] <ajmitch> symlink migration is never fun to do
[04:19] <crimsun> well, TheMuso's the authority on this one, since he suffered through it
[04:24] <freakabcd> crimsun, its a bit difficult for me to realise why it would be non-trivial. but i will agree with you for now
[04:25] <crimsun> freakabcd: see the bit above about config files also storing sound event translations
[04:25] <crimsun> (I need to catch the train, so I'll have to step out here)
[04:26] <freakabcd> yeah, best would be to do it in a proper way.
[04:26] <TheMuso> Which means doing it in GNOME.
[04:26] <TheMuso> If I had the coding knowledge, I'd step right in and help do it.
[04:27] <freakabcd> TheMuso, yeah. i'll check if i can peek into it
[04:27] <tonyyarusso> Is there anything besides Flash that is still a PITA on 64-bit?
[04:28] <StevenK> Flash on 64 bit should be okay
[04:28] <Fujitsu> tonyyarusso: Isn't Flash no longer a pain, due to nspluginwrapper automation?
[04:28] <TheMuso> By saying that, I am able to read, and work out msot C code, and could work out how to modify the UI to add a text box element etc, with time and patience. However, the real problem here is working out where to put the translations for the sound events.
[04:28] <tonyyarusso> Fujitsu: I didn't actually know about that.
[04:28] <freakabcd> translations ?
[04:28] <tonyyarusso> StevenK, Fujitsu: So it's pretty much on par these days?
[04:29] <Fujitsu> As far as I know.
[04:29] <TheMuso> freakabcd: The names of sound events in languages other than English.
[04:29] <nand`> btw, is REVU uploading still broken?
[04:29] <Fujitsu> There are issues with Wine, probably, but that's about it.
[04:29] <freakabcd> err.. storing the sound event translations is the problem?
[04:30] <StevenK> Fujitsu: Both ajmitch and I are happy playing WoW on amd64
[04:30] <TheMuso> Most likely you'd make them part of the aprent app that includes the sound applet, but there is likely a reason why the translations are stored where they are.
[04:30] <tonyyarusso> good to know
[04:30] <TheMuso> freakabcd: Not storing them, deciding where and how to store them, other than in the config files themselves.
[04:30] <TheMuso> freakabcd: eIf you are using GNOME, take a look at /etc/sound/events/gnome-2.soundlist
[04:30] <freakabcd> how are the other translations for themes stored?
[04:31] <TheMuso> freakabcd: Visual/window themes are done correctly, and have translation issues sorted.
[04:31] <TheMuso> As far as things go for Sound, having a sound theme was just a quick add-on for GNOME, as it didn't seem to be of importance.
[04:31] <TheMuso> Thats how I see things anyway.
[04:32] <freakabcd> where are the translations for the visual elements stored?
[04:32] <freakabcd> somewhere through gconf?
[04:33] <TheMuso> freakabcd: No, I'm not entirely sure.
[04:33] <TheMuso> Gconf is never used for translation.
[04:33] <TheMuso> translations
[04:33] <freakabcd> no..
[04:33] <TheMuso> As far as I know anyway.
[04:33] <freakabcd> i meant gconf prolly has the location of the translations storage
[04:33] <TheMuso> Nope I don't think so.
[04:34] <TheMuso> Translations are either part of te theme index file itself, or somewhere in /usr/share/locale. I think its the former.
[04:34] <freakabcd> so we just need to find out where the translations for the visual elements are stored and lump the sound translations along in the same place
[04:34] <TheMuso> freakabcd: No, I think not., They are two totally separate systems.
[04:35] <TheMuso> As I said earlier, it seems most sensible to ahve the translations as part of the main applet package, which is gnome-control-center I think
[04:36] <TheMuso> However, again as I said, there may be a good reason why the translations are stored where they are.
[04:41] <freakabcd> err..
[04:41] <freakabcd> bddebian, are you taking care of debian packages?
[04:45] <LaserJock> freakabcd: some, he does a lot of stuff
[04:45] <bddebian> freakabcd: I am on the games team now, why?
[04:45] <freakabcd> sorry, maybe my mistake.
[04:46] <freakabcd> when you do an apt-get source. it grabs the dsc, orig.tat.gz and the diff.gz file ,right?
[04:46] <bddebian> Well I am maintainer for colorgcc as well
[04:46] <freakabcd> then how does it apply the patch?
[04:46] <freakabcd> goes into the src dir, then patch -p1 < ../blah.diff ?
[04:46] <Fujitsu> freakabcd: It gunzips it and pipes it through patch, presumably.
[04:46] <Fujitsu> Something like that.
[04:46] <freakabcd> Fujitsu, with p1 ?
[04:47] <freakabcd> or p0 ?
[04:47] <Fujitsu> p1, I would presume.
[04:47] <StevenK> exec('patch','-s','-t','-F','0','-N','-p1','-u',
[04:47] <StevenK>                  '-V','never','-g0','-b','-z','.dpkg-orig') or &syserr(_g("exec patch"));
[04:48] <freakabcd> ah, its p1. ok cos i thought it was weird. my bad.
[04:49] <freakabcd> ok, time for games (badminton) after which i'll build my octave2.9.17 and then start working on building source packages for the various octave-forge bits
[04:49] <freakabcd> back after few hours
[04:49] <freakabcd> thanks all
[04:54] <bddebian> uhm...
[06:40] <dholbach> good morning
[06:41] <imbrandon> heya dholbach
[06:42] <LaserJock> darn, we almost went two whole hours of silence
[06:42] <imbrandon> heh
[06:42] <StevenK> LaserJock: Ponies!
[06:42]  * StevenK works on giving LaserJock a complex like the one he gave mvo
[06:42] <imbrandon> ugh i give up on django untill ajmitch or Fujitsu can school me
[06:42] <dholbach> hey imbrandon
[06:43] <warp10> Hi all!
[06:45] <TheMuso> Hey dholbach.
[06:46] <LaserJock> imbrandon: but it's supposed to be so easy :-)
[06:47] <imbrandon> hah
[06:47] <imbrandon> better in the long run maybe but easy it is not
[06:48] <LaserJock> I did the "hello world" but that's about it so far
[06:48] <dholbach> heya TheMuso
[06:48] <dholbach> TheMuso: MOTU BLOGGING!
[06:48] <dholbach> :-)
[06:49] <TheMuso> dholbach: Thats just one of the things I intend to blog about.
[06:49] <imbrandon> LaserJock: i dident even get that far before i said <?php echo "Hello Wold"; ?> :)
[06:50] <dholbach> TheMuso: ROCK :)
[06:52] <LaserJock> imbrandon: pfftt
[06:59]  * Hobbsee ponders blogging
[07:00] <LaserJock> uh oh
[07:00]  * imbrandon hides Hobbsee's keyboard
[07:00] <Hobbsee> imbrandon: this is a laptop.  :P
[07:00] <imbrandon> heh
[07:00] <imbrandon> even more of a trick then, now its a tablet :)
[07:02] <Hobbsee> :P
[07:02] <TheMuso> Hobbsee: Of course you want to blog. Everybody on planet Ubuntu wants to blog.
[07:02] <Hobbsee> TheMuso: why?
[07:02] <TheMuso> Hobbsee: Because there is so much interesting stuff to talk about.
[07:02]  * StevenK gags TheMuso
[07:03] <TheMuso> StevenK: That doesn't stop me typing you know.
[07:03]  * StevenK unplugs TheMuso's speakers
[07:03]  * TheMuso pats his braille display.
[07:04]  * StevenK places a null modem between the computer and the braille display's serial interface
[07:04]  * TheMuso uses his notebook with internal speakers.
[07:04] <TheMuso> ...and prepares to write another entry, just to stir StevenK.
[07:04] <imbrandon> lol
[07:05] <StevenK> Just because they're internal doesn't mean they can't be unplugged
[07:05] <imbrandon> just pour water on the speaker cones
[07:05] <imbrandon> if it dont mess the speakers it'll get the proc
[07:05] <TheMuso> imbrandon: ssh. Don't give him any ideas.
[07:05] <imbrandon> heh
[07:06] <StevenK> Actually, the processor may miss out, depending where on the board you hit
[07:06] <imbrandon> man
[07:09] <TheMuso> Hobbsee: Yes, you really really should blog, considering when your last entry was written...
[07:32] <\sh> moins
[07:39] <pwnguin> pochu: your liferea bug has the wrong version listed in the title :P
[07:43] <Hobbsee> TheMuso: there.  blogged.
[08:02] <imbrandon> ugh LaserJock mr edubuntu how good is your ltsp-foo ?
[08:02] <dholbach> imbrandon: you could also ask ogra :)
[08:03] <imbrandon> heh, true
[08:03] <imbrandon> i just wanna build a ppc ltsp root on a x86
[08:03] <imbrandon> without installing ubuntu first on the ppc heh
[08:10] <Jazzva> What's the process in case of FTBFS sync from Debian? Should I supply the .debdiff that will fix the source?
[08:13] <Hobbsee> Jazzva: usually a good idea
[08:13] <Hobbsee> does it ftbfs in debian too?
[08:14] <Jazzva> Hobbsee: Dunno... I will setup a debian chroot to test.
[08:18] <Jazzva> Hobbsee: It looks like it's ok. The version that fails to build in Ubuntu is in Debian...
[08:20] <TheMuso> Hobbsee: Very good. You really should do it more often. :p
[08:20] <Hobbsee> TheMuso: it was to customers_suck, though
[08:21] <TheMuso> heh
[08:21]  * ajmitch waves
[08:22] <Hobbsee> greetings ajmitch
[09:22] <Fujitsu> Oh dear, it looks like it was a mistake to post to launchpad-users. I've had three seemingly random people reply privately saying `[they] want [their] Ubuntu' or similar, completely offtopic.
[09:22] <huats> morning everyone
[09:23] <Fujitsu> Hi huats.
[09:23] <KillerKiwi2005> kubuntu live cd - xdg utils cant install.. does anybody have a fix work around?
[09:24] <StevenK> Blah. WoW randomly pauses
[09:25] <Amaranth> Fujitsu: the first reply was so awesome
[09:26] <Amaranth> "Hi I'm on the universe security team and would like launchpad to do this, this, and that" "universe doesn't have security support, you should talk to the universe security team to see what they need"
[09:27] <pochu> pwnguin: lol, right :)
[09:28] <pwnguin> pochu: so im trying some advanced liferea stuff here with torrents.
[09:28] <pwnguin> pochu: but i cant figure out how to get liferea to launch azureus on enclosure urls
[09:29] <pochu> pwnguin: no idea, but you can ask in #liferea :)
[09:29] <pochu> oh, you're there!
[09:29] <pwnguin> yea
[09:29] <pwnguin> kinda small
[09:29] <pwnguin> surprsing really
[09:29] <pwnguin> liferea's rather nice
[09:29] <Fujitsu> pwnguin: liferea probably has it blacklisted to preserve your sanity.
[09:29] <Fujitsu> It is rather nice, yes.
[09:30] <pwnguin> ?
[09:30] <pwnguin> oh azureus
[09:30] <pwnguin> well, any torrent would do, even bittornado
[09:31] <pwnguin> the deal is, it keeps asking me what to do with an enclosure of type org/get/984023
[09:33] <pwnguin> i guess its just that feed
[09:38] <DaveMorris> Hi, I've uploaded a new version of my package (opensg-dev) to revu after fixing the issues siretart found with the previous upload.  Can someone take another look at it for me please.  http://revu.tauware.de/details.py?package=opensg-dev
[09:46] <siretart> DaveMorris: I'm currently busy at work.sorry :(
[09:48] <DaveMorris> np, I really only mentioned your name to say I'd fixed your comments
[09:49]  * DaveMorris Should of learnt to package with a simpler program
[09:50] <siretart> DaveMorris: please use the correct syntax in debian/changelog, so that the bug gets closed on upload
[09:51] <siretart> DaveMorris: and tbh, I'd keep the config.status rule, call configure from there and depend from the build rule
[09:51] <TheMuso> \whois \sh
[09:51] <TheMuso> ugh
[09:52] <TheMuso> \sh: Re your ldtp merge. You managed to leave Maintainer: as part of the XSBC-Original-Maintainer.
[09:52] <TheMuso> \sh: And, generally one doesn't need to mention any previously closed bugs in a new changelog entry for a merge, since they are documented earlier in the merge changelog.
[09:52] <DaveMorris> siretart: I had that before but it seemed not to be working, I'll have a look to see if I was doing something wrong.  Regarding the changelog syntax, do you know of a package I could use as an example
[09:53] <Fujitsu> TheMuso: I've seen some uploads by other MOTU (I won't name names) which are 'Maintainer: Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>'
[09:54] <TheMuso> Fujitsu: Right.
[09:55] <TheMuso> Sounds interesting.
[09:55] <siretart> DaveMorris: the syntax is ' LP: #12345', see hardy-changes@l.u.c mailing list archive for examples
[09:55] <DaveMorris> thanks
[09:55] <siretart> DaveMorris: the generated .changes file must contain a Launchpad-Fixes-Bugs header
[09:55] <siretart> that's what the archive looks at
[09:56] <StevenK> Hrm. test, aren't you supposed to you know, exit 1 and kill make?
[09:59] <s1024kb> RAOF: hi, want to ask you some questions...
[10:00]  * StevenK replaces test with an exit. Skip that, make
[10:01] <s1024kb> dholbach: excuse me, may i ask you some questions about merge?
[10:02] <dholbach> s1024kb: sure, fire away
[10:02] <dholbach> s1024kb: just ask in the channel, somebody will reply :)
[10:03] <\sh> TheMuso: hmm...I would say it's a copy and paste bug ,-=)
[10:03] <\sh> TheMuso, will provide a fixed debdiff soon
[10:04] <s1024kb> dholbach: thanks. yesterday i followed my teacher and have merged my first package with "grab-merge". He told me to do the last step. So i should modify the changelog and control file in the /debian?
[10:06] <s1024kb> dholbach: shall i replace "-- Ubuntu Merge-o-Matic <mom@ubuntu.com>" with my own name and e-mail address in changelog?
[10:07] <dholbach> s1024kb: yes, you should do that and explicitly list what kind of changes are necessary over the debian version
[10:08] <TheMuso> \sh: Ok thanks. I've left a comment int he bug also.
[10:12] <s1024kb> dholbach: and then i modify the control file? i replace "Maintainer: Ubuntu MOTU Team <ubuntu-motu@lists.ubuntu.com>" with my own name and e-mail address?
[10:12] <Fujitsu> s1024kb: Which package is this?
[10:13] <s1024kb> Fujitsu: yappy
[10:13] <dholbach> s1024kb: http://wiki.ubuntu.com/DebianMaintainerField has more documentation on it - depends if it's in main or universe
[10:13] <dholbach> (update-maintainer of the ubuntu-dev-tools package will do it for you too)
[10:15] <s1024kb> dholbach: so i only modify the changelog, add the list of changes and then use "debuild -S", my name and my e-mail will be updated automatically?
[10:16] <dholbach> s1024kb: it won't get updated in debian/control
[10:16]  * Fujitsu recommends that the Maintainer field be set to the properly compliant value.
[10:17] <s1024kb> dholbach: so i have to modify it by hand?
 (update-maintainer of the ubuntu-dev-tools package will do it for you too)
[10:17] <dholbach> thank god somebody wrote the tool :-)
[10:17] <s1024kb> dholbach: excuse me, what command i should type? (sorry, this is my first time...)
[10:18]  * TheMuso has been thinking of changing it slightly so it only changes debian/control, and doesn't add a changelog entry. I sometimes think that the changelog entry it adds is sometimes too verbose...
[10:18] <dholbach> install ubuntu-dev-tools, then run update-maintainer
[10:18] <dholbach> TheMuso: good idea
[10:19] <dholbach> I had cases, where I sponsored an upload and the updated maintainer field was missing; update-maintainer changed the changelog so that I was the "uploader"
[10:19] <TheMuso> dholbach: Yes theres that too.
[10:19] <TheMuso> I'll do that now.
[10:19]  * dholbach hugs Super-TheMuso
[10:19] <TheMuso> lol
[10:19]  * TheMuso hugs dholbach back.
[10:20] <dholbach> :-)
[10:20] <s1024kb> dholbach: so what i must do by hand is to add the change list to the changelog? Is it all what i should do?
[10:21] <dholbach> s1024kb: if the rest of the merge looks good to you, yes, that should be it
[10:21] <s1024kb> dholbach: i even don't need to update my name and e-mail address, i only write the change list, and run the tool to gen my name and e-mail?
[10:22] <dholbach> s1024kb: update-maintainer will only make changes debian/control (according to http://wiki.ubuntu.com/DebianMaintainerField)
[10:22] <TheMuso> Hmm. Maybe we should also switch update-maintainer-field to use rmadison, so one can use it in gutsy for example, yet let it still find a package in hardy.
[10:23] <StevenK> TheMuso: It uses apt-cache currently?
[10:23] <TheMuso> StevenK: Aye, apt-cache madison.
[10:23] <s1024kb> dholbach: okay, so plus my name and e-mail adding to the changelog. Okay?
[10:23] <StevenK> Right, that should be easy to kill.
[10:23] <TheMuso> Indeed.
[10:24] <TheMuso> And, I think this code could be cleaned up a little... Especially the code that displays usage info...
[10:24]  * StevenK bzr pull's down ubuntu-dev-tools
[10:24] <dholbach> s1024kb: yes
[10:24] <StevenK> TheMuso: Do you want to do it, then? :-)
[10:24] <TheMuso> StevenK: I'm going to be adding an extra command-line argument, so yes I'm happy to do it.
[10:24] <s1024kb> dholbach: so after do these things, my package is finished?
[10:25] <dholbach> s1024kb: after that you can put it up for review
[10:25]  * dholbach is off for a bit
[10:26] <StevenK> Isn't it @foo to have make no echo the command?
[10:26] <s1024kb> dholbach: so how to put it up for review? (sorry, and thank you very much for guiding me on my first task. :-))
[10:26] <StevenK> not echo, even
[10:27] <StevenK> Meh. It doesn't seem to be anyway
[10:27] <jpatrick> s1024kb: dput revu file.changes
[10:30] <Fujitsu> jpatrick: It's not a new package.
[10:30] <s1024kb>  jpatrick: in my case, i should type "dput revu file.changes" in my terminal? but i can't find any file.changes in all the directories?
[10:30] <s1024kb> Fujitsu: could you please tell me what is the last step?
[10:31] <jpatrick> Fujitsu: sorry, I thought he wanted to know how to upload to revu
[10:31] <s1024kb> jpatrick: aha, "she" wanted to, :-) :-)
[10:32] <jpatrick> s1024kb: sorry, again, I didn't know :)
[10:32] <s1024kb> jpatrick: okay, i know that you don't know, :-)
[10:33] <s1024kb> jpatrick: actually i really don't know how to upload to revu, because i had never did it.
[10:33] <jpatrick> s1024kb: have you made the source package?
[10:35] <s1024kb> jpatrick: i am not sure. because i only typed "grab-merge" and downloaded all the files and directories, my teacher said that this package was a special one - it happened to be not having conflicts. so he told me last evening to do the final things to finish it.
[10:36] <jpatrick> s1024kb: there should be a merge-buildpackage script, have you ran that after checking everything?
[10:37] <s1024kb> jpatrick: not yet. where to find it?
[10:37] <jpatrick> s1024kb: in the dir of the merge
[10:38] <s1024kb> jpatrick: ah, see it. and also see another one "merge-genchanges"
[10:39] <s1024kb> jpatrick: shall i run them both?
[10:40] <jpatrick> s1024kb: yes, that's right :), buildpackage would be better if you plan to get it into revu
[10:42] <Fujitsu> jpatrick: It is not a new package. It will not be heading to REVU.
[10:42]  * persia notes that debdiffs against debian are preferred for merges, rather than uploads to REVU
[10:43] <Hobbsee> persia: you prefer upstream spew in them?  strange :)
[10:43]  * Hobbsee likes both, and checks different bits in each.
[10:43] <persia> Hobbsee: debdiff against *Debian*
[10:44] <persia> (for merges)
[10:44] <Hobbsee> oh, against debian.  got it.
[10:44] <Hobbsee> that's the best of both worlds, then :)
[10:44] <persia> Hobbsee: Exactly :)
[10:45] <s1024kb> jpatrick： after running the scripts, the file.change will appear, right?
[10:45] <jpatrick> s1024kb: should do, but I'm not sure what you're doing..
[10:47]  * TheMuso does some code cleanup in update-maintainer.
[10:47] <TheMuso> update-maintainer-field
[10:47] <zul> morning
[10:47] <s1024kb> jpatrick: you mean...? i am working in my first package "yappy", i grabbed it with "grab-merge", that was all what i had done.
[10:49] <s1024kb> persia: hi, persia, just now we're talking about my first package "yappy". Last evening my teacher had explained it to me. i had did the "grab-merge" step, my teacher asked me to finish the last steps.
[10:50] <StevenK> persia: Can I borrow your C++ skillz?
[10:50] <persia> s1024kb: Hi.  Have you been successful so far?
[10:51] <persia> StevenK: Ummm...  I don't have any, but you can certainly borrow my random language code reading skills :)  What's the issue?
[10:52] <StevenK> persia: Helix doesn't build. Do you want run screaming now?
[10:52] <persia> StevenK: Nah.  I'm not smart enough to become afraid yet.  Does LP have the buildlog?
[10:52] <s1024kb> persia: just now i was asking them if i should add the change list to the /debian changlog, and that's okay. there is no conflicts in the merge.
[10:53] <StevenK> persia: Not a current one, since I redid the build system.
[10:53] <persia> s1024kb: That sounds right, but you want to check the merge carefully, and only include the changes are are still there.
[10:53] <StevenK> persia: Let me generate one, hang on
[10:55] <persia> StevenK: Could you also tell me the package name?  apt-cache and aptitude are stumped :(
[10:55] <StevenK> persia: helix-player
[10:55]  * persia wonders why `apt-cache search helix` didn't show that, but isn't going to investigate any time soon
[10:56] <s1024kb> persia: after that step i can send it for revu?
[10:57] <persia> s1024kb: No.  You'll want to generate a debdiff against Debian.  See https;//wiki.ubuntu.com/MOTU/Contributing for the commands
[10:58] <s1024kb> persia: okay, thanks. so what is the final thing i should hand out for revu?
[10:58] <persia> s1024kb: You will want a debdiff for review.  REVU is only for new packages.
[10:58] <DaveMorris> StevenK: I can look at it building if you want, not sure how much help I'll be but I program in C++
[10:59] <StevenK> DaveMorris: It's wierd error.
[10:59] <s1024kb> persia: okay. so after i think that i had finished everything, who shall i contact to or i upload the files myself?
[10:59] <DaveMorris> StevenK: can you pastebin the log?
[10:59] <persia> s1024kb: You'll want to upload them to your merge bug, and request sponsorship (see the MOTU/Contributing link)
[11:00] <StevenK> DaveMorris: I'm still waiting for it to fail
[11:00] <StevenK> DaveMorris: I'll tell you and persia when I've put the log up
[11:00] <DaveMorris> thanks
[11:00] <s1024kb> persia: thanks
[11:00] <persia> DaveMorris: for context, you can look at the last build log (with a different build system) from http://launchpadlibrarian.net/10375047/buildlog_ubuntu-hardy-amd64.helix-player_1.0.9-0ubuntu1_FAILEDTOBUILD.txt.gz
[11:00] <persia> The code is full of ugliness that doesn't look good :)
[11:01] <StevenK> persia: THe current error is nothing like that.
[11:01] <persia> StevenK: You cleaned up all the warnings?  I'm extremely impressed.
[11:02] <StevenK> persia: I did not. I changed the build system that means it won't try and do stupid stuff during a build, like CVS checkout.
[11:02] <persia> StevenK: Ah.  It would make sense that release code would be cleaner :)
[11:03] <StevenK> persia: That, and the fact that the buildds don't have Internet access, so a CVS checkout is pointless
[11:05] <StevenK> "Build killed with signal 15 after 150 minutes of inactivity"
[11:05] <StevenK> Woot
[11:06] <StevenK> persia, DaveMorris: I'm a bozo, re-generating a log that will fail the right way now.
[11:06] <persia> :)
[11:09] <persia> RAOF: About kvm/qemu: are you still in discussions, or does it make sense to just push the USB path issue to hardy / gutsy?
[11:10] <StevenK> persia, DaveMorris: My upstream bandwidth sucks, so if you want the orig tarball, grab it from a mirror.
[11:10] <persia> StevenK: OK.  Which version?  1.0.9?
[11:10] <StevenK> Right, 1.0.9
[11:11] <persia> StevenK: That's already in the archive :)
[11:11] <StevenK> persia: Right. -0ubuntu2 isn't.
[11:11] <persia> Aha!  Now I'm beginning to understand...
[11:12] <nand`> hiya! Is REVU uploading still broken?
[11:12] <StevenK> persia, DaveMorris: http://wedontsleep.org/~steven/helix-sucks/ contains a build log, and the .dsc and .diff.gz for -0ubuntu2
[11:12] <DaveMorris> nand`: no it's fixed
[11:12] <DaveMorris> I uploaded around 15 mins ago
[11:12] <nand`> DaveMorris: Ok thanks.
[11:13] <DaveMorris> StevenK: got a link I got download the orgi.tar from to make sure I'm on the same song sheet
[11:13] <ogra> imbrandon, you need a ppc to build the chroot/image on (depending on the release, gutsy uses an image) ....
[11:14] <StevenK> DaveMorris: http://archive.ubuntu.com/ubuntu/pool/universe/h/helix-player/helix-player_1.0.9.orig.tar.gz
[11:14] <persia> StevenK: Quick answer before I dig the code: likely a missing header #include (new gcc doesn't like header including header).  Looking explcitly now...
[11:14] <StevenK> persia: I thought so too, but I think digging proved me wrong
[11:16]  * persia is grateful for the waving of warning flags when blind alleys are considered :)
[11:18] <DaveMorris> StevenK: I'm looking at the source however I can't see the header files it's meant to include in the same path as chxmimemanager.cpp (I'm prob been stupid though)
[11:19] <StevenK> DaveMorris: If you look at the build log, there's a whole bunch of -I flags
[11:19] <DaveMorris> grrr, I dislike that programming style
[11:20] <StevenK> If you want to try and build it, it takes about 4 minutes to fail on my hardware
[11:20] <DaveMorris> how do I apply the patch again, my brain has balnked
[11:21] <nand`> I request a REVU package review of ike please : http://revu.ubuntuwire.com/details.py?package=ike
[11:21] <persia> DaveMorris: Put the .dsc, .diff.gz, and .orig.tar.gz all in the same directory, and use sbuild or pbuilder
[11:21] <nand`> all should be fixed
[11:22] <StevenK> DaveMorris: dpatch apply-all
[11:22] <StevenK> Or apply, I forget
[11:25]  * StevenK wonders if he broke persia 
[11:26] <persia> StevenK: No, I'm just trying to see if I can decode the mess that is DEFINE_GUID.  I'm guessing the problem is that the parser can't match the interface in the referenced location, but I don't know enough about DEFINE_GUID yet to be confident of my hypothesis.
[11:26] <StevenK> I couldn't even find DEFINE_GUID
[11:27] <persia> StevenK: It's a built-in, that allows one to create a symbolic reference to a binary blob (as far as I can tell so far)
[11:27] <StevenK> Oh, right. I didn't know that bit.
[11:27] <persia> Apparently, it is used quite commonly to compile against Windows drivers when accessing interfaces that aren't supposed to be exposed.
[11:27] <StevenK> Heh
[11:27] <persia> StevenK: I didn't know it either until Google just told me :)
[11:28] <StevenK> Oh, right
[11:31] <persia> StevenK: Unforuntately, I'm not finding lots of docs, although I thought http://www.devdaily.com/scw/c/cygwin/src/winsup/w32api/include/ddk/ndisguid.h.shtml was amusing :)  Demonstrates the significant benefits of having access to library headers.
[11:33] <StevenK> I just don't see why it would fail. DEFINE_GUID should get replaced by the C++ preprocessor to something sane, the parser should see it and it should be declared.
[11:35]  * StevenK can't find any mention of DEFINE_GUID under /usr/include
[11:36] <persia> StevenK: Interestingly enough, ":~/src/scratch/foo/gcc-4.2-4.2.2$ grep -r DEFINE_GUID *" returns nothing...
[11:37] <TheMuso> Ok. Update-maintainer for hardy now uses rmadison, and the code is somewhat more readable now, at least IMO.
[11:37] <StevenK> TheMuso: Yay
[11:38] <TheMuso> StevenK: Agreed. It at least means I can now use it on hardy changelogs from within gutsy.
[11:38] <TheMuso> And, its now possible to change the field without adding a changelog entry.
[11:38] <TheMuso> Just use --nochangelog
[11:39] <persia> Hrm.  `rmadison -u debian` fails in my hardy chroot...
[11:40] <StevenK> persia: Fails how?
[11:41] <persia> StevenK: "<br /><b>Warning</b>:  stat(): Stat failed for /srv/ftp.debian.org/backup/dump_2007.11.03-20:44:50 (errno=2 - No such file or directory) in <b>/org/qa.debian.org/web/madison.php</b> on line <b>82</b><br />"
[11:41] <StevenK> Ah, then qa.d.o is borked :-)
[11:41] <RAOF> persia: What discussions?  The kvm fix has already been pushed into hardy (I think).  I haven't really been tracking the gutsy-proposed parts.
[11:41] <TheMuso> persia: I get similar behavior here, but in gutsy also.
[11:42] <TheMuso> So that would explain why requestsync is giving me incorrect version numbers then.
[11:42]  * TheMuso has had to take the contents of what requestsync presents and file bugs manually.
[11:42] <persia> RAOF: You posted to the bug about the qemu, and wondering which would be the right solution.  After that, the submitter let a small comment, and I presumed additional offline discussions.
[11:42] <TheMuso> Once the version number was altered.
[11:43] <persia> StevenK: Right.  Nothing to worry about then.
[11:43] <RAOF> persia: No, actually.  I've just looked at it again, and remembered to subscribe to it this time.
[11:43] <rexbron> morning persia
[11:43] <persia> evening rexbron
[11:43] <rexbron> :)
[11:43] <rexbron> Feeling better?
[11:43]  * Hobbsee waves to rexbron, when she's actually awake
[11:43] <persia> rexbron: almost.
[11:44] <rexbron> hey Hobbsee
[11:44]  * StevenK sighs. DEFINE_GUID is black magic
[11:44] <persia> StevenK: At least it's explicity defined as black magic :)
[11:45]  * rexbron needs some review McLovin: http://revu.tauware.de/details.py?package=openlibraries and http://revu.tauware.de/details.py?package=genpo
[11:45] <StevenK> persia: Are you still digging, or have you thrown down the shovel?
[11:46] <persia> StevenK: I'm digging upstream, as DEFINE_GUID is proving sufficiently opaque that I'd need new X-Ray specs
[11:46] <DaveMorris> I'm digging in between other tasks
[11:46]  * StevenK chuckles
[11:46] <StevenK> persia: Digging where?
[11:47] <persia> StevenK: https://player.helixcommunity.org/
[11:47] <StevenK> Ah
[11:47]  * StevenK idly ponders being evil and putting the DEFINE_GUID macro call in the .cpp file directly
[11:48] <persia> StevenK: From the little I've been able to discover, one has to jump through special hoops when mixing DEFINE_GUID with other header information.  Putting it in the .cpp makes me think it won't work at all.
[11:48] <persia> (plus, it gets used two places in the source)
[11:49] <StevenK> I've only seen one
[11:49] <persia> StevenK: player/app/gtk/mimetypes.cpp:100 + player/app/gtk/mimetypes.cpp:534
[11:50] <persia> Err..    That's player/mime/util/chxmimemanager.cpp:100 + player/app/gtk/mimetypes.cpp:534
[11:50]  * StevenK nods
[11:50]  * persia is a big fan of grep -rn
[11:50]  * StevenK too
[11:51] <\sh> guys, what do you think about getting rid of ircii-pana aka bitchx?
[11:51] <persia> StevenK: The release notes for 1.0.8 seem to say that people should install 1.0.8.  This could be a typo, but it may also indicate some unconscious opinion...
[11:51] <persia> Umm..  Release notes for 1.0.9 (see I did it too)
[11:52] <StevenK> Oh. That's ... wierd
[11:52] <zul> \sh: why? do people still use it?
[11:52] <\sh> zul, there are some security exploits ... but upstream looks like dad
[11:52] <\sh> s/dad/dead/
[11:53]  * persia thinks dead upstream + security exploits + available alternatives is a recipe for removal
[11:53] <zul> \sh: sure ok with me
[11:54] <rexbron> siretart: Have time to discuss ffmpeg?
[11:54] <StevenK> persia: I can't see other header files doing anything special with regard to DEFINE_GUID
[11:55] <DaveMorris> StevenK: have you tried telling it to use the g++-3.4 compiler rather than g++ (which prob points to 4.1)
[11:55] <siretart> rexbron: what's up?
[11:55] <StevenK> DaveMorris: I'd rather avoid that if I can help it
[11:55] <siretart> rexbron: you want to help porting the patches to the next upstream version?
[11:55] <DaveMorris> yeah, but there are big changes between them, which might be causing this.
[11:56] <DaveMorris> might be worth the 5 mins to patch it and build it
[11:56] <rexbron> siretart: I am terrible at c/c++ but I can take a look and do what I can
[11:56] <rexbron> siretart: FFmpeg now includes support for Avid's DNxHD codec
[11:56]  * persia notes that chxmimemanager.cpp no longer appears in upstream nightly builds on AMD64
[11:57] <siretart> I have some local uncommitted chagnes, which would need to be reviewed
[11:57] <StevenK> Hah, neat.
[11:57] <siretart> the most terrible patches the inline assembler ones
[11:57] <rexbron> siretart: and the BBC has released a library (libMXF) for working with .mxf files produced by Panasonic cameras and avid workstations
[11:57] <rexbron> siretart: which depends on those new features in ffmpeg
[11:58] <siretart> I see
[11:58] <rexbron> siretart: !!, I have _no_ real understanding of assembally
[11:58] <rexbron> siretart: Are they bug fix patches?
[11:59] <StevenK> DaveMorris: Trying your idea
[11:59] <StevenK> persia: In the source, or build logs?
[12:00] <siretart> rexbron: I'd suggest you check out the svn and have a look for yourself
[12:00] <persia> StevenK: build logs: I'm trying to grab CVS now, but it keeps asking me for a password...
[12:00] <rexbron> siretart: On the upside of all of this, there has been a huge swing in momentum for the underlying FOSS video libraries
[12:01] <StevenK> persia: Ah. This could be due to a different in the build system - I'm not using build/bin/build.py, which I bet they are.
[12:01] <rexbron> siretart: DVCPRO HD will be supported soon, according to the ML
[12:01] <persia> StevenK: They certainly are.
[12:01] <StevenK> persia: build/bin/build.py does CVS checkout and other stupid shit which I really really want to avoid.
[12:01] <persia> Note that if their build system excludes this file, it may be that this file doesn't need to be compiled...
[12:02] <StevenK> Hey, I'm just running $(MAKE) :-)
[12:02] <Fujitsu> \sh: I agree.
[12:02] <persia> StevenK: Can't you just comment that out or something?
[12:02] <Fujitsu> I was looking at that a couple of days back (and filing bugs) and wondering wth. we were going to do with it.
[12:03] <StevenK> persia: 1) The Python code for build.py is spread over about 30 files, and 2) It isn't just the CVS checkout that's a problem, the bigger one is fundamental.
[12:03] <\sh> Fujitsu, see mail to u-d-d and u-m...please reply there...so we have some thoughts
[12:03] <Fujitsu> \sh: Right, I saw that mail, hence the response.
[12:03]  * Fujitsu checks Debian.
[12:04] <StevenK> persia: Do any other files under player/mime/util get built?
[12:04] <\sh> Fujitsu, the bugs are known in debian, too...but nico is unable to fix it
[12:04] <\sh> Fujitsu, at least one bug
[12:04] <rexbron> siretart: Looking at the diff
[12:05] <Fujitsu> \sh: I saw one of them had a fix, but the other not.
[12:05] <rexbron> siretart: from debian, there is a fair amount of inline patching, is that advisable?
[12:05] <Fujitsu> \sh: Might want to discuss this with #debian-security@OFTC
[12:05] <persia> StevenK: I don't have the log in front of me now: I'll check in a couple minutes (unless you find it first - in the nightly builds section)
[12:06] <\sh> Fujitsu, the last fix I did for ircii-pana for ubuntu, thx to debian....
[12:06] <\sh> Fujitsu, thx for the reminder...I was missing  a tab in my xchat ;)
[12:07] <DaveMorris> StevenK: I tried it and it didnt work (using g++3-4)
[12:07] <Fujitsu> \sh: bitchx does have quite a few users, judging by popcon.
[12:08] <StevenK> persia: Nighty builds is for 2.0
[12:08] <\sh> Fujitsu, tbh, I don't care of those scriptkiddies...
[12:08] <\sh> Fujitsu, I don't find newer upstream versions neither I do find any healthy website or ML
[12:08] <Fujitsu> There are three open CVEs, two of which don't have patches anywhere.
[12:09] <Fujitsu> Upstream is well and truly dead.
[12:09] <persia> StevenK: Hrm.  That might explain it :)
[12:09] <Hobbsee> set it on fire.
[12:09] <Hobbsee> problem solved.
[12:09] <Fujitsu> I would prefer to talk with Debian first.
[12:09] <persia> (still, it would be nice to be able to find the anonymous CVS hook)
[12:09] <StevenK> Bwahahaha
[12:09] <StevenK> g++-3.4 gives a nice error
[12:10] <StevenK> chxmimemanager.cpp:99: error: `IID_IHXMimeAssocManager' was not declared in this scope
[12:10] <StevenK> chxmimemanager.cpp:99: warning: unused variable 'IID_IHXMimeAssocManager'
[12:10] <TheMuso> Night folks.
[12:10] <persia> good night TheMuso
[12:10] <Fujitsu> \sh: I also see that somebody adopted it, and it only built for a very short time.
[12:10] <\sh> Fujitsu, do you have a link to popcon stats?
[12:10] <persia> StevenK: Isn't that about the same thing as we see in 4.2?
[12:10] <Fujitsu> \sh: popcon.ubuntu.com
[12:10] <Fujitsu>  /by_inst.gz
[12:10] <StevenK> persia: No warning in 4.2
[12:11] <StevenK> persia: It's the warning and error that makes me laugh
[12:11] <persia> StevenK: Ah.  I missed that :)
[12:13] <StevenK> persia: I found a link to a browsable CVS repository - only using ViewVC, sadly
[12:13] <persia> StevenK: I see it now: https://player.helixcommunity.org/2005/downloads/ (for 1.0.9) ends up pointing to 2.0 for nightly builds.  Apparently it takes 3-4 days to get CVS access (and I'm not that motivated), and there aren't any reported bugs.
[12:13] <persia> StevenK: You did?  Where?
[12:13] <persia> Ah.  Found it.  Handy little "CVS" link :)
[12:15] <persia> StevenK: Now I'm back to "Where?".  I see nothing at https://helixcommunity.org/viewcvs/player/player/
[12:17] <StevenK> persia: I've found a bunch of stuff under /app/gtk
[12:18] <StevenK> persia: /player/player is a red herring. Everyting you want is under /player
[12:19] <persia> StevenK: Right.  The tarball is so stripped, I didn't even recognise it.
[12:20] <StevenK> Looks like stuff under player/mime hasn't been touched in over 3 years
[12:21] <Fujitsu> \sh: Filing the ircii-pana bug?
[12:21] <Fujitsu> Hm, but what to do about it in stable releases...
[12:21] <persia> StevenK: There was a license change ~4 months ago to exclude GPLv3 for the file calling DEFINE_GUID.
[12:22] <\sh> Fujitsu, jepp...even for debian :)
[12:22] <Fujitsu> \sh: So I saw. Very good, I'll be glad to see it go.
[12:23] <\sh> Fujitsu, good to know what nion speaks my mother language ,-)
[12:23] <StevenK> persia: Yeah, but that isn't a code change
[12:24]  * persia cheers the UUS queue being at 3 bugs, and hopes someone feels like pushing a couple merges
[12:24] <Hobbsee> wow!
[12:24]  * Hobbsee should give away more of her stuff, if it turns out like that then :P
[12:24] <persia> StevenK: Right.  Just a touch.  I'm just not sure why it might work for them, and not for us.  1.0.8 had a sad time in Debian as well.
[12:26] <Nightrose> didn´t he set that recently? well... doesn´t matter
[12:27] <Nightrose> ah sorry - wrong channel :)
[12:27]  * StevenK kicks umake
[12:28] <StevenK> You can pass a profile to build.py, but not umake
[12:30] <siretart> rexbron: its all with quilt, no inline
[12:30] <rexbron> siretart: ok
[12:30] <DktrKranz> persia, about u-u-s queue (especially that seven-task bug), I'm going to look at it soon
[12:30] <rexbron> siretart: TBH, I don't understand enough of the code base to beable to really help
[12:31] <persia> DktrKranz: TJ is currently working on that bug, and I'm a big fan of letting the submitter create the debdiffs if they are willing.  It's the other 3 that need quick hits.  I suspect dspam is likely most interesting: the others are just merges.
[12:32] <DktrKranz> persia, related to dspam, I asked blueyed if he would like to investigate for dapper, edgy and feisty too, but if you need additional testers for /dev/bus stuff, count on me
[12:33] <StevenK> Neat. I found a problem that managed to defeat persia
[12:33] <persia> DktrKranz: Thanks.  I'm fairly certain that feisty qemu/kvm works, as I remember testing it shortly before release: I believe the kernel change is new for gutsy.
[12:34] <Fujitsu> StevenK: That's not possible.
[12:34] <persia> StevenK: I found the macro definition on common/include/hxcom.h, so I'm not defeated yet, just wounded, tired, and with a broken blade
[12:34] <Fujitsu> See!
[12:34] <StevenK> Hehe
[12:35] <StevenK> persia: I've found a difference between the build systems in -0ubuntu1 to -0ubuntu2, so I'm seeing if that makes a differnce
[12:35] <StevenK> difference
[12:36] <persia> StevenK: That'd be nice.  I'd prefer a silly mistake on your part to actually determing how to mangle the unique identifiers for the upstream binary blobs (or whatever it's using DEFINE_GUID to define)
[12:37] <persia> StevenK: You know, if you statically link everything, it doesn't actually call the referenced path...
[12:38] <StevenK> Funny. I didn't know what powdered tooth enamel tasted like.
[12:39] <persia> It's just wrong to use random binary references to manage malloc calls.  Just wrong!
[12:43] <StevenK> Excellent. Now it applies the same profile.
[12:44] <persia> StevenK: What happens if you include hxcom.h in chxmimemanager.cpp ?
[12:45] <persia> I'm wondering if chxmimemanager just can't figure out what DEFINE_GUID means...
[12:45] <StevenK> persia: Hold on, I've got a build currently running
[12:46] <persia> StevenK: Ah.  Too bad.  I was hoping you'd have a good reason to shoot that down :)
[12:46] <StevenK> persia: This is the build-system fix build, so now I get to see if it still fails
[12:47] <pkern> persia: I got the reason for the longish repair of my lappy:  the technician fried the system board when replacing the LCD.
[12:47] <StevenK> Nice!
[12:47] <persia> StevenK: Right.  Let's hope it does, as at this point, I'm poking blindly at namespace models.
[12:47] <pkern> Or rather... the repair is finished today, they'll check it again if it was s.th. which fried it... it might leave them today, though.
[12:47] <pkern> s.th. else
[12:47] <StevenK> How do you fry a system board when replacing an LCD?
[12:47] <persia> pkern: Aha!  Did they give you a new delivery estimate?
[12:48] <pkern> persia: Maybe today, if they don't screw up again and it passes the QA test.
[12:48] <pkern> (Or rather shipping, not delivery.)
[12:48] <persia> StevenK: apply the wrong voltage because the LCD regulator isn't tuned properly: I'm sure there are other ways as well, but that's the only one I've had success with.  It really only fries the controller, but you can't usually easily extract just that.
[12:49] <StevenK> Sure you can, given infinite time. :-)
[12:49] <pkern> persia: Yeah the system board is one replacement component, so if there's s.th. broken the whole time gets replaced.
[12:49] <pkern> *thing
[12:49] <pkern> WTF is happening with me.  Low on coffee or what.
[12:49] <StevenK> Usually because that's quick and simple.
[12:50] <persia> StevenK: Right.  When you're a big OEM, simple is key.  It's dangerous to trust monkeys with soldering irons
[12:51] <pkern> persia: They already fscked the LCD replacement.  So... ;)
[12:54] <StevenK> persia: I *think* it's gotten further.
[12:54] <persia> Excellent.  I'll hold off manually backtracing the #ifdefs then :)
[12:55] <siretart> rexbron: it is indeed a complicated matter, and I understand that we really need a newer ffmpeg snapshot
[12:56] <siretart> Perhaps I should consider dropping patches that aren't really necessary in ubuntu.. hm
[12:58] <StevenK> Hrm. I'm *much* happier with this build system.
[12:59] <persia> StevenK: Does it work?
[13:00] <StevenK> persia: It fails 17 minutes in, as opposed to 4.
[13:00] <DaveMorris> StevenK: progress :)
[13:00] <persia> StevenK: What's the error this time (and I only need the last ~50 lines of the buildlog)
[13:01] <StevenK> persia: It's not even a code error.
[13:01] <persia> What's the error?
[13:02] <StevenK> make[3]: Entering directory `/build/steven/helix-player-1.0.9/player/installer/archive'
[13:02] <StevenK> test -d ../../../debug || mkdir ../../../debug
[13:02] <StevenK> cp dbg/symbols.tar.gz ../../../debug
[13:02] <StevenK> cp: cannot stat `dbg/symbols.tar.gz': No such file or directory
[13:02] <persia> That sounds like the build worked, and it's just dealing with cleanup.
[13:05] <StevenK> persia: Do you want to look at the new build log?
[13:05] <persia> StevenK: Only in combination with the new build system: I don't think I can chase that from upstream code.
[13:07] <StevenK> persia: http://wedontsleep.org/~steven/helix-sucks/build-log if you want to look
[13:09]  * StevenK stops calling $(MAKE) copy
[13:09] <slomo_> who wants helix anyway ;)
[13:10] <StevenK> My employer.
[13:10] <persia> slomo_: At least someone has it installed according to popcon.  I'm sure neither StevenK nor I would object if you went there and uninstalled it :)
[13:10] <persia> (well, maybe StevenK then)
[13:11] <LeRoutier> Hello
[13:12] <persia> Welcom LeRoutier
[13:13] <persia> StevenK: Looking at that build log, I'm placing full blame on the build system.  It looks like it's just setting up the installer, etc.
[13:14] <StevenK> persia: It looks like make copy is doing it, so I'm rebuilding with it.
[13:14] <persia> with?  without?
[13:15] <StevenK> Er, yeah. :-) Without
[13:15]  * persia waits 22 minutes
[13:15] <StevenK> I'm not sure if I can, it's 12:16am here :-)
[13:16] <persia> StevenK: Right.  Time change.  I'm more than happy for that: I'd rather sleep anyway :)
[13:16] <StevenK> TBH, I'm much happier with my NWO of build systems
[13:17] <StevenK> I know how $(MAKE) behaves and how to debug it - a threaded Python app - not so much.
[13:17] <persia> StevenK: How are you doing it?  All make?
[13:17] <StevenK> persia: -0ubuntu1 set some environment variables and called build/bin/build.py with a bunch of command line arguments.
[13:18] <StevenK> persia: -0ubuntu2 iterates over every Umakefil it can find, and runs build/bin/umake.py on it to generate Makefiles and then runs $(MAKE) directly.
[13:18] <persia> StevenK: Ah.  Autotools in python.  Nifty, and lots easier to debug :)
[13:19] <StevenK> persia: One of the problems with the build system in -0ubuntu1 is that if a bit failed to compile, it would log to stderr "Make failed" and *keep going*
[13:20] <persia> That gives me a new definition to "mistrust" when it comes to build systems.  At least with "-$(MAKE)" I can see the character that shouldn't be there.
[13:21] <StevenK> Heh
[13:21] <StevenK> -$(MAKE) clean/distclean I can understand, -$(MAKE) is just wrong
[13:21] <StevenK> persia: Also note the checking I do in debian/rules after the umake.py call
[13:21] <persia> StevenK: -$(MAKE) is what you've described for -0ubuntu1 though...
[13:22] <StevenK> persia: Who can tell? It's being run in an opaque manner
[13:23] <persia> StevenK: Right.  The behaviour was -$(MAKE), but it's taken significant time for two people to figure that out.
[13:23] <persia> Three people
[13:23] <\sh> Fujitsu, filed removal request and subscribed u-u-s
[13:23] <StevenK> Isn't Helix fun?
[13:23]  * persia wishes make was happier with indenting for if/endif
[13:24] <StevenK> As soon as you indent, it isn't a make directive
[13:25] <persia> StevenK: Don't use "for" in a makefile!  That's why $(foreach ...) exists.
[13:25] <LeRoutier> in what shape are PPA buildbots today ?
[13:25] <StevenK> persia: If you want to paste a better line in /query, I'm happy to use it
[13:26]  * persia goes off to play with make
[13:26] <StevenK> persia: I can't remember $(foreach) semantics, but I can remember how to write for loops in shell, and how to escape them so make doesn't hate me, so ....
[13:29] <persia> StevenK: Sure.  I can never remember syntax either, it's just that "for" in make tends to make makefiles less makey
[13:29]  * StevenK chuckles
[13:29] <StevenK> "less makey"
[13:31] <persia> Right.  $(foreach ) isn't even the right syntax for this...
[13:38] <\sh> dholbach, you don't need to be member anymore to become a motu?
[13:38] <dholbach> \sh: MOTU membership includes ubuntumembers membership
[13:39] <\sh> dholbach, yeah but as I understand your post on p.u.c, that there is no splitted application necessary anymore? or did I miss something?
[13:39] <dholbach> \sh: no, only one application
[13:40] <dholbach> we have that for nearly a year now
[13:40] <LucidFox> norsetto> the Debian developer for Psi has just uploaded 0.11-3, which incorporates all Ubuntu changes
[13:40] <norsetto> lucidfox: \o/
[13:41] <norsetto> LucidFox: you should ask for a sync then
[13:41] <\sh> dholbach, well, I was still thinking, that you need to apply for plain ubuntu membership first and then in the second round apply for motuship...well, I'm getting old ;)
[13:41] <LucidFox> It's still in incoming.debian.org, though - not yet moved to the archive. Should I wait? And should I submit a separate bug or reopen that one?
[13:41] <persia> \sh: That was only true for about 18 months.
[13:42] <norsetto> LucidFox: just submit a new bug once its in the debian archive then
[13:43] <\sh> persia, well, I was one of the old farts who had to deal with sabdfl in the first round and mdz in the second...
[13:43] <persia> \sh: I know :)
[13:44] <StevenK> So did I
[13:44] <\sh> oh wow...good to know that I don't use mac osx
[13:45] <Hobbsee> \sh: that's just scary.
[13:45]  * Hobbsee had to deal with keybuk and such first, then mdz for core.
[13:46] <\sh> Hobbsee, oh yes, for the third round I just forgot ;)
[13:47] <Hobbsee> haha
[13:47]  * Hobbsee remembers the first round as she was still on a mostly-canonical call, as was keybuk, and we didnt have quorum for my TB meeting, and they couldnt do it without me there.
[13:47] <Hobbsee> er, last round
[13:48] <norsetto> ah, the good (!?) memories
[13:49] <Hobbsee> yeah.  was good neough
[13:49] <zul> heh when I went for core I was eperiencing a shortness of breath
[13:49]  * Hobbsee just answered questions on how she found UDS, and hammered them on not being more organised.  *shrug*
[13:50] <Hobbsee> and about release management, and my plans for that, i think
[13:50] <StevenK> I had mako for membership, keybuk/someone else for MOTU, and mdz/mjg59 twice for core
[13:51] <\sh> norsetto, mindi: read the comment :) I really don't know where you looked for the control file, but distributions/debian/ is just not the right location :)
[13:51] <norsetto> \sh: I just searched for /control in patch, heck, there are about 100 of them ;-)
[13:52] <\sh> norsetto, in the diff? no...just use the plain debian package and patch it with the debdiff...
[13:52] <norsetto> \sh: but please edit the patch with the remaining issues, I really don't understand why you want to have linux-image as a reccomend
[13:52] <\sh> norsetto, I just realized, that the mom/dad merge sources are really a pain in my a*s
[13:52] <norsetto> recommend even
[13:53] <\sh> norsetto, because debian recommends all their flavours...we just need the one package to rule them all..it just catches up with the installed kernel already.
[13:53] <norsetto> \sh: yes, but whats the point? We should add linux-image as a Depends to all packages really .....
[13:54] <\sh> norsetto, oh you want it as dependency...now I got that point :)
[13:54] <persia> norsetto: That very much doesn't work.  Firstly, because many packages don't need it, and nexenta, etc. would suffer, and secondly because it's insufficiently specific for version issues.
[13:55] <norsetto> \sh: no, I don't think we need it at all
[13:55] <zul> no you shouldnt add linux-image to Depends because that changes alot
[13:55] <norsetto> well, whats the point of having linux-image as a recommend?
[13:57] <\sh> norsetto, if you be safe, you would need to "OR" all ubuntu kernel flavours, like debian is doing it....it needs at least one image to build boot/root media ... so debian is giving the user a choice...I don't, that's why I recommend linux-image (which matches the installed kernel) only
[13:57] <norsetto> \sh: yes, but why do we need it explicitely as a recommend?
[13:58] <norsetto> \sh: I mean, do we have ubuntu installations without linux-image? Isn't linux-image part of the Base package?
[13:59] <norsetto> \sh: I'm not talking about a fancy arch here, its i386, amd64 and ia64
[13:59] <\sh> norsetto, no...but we have -generic, -server etc. as flavour...Imean I could put them as well as recommends, because the package just works with the installed kernel...
[14:00] <\sh> so I remove linux-image, and put all flavours in, that's the debian way...
[14:00] <norsetto> \sh: exactly, so, why do we want to have a recommend?
[14:01] <\sh> because you could install more kernel flavours...then the default...yes, I think it's more serious to add all flavours
[14:01] <norsetto> \sh: yes, but what mind wants its a kernel, do we need to recommend that a kernel is installed?
[14:02] <\sh> norsetto, it needs at least "one kernel" not "the installed kernel"
[14:02] <\sh> you can choose the kernel version or flavour of what boot/root media you want...
[14:02] <\sh> so if you want boot/root media for -server flavour you need to have the linux-image-server installed
[14:03] <\sh> and this applies for all other flavours
[14:03] <norsetto> \sh: yes, so how linux-image is going to solve that? Its just telling you that a kernel is recommended, do we need that recommendation?
[14:04] <\sh> norsetto, that's why I realized now...I just add linux-image-generic | linux-image-server  to recommends
[14:04] <\sh> s/why/what/
[14:04] <norsetto> \sh: yes, but why? I still don't see the need
[14:04] <\sh> norsetto, because of the choice
[14:05] <norsetto> \sh: what choice? Unless you want for instance to restrict it to non -rt for instance
[14:05] <\sh> norsetto, do you know what mindi does?
[14:05] <norsetto> \sh: no idea at all
[14:05] <\sh> it creates boot/root disks :) and for this you have the choice of the kernel
[14:06] <\sh> it creates those disks with your choosen kernel, modules, tools and libs...so you have a choice here
[14:06] <\sh> like mkinitrd or mkinitramfs does, too :)
[14:06] <norsetto> \sh: right, so, how does a recommend in your package help you with that?
[14:07] <\sh> norsetto, the user doesn't have all kernels installed, but the user (mostly admins) have an advice, which kernels we/debian have/has...it's more accurate
[14:07] <\sh> so they see what they can install...
[14:08] <norsetto> \sh: you now that apt-get will install the recommends now?
[14:08] <pkern> Recommends will be installed by default soon?
[14:08] <pkern> Or even now.
[14:08] <norsetto> pkern: I think it does already
[14:08] <pkern> You could add Suggests.
[14:08] <\sh> norsetto, it's been discussed yes...
[14:09] <\sh> as I understand the mail from this morning on u-d-d correctly..so right now, recommends is the right place, and for the future, when debian goes with the same decision, we will move it to suggests
[14:09] <pkern> Debian already installs recommends by default.
[14:10] <\sh> pkern, ugh...
[14:10] <pkern> \sh: Since Oct 1
[14:10] <pkern> That one I know for sure. ;)
[14:10] <\sh> pkern, bad
[14:10] <\sh> pkern, habbit ,-)
[14:10] <pkern> Coherent...
[14:11] <\sh> pkern, hopefully there is a switch in d-i to stop the packagemanager of installing them
[14:22] <siretart> norsetto: not yet, but mvo is going to do this change in hardy RSN
[14:22] <siretart> norsetto: that change has already reached debian
[14:23] <norsetto> siretart: right .... talking about what if I may ask :-)
[14:31] <\sh> norsetto, ok...I'll change the recommends to suggests (for the kernels) and add all flavours
[14:31] <norsetto> \sh: ok, please also remove the version change for mindi-busybox, I think its not needed anymore
[14:32] <siretart> \sh: exactly. that change makes maintainers to think about the difference between recommends and suggests. and makes them actually useful for something
[14:37] <Rospo_Zoppo> norsetto: hi, can I ask you something about build-depends ?
[14:38] <norsetto> Rospo_Zoppo: sure, ask the audience too ;-)
[14:38] <Rospo_Zoppo> ok
[14:38] <Rospo_Zoppo> I'm trying to merge foobillard
[14:38] <Rospo_Zoppo> but I have two different build-depends fields
[14:39] <Rospo_Zoppo> between the old Ubuntu version and the new Debian version
[14:39] <\sh> norsetto, attached new diff
[14:39] <norsetto> \sh: thanks
[14:40] <Rospo_Zoppo> norsetto: this is the old version
[14:40] <Rospo_Zoppo> http://pastebin.ubuntu.com/2004/
[14:40] <Rospo_Zoppo> and this is the new one
[14:40] <Rospo_Zoppo> http://pastebin.ubuntu.com/2005/
[14:41] <Rospo_Zoppo> norsetto: maybe it's transitional stuff or something like that ?
[14:42] <norsetto> Rospo_Zoppo: I didn't look at the second, but I recognise some transitional package in the first, yes
[14:47] <Rospo_Zoppo> norsetto: thanks
[14:48] <frafu> Hello, I am preparing a package for revu. The C-source code files are under GPL v3,but there is no indication in the config, makefiles, intltool, etc. Do each of this files also need a few lines at the top about the license?
[14:53] <frafu> Moreover, the package includes a manual under GFDL 1.1,but the text of the license is not included in the package. Do I have to add a file with the gfdl 1.2 text to the source package? Or does a link in debian/copyright be enough?
[15:04] <norsetto> frafu: the gfdl needs to be mentioned in copyright, same type of mention as the gpl (a link is not enough)
[15:05] <norsetto> frafu: are u upstream too?
[15:06] <frafu> yes,  I am also an upstream maintainer of the package
[15:06] <Lutin> siretart: bzr-buildded is syncable, isn't it ?
[15:07] <siretart> Lutin: yes, it is!
[15:07] <siretart> and should be in sync, in fact
[15:08] <Lutin> siretart: ok
[15:08] <norsetto> frafu: ok, then as you mentioned you should add the gfdl in COPYING (or whatever it is you use) too
[15:09] <Lutin> siretart: just want to make sure. the current ubuntu version is a no-change upload from debian, right ?
[15:09] <Rospo_Zoppo> norsetto: it's not necessary to do a merge only for a .desktop clean-up right ?
[15:10] <siretart> Lutin: http://patches.ubuntu.com/b/bzr-builddeb/bzr-builddeb_0.90ubuntu1.patch
[15:10] <norsetto> Rospo_Zoppo: if its just an aesthetic change I would say not, report it to debian and we will take it from them
[15:11] <Lutin> siretart: ok
[15:11] <frafu> norsetto: are you telling me to add the text of both, the gpl and gfdl, to the file named COPYING? It currently contains only the text of the gpl license.
[15:11] <norsetto> frafu: yes, that would be good
[15:12] <Rospo_Zoppo> norsetto: it's only for the icon field, I will do a sync request
[15:13] <norsetto> frafu: you can also add two different files, lets call them GPL and GFDL and link them in COPYING
[15:14] <frafu> But changing the COPYING file, the source package will not be identical anymore to the release that I am preparing for revu. Should I increase the release version number?
[15:15] <norsetto> frafu: the release number for revu is practically irrelevant, it only need to record the first release, you may leave it unchanged
[15:15] <frafu> norsetto: what kind of link do you have in mind?
[15:16] <norsetto> frafu: a textual one: "this and this file are released under the GPL etc., a copy of the license is in the file foo/GPL ...." this type of things
[15:17] <norsetto> frafu: you are pretty free to do what is best for you, as long as there is a clear unique reference to what license is used for what source in one general license file (for instance COPYING)
[15:18] <frafu> norsetto: what about the makefiles, config*, intltool, etc. Does each file also have to mention a license?
[15:18] <norsetto> frafu: the way I understand it, its not needed for autogenerated files
[15:19] <frafu> norsetto: thanks for your help. If I have further questions I will come back :-)
[15:20] <norsetto> frafu: sure, np, for license questions you may also ask in ubuntu-devel, as most archive admins hang in there
[15:21] <frafu> norsetto: thanks for the tip about ubuntu-devel, too
[15:23] <Rospo_Zoppo> mr_pouit: I've seen that you patched foobillard, now I'm trying to merge it but I don't know how to deal with this change you made "* Bump DH_COMPAT to 5, bump build-dependency: debhelper (>= 5)."
[15:23] <DaveMorris> can someone please point me in the right direction, or tell me the answer in how to fix this lintian error?  postinst-must-call-ldconfig
[15:23] <norsetto> Rospo_Zoppo: he is not logged at the moment
[15:24] <norsetto> DaveMorris: is your package packaging shared libraries?
[15:24] <DaveMorris> yes
[15:24] <norsetto> DaveMorris: and you are not using dh_makeshlibs?
[15:25] <DaveMorris> norsetto: http://pastebin.ca/775285
[15:25] <norsetto> DaveMorris: because that will also add the call to ldconfig for you
[15:25] <DaveMorris> yeah I am
[15:26] <norsetto> DaveMorris: how many binary packages you have?
[15:26] <DaveMorris> 2
[15:26] <DaveMorris> the other one doesn't have the error
[15:27] <norsetto> DaveMorris: ok, so you get the error in the -dev package I guess?
[15:28] <DaveMorris> actually no, the dev package is fine
[15:29] <norsetto> DaveMorris: outside your question, I would nont add the .la files since you have the *.pc already
[15:29] <DaveMorris> ok, thanks
[15:30] <norsetto> DaveMorris: see if specifying the package with -p helps in your call to dh_makeshlibs
[15:30] <Rospo_Zoppo> norsetto: can you tell me what that "bump" means ? :)
[15:31] <Rospo_Zoppo> norsetto: I mean, is it a change to reproduce ?
[15:31] <norsetto> DaveMorris: if you add an "export DH_VERBOSE=1" this will also add some verbose output from the debhelper calls which may give you some hints
[15:33] <norsetto> Rospo_Zoppo: bump means raise, so bump debhelper to >= 5 means raising it from whatever it was before (4 or lower) to 5
[15:33] <Rospo_Zoppo> ok
[15:37]  * norsetto -> has tea
[15:38] <DaveMorris> norsetto: thanks, it appears they are been made but not installed to the correct dir
[15:40] <DaveMorris> they are appearing in debian/ rather than debian/libcpptest/DEBIAN
[15:43] <LeRoutier> re
[15:44] <LeRoutier> could someone tell me if we get a mail after uploading to REVU ?
[16:04] <Nightrose> \sh_away: have a look at facebook - I finally changed "it" as promised ;-)
[16:17] <norsetto> DaveMorris: ah, but that is because you are calling dh_installdeb before dh_makeshlibs then
[16:18] <DaveMorris> yep, that was it, thanks
[16:33] <nixternal> alrighty, give me a quick and dirty rule about man pages?
[16:33] <nixternal> why would a plugin need a manpage? why would a guy app that has far more extensive help documentation need a manpage?
[16:33] <nixternal> it is absolutely stupid, a waste of space, and a waste of time
[16:34] <azeem> nixternal: why do you think a plugin needs a manpage?
[16:34] <nixternal> I don't think a plugin needs a manpage
[16:34] <azeem> okk
[16:34] <nixternal> I don't think a gui app that doesn't even use the command line needs a man page, especially when a majority of apps come with documentation
[16:35] <nixternal> supposedly there is this really dumb rule that says "binaries should have manpages"
[16:38] <soren> nixternal: In that case, the man page could just explain in 15 words what the binary is for.
[16:39] <soren> nixternal: Well... It's not all binaries. Just the ones in {/usr,}/{,s}bin
[16:39] <soren> nixternal: if it's a plugin for something and is not meant to be called directly, it doesn't belong in a {/usr,}/{,s}bin. It's quite simple.
[16:41] <nixternal> quite simple, and at times quite silly
[16:46] <apachelogger> siretart: ping
[16:47] <siretart> apachelogger: please don't do contentless pings
[16:48] <apachelogger> siretart: ping, revu is eating my uploads key: 1024D/72F23991 mail: apachelogger@ubuntu.com
[16:48] <apachelogger> eating = I upload and the upload never shows up -.-
[16:49] <siretart> what package did you upload?
[16:49] <apachelogger> siretart: khalkhicards
[16:50] <siretart> apachelogger: and you are absolutely sure you uploaded it to review? check your .upload file
[16:51] <apachelogger> Successfully uploaded kopete-plugin-thinklight_0.3-0ubuntu1.dsc to revu.tauware.de.
[16:51] <apachelogger> ah, wrong one, sorry
[16:52] <apachelogger> siretart: hm, something is really wrong here... I'll try again
[17:15] <gnomefreak> siretart: same problem that me and a few others had?
[17:15] <gnomefreak> where uploads are stuck in a dir. and not pushed to revu page?
[17:16] <siretart> gnomefreak: that he failed to upload it to the right host? probably yes :)
[17:16] <gnomefreak> i uploaded 3 times after nov 13th 7:00 and they never showed up, people have found the issue but its still not fixed
[17:16] <DaveMorris> gnomefreak: it's fixed
[17:16] <DaveMorris> I've uploaded since and I had the same problem
[17:16] <gnomefreak> DaveMorris: my page wasnt updated
[17:17] <gnomefreak> should i re-upload it?
[17:17] <siretart> gnomefreak: oh yes, there has been some upload swallowed yesterday, that should be fixed now
[17:17] <DaveMorris> yeah
[17:17] <siretart> gnomefreak: what package was that?
[17:17] <gnomefreak> ok ill re send it. lightning-sunbird
[17:17] <siretart> yes, please reupload
[17:17] <Lutin> joejaxx: what's the need of the libglu1-mesa-dev -> libglu1-mesa-dev | libglu-dev change in antennavis ? can't get it
[17:17] <gnomefreak> ok re uploading
[17:18] <gnomefreak> ty siretart and DaveMorris
[17:18] <apachelogger> siretart: ok, khalkhicards went online, but it seems like kopete-otr seems to be stuck somewhere
[17:18] <siretart> apachelogger: if you uploaded it yesterday, please reupload
[17:19] <apachelogger> siretart: tried 8 minutes ago
[17:20] <siretart> ACCEPTED /srv/uploads/khalkhicards_0.2.2-0ubuntu1_source.changes
[17:20] <siretart> but no trace of kopete-otr
[17:22] <apachelogger> really strange
[17:22] <apachelogger> siretart: http://paste.ubuntu-nl.org/44630/
[17:23] <siretart> care to paste your kopete-otr .upload file as well?
[17:23] <apachelogger> again the wrong package -.-
[17:23] <apachelogger> siretart: http://paste.ubuntu-nl.org/44632/
[17:24]  * apachelogger kicks khalkhi to the moon for always blocking his clipboard
[17:27] <apachelogger> siretart: here's the .upload file: http://paste.ubuntu-nl.org/44633/
[17:28] <siretart> interesting
[17:28] <siretart> when was that?
[17:28] <apachelogger> siretart: 16 minutes ago
[17:29] <siretart> apachelogger: what's the problem with this? http://revu.ubuntuwire.com/details.py?package=kopete-otr
[17:30] <apachelogger> honestly, I really shouldn't do any work today
[17:30] <apachelogger> siretart: well, thanks for looking anyway
[17:37] <Lutin> StevenK: are you ok with a cynthiune.app sync ? seems that your patch has been applied in debian
[17:47] <bddebian> Heya gang
[17:48] <pochu> hey bddebian
[17:48] <bddebian> Hi pochu
[18:06] <geser> Hi bddebian
[18:18] <bddebian> Heya geser
[18:29] <Lutin> geser: don't you think we should drop the description typo fix in edenmath.app and just sync it ?
[18:30] <geser> Lutin: I looked at it today and asked that myself
[18:31] <geser> on one side it isn't important enough to keep on the other side it closed an LP bug
[18:31] <Lutin> geser: yeah, but do we want to keep a diff against debien for such a minor bug ?
[18:32] <Lutin> (I would not even call that a bug anyway)
[18:33] <geser> not really
[18:39] <Lutin> geser: let's sync then :)
[18:40] <norsetto_> lutin, geser: submitting the bug to debian is not even an option?
[18:41] <Lutin> norsetto: the bug has already been reported to the BTS
[18:41] <norsetto> lutin: ok, and they just couldn't care less or what?
[18:41] <Lutin> norsetto: reported 9 days ago, can't tell :)
[18:41] <Lutin> no answer yet, quite normal
[18:48] <\sh> re
[18:48]  * norsetto thinks that this place looks differently without scottk
[18:49] <\sh> what's up with scottk?
[18:51] <norsetto> \sh: didn't you see his email to the lists?
[18:51] <\sh> norsetto, need to start my email client
[18:52] <norsetto> \sh: need an help? I can push while you steer
[18:53] <\sh> norsetto, I just setting up claws mail...after thunderbird with enigmail doesn't like cardreader for gpg cards...:(
[18:53] <proppy> norsetto: ScottK gone ?
[18:53] <norsetto> proppy: no, but stepping down considerably
[18:53] <proppy> :(
[18:55] <\sh> norsetto, hmm...I just got the mail about the mentoring from him
[18:56]  * norsetto checks his incoming mail
[18:57] <\sh> norsetto, thinking about u-m@l.u.c
[18:57] <norsetto> \sh, proppy: https://lists.ubuntu.com/archives/ubuntu-motu/2007-October/002581.html
[18:58] <\sh> oh this one...old one :)
[19:00] <\sh> norsetto, and tbh, I agree with him in some points...
[19:02] <\sh> norsetto, yeah I saw that too late (mindi)...I wonder what grab-merge.sh (the moms way) is doing to the original debian package or whatever...I'll merge it now cleanly...I'm tired of mom
[19:02] <norsetto> \sh: well, its uploaded already with those changes
[19:03] <norsetto> \sh: I added all linux-images- for the 3 arches btw
[19:03] <ajmitch> hi
[19:03] <norsetto> \sh: I think you have an amd64 since you only added those for that arch?
[19:03] <norsetto> hiya ajmitch
[19:05] <\sh> norsetto, there is no arch for linux-image-generic ... don't add the arch specific ones...that's wrong
[19:05] <\sh> norsetto, and no...I just have i386
[19:05] <\sh> all flavours are available
[19:06] <\sh> norsetto, linux-image-{generic,server,rt,virtual} are meta packages where dependencies are set during build time for the compiled arch (afaik)
[19:07] <\sh> norsetto, so you will find for linux-image-generic on i386 an i386 dependency to the real kernel...and on ia64 for ia64 and so on...
[19:11] <\sh> ugh
[19:12] <zul> most if not all -source packages for hardy in universe will not build against 2.6.24
[19:13] <\sh> who wants to fix wireshark for feisty and down?
[19:13] <\sh> https://rhn.redhat.com/errata/RHSA-2007-0709.html looks really interesting
[19:14] <zul> \sh: assign it to me and ill get to it
[19:16] <\sh> zul, don't bother, I'm grabbing the patches and file a bug
[19:27] <\sh> oh this is so crap...why can't they put the cve in the svn/cvs log
[19:28] <\sh> hey ivoks
[19:28] <ivoks> hello
[19:53] <proppy> any debian bugs report guru here ?
[19:53] <slangasek> proppy: what's the question?
[19:54] <proppy> slangasek: I forgot to set the severity of a bug, can I change/add it by replying to the bugmai l?
[19:54] <azeem> bts <nnnn> severity foo
[19:54] <RainCT> hi
[19:54] <azeem> hrm, or does bts go to LP by default?
[19:55] <azeem> proppy: actually, it's bts severity <nnnn> foo
[19:55] <RainCT> i've seen a "Homepage:" entry in debian/control some days ago. is this new policy or just something strange? :P
[19:55] <proppy> azeem: it bts a command, or something I should put in the mail content pseudo header ?
[19:55] <norsetto> rainct: new policy
[19:55] <jpatrick> RainCT: new policy
[19:55] <azeem> proppy: command
[19:55] <azeem> proppy: you can also mail control@bugs.debian.org
[19:56] <azeem> proppy: see http://bugs.debian.org
[19:56] <proppy> ok thanks
[19:56] <proppy> azeem: thanks
[19:56] <RainCT> nice. will synaptic add it automatically to the description?
[20:01] <Kmos> RainCT: that need to be adapted :) synaptic get that field from package
[20:01] <Kmos> it's new dpkg feature =)
[20:01] <proppy> azeem: few done by mail
[20:02] <proppy> do not really know how to feel about mail based bts :)
[20:03] <proppy> wonders if day to day use feels easy
[20:04] <proppy> Severity set to `wishlist' from `normal' Request was from Johan Euphrosine <proppy@aminche.com> to control@bugs.debian.org.   (Thu, 15 Nov 2007 20:03:06 GMT) Full text and rfc822 format available.
[20:04] <proppy>    Severity set to `wishlist' from `wishlist' Request was from Gerfried Fuchs <rhonda@debian.at> to control@bugs.debian.org.   (Thu, 15 Nov 2007 20:03:10 GMT) Full text and rfc822 format available.
[20:04] <proppy> ahah :)
[20:15] <norsetto> proppy: isn't that the one from viewcs?
[20:16] <proppy> norsetto: nop, just a bug I found out in a package I've just installed
[20:16] <proppy> norsetto: I've not received any news for the viewvc one
[20:16] <norsetto> proppy: don't know why but the nickname rings a bell
[20:17] <proppy> norsetto: which nickname ?
[20:17] <norsetto> proppy: rhonda
[20:17] <proppy> norsetto: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409864 not updated
[20:17] <ubotu> Debian bug 409864 in viewvc "viewvc: No such file or directory: '/usr/lib/templates/directory.ezt' for SVN, but CVS works OK" [Important,Open]
[20:24] <warp10> Hi all!
[20:24] <norsetto> hiya warp10
[20:25] <warp10> norsetto: :-)
[20:25] <norsetto> I have seen some strange versions but this is pretty funny
[20:26] <norsetto> you like this warp10: 2.~-1.0~beta1-1 ?
[20:27] <warp10> norsetto: Indeed it has a kind of artistic sense
[20:31]  * proppy hugs norsetto
[20:31] <proppy> seeyou
[20:32] <norsetto> thats what I call a hug and run offense
[20:43] <\sh> now...let's see if wireshark compiles...
[20:49] <geser> where does I find the current section list for the Debian menu?
[20:50] <frafu> Hello, I am preparing a package for revu and had to do a few changes to conform to the rules concerning the submission of a new package. These changes now imply that it is not equal anymore to the release tarball that I had when I started. Could anybody please tell me how to proceed about the versioning?
[20:51] <mdomsch> frafu, you'll have an .orig.tar.gz from upstream
[20:51] <mdomsch> and a set of patches you apply
[20:51] <mdomsch> and a patch that contains the debian/ dir and files
[20:52] <mdomsch> -0ubuntu1 would be the -release part of your version-release
[20:52] <frafu> mdomsch: no, I did the changes in the source itself
[20:52] <mdomsch> frafu, are you the upstream maintainer?
[20:53] <frafu> yes
[20:53] <mdomsch> ok, then you can either a) release a new upstream version with your changes, or
[20:53] <mdomsch> b) see above, so it's your last upstream version, plus a patch
[20:53] <mdomsch> plus the debian/ dir patch
[20:54] <\sh> oh damn...we should host all dapper stuff in bzr or whatever
[20:59] <frafu> mdomsch: I will try b). (I am new to this); To be sure: could you confirm that I can use the b) route, even if there is no package submitted to revu yet?
[21:01] <mdomsch> frafu, you bet
[21:01] <frafu> mdomsch: thanks
[21:01] <mdomsch> frafu, debian developers occasionally have to fix code, e..g a diff from the upstream released version
[21:01] <mdomsch> if only to get it to build properly on debian/ubuntu
[21:02] <mdomsch> there's a 'dpatch' mechanism, and others I'm sure, for applying a set of patches cleanly
[21:02] <mdomsch> during debuild
[21:04] <frafu> mdomsch: does debuild automatically see the patches? In other words: I can call 'debuild -S' as usual!?
[21:05] <mdomsch> frafu, this I'm not sure, I haven't needed to use dpatch myself yet
[21:05] <mdomsch> but I'm told I should have once before :-)
[21:05] <\sh> frafu, for additional dpatches you need to add them to 00list in debian/patches
[21:06] <TheMuso> And, if the apckage doens't yet use dpatch, you need to change debian/rules to knwo about it.
[21:06] <geser> and also build-depend on dpatch
[21:06] <\sh> and if you want to be c0ol use quilt ,-)
[21:07] <\sh> (forget about that ,-))
[21:08] <frafu> Do I have to change debian/rules manually?
[21:09] <\sh> frafu, when debian/rules doesn't know anything about dpatch, yes
[21:12] <frafu> It does not yet use dpatch yet. My debian rules is auto generated... I will have to look now for the details. Thanks to all for pointing me in the right direction.
[21:12] <mdomsch> it looks like cdbs has its own patch system, if you happen to be using that
[21:13] <frafu> no, I am using debhelper
[21:13] <\sh> autogenerated debian/rules?
[21:13] <frafu> from dh_make
[21:14] <\sh> oh it's the initial debian/rules
[21:14] <\sh> so you need to add the magics from dpatch, which are written down in man dpatch
[21:14] <\sh> include /usr/share/dpatch/dpatch.make
[21:14] <\sh> and the next 2 makefile targets you need to find out yourself in man dpatch :)
[21:15] <frafu> I did not have to change it yet (apart one line in the clean target)
[21:15] <\sh> Fujitsu, can you set the importance of bug #132915 to high?
[21:15] <ubotu> Launchpad bug 132915 in wireshark "WireShark versions prior to 0.99.6 vulnerability" [Undecided,In progress] https://launchpad.net/bugs/132915
[21:16] <geser> \sh: done
[21:16] <\sh> geser, thanks :)
[21:16] <frafu> thanks again
[21:17] <\sh> I wonder if all this patching works down to dapper
[21:17] <Fujitsu> \sh: We have bigger problems in Dapper, of course.
[21:17] <Fujitsu> We even need 0.99.4 down there, IIRC.
[21:17]  * Fujitsu checks.
[21:17] <\sh> Fujitsu, 0.99.4 is just finished...(feisty)
[21:18] <\sh> dapper has 0.90.x
[21:18] <Fujitsu> Oh, it was Ethereal back then, wasn't it?
[21:18] <\sh> 0.99.0 as ethereal
[21:18] <\sh> yes
[21:18] <Fujitsu> I simply don't think we can support that.
[21:19] <Fujitsu> Other distros backported 0.99.4 because they couldn't pick out the security stuff.
[21:19] <\sh> e.g. there is another cve hanging (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3391) which doesn't apply for us in general, the functionality is not in our versions from feisty downto dapper...
[21:19] <ubotu> Wireshark 0.99.5 allows remote attackers to cause a denial of service (memory consumption) via a malformed DCP ETSI packet that triggers an infinite loop. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3391)
[21:20] <\sh> Fujitsu, well, we can try...for a vital app like ethereal/wireshark that's one of the important things for ubuntu and it's community driven support
[21:21] <\sh> Fujitsu, I think when we can show the outside people, that motu is able to support the community section for about 5 years, it would be the greatest thing on earth ,-)
[21:21] <Fujitsu> We might have a chance for Hardy, if we get a sane security tracker up and running.
[21:22] <Fujitsu> \sh: Were you able to nominate bug #132915 for Dapper today?
[21:22] <ubotu> Launchpad bug 132915 in wireshark "WireShark versions prior to 0.99.6 vulnerability" [High,In progress] https://launchpad.net/bugs/132915
[21:23] <\sh> yepp.
[21:23] <\sh> i just did that (10 minutes ago)
[21:23] <\sh> and I think it's a bug ,-)
[21:23] <Fujitsu> Right, I'm filing it.
[21:23] <Fujitsu> Because I can't approve it.
[21:23] <Fujitsu> Or decline it.
[21:23] <Fujitsu> It's just stuck there forever.
[21:23] <\sh> lol
[21:24] <\sh> Fujitsu, sorry...
[21:24] <Fujitsu> Heh, it's LP's problem.
[21:24] <Fujitsu> So you're going to backport those 4 CVE fixes to Edgy/Feisty?
[21:25] <\sh> Fujitsu, feisty is just building
[21:25] <Fujitsu> Very good.
[21:25] <\sh> Fujitsu, edgy will be the last..I'm trying dapper first
[21:25] <\sh> i think it's more important the bumpy edgy
[21:25] <Fujitsu> There are others that need fixing in Dapper.
[21:26] <Fujitsu> I'll try and get a list some time today.
[21:26] <\sh> Fujitsu, I'm going down the security list of our security team...
[21:26] <Fujitsu> ~motu-swat?
[21:26] <\sh> php4 is something
[21:26] <Fujitsu> php4 should be doable for another month, but then we're completely screwed.
[21:26] <\sh> Fujitsu, no ubuntu-security-team
[21:26] <Fujitsu> Ah.
[21:26] <Fujitsu> That's probably more complete.
[21:27] <\sh> there are a lot of bugs, and no one bothers to go down the road an start working on really low hanging fruit
[21:27] <\sh> in the last days, i did some other bugfixes...
[21:27]  * keescook is excited to see activity.  :)
[21:27] <Fujitsu> I did about 20 from ~motu-swat a week ago.
[21:27] <\sh> keescook, dude, I'll spam ,-)
[21:27] <keescook> cool; I need to get the list of tested debdiffs now, so I can start uploading them.
[21:28]  * Fujitsu can also do more starting later today, as there will be no more damn exams.
[21:28] <Fujitsu> keescook: Thanks.
[21:28] <Fujitsu> They should all be searchable by In Progress + patch.
[21:28] <keescook> Fujitsu: perfect!
[21:28] <\sh> ah some of themI didn't set to progress
[21:28] <\sh> but will do in a moment
[21:28] <Fujitsu> keescook: Can you please look at bug #132915, and tell me if you can decline the Dapper task? As you're core-dev, you may have more powers than I.
[21:28] <ubotu> Launchpad bug 132915 in wireshark "WireShark versions prior to 0.99.6 vulnerability" [High,In progress] https://launchpad.net/bugs/132915
[21:29] <keescook> Fujitsu: we don't have a way of marking a debdiff as "tested" though, do we?
[21:29] <Fujitsu> keescook: Not at the moment, but I believe I've tested them all.
[21:29]  * Fujitsu checks.
[21:29] <\sh> keescook, build test or exploit tests?
[21:29] <keescook> Fujitsu: I mean actual run-the-program testing (not just build-tests)?
[21:30] <keescook> Fujitsu: yup, dapper declined.
[21:30] <Fujitsu> keescook: In most cases I've tested the functionality of the program around the fix, yes.
[21:30] <Fujitsu> keescook: Thanks, that's a bug,.
[21:31] <keescook> Fujitsu: that works for me.  While it'd be great to test PoC or exploits, the critical bit is to avoid regression.  :)
[21:33] <Fujitsu> keescook: I've tested exploits which were easily findable.
[21:33] <\sh> Fujitsu, some parts I can fix I think for dapper/ethereal
[21:33] <Fujitsu> \sh: Oh, good. Are you able to find the CVEs fixed in .1-.5?
[21:34] <\sh> Fujitsu, when you read the debdiff for wireshark, there are bug reports from upstream...there are some demo code inside ,-)
[21:35] <\sh> Fujitsu, well I think I can manage, but it takes time...right now my wife comes home..so end of business today :)
[21:35] <Fujitsu> OK, talk to you tomorrow, then. Thanks for the work you've done!
[21:35] <\sh> Fujitsu, I'll work tomorrow from office...then I have time :)
[21:36] <\sh> cu good night
[21:36] <Fujitsu> Night.
[21:38] <Fujitsu> That's one nasty changelog entry in the feisty/wireshark debdiff.
[22:01] <alvinc> holy server link batman
[22:01] <DaveMorris> can someone nuke my package on revu as I'm sorting it out http://revu.tauware.de/details.py?package=opensg-dev
[22:13] <bddebian> DaveMorris: Done
[22:13] <DaveMorris> thanks
[22:46] <Jazzva> Hmm... any idea why "cp {file1,file2}.extension somewhere" works when I build from source in Debian, but it doesn't in Ubuntu? It works in Ubuntu too, if it's not run from Makefile...
[22:47] <geser> Jazzva: dash vs bash
[22:47] <Jazzva> geser: Hmm... Thanks. I'll supply a debdiff for this one, then...
[22:56] <geser> apachelogger: did you try to upload gtkmm-utils 0.3.0-0ubuntu1 to Debian?
[22:56] <apachelogger> geser: wah, I did -.-
[22:57] <apachelogger> someday I might get dput configured right
[23:00] <Jazzva> Hmm... another question. If I'm submitting a fix for package that needs to be synced, is that similar to a merge (in a way there are some Ubuntu changes, but they're not from previous versions, unlike in merge)?
[23:01] <Fujitsu> Jazzva: It would be performed identically to a merge.
[23:01] <Fujitsu> Except for the merging old changes bit; you'd just merge the new changes instead.
[23:02] <Jazzva> Ok... thanks :).
[23:02] <Fujitsu> Jazzva: Make sure you note in the sponsorship bug that that's what you've done, to avoid confusing people and to make sure they generate the .changes properly.
[23:04] <Jazzva> Fujitsu: I suppose I should change the status to match the merge request... right?
[23:08] <Fujitsu> Jazzva: Of the bug? Probably.
[23:10]  * Fujitsu blinks.
[23:11] <Fujitsu> Why is rhythmbox segfaulting in main()!?
[23:41] <Lutin> someones know who added the 'no need to sync' comment for xt on DaD ? is it you zul ?