[00:00] <Fujitsu> ScottK: Ah, that does seem a bit odd.
[00:00] <_16aR__> geser: the 2 env var are primarily used to get default config file and media data (textures, sounds, 3D models)
[00:00] <minghua> _16aR__: Is there a sane default for those two variables?
[00:00] <StevenHarperUK> Hi, does anyone know which channel I should ask for a review my translation file ? https://translations.launchpad.net/easycrypt/trunk/+imports
[00:01] <minghua> _16aR__: Maybe this software should switch to using a config file instead...
[00:01] <Fujitsu> StevenHarperUK: #launchpad is the right place, or just wait.
[00:01] <ScottK> Fujitsu: Fortunately the app is in Python, so I can pick at is and make sure I understand what it is doing.  It already checks if it's in KDE or Gnome, so adding a bit to pull in XAUTHORITY when in KDE should be easy enough.
[00:01] <StevenHarperUK> Fujitsu: I did that : thanks - ill wait now
[00:01] <Fujitsu> ScottK: Ah.
[00:02] <minghua> StevenHarperUK: No idea at all<EMAIL_ADDRESS>list is probably worth trying (if you mean the POT file).
[00:03] <Fujitsu> minghua: 'tis a task that only Rosetta administrators can perform.
[00:03] <LaserJock> and they get to it when they get to it
[00:03] <LaserJock> generally
[00:03] <_16aR__> minghua: I think that I can put every "base" media files into a /usr/share/ dire
[00:04] <_16aR__> dir **
[00:04] <minghua> StevenHarperUK: Listen to Fujitsu then. :-)
[00:04] <Fujitsu> LaserJock: They only sometimes get to it when they get to it? That sounds odd.
[00:04] <minghua> _16aR__: I probably don't know enough about the package to make more comments, then.
[00:04] <LaserJock> Fujitsu: sometimes if you bug them properly and do the right chants they might get to it quicker ;-)
[00:04] <_16aR__> minghua: since it is a Path env var, You can add your own if you need to
[00:04] <_16aR__> like
[00:05] <_16aR__> myOwnGameDire/data:otherDir:/usr/share/package/data
[00:06] <frenchy> Hi everyone, I've been told that my package generates a manpage-has-bad-whatis-entry.  When I run a `lintian *.changes` or a `lintian *.deb` against my packages then I don't get the warning.  Can someone please tell me what I'm doing wrong.
[00:07] <ScottK> frenchy: What release are you running?
[00:07] <frenchy> Gutsy.
[00:07] <ScottK> frenchy: If you don't have backports enabled, enable it and install the updated lintian from that.
[00:07] <ScottK> That would be a first step.
[00:07] <frenchy> ScottK: Thanks, I'll try that.
[00:08] <Nafallo> Geisty *giggles*
[00:09] <frenchy> ScottK: Got backports. Have lintian 1.23.36 (default gutsy is 1.23.32).
[00:10] <ScottK> Try that and see if you get the error.
[00:10] <ScottK> Gotta run.
[00:10] <frenchy> ScottK: ok, cya.  I already had it all set up when I ran it the first time.
[00:10] <frenchy> Can anyone else help please?
[00:13] <frenchy> Pretty please?
[00:14] <albert23> frenchy: does the description on top of this page help? http://lintian.debian.org/reports/Tmanpage-has-bad-whatis-entry.html
[00:17] <frenchy> albert23: Hi, well "yes" and "no".  I was told of the man page warning via REVU so I fixed the man page (or so I thought).  And uploaded again only to find out that it's still happening.  I don't want to waste peoples time checking the same warning and would like to know how I can get the warning reported so I know when it's fixed.
[00:18] <frenchy> albert23: I really thought I'd fixed it.
[00:19] <frenchy> I've got:
[00:19] <frenchy> .SH NAME
[00:19] <frenchy> Me TV \- a digital television (DVB) viewer for GNOME
[00:20] <albert23> frenchy: you could try to use manedit to edit the man page
[00:20] <frenchy> I didn't have the description before.  Which is what the manpage-has-bad-whatis-entry warning is about.
[00:20] <frenchy> albert23: Hmmm ... nice idea.
[00:20] <albert23> and maybe lintian -i -v will say more
[00:21] <frenchy> albert23: Would that error be generated from the *.changes or the *.deb?
[00:22] <albert23> I would think the deb, but I am not sure. I only had a  man problem once so far
[00:23] <geser> lintian (or linda) *.changes checks the source package and the binary debs
[00:23] <frenchy> albert23: -i -v didn't help against either.  But thanks for your help.  I'll try manedit.  I didn't know it existed.
[00:24] <frenchy> geser: Is that the changes from the source (-S) build or binary build?
[00:25] <geser> lintian *.changes checks all the mentioned files there, if you use the one with source only then only the source is checked, if you use on that has source and binary (like from pbuilder) than both are checked
[00:32] <frenchy> geser: Thanks.  I haven't using pbuilder.  I've been dpkg-buildpackaging-ing.  That'll change now.
[00:32] <frenchy> *I haven't been using pbuilder
[00:33] <zul> evening
[00:33] <LaserJock> hi zul
[00:33] <zul> hey LaserJock how goes it?
[00:34] <LaserJock> oh alright I guess
[00:35] <LaserJock> trying to figure out what to do with this case
[00:35] <LaserJock> I've  got 4 cases and a number of parts
[00:36] <LaserJock> the toughest part seems to be that the motherboards never seem to work with the front connections on the cases
[00:44] <Nafallo> LaserJock: rack mountable?
[00:45] <LaserJock> hahaha ... no
[00:45] <LaserJock> at least I wouldn't think
[00:45] <Nafallo> :-P
[00:45] <LaserJock> and I don't have a rack to try/use
[00:46] <Nafallo> would be easy to see on them :-)
[00:46] <Nafallo> sounds like desktops ;-)
[00:47] <LaserJock> yes
[00:47] <LaserJock> I've never had a rack
[00:47] <LaserJock> I don't think I've ever seen one either
[00:47] <RainCT> good night.  (btw, if a core dev is arround please consider sponsoring bug #175000 :P)
[00:47] <ubotu> Launchpad bug 175000 in desktop-file-utils "Bash completion for desktop-file-validate" [Wishlist,Triaged] https://launchpad.net/bugs/175000
[00:48] <LaserJock> but I know the general idea of what it should look like I think
[00:49] <Nafallo> LaserJock: http://www.sentralsystems.com/offers.html
[00:49] <Nafallo> that's about it :-)
[00:50] <Nafallo> http://www.sentralsystems.com/ispserv.html
[00:50] <Nafallo> that might even be better :-)
[00:50] <LaserJock> hmm, yeah
[00:50] <LaserJock> are they like standard ATX or micro-ATX motherboards or do they have to be special?
[00:50] <Nafallo> the bluearc is also rackmounted.
[00:51] <Nafallo> http://www.bluearc.com/products/titan.shtml
[00:51] <Nafallo> depends on the chassi.
[00:51] <blueyed> icedtea is not installable in hardy currently, is it?
[00:51] <Nafallo> sentral has some half depths, which takes micro I think :-)
[00:52] <LaserJock> ok, so what is all the 1U, 2U ,etc.?
[00:53] <Fujitsu> LaserJock: That's the height of the device.
[00:53] <Nafallo> U = unit.
[00:53] <Fujitsu> Most full-size racks are 47U.
[00:53] <Nafallo> 1U = three rackscrews :-)
[00:53] <Nafallo> Fujitsu: most are 43U mate :-)
[00:53] <Fujitsu> Blah, same thing.
[00:54] <Nafallo> Fujitsu: that's why Juniper T640 is half rack. 21U ;-)
[00:54] <Fujitsu> Ah, right.
[00:55] <Nafallo> insanely kewl monster that one :-)
[00:55] <Nafallo> and scales well.
[00:55] <Fujitsu> One would hope.
[00:56] <LaserJock> were do you get a rack?
[00:56] <LaserJock> do they just sell those in stores?
[00:57] <ScottK> LaserJock: You've got lasers.  Make one.
[00:57] <ScottK> ;-)
[00:58] <Nafallo> hehe
[00:58] <Fujitsu> I think you can get them cheaply from PONIES PONIES PONIES.
[00:58] <Fujitsu> Ahem.
[00:58] <Nafallo> minitran.co.uk for example.
[00:58] <Nafallo> prism...
[00:58] <Nafallo> etc.
[00:58] <LaserJock> ScottK: I suppose I could have the machinist make me one
[00:59] <Nafallo> APC
[00:59] <ScottK> That or head over to the computer science department and steal one.
[00:59] <LaserJock> hmmm, that sounds fun
[00:59] <LaserJock> I'm not really sure where CS is
[01:01] <LaserJock> I should convince my boss that we need a rack
[01:02] <Fujitsu> Biggles! Bring in the rack!
[01:02] <ScottK> Stealing sounds more fun.
[01:02] <Nafallo> we have a rack in the office :-)
[01:02] <Fujitsu> Nafallo: That's not particularly surprising.
[01:03] <Nafallo> and... 18(?) in our suite? :-)
[01:03] <LaserJock> we just have desktops stacked wherever we can get some space
[01:03] <Nafallo> so that's 19.
[01:03] <LaserJock> same thing with the clusters
[01:03] <Nafallo> and then we colo some in THN.
[01:03] <Nafallo> so 20 racks ;-)
[01:04] <LaserJock> Nafallo: mostly full?
[01:04] <Nafallo> mostly full
[01:04] <Nafallo> we need more racks :-P
[01:05] <Nafallo> well, I'm tasked to design them :-)
[01:05] <Nafallo> will need to be remotly bootable and have nice cabling this time around ;-)
[01:05] <Nafallo> +e
[01:09] <StevenK> LaserJock: Ponies!
[01:10] <StevenK> dh_shlibdeps -a --dpkg-shlibdeps-params=--ignore-missing-info
[01:10] <StevenK> Hrrrm. Which now dies a horrid death.
[01:11] <StevenK> Hurray, and a C++ strictness failure for another package.
[01:12] <bddebian> Heya gang
[01:12] <LaserJock> bddebian!
[01:12]  * StevenK waves to bddebian and to the PONY that just appeared.
[01:13] <bddebian> Heh, heya LaserJock, StevenK
[01:15]  * StevenK idly wonders about lunch.
[01:16]  * StevenK chuckles
[01:17]  * GoldenPony tries to chuckle, but fails due to anatomical differences.
[01:17] <StevenK> Settle for a comical neigh?
[01:17] <GoldenPony> Nay, just a normal neigh.
[01:22]  * StevenK throws nine uploads at Soyuz and yells "Catch!"
[01:23] <bddebian> heh
[01:24] <ScottK> Which is nice of StevenK, since soyuz likes to eat uploads for lunch.
[01:25] <StevenK> Yeah, well
[01:28] <Fujitsu> ScottK: It needs feeding, so what do you expect?
[01:29]  * ScottK wasn't complaining, just complimenting StevenK on his generousity.
[01:31]  * LaserJock wonders if Soyuz like Scoobie Snacks
[01:31] <Fujitsu> !soyuzsnack
[01:31] <ubotu> Sorry, I don't know anything about soyuzsnack - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[01:31] <Fujitsu> Aw...
[01:31] <bulio> I'm just wondering, can I find a guide on how to create a ubuntu package?
[01:31] <ScottK> !packagingguide | bulio
[01:31] <ubotu> bulio: packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[01:31] <StevenK> Maybe we need to add a Soyuz Snack factoid that it's whatever was most recently uploaded?
[01:32] <Fujitsu> StevenK: Haha.
[01:32] <Fujitsu> `Mmm, thanks $UPLOADER.'
[01:32] <StevenK> Haha
[01:35] <limac> How can i fix bugs?
[01:35] <limac> dumb question but
[01:36] <bulio> jeez, making a package seems tough :S
[01:36] <limac> I read the tutorial on howto fix bugs and there they are saying that we have to collect the sources. where are we going to get the sources from?
[01:36] <DarkMageZ> bulio, it gets easier as you get to understand it
[01:37] <bulio> which is the easiest way to make a firefox package
[01:37] <Fujitsu> We have a Firefox package already.
[01:37] <bulio> I know, its a firefox 3 beta2 package I want to make
[01:38] <Fujitsu> We have beta1.
[01:38] <Ubulette> ..and firefox is not really the easiest package to learn packaging
[01:38] <Fujitsu> And beta2 should be in the package soon enough.
[01:38] <Fujitsu> +1 Ubulette
[01:38] <Ubulette> :)
[01:39] <DarkMageZ> :( @ requiring hardy for Ubulette's firefox packages
[01:39] <LaserJock> limac: you need to have the source repos enabled and then you can run apt-get source <package> to get the source
[01:39] <Ubulette> DarkMageZ, i did gutsy too.
[01:39] <limac> ok thx I'll try and let u no. :)
[01:39] <DarkMageZ> oh. link me again ッ
[01:39] <limac> LaserJock
[01:40] <Ubulette> https://edge.launchpad.net/~fta/+packages
[01:40]  * Fujitsu is allergic to anything with FTA in it.
[01:41] <LaserJock> Fujitsu: ?
[01:41] <Ubulette> Fujitsu, why ?
[01:41] <StevenK> Therefore, you're allergic to Launchpad. It makes you break out in complaining.
[01:42] <Fujitsu> Free Trade Agreement.
[01:42] <StevenK> Ahh.
[01:43] <StevenK> Did we end up signing that?
[01:43] <Fujitsu> We did.
[01:43] <Fujitsu> Quite some time ago.
[01:43] <StevenK> It remains to be seen how Rudd treats Bush
[01:43] <Fujitsu> Yes.
[01:43] <Fujitsu> I will be most interested.
[01:43] <Fujitsu> Good to see Kyoto done, though.
[01:44] <limac> allright, they are then saying to create a backup directory, how is that done???
[01:47] <LaserJock> limac: what are you reading?
[01:47] <LaserJock> and I would think you could just make a directory somewhere convenient
[01:47] <limac> actually nm i got the answer
[01:47] <limac> but after i do that how can i get access to the sources code?
[01:48] <limac> source code
[01:48] <LaserJock> did you get the source package?
[01:48] <limac> yup
[01:48]  * GoldenPony makes pony noises.
[01:49] <limac> actually hold on, what do u mean by "getting the sources package"?
[01:49] <Ubulette> apt-get source something
[01:50] <limac> I so far ran these two cammands: apt -get <package> and cp -a <dir>
[01:50] <frenchy> I have a warning from pbuilder build "dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}".  Can I simply remove it safely?  I don't know where it's come from and has probably been in there from the start.
[01:50] <ScottK> frenchy: Ignore the warning.
[01:51] <frenchy> ScottK: Leave it in there?
[01:51] <ScottK> Yes.
[01:52] <ScottK> dpkg-gencontrol is behind the times.
[01:52] <LaserJock> limac: you want to do apt-get source <package>
[01:52] <frenchy> ScottK: Ok, sorry to ask the obviuos.
[01:52] <ScottK> Actually I've no idea if you need it or not, but the dpkg-gencontrol warning is irrelevant.
[01:52] <ScottK> frenchy: No problem.
[01:52] <limac> LaserJock, I did that.
[01:52] <StevenK> What it's warning is that misc:Depends expands to nothing
[01:53] <LaserJock> limac: ok, then the source should be in the directory you were in when you ran that
[01:53] <limac> Laserjack, but where???
[01:53] <frenchy> StevenK: Yeah, I figured that so I thought that I could remove it.
[01:53] <LaserJock> StevenK: really? I thought it always gave that
[01:53] <LaserJock> limac: in the directory that you were in where you issued that command
[01:53] <StevenK> LaserJock: It will only complain about it if it's empty.
[01:53] <LaserJock> StevenK: cool, that's good to know
[01:54] <StevenK> LaserJock: debconf will, for example, put itself into misc:Depends
[01:55] <limac> usually what extensions does it have or how can i figure out which one it is, there are so many things in it!
[01:55] <ScottK> Fujitsu: Are you planning on looking at the python-numpy merge/sync?
[01:55] <LaserJock> StevenK: yes, I know why it's there, I just didn't know that it threw that warning when it was empty
[01:55] <LaserJock> limac: what was the package that you did?
[01:55] <limac> kdeutils
[01:55] <StevenK> LaserJock: Because it's specified in the control file, and it isn't listed in debian/substvars
[01:55] <Ubulette> strange, all 9 ppa builders are idle. I've pushed something 3h ago, it's not even in queue.
[01:56] <Fujitsu> ScottK: I haven't heard anything more from Ondrej. I'll talk to him when I see him online again.
[01:56] <LaserJock> limac: ok, then there should be a .dsc file, a .diff.gz file and a .orig.tar.gz file
[01:56] <LaserJock> limac: that's the source package
[01:56] <limac> hold on let me see
[01:56] <ScottK> Fujitsu: I was more thinking along the lines of I touched it last, but really would rather not worry about it, so I want to make sure you will...
[01:56] <Fujitsu> Ubulette: I wouldn't quite call that strange. It's normal, albeit broken, Soyuz behaviour.
[01:56] <LaserJock> limac: and you should see a new directory starting with kdeutils that is the unpacked source
[01:57] <Fujitsu> Ubulette: Which package?
[01:57] <Ubulette> xulrunner-1.9_1.9~b2~cvs20071207t1611+nobinonly-0ubuntu1~fta1
[01:58] <LaserJock> uggg, what a version
[01:58] <Ubulette> :)
[01:58] <Fujitsu> Ubulette: I can't see that in your PPA.
[01:58] <Ubulette> i know
[01:58] <Ubulette> that's why i said it's strange
[01:58]  * minghua wonders if there is a fixed buffer size for version number...
[01:59] <Fujitsu> Ubulette: Did you get an acceptance email?
[01:59] <Ubulette> no reject, no accept, nothing
[01:59] <limac> LaserJosk: did u get that, that's what the dir holds
[01:59] <Fujitsu> Ubulette: Ah, upload again. You probably didn't sign it properly.
[01:59] <Fujitsu> LaserJock: I find 2:0.99+1.0pre7try2+cvs20060117-0ubuntu8.1 fairly fowl (Dapper's mplayer)
[02:00] <blueyed> minghua: aptitude uses 10 chars by default to display versions.. ;)
[02:00] <Fujitsu> s/fowl/foul/
[02:00] <Ubulette> Fujitsu, hmm, i'm sure i did
[02:00] <Ubulette> it's not my 1st up either ;)
[02:00] <Fujitsu> Ubulette: Alternatively, you may have used an incorrect email format in the .changes, or a multitude of undocumented ways to get silent rejections.
[02:00] <Ubulette> arh
[02:01] <LaserJock> limac: I didn't, you can pastebin it if you want
[02:01] <LaserJock> !pastebin > limac
[02:01] <Ubulette> gasp, i pushed to revu instead of ppa :P
[02:01] <minghua> blueyed: Only when it's sent to 80-column terminals.
[02:01] <Fujitsu> Ubulette: Haha.
[02:01] <Ubulette> how do I nuke that on revu ?
[02:01] <limac> LaserJock: How can i paste bin it?
[02:02] <Fujitsu> Ubulette: You can't. Only one of the four REVU gods can do it.
[02:02] <LaserJock> !pastebin
[02:02] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[02:02] <LaserJock> limac: ^^
[02:02] <blueyed> minghua: no, see http://people.debian.org/~dburrows/aptitude-doc/en/ch02s04s01.html
[02:03] <Ubulette> please, REVU Gods, kill xulrunner-1.9 (and archive prism)
[02:03] <limac> LaserJock: how can I attach  a picture to it?
[02:03] <minghua> blueyed: Right.  I was thinking of dpkg.
[02:04] <blueyed> Any lib transition experts around? Is the changed desc for bug 78309 correct?
[02:04] <ubotu> Launchpad bug 78309 in giflib "libungif to giflib transition" [Medium,Triaged] https://launchpad.net/bugs/78309
[02:04] <LaserJock> limac: don't, just copy and paste what you get in a terminal
[02:05] <limac> huh?
[02:05] <limac> LaserJock:huh?
[02:06] <LaserJock> limac: just copy and paste the text you get when you look at the directory contents in a terminal, i.e. ls
[02:06] <limac> LaserJock:gotcha
[02:06] <limac> LaserJock:Didn't really think of it that way!
[02:08] <limac> LaserJock:after pasting what shoul i do to send it to you?
[02:10] <minghua> blueyed: Unless libgif4 and libungif4g are ABI compatible, the description in bug 78309 is completely wrong.
[02:10] <ubotu> Launchpad bug 78309 in giflib "libungif to giflib transition" [Medium,Triaged] https://launchpad.net/bugs/78309
[02:10] <blueyed> minghua: my guess is, that they are compatible, but I don't know.
[02:11] <minghua> blueyed: ... ABI compatible, and that libgif4 provides a /usr/lib/libungif.4.so symlink, that is.
[02:12] <blueyed> minghua: both ship /usr/lib/libgif.so.4.1.4
[02:12] <minghua> blueyed: Then I suggest not using words like "A quick fix for this appears to be ..." in the description.
[02:14] <minghua> blueyed: "The libungif library is a specially modified version of giflib which is free of the Unisys LZW patent. It can read all GIFs, but only write uncompressed GIFs. If you need to be able to write compressed GIFs, you can install the giflib packages instead."
[02:14] <minghua> blueyed: Doesn't sound ABI compatible to me.
[02:15] <blueyed> minghua: sounds like libgif adds more functionality/symbols "only".
[02:16] <blueyed> I guess anything that builds against libungif builds also against giflib, don't you think?
[02:16] <minghua> blueyed: Maybe, maybe not.
[02:17] <minghua> blueyed: Guessing doesn't help, you need to first compare the symbols, then read a bit more about the code to be sure.
[02:18] <LaserJock> limac: sorry, just give me the URL here
[02:18] <limac> LaserJock:sure hold on a sec
[02:18] <Ubulette> is there a way to speed up sponsorship of seamonkey ? or are the security fixes in hardy not important ?
[02:19] <minghua> I think security fixes in hardy is not important.
[02:20] <limac> LaserJock: http://paste.ubuntu-nl.org/47486/
[02:21] <LaserJock> limac: yep, that's the source
[02:21] <Ubulette> for me, security always matter but i'm biased, i'm running what I build
[02:21] <limac> LaserJock: WHich one?
[02:21] <LaserJock> limac: all of it
[02:22] <Fujitsu> minghua: I treat security fixes in Hardy as just as important as the rest, and they're normally quicker.
[02:22] <limac> LaserJock: so how do i edit it(fix it)
[02:22] <Fujitsu> s/the rest/other releases/
[02:22] <LaserJock> limac: the packaging bits (the part that is for creating an Ubuntu package) are in the debian/ directory
[02:23] <LaserJock> limac: well, you gotta figure out what's wrong, and then fix it :-)
[02:24] <minghua> Fujitsu: Sure.  I'm just saying *I* don't expect hardy to have very in-time security updates.  If there indeed are, it's good. :-)
[02:24] <Fujitsu> minghua: Hardy will be more up-to-date security-wise than any other release.
[02:24] <limac> LaserJock: so this is where my skills come in handy! :P
[02:24] <limac> :)
[02:24] <LaserJock> yep
[02:24] <Ubulette> bug 174739
[02:24] <ubotu> Launchpad bug 174739 in seamonkey "[upgrade] seamonkey 1.1.7" [Undecided,Confirmed] https://launchpad.net/bugs/174739
[02:25] <limac> thnx dude, thx a lot for all the help
[02:25] <LaserJock> limac: no problem
[02:25] <Ubulette> i already have asac's approval
[02:25] <Fujitsu> Urgh, Mozilla.
[02:26] <limac> LaserJock: I'll ask u if i have any further problems. Hope that's ok with u! :)
[02:26] <Ubulette> Fujitsu, yep, i like that
[02:27] <minghua> Fujitsu: Good to know.  And thank you for that.  (Although I don't use hardy...)
[02:27] <LaserJock> limac: if I'm around no problem
[02:27] <LaserJock> otherwise feel free to ask the channel in general
[02:27] <limac> LaserJock: thx again
[02:27] <limac> see ya around then
[02:28] <bulio> is there another channel I can hang out in to learn about creating and maintaining a repository?
[02:28] <DarkMageZ> bulio, use the personal package archives?
[02:28] <bulio> DarkMageZ, I have no idea how to upload source on to them
[02:29] <bulio> I signed as a ubuntero, and created a PGP key
[02:35] <LaserJock> bulio: there is a QuickStartGuid on the launchpad wiki
[02:36] <LaserJock> bulio: https://help.launchpad.net/PPAQuickStart
[02:50] <bulio> I'm confused
[02:50] <LaserJock> bulio: about what?
[02:50] <bulio> I have thew latest AWN source code
[02:50] <bulio> now what do I do with it to get the PPA to build it?
[02:50] <bulio> PPA says something about dput
[02:50] <bulio> but source.changes, not the actual source code
[02:52] <LaserJock> yep
[02:52] <LaserJock> you might want to read over the packaging guide a bit
[02:52] <LaserJock> a _source.changes file holds the md5sums of the source package components
[02:52] <bulio> so how do I create that?
[02:52] <LaserJock> and so when you give it to dput it knows what to upload
[02:53] <LaserJock> bulio: the easiest way is to create a source package and run debuild -S
[02:54] <bulio> whats the command to create a source package
[02:54] <LaserJock> well, debuild -S
[02:55] <LaserJock> bulio: do you have a source package already or do you just have a tarball of the source code?
[02:55] <bulio> source code from bazaar checkout
[02:55] <LaserJock> does it have a debian/ directory?
[02:57] <bulio> nope
[02:57] <bulio> wait, yes it does
[02:58] <Jazzva> Hmm, Ubuntu can't use .menu files for menu entries, right?
[02:58] <LaserJock> Jazzva: well, kinda
[02:58] <LaserJock> not by default
[02:59] <LaserJock> but you can install a package that gives you the Debian menu
[02:59] <LaserJock> bulio: ok, then try running debuild -S in the source directory
[03:00] <Jazzva> LaserJock: But that's not by default :). I installed gtwitter and noticed it doesn't provide a desktop file, but it does provide a .menu file. I suppose it's can be confusing to a typical user...
[03:01] <LaserJock> Jazzva: there are a great many packages like that
[03:02] <Jazzva> LaserJock: That's not good, right :)?
[03:02] <LaserJock> Jazzva: I'm not sure what the current "policy" is, but if there are already Ubuntu changes you might add a .desktop
[03:03] <minghua> Jazzva: It's not default in Debian either.
[03:03] <Jazzva> Nope, there are none so far :/...
[03:03] <Jazzva> So, should I file a bug in LP and attach a desktop file?
[03:04] <LaserJock> Jazzva: you might file a bug in Debian actually
[03:04] <LaserJock> and see if they will add it there
[03:04] <Jazzva> LaserJock: Ok... I'll do that.
[03:04] <Jazzva> Thanks for the help :)
[03:04] <bulio> LaserJock, I'm getting an error
[03:04] <bulio> running debuild -S inside avant-window-navigator source dir
[03:05] <bulio> make: *** No rule to make target `/usr/share/cdbs/1/rules/simple-patchsys.mk'.  Stop.
[03:05] <bulio> debuild: fatal error at line 1247:
[03:05] <LaserJock> bulio: ok, you need to install cdbs
[03:06] <bulio> debuild: fatal error at line 1174:
[03:06] <bulio> running debsign failed
[03:06] <LaserJock> right
[03:06] <LaserJock> because the you aren't the person in the changelog :-)
[03:06] <LaserJock> to get around it for the moment you can debuild -S -us -uc
[03:07] <LaserJock> but once you add a changelog entry (i.e. before you upload) in debian/changelog then drop those to sign the package
[03:07] <bulio> oh, so I need to edit the changelog?
[03:08] <LaserJock> well, if you want to upload yes
[03:08] <LaserJock> you'll want to have a proper version, perhaps set yourself as maintainer of your package, etc.
[03:09] <ScottK> persia: Are you able to take another look at disk-manager?  I think it's all fixed up now (and looking for 2nd advocate). http://revu.tauware.de/details.py?package=disk-manager
[03:09] <hudyx> hi sll
[03:09] <hudyx> all
[03:10] <Hobbsee> ScottK: nice mails
[03:11] <bulio> LaserJock, how do I create a proper version then?
[03:11] <ScottK> Hobbsee: Thanks.
[03:12] <hudyx> I'm trying to install Ubuntu for the first time, but I can't even get my new Vista machine to boot from the LiveCD
[03:12]  * ScottK just got Scotch in prepartion for replying to geser's latest.
[03:12] <ScottK> hudyx: The channel for support is #ubuntu.
[03:12] <StevenK> ScottK: On -motu?
[03:12] <ScottK> StevenK: motu-council.
[03:12] <LaserJock> bulio: well, for PPAs you want something that isn't going to conflict with something that's already in the archives or will be in the future
[03:13] <LaserJock> bulio: generally it's good to include something like ~ppaX where X is 1,2,3... for each upload you do
[03:14] <bulio> LaserJock, can we go through this step by step?
[03:14] <bulio> btw, I appreciate all the help
[03:15] <bulio> Ok, so I have an AWN dir, now what do I do so that I can have a proper version
[03:15] <bulio> in which I am pkg maintainer
[03:16] <LaserJock> bulio: run dch -i
[03:16] <LaserJock> that will help you edit the changelog
[03:17] <bulio> ok, done that
[03:18] <LaserJock> so make sure to set the name and email address to the exact same as in your gpg key
[03:18] <bulio> done
[03:19] <LaserJock> what version do you have in the first line
[03:19] <bulio> of what
[03:19] <LaserJock> of the changelog
[03:19] <bulio> avant-window-navigator-trunk (0.2.1+bzr-1ubuntu1) gutsy; urgency=low
[03:21] <LaserJock> hmm
[03:21] <LaserJock> that's kind of a funky package name with -trunk
[03:21] <LaserJock> bulio: can you pastebin the entire changelog for me?
[03:21] <LaserJock> ScottK, Hobbsee: just sent a reply
[03:22] <ScottK> LaserJock: Thanks.  Me too.
[03:23] <bulio> LaserJock, http://rafb.net/p/EVOolK64.html
[03:23] <LaserJock> bulio: that's the whole thing?
[03:24] <ScottK> LaserJock: Thanks.  I'll have a reply for that in a moment.
[03:24] <Hobbsee> LaserJock: you got moderated, i take it?
[03:24] <Hobbsee> ScottK: ++
[03:24] <LaserJock> Hobbsee: shouldn't
[03:24] <limac> LaserJock: Sorry for the interruption but I am just curious: what languages do u prefer knowing in order to help resolve bugs?
[03:24] <bulio> LaserJock, yeah
[03:25] <LaserJock> limac: knowing anything is great
[03:25] <LaserJock> limac: generally bash, python, and C/C++ are great
[03:25] <limac> LaserJock: What if we don't konw anything (I'm am on the verge of learning c++)
[03:26] <ScottK> Hobbsee: His went out.
[03:26] <Hobbsee> ah, it just came late
[03:26] <LaserJock> limac: then you might want to focus on packaging bugs or things that don't require fixing the actual code
[03:26] <LaserJock> limac: I'm on the verge of learning C++ too ;-)
[03:27] <limac> LaserJock: I guess i'll just learn the languages first, packaging bugs is boring. But fixing the code is challenging and fun!
[03:28] <limac> :)
[03:28] <limac> LaserJock:Thnx again and see ya around later. ;0
[03:31] <LaserJock> ScottK: I'm really not sure if anything can actually be enforced
[03:31] <Ubulette> oh, a langpack flood in ppa :P
[03:31] <Ubulette> i'm going to bed. that will take a day
[03:32] <Ubulette> cu
[03:34] <nenolod> who should i ask for a rebuild to be triggered on xmms-crossfade?
[03:34] <nenolod> or should i wait for the sync to pull in xmms-crossfade 0.3.14-1 instead? :)
[03:35] <Hobbsee> Source version: 0.3.14-1 is in hardy already
[03:36]  * Hobbsee retries
[03:41]  * ScottK goes and does merges.
[03:46] <LordKow> hm i wonder why the new pulseaudio is using policykit when there is no policy for it
[03:47] <LordKow> and why is it trying to run w/ realtime priority? hmm.
[03:47] <LordKow> pulseaudio[6616]: main.c: Called SUID root and real-time/high-priority scheduling was requested in the configuration. However, we lack the necessary priviliges: main.c: We are not in group 'pulse-rt' and PolicyKit refuse to grant us priviliges. Dropping SUID again.
[03:48] <LordKow> weird, i ran pulseaudio --dump-config and according to the configuration pulseaudio should not be trying to run realtime
[03:49] <LordKow> oh yay and now its segfaulting. time to downgrade back to 0.9.7
[03:49] <StevenK> dns.cpp:817: error: 'void* libfwbuilder::DNS_bulkBackResolve_Thread(void*)' should have been declared inside 'libfwbuilder'
[03:50] <StevenK> What does that error actually mean?
[03:51] <persia> StevenK: It means you've called a function in a namespace different than that it was declared.
[03:51] <persia> (in which)
[03:52] <ScottK> persia: Are you going to be able to review
[03:52] <StevenK> persia: But :817 is a function declaration
[03:52] <persia> ScottK: Yes.  dget just finished.
[03:52] <persia> StevenK: Right, but it is not in the right namespace: you7re declaring a foreign function, which you oughtn't do.
[03:52] <StevenK> It seems 2.1.14 has fixes for gcc 4.2 and 4.3
[03:52] <LordKow> you have to declare the function in the proper namespace
[03:52] <ScottK> persia: Great.  I'm not 100% satisfied with how lintian reacted to the .desktop, but it validated...
[03:53] <persia> ScottK: If lintian and desktop-file-validate don't agree, there's a bug somewhere.
[03:53] <ScottK> persia: My changes for Kubuntu integration have only been tested on Kubuntu, so it'd be good to make sure I didn't break Gnome in the process.
[03:53] <StevenK> So I think I might update libfwbuilder and fwbuilder since we've jumped
[03:53] <StevenK> persia: Sound like a plan?
[03:53]  * ScottK bows in the direction of the great persia to provide clarity on the .desktop confusion.
[03:54] <persia> StevenK: I generally believe upstream is likely to do the right thing :)
[03:54]  * StevenK waits for SourceForget
[03:56] <Jazzva> When submitting a patch to Debian BTS should I skip the new changelog entry?
[03:57] <persia> Jazzva: Yes.
[03:57] <Jazzva> thanks
[03:57] <persia> Jazzva: Even more so, if the package contains a patch system, consider just submitting the patch from debian/patches, rather than a debdiff.
[03:58]  * StevenK sighs.
[03:58] <StevenK> *Fracking* DBS
[03:58] <Jazzva> nope, it doesn't... I'll submit the debdiff... It's small :).
[04:01] <persia> ScottK: The .desktop file in the binary looks nothing like the .desktop file in debian/.  debian/disk-manager.desktop should be dropped, and ./data/disk-manager.desktop.in.in updated to have the desired information.  As-is, the binary .desktop doesn't validate, won't appear in the menu, and has a duplicated key.
[04:01] <ScottK> Ah ha.
[04:01] <ScottK> Thanks.  I totally missed there was un upstream .desktop.
[04:02] <ScottK> persia: I'll work on that and upload again.
[04:02] <persia> ScottK: The most critical issue is really the lack of a Main Category, telling the menu system which is the correct sub-menu in which to display the entry.
[04:03] <ScottK> OK.  Time for me to learn about .desktop files.
[04:04] <persia> ScottK: Also, please add a menu file so the package is useful for fluxbox users.
[04:05] <ScottK> persia: Any chance you'd help me with that.  I've never made one before.
[04:06] <persia> The menu file?  Sure.  What kind of help do you want?  Pointers to docs?  A sample?  One I wrote?
[04:06] <LaserJock> a sample and what category to use is usually enough it think isn't it?
[04:06] <LaserJock> they're pretty easy
[04:06] <ScottK> persia: I'll start the bidding at do it for me.
[04:06] <LaserJock> lol
[04:07] <persia> ScottK: OK.  Price for that is 3 REVU or UUS reviews.
[04:07] <bddebian> heh
[04:08] <ScottK> persia: How about 1 merge, 1 sync request, and one review?
[04:09] <persia> ScottK: If one of the merges or sync requests is lintian.
[04:10] <ScottK> persia: OK.  As long as it still counts if I give it a good honest try and can't do it.
[04:10] <persia> ScottK: Fair enough.
[04:11] <persia> ScottK: http://paste.ubuntu.com/2571/
[04:12] <ScottK> persia: And then that goes in as debian/disk-manager.menu?
[04:13] <persia> ScottK: Given your packaging, I'd just call it debian/menu
[04:13] <persia> CDBS should stick it in the right place (/usr/share/menu)
[04:13] <ScottK> persia: OK.  THanks
[04:14] <persia> ScottK: Also, Please don't install with both debian/docs and dh_installchangelogs.  One is sufficient.  Drop ChangeLog from docs, and s/NEWS/ChangeLog/ in rules.
[04:16] <ScottK> persia: OK.  I'll look into it.
[04:17] <StevenK> Right. ChangeLog isn't documentation
[04:17] <ScottK> RIght, well I turned the knob I had handy.
[04:17] <persia> ScottK Understood.  That's the point of peer review :)
[04:18] <ScottK2> Of course
[04:18] <persia> pochu: Feel free to snipe the wxwidgets update: it's not moving very quickly.
[04:19] <LaserJock> soo.... how are SRUs getting processed these day?
[04:20] <persia> LaserJock: Well, you could follow the old rules, but those are deprecated.  The new rules don't work until we have at least one appointee for ~motu-sru.  If it's important, do it the old way (upload to -proposed with a TEST CASE in the bug)
[04:20] <ScottK> LaserJock: The same old way I'd say.
[04:24] <LucidFox> Should new packages now have Standards-Version: 3.7.3?
[04:24] <persia> LucidFox: If they comply with 3.7.3, sure.
[04:24] <LaserJock> I've never quite been happy with that
[04:25] <LaserJock> people just seem to trivially set Standards-Version
[04:25] <persia> LaserJock: Err.  Which "that"?
[04:25] <LaserJock> but it's kinda difficult to determine if you're in compliance
[04:25] <LaserJock> persia: I guess how we set Standards-Version
[04:25] <LaserJock> it would be good if there was a script that could check
[04:25] <LaserJock> at least most of the stuff
[04:26] <persia> LaserJock: Why?  Read the policy, set the appropriate version.  Ideally, push to the newer version and fix stuff.  3.7.2 -> 3.7.3 is mostly about the new menu stuff, and some bugfixes.
[04:26] <ScottK> LaserJock: That's what linitian is supposed to do.
[04:26] <persia> LaserJock: linda and lintian are designed for that.
[04:27] <LaserJock> ah, well that is nice
[04:27] <LaserJock> in the past I've dredged through the debian-policy changelog
[04:27] <ScottK> LaserJock: I suspect that's why persia wants me to merge lintian
[04:27] <LaserJock> and it's not exactly fun if you aren't the maintainer
[04:28] <ember> Is there any policy to follow about adding LP integration to a packge?
[04:28] <ember> *package.
[04:28] <LaserJock> ScottK: are you a core dev?
[04:28] <LaserJock> ember: what do you mean LP integration?
[04:28] <ScottK> LaserJock: No.
[04:29] <ScottK> So at best I'll have something that needs to be sponsored.
[04:29] <persia> ScottK: You're suspicion is correct.  Getting a sponsor oughtn't be hard.
[04:29] <LaserJock> ScottK: I can sponsor it if you like, if I'm around
[04:29] <LaserJock> I've done a lintian patch and merge before so I don't mind doing it
[04:30] <ScottK> LaserJock: That'd be great.  I've never touched it before, so ...
[04:30] <persia> Hmmm..  Maybe it's not a sync.  Be nice to have an Ubuntu-equivalent check for Debian 356051
[04:30] <ubotu> Debian bug 356051 in lintian "lintian: Add a warning if the Initial Release of a package does not have an ITP." [Wishlist,Fixed] http://bugs.debian.org/356051
[04:31] <ember> LaserJock: launchpad-integration
[04:32] <LaserJock> ember: I don't know if this is the place to ask about that unfortunately, I don't think we use it in Universe
[04:32] <LaserJock> persia: last time I looked there was a lot of Ubuntu stuff left in lintian
[04:33] <Nafallo> I use it in gajim ;-)
[04:33] <persia> LaserJock: Then you haven't looked at the changelog for 1.23.39 :)
[04:34]  * ScottK is seriously hoping for a sync.
[04:34] <ScottK> (Having looked at the changelog)
[04:34] <LaserJock> persia: oh, that is nice indeed
[04:35] <LaserJock> wow, something I did actually made it into Debian :-)
[04:35] <nenolod> Hobbsee, hmm. strangeness. on my package maintainance report in launchpad it reports 0.3.13-1 and build failures due to missing depends :D
[04:35] <nenolod> LaserJock, congrats (!)
[04:36] <ScottK> Heya stratus.  Persia found some stuff that I'd missed, so I'm working on disk-menu some more.
[04:36] <StevenK> Geeez
[04:36]  * StevenK comes back from rushing the car under cover
[04:36] <StevenK> It's just starting hailing heavily here
[04:37] <Hobbsee> nenolod: it does.  but, it won't autosync from debian, if tha'ts the latest version in debian
[04:37] <StevenK> Hailstones as big as marbles :-/
[04:37] <nenolod> Hobbsee, 0.3.14-1 is the latest in debian. :P
[04:38] <nenolod> ah.
[04:38] <nenolod> now it's reporting 0.3.14-1. wtf :D
[04:38]  * nenolod wonders if launchpad is on craq
[04:39] <LaserJock> hmm
[04:39] <LaserJock> "Remove the unused Standards-Version header" what does that mean?
[04:39] <persia> LaserJock: Standards-Version is not required in .changes (I think)
[04:40] <LaserJock> ah
[04:41] <stratus> ScottK: about the current or last upload?
[04:41] <ScottK> The current.
[04:41] <stratus> ScottK: btw, hey ;)
[04:42] <ScottK> stratus: Would you mind getting the latest package from revu and then taking a stab at it.
[04:42] <ScottK> Hey.
[04:44] <stratus> ScottK: let me see...
[04:46] <ScottK> stratus: I added persia's comments to the revu page.  The last be about putting ChangeLog in docs was my mistake.
[04:46] <stratus> ScottK: oh ok, got lost on that bit.
[04:47] <ScottK> Well that was my attempt to fix it and it appears it didn't work so well.
[04:47] <stratus> ScottK: Let me prepare a build setup on this hardy, so I won't screw up on these minor bits anymore. :)
[04:47] <ScottK> Over to you ...
[04:47] <ScottK> OK
[04:47] <ScottK> stratus: He also asked to have a menu file added for fluxbox users and created it http://paste.ubuntu.com/2571/
[04:48]  * persia notes that menu files are also appreciated if the package will be submitted to Debian
[04:48] <stratus> ScottK: cool, I'll push it in
[04:49] <stratus> persia: sure, but I was going to diverge on that, let it be -1 and wait for a sync. I can upload to Debian, btw but not here in US.
[04:49] <persia> stratus: Makes sense.  It's certainly more critical for Debian :)
[04:50] <stratus> persia: absolutely
[04:50] <StevenK> Ooof
[04:50] <StevenK> I think the hailstorm has moved on
[04:50] <stratus> thanks anyway, if we've it let's put it there now.
[04:51] <Hobbsee>   yes, it's coming towards us.
[04:55] <nenolod> Debian Standards-Version is now at 3.7.3.
[04:55] <nenolod> it'd be nice of lintian would stop nagging about a new standards-version being used.
[04:55] <ScottK> Fujitsu: I notice that you touched lintian last.  Mind me taking a whack at it?
[04:56] <nenolod> just you know, a wishlist, if anyone is backporting to gutsy
[04:56] <ScottK> nenolod: That's why I'm looking at lintian right now.
[04:56] <nenolod> ;)
[04:57] <nenolod> ScottK, you are an hero. :P
[04:57] <ScottK> nenolod: Not yet I'm not.
[04:57] <nenolod> you soon will be one hopefully ;)
[05:11]  * StevenK idly wonders if there a way to update the timestamp using dch
[05:12] <crimsun> with -e ?
[05:12] <StevenK> Well, dch -r does so, but I don't want to be left in an editor
[05:13] <StevenK> Bloody DBS
[05:13] <StevenK> Have to manually set the version in the debian/rules file, grumble, grumble
[05:16] <persia> StevenK: Can't you set it with dpkg-parsechangelog ?
[05:17] <StevenK> persia: Probably, but the less I touch of this DBS-infested package, the better
[05:17] <persia> StevenK: Once your name is in the changelog...
[05:19]  * StevenK goes back to trying to figure out how to out-smart dch
[05:19] <persia> StevenK: `dch -r "Update Timestamp"`
[05:20] <StevenK> I don't want to add a new entry, I just want it to update the timestamp and drop me back to the shell
[05:20] <persia> StevenK: Ah.  That's harder then.
[05:20] <StevenK> Right
[05:20] <persia> Actually, when testing, I don't see "update timestamp" in the changelog I just mangled.
[05:21] <persia> StevenK: Best I can see, dch -r with an argument ignores the argument (which may be a bug)
[05:22] <StevenK> But works for me
[05:22]  * persia notes that this is an excellent example of why most SRUs should be bug-for-bug compatible with previous release revisions
[05:23] <LaserJock> persia: ?
[05:23]  * ScottK enjoys the irony of running lintian on lintian.
[05:23] <LaserJock> heh
[05:23] <bddebian> heh
[05:24] <LaserJock> ScottK: use linda so it's less incestuous
[05:24] <persia> LaserJock: `dch -r` fails to add a changelog entry when called with an argument, which doesn't match the documentation.  This is a good thing for StevenK under current usage, and not actually harmful for the majority of users, so such behaviour should be kept unless there is a change upstream.
[05:36] <ScottK> So I file the sync bug and now he leaves.
[05:37]  * Nafallo ponders
[05:40] <ScottK> Heya LaserJock.  It looks like lintian is a sync now.  Please have a look at Bug #175036 and ack it to the archive if you agree.
[05:41] <ubotu> Launchpad bug 175036 in lintian "Please sync lintian (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/175036
[05:43] <LaserJock> ScottK: looking
[05:43] <LaserJock> that's one heck of a changelog
[05:44] <ScottK> LaserJock: It is.  In addition to reviewing the entire .diff between the two releases, I also did some test runs against debian and ubuntu packages to see if the ubuntu specific distro name tests were working.
[05:45] <LaserJock> excellent
[05:45]  * persia notes that Ubuntu linda is already mostly 3.7.3 compliant, so with this sync we should enter the new era
[05:45] <ScottK> persia: lintian sync done.  dkim-milter merged.  Now for a REVU and we're even.
[05:46] <persia> ScottK: Thank you :)
[05:46] <LaserJock> ScottK: are you wanting to sync 1.23.39 or 1.23.40?
[05:47] <ScottK> Just for completeness I also invalid'ed the pending merge bug for an older version of lintian
[05:47] <ScottK> LaserJock: 39
[05:47] <ScottK> Urgh.
[05:47] <persia> -40?
[05:47] <LaserJock> ScottK: .40 exists
[05:47] <StevenK> .40 is only like 2 bugfixes, if I recall
[05:47] <LaserJock> yep
[05:47] <LaserJock> a brown paper bag release
[05:48] <StevenK> Russ is being terribly efficent and making me look bad
[05:48] <ScottK> LaserJock: Neither MoM nor DaD know about 40.
[05:48]  * persia 's sid also doesn't know about .40, but p.qa.d.o does.
[05:48] <LaserJock> ScottK: tsk tsk, relying on MoM and DaD ;-)
[05:49] <ScottK> Neither does p.d.o
[05:49] <persia> .40 would be good: 454941 sounds unfortunate
[05:49] <LaserJock> looks like it
[05:50] <ScottK> Agreed.  .39/.40 wouldn't affect if it's a sync or a merge.
[05:51] <LaserJock> yep
[05:51] <LaserJock> how long do you think it'll take to get .40 downloadable?
[05:51] <ScottK> I grabbed it from incoming.
[05:51] <LaserJock> ah
[05:53] <Nafallo> hmm
[05:53] <Nafallo> can vim fqdn:path/to/file work? ;-)
[05:54] <LaserJock> I think so
[05:54] <LaserJock> or rather, I think you might have to do it from within vim
[05:54] <ScottK> LaserJock: .40 seems to work OK too.
[05:54] <LaserJock> but I read that it'll go over ssh, etc.
[05:54] <Nafallo> hmm. kinky :-)
[05:55] <LaserJock> ScottK: gonna fix the bug report?
[05:55] <ScottK> Nafallo: It works
[05:55] <ScottK> LaserJock: I'll say I'll take 39 or 40 since if 40 isn't available yet, we'll get it on autosync.
[05:56] <StevenK> -archive will sync the latest source available, which will more than likely be .40
[05:56] <persia> ScottK: If we get 39, we'll get lots of spurious errors.  Why not just update the bug: .40 will be in by the time the archive-admins look at it on Monday.
[05:56] <Nafallo> oh.
[05:56] <Nafallo> I had to use proper stuff :-)
[05:57] <StevenK> The sync request is just a confirmation of "These are the Ubuntu changes, I have checked that they can be dropped, do it!"
[05:57] <Nafallo> sftp://fqdn/path/to/file
[05:57] <persia> StevenK: In that case, why do we mention the Debian version in every bug?
[05:57] <ScottK> LaserJock: Updated.
[05:58] <StevenK> persia: Because that's the one you've checked against -- and it's incredibly unlikely that the Ubuntu changes will get dropped by Debian in the very next version
[05:58] <ScottK2> Nafallo: vim http://incoming.debian.org/lintian_1.23.40_i386.changes also works
[05:58] <Nafallo> yea. proper URLs :-)
[05:58] <LaserJock> ScottK2: cool
[05:58] <persia> StevenK: Ah.  Makes sense.
[05:58] <Nafallo> rather then fqdn:path :-)
[05:59] <LucidFox> What are .changes files for, anyway?
[06:01] <persia> LucidFox: They specify the bugs closed, all changes since the last upload (sometimes multiple revisions), the checksums of all the package sections, and contain the signature of the uploader.  This is parsed to verify that someone authorised truly wished to make the upload, and used to update tracking systems.
[06:02] <LucidFox> Ack.
[06:05] <LaserJock> ScottK: is it proper to unsub -sponsors after acking?
[06:05] <persia> LaserJock: That's what we do in universe.  The procedure for main remains undocumented.
[06:06] <LaserJock> bah, I'm not a member of -sponsors, I'll have to just leave it
[06:16] <LaserJock> I wonder if there's much difference between running Firefox and epiphany in KDE
[06:17] <ScottK> persia: http://revu.tauware.de/details.py?package=firmware-addon-dell reviewed.  I think I need to get to bed.
[06:18] <persia> ScottK: Sleep well, and thanks again: the "price" was more of a joke, but you've hit it perfectly in short order.
[06:18] <LucidFox> LaserJock> Difference in what sense?
[06:19] <ScottK> persia: Sure.  I'll confess now that I was already doing the merge when you named your price ;-)
[06:22] <LaserJock> LucidFox: as in does epiphany pull in a lot of gnome libs that would counteract the savings of using epiphany
[06:25] <ScottK> LaserJock: I would encourage you to try using Konqueror.  I find I use it more and more as I get used to it.
[06:26] <LaserJock> hmm, and I can't find a kmail menu entry
[06:31] <ScottK> LaserJock: There's a big icon just to the right of the K menu button.  It's in Kontact.  We don't do Kmail separately in Kubuntu.
[06:33] <LucidFox> Wait, I use just Kmail.
[06:33] <ScottK> LucidFox: Yes, but by default there's no icon for it.
[06:33] <LucidFox> (I have Kontact uninstalled, though.)
[06:33] <LucidFox> ah
[07:47] <pwnguin> what's the best way to publish packages for something usable but under rapid development currently?
[07:48] <pwnguin> Ubuntu already publishes deluge, but it's severely out of date devs say
[07:53] <pwnguin> they currently host their own packages for ubuntu
[07:53] <pwnguin> is this something -backports would handle?
[07:59] <RAOF> pwnguin: Sounds like the "upstream pass" idea that was kinda threshed out beryltime
[07:59] <persia> pwnguin: Yes.  Someone would track Deluge development, and pick a good target upstream version during the 17 weeks opf
[07:59] <pwnguin> opf?
[08:01] <persia> s/opf/of open archives.  This version could be backported, and the default version for the next release would be the selected version.  Bugfixes would be backported to this selected version for the next 7 weeks, with only truly critical fixes being applied for beta & RC freezes/ (backpace & enter are too close)
[08:01] <pwnguin> so in no case is one simply bringing in new code to an old release
[08:01] <pwnguin> aside from bugfixes
[08:02] <persia> pwnguin: Right, although new code present in the current development environment may be backported, which handles 34 weeks of the year.  The other 18 are harder to handle.
[08:02] <pwnguin> im not as worried about development version as much as what happens after release
[08:04] <persia> pwnguin: The two are tied directly.  Backports may only be performed on packages in the development release (or in special cases, packages from previous releases to even earlier releases).  Therefore, the development release needs to track upstream fairly closely for it to be backportable.
[08:11] <pwnguin> in the case of deluge, ive been told that software from august is "ancient". backportability of upstream patches may not be simple =/
[08:12] <pwnguin> in any case, i dont think i can nessecarily do it, and i doubt the developers have the willpower to put up with ubuntu qa processes =(
[08:12] <RAOF> It may be "ancient", but it works (in the most part).
[08:12] <pwnguin> yea. aside from some strange cpu consumption related dht
[08:13] <RAOF> So, for fun new features, there's backports.
[08:13] <pwnguin> what?
[08:13] <persia> pwnguin: Just to make sure I'm clear, if the new upstream goes into hardy, the new upstream can go into gutsy-backports, just not into gutsy.  If there is a specific bug for which a patch can be extracted that meets the SRU criteria, that's different.
[08:13] <pwnguin> which is fine
[08:14] <pwnguin> deluge is currently on par in hardy with their own publishing
[08:14] <persia> !backports
[08:14] <ubotu> If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[08:15] <persia> pwnguin: There's info there that talks about where to file the bug to get that into gutsy-backports.  Saves upstream publishing their own.
[08:15] <pwnguin> i sorta imagined backports required some developer effort to verify and cherry pick or something
[08:16] <persia> pwnguin: My understanding is that it requires 1) no reverse dependencies, 2) a build log showing it builds in the previous release, 3) a couple testers reporting that it works in the previous release, and 4) approval from the backports team.  Usually pretty simple (but needs more testers).
[08:17] <pwnguin> apparently i misread a few statements with a negative where not was present
[08:45] <Gunner_Sr> greetings, all. what is the best way to look at a segmentation fault?
[08:47]  * Gunner_Sr never mind, I will just gdb it. :-)
[09:01] <RAOF_> Gunner_Sr: That *is* the easiest way to look at a segfault :)
[09:01] <Gunner_Sr> yep, the joys of getting use to linux world :-)
[09:02] <Gunner_Sr> RAOF_: seems I got a great bug to fix, I have created another one that I need to fix first :-)
[09:05] <RAOF_> Always the way :)
[09:05] <Gunner_Sr> RAOF_: wow, that's wierd. If I try and execute the binary is fails with a segmentation fault, execute it with valgrind and works fine???
[09:16] <RAOF_> Ah, the joys of instrumentation.
[09:16] <Gunner_Sr> can anyone help me with this problem - 'If I try and execute the binary is fails with a segmentation fault, execute it with valgrind and works fine?'
[09:16] <RAOF_> Gunner_Sr: That's (quite obviously) not impossible, but it *does* make it somewhat harder to fix.
[09:16] <RAOF_> Does it segfault under gdb?
[09:16] <Gunner_Sr> RAOF_: yes
[09:17] <RAOF_> Well, that's an *excellent* first step.  Where does it segfault?
[09:17] <RAOF_> You probably want to install the relevant -dbgsym packgages and get it to segfault under gdb
[09:18] <Gunner_Sr> it appears that address is out of bounds for mapping a window
[09:18] <Gunner_Sr> RAOF_: okay, will do that.
[09:18] <RAOF_> That sounds like Compiz?
[09:19] <Gunner_Sr> humm, so how do I turn it off to check?
[09:20] <RAOF_> Oh, the segfault isn't in compiz?
[09:20] <Gunner_Sr> no, it is a game xgalaga..
[09:20] <RAOF_> Sorry, compiz is just my natural assumption for "crash" + "window" :)
[09:20] <Gunner_Sr> np
[09:20] <RAOF_> https://wiki.ubuntu.com/Backtrace if you haven't seen it already
[09:22] <Gunner_Sr> RAOF_: okay, I will look into it. Thanks.
[09:29] <Gunner_Sr> RAOF_: I have the offending line now. it appears that the window is being mapped to an invalid address.
[09:29] <LordKow> has anyone else had issues with pulseaudio recently? i feel like its just me
[09:31]  * StevenK grumbles at bug 159307
[09:31] <ubotu> Launchpad bug 159307 in openh323 "undefined reference to `PSafeObject::PSafeObject()'" [Undecided,New] https://launchpad.net/bugs/159307
[09:36] <RAOF_> StevenK: It's missing a link to a constructor?  Also what crazy man exports C++ as the ABI?
[09:37] <StevenK> RAOF_: Yeah, well, who knows. It *is* VoIP.
[09:40]  * RAOF_ wonders idly why iwl3945 suddenly wants to drop out after 30min or so.
[09:42] <slicer> I forgot; how do you view the source of a package using launchpad?
[09:43] <slicer> nm
[09:52] <pwnguin> RAOF_: which kernel?
[09:57] <RAOF_> 2.6.22
[09:58] <RAOF_> pwnguin: I tend to switch to the next kernel only when the kernel team feel that making it default in linux-meta is a good idea :)
[09:59] <pwnguin> i see
[09:59] <pwnguin> i dont think ive ever noticed before
[09:59] <pwnguin> but id really like to get sdcard working this time around
[10:35] <RainCT> what's the way to fix bugs like bug #92939? just let the packages conflict?
[10:35] <ubotu> Launchpad bug 92939 in libowfat "[can-not-install] file overwrite error" [Medium,Confirmed] https://launchpad.net/bugs/92939
[10:35] <LucidFox> When do I need to call dh_icons?
[10:36] <persia> RainCT: Either conflict, or move the files to not be the same.
[10:36] <persia> LucidFox: Whenever you install icons in icon cache directories.
[10:46] <persia> RainCT: Was it you who tried to package ninvaders for gutsy?
[10:47] <RainCT> persia: no
[10:47] <persia> RainCT: Sorry then.  Thanks.
[10:47] <RainCT> np
[10:48]  * Gunner_Sr goodnight all.
[10:49] <Gunner_Sr> Sick of staring at gdb ;-)
[10:53] <oly_> hi, when i am building my package using dpkg-buildpackage, it generates a tar.gz file with everything in, but none of the files make it to the .deb file the rues file is pasted here http://pastebin.ubuntu.com/2573/
[10:53] <persia> oly_: What command line are you using with dpkg-buildpackage?
[10:53] <oly_> if anyone can look and figure out anything it would be appreciated
[10:53] <oly_> dpkg-buildpackage -rfakeroot
[10:53] <oly_> when inside the extracted folder
[10:54] <persia> oly_: And there's neither a .deb nor an error?
[10:55] <oly_> there is a deb, no error but the deb does not conain the files of the program it only contains the debian files
[10:56] <persia> oly_: I suspect that "$(MAKE) DESTDIR=$(CURDIR)/debian/usm-core-0.2 install" isn't quite doing what you want then.  Try without the "-0.2".
[10:56] <oly_> i actually added that to see if that fixed it
[10:57] <persia> oly_: I recommend looking carefully at your build log to see where the files are being installed, and from where the files are being pulled by dh_builddeb.  I suspect there is a disconnect there.
[10:58] <oly_> okay, where does the build log get put
[10:59] <oly_> dont think i have seen that yet
[10:59] <persia> oly_: Usually in a .build file in the same directory as the .deb.
[10:59] <persia> If it's not there, maybe try with debuild instead of dpkg-buildpackage
[11:02] <persia> It's REVU Day Again.  There's 20 candidates up for review, 3 of which have an advocate, so the reviewers have a bit to do.  The Needs Work queue is about twice that long, so new uploads are encouraged.  Let's get 10 packages uploaded today!
[11:03] <oly_> if i can make my package i will upload it :)
[11:03] <oly_> found that .build file looking at it now
[11:03] <Hobbsee> i't so isn't revu day.
[11:03]  * Hobbsee ignores the topic
[11:03] <persia> Hobbsee: It is REVU day.  You don't get to play.  Nyah-Nyah.
[11:04] <Hobbsee> woot!
[11:04] <persia> Hobbsee: Do you do sync request approvals yet?
[11:05] <Hobbsee> no
[11:05] <Hobbsee> probably won't for months
[11:05] <slicer> Wohoo! I got an advocate for my package :)
[11:05] <persia> slicer: If you can fix the bugs, and upload again, that'd be good too :)
[11:05] <slicer> persia: Ah. It crashed gnome-panel?
[11:05] <persia> slicer: Yep.
[11:06] <slicer> persia: *boggles* How is that possible? murmur has no GUI components at all.
[11:06]  * RainCT is currently working on a package upgrade
[11:06] <persia> slicer: No idea: didn't really make sense to me, but I typed dpkg -i ... and it reloaded the panel.
[11:07] <slicer> persia: I'll see if debhelper does anything fancy to it.
[11:07] <persia> slicer: That might be it.  Maybe something with the services entries?
[11:07] <sistpoty> hi folks
[11:08] <persia> sistpoty: Good morning.  Happy REVU Day!
[11:08] <sistpoty> hi persia
[11:08] <sistpoty> oh it's revu day today?
[11:08] <persia> Well, it's Monday somewhere...
[11:09] <sistpoty> hehe... still sunday for me :)
[11:09] <StevenK> It's only just ticked over to Monday in .nz
[11:12]  * persia refuses to be bound by locality
[11:13]  * sistpoty wonders if he should implement the revu contributors spec right now
[11:13] <LucidFox> Speaking of REVU... what's the point of this? http://revu.tauware.de/details.py?package=psi
[11:14] <persia> LucidFox: How do you mean?
[11:14] <LucidFox> Well, 0.11-3 is in the archive, so it's probably redundant to upload the same upstream release to REVU
[11:14] <persia> sistpoty: How does REVU check to see if packages are in the archive?  Shouldn't that be sorted differently?
[11:15] <persia> Err.  sistpoty: Nevermind.  I'm blind.
[11:15] <persia> LucidFox: Those packages mostly get ignored, but some people find REVU a convenient dget-compatible place to upload new revisions.
[11:15] <sistpoty> persia: iirc it rebuilds its database of stuff in the archive once a day. on a upload with a not yet known package, it checks the database and marks it as such (imo not at subsequent uploads, which is a bug)
[11:15] <slicer> Our minimum target for IA32 is i586, right? Is that with or without MMX?
[11:16] <persia> sistpoty: Ah.  It's the "not at subsequent uploads" part that was confusing me.  Thanks.
[11:16] <persia> slicer: Best to check for MMX at runtime.
[11:17] <slicer> Bah, it makes the code ugly. Oh well.
[11:17] <sistpoty> slicer: if it really makes a huge performance difference, you could build two binary packages (-386 and -686)... but usually there's no such big difference unless you do massive FPU stuff
[11:18] <persia> slicer: There are quite a few packages that check at compile time, but they tend to generate an MMX bug eventually.  Depends on what you're willing to support.
[11:19] <slicer> sistpoty: MMX gives me ~10-20%. Enabling SSE doubles performance.
[11:20] <slicer> It's not critical, but I hate wasting CPU cycles. Anyway, I'll stick to the plain-FPU version for now.
[11:20] <sistpoty> slicer: what's the application? does it make sense to run it on non-mmx boxes at all? (imo mythtv used to just enable mmx, because it wouldn't work properly on non-mmx boxes anyways)
[11:21] <slicer> sistpoty: Mumble, VoIP application. .. Er. Hm. Last non-MMX pentium was ... 90Mhz, right? I'll go check if it's feasible.
[11:21] <imbrandon> you need to rember that not everything is x86 also
[11:22] <slicer> It works on PPC :)
[11:22] <imbrandon> ppc,sparc,mips,arm, none have mmx
[11:22] <slicer> But a modern PPC has slightly more CPU power than a old pentium.
[11:23] <LucidFox> http://revu.tauware.de/details.py?package=xulrunner-1.9 - the uploader requests this to be nuked
[11:23] <sistpoty> LucidFox: done
[11:24] <imbrandon> slicer: i would watch making assumptions for your users though, if you do enable stuff like that please build both
[11:24] <LucidFox> imbrandon, please check PM on IRC
[11:24] <persia> slicer: Yes, but my PPC 233 doesn't
[11:24] <bobbo> Can anyone in here sync my GPG key with REVU?
[11:24] <imbrandon> LucidFox: i got it
[11:25] <persia> bobbo: Have you joined the LP group?
[11:25] <bobbo> yeah
[11:25] <persia> bobbo: OK.  I'll sync the keys.  Takes about half an hour or so
[11:25] <bobbo> ok, thanks persia
[11:25] <slicer> Gah, the last non-MMX pentium was the P54CS@200Mhz. Which, in theory, is enough. So no MMX for now.
[11:26] <persia> imbrandon: Isn't that the processor you use?
[11:26] <imbrandon> persia: haha yea, iths the one i'm on now :)
[11:26] <imbrandon> its*
[11:26] <sistpoty> poor imbrandon
[11:26] <imbrandon> slicer: thats my main machine :)
[11:26] <persia> slicer: See.  People still use those :)
[11:26] <jeromeg> persia: could you please reviw this one ? http://revu.tauware.de/details.py?package=gnome-launch-box
[11:26] <slicer> imbrandon: You do realize most cellphones have more CPU power? ;)
[11:26] <persia> jeromeg: Why me?
[11:27] <jeromeg> jeromeg: because you're nice :)
[11:27] <imbrandon> slicer: and? it lets me get dev work done , lots better than being offline fo months :)
[11:27] <jeromeg> persia: I'm not the uploader, but this is an upgrade, and the buy also maintains it into debian
[11:27] <persia> jeromeg: I'll recommend a general advertisement.  I'm one of the more picky reviewers: I think I've advocated 3 things since hardy opened.
[11:27] <slicer> imbrandon: But.. It will take you months to compile a single package ;)
[11:27] <jeromeg> persia: it's not yet in debian
[11:28] <persia> jeromeg: An update?  Why is it on REVU?
[11:28] <jeromeg> persia: it shouldn't ?
[11:28] <jeromeg> persia: revu is only for new packages ?
[11:28] <slicer> persia: That actually makes you more desirable as a reviewer. When you sign off on things, the uploader feels it's really ready :)
[11:28] <imbrandon> slicer: not really, i maintain quite a few packages
[11:29] <persia> jeromeg: Generally a patch submitted to the sponsors queue is better for upgrades.  REVU is for new packages.  Upgrades can go there, but they usually get ignored.
[11:29] <jeromeg> persia: yep i see that
[11:29] <jeromeg> persia : even with new upstream tarball ?
[11:29] <persia> jeromeg: Yep.  See https://wiki.ubuntu.com/MOTU/Contributing
[11:30] <bobbo> persia: I made a patch to fix a bug in a package that hadnt been updated since Breezy and became the new maintainer (This is my first package) Should this go in REVU?
[11:30] <persia> jeromeg: Just make sure that either the watch file works or there is a working get-orig-source rule.
[11:30] <persia> bobbo: No need.  Best to just send a patch to the sponsors queue.  That way you don't have to wait for Mondays, and the responses will be tracked better.
[11:30] <jeromeg> persia: the watch file is introduced with this new version
[11:31] <persia> jeromeg: Excellent.
[11:31] <bobbo> persia: where is the sponsors queue found?
[11:31] <jeromeg> persia: so where is the guy supposed to put everything, on LP ?
[11:31] <persia> bobbo: See the MOTU/Contributing link for information on preparing the diff and submitting to the queue.
[11:31] <bobbo> thanks persia
[11:31] <persia> jeromeg: We only need the interdiff.
[11:33] <jeromeg> persia: ok i'll mail this to the maintainer before he gets desesperated !
[11:33] <persia> jeromeg: Thanks.  REVU can be frustrating sometimes.
[11:33] <jeromeg> persia: :)
[11:35] <persia> So.  Who has a new package on REVU and wishes a REVU?  Any advertisements?
[11:36] <jeromeg> persia: the same guy has http://revu.tauware.de/details.py?package=awn-extras-applets
[11:36] <jeromeg> persia: the maintains the awn-core
[11:40] <persia> bobbo: keyring sync complete
[11:40] <bobbo> thanks persia
[11:41] <jeromeg> got to go
[11:41] <jeromeg> bye all
[11:43] <LucidFox> persia> http://revu.tauware.de/details.py?package=inkblot
[11:43] <LucidFox> (new)
[11:43] <LucidFox> also updated paclages: http://revu.tauware.de/details.py?package=avidemux http://revu.tauware.de/details.py?package=smplayer
[11:44] <persia> LucidFox: A general advertisement would be much better, especially now as the last pointed at me is still building.  For the updated packages, please submit a diff in a bug to the sponsors queue.
[12:00] <DaveMorris> apachelogger_: re your comment for cpptest, with libcpptest-dev conflicting with libcpptest-dev.   This is to stop people accidentally upgrading the dev packages through system upgrades which could break the build environment, it can still be upgrade but requires the package to be removed 1st.  How come this is a bad idea?
[12:01] <persia> LucidFox: I've just taken a look at inkblot.  Nice job.  I don't have the hardware to test, and only have minor comments.  Would you prefer a comment for a new upload, or me to leave it for someone who can test?
[12:02] <persia> DaveMorris: You have a package that conflicts with itself?
[12:02] <DaveMorris> yeah
[12:02] <DaveMorris> the -dev package of a lib
[12:04] <persia> DaveMorris: Don't do that.  It makes it hard to install & upgrade.  For a stable release, the ABI will be stable, so there's no danger of someone having a conflict from an upgrade.  For a release under development, there's no promise of stability, so there's no point.
[12:04] <DaveMorris> ABI?
[12:04] <persia> Application Binary Interface
[12:19] <RainCT> u-u-s can be unsubscribed from bug #66174
[12:19] <ubotu> Launchpad bug 66174 in showfsck "Man page is incorrect" [Low,Confirmed] https://launchpad.net/bugs/66174
[12:20] <persia> RainCT: Done.
[12:20] <persia> RainCT: Thanks for helping clear the queue.
[12:21] <bobbo> RainCT: Thats the bug im working on. Once I fix the stuff in your comment what should i do to get it included?
[12:21] <RainCT> np, it's fun and I might even learn something new on the way :)
[12:21] <persia> RainCT: Just be prepared for complaints if you get it wrong :)
[12:22] <RainCT> heh
[12:22]  * Hobbsee must have some outstanding bugs, too
[12:22] <RainCT> bobbo: subscribe ubuntu-universe-sponsors again and/or announce it here :)
[12:23] <bobbo> ok thanks, working on it now
[12:23] <Hobbsee> oh, sigh, this is not hardy.
[12:24] <RainCT> bug 175018 has no interdiff (but .dsc, .orig and .diff instead), so I guess it can be unsubscribed too..
[12:24] <ubotu> Launchpad bug 175018 in strongswan "strongswan: New upstream release 4.1.9" [Undecided,New] https://launchpad.net/bugs/175018
[12:24] <persia> RainCT: No.  We can use that: it is just a waste of LP archive space.
[12:28]  * Hobbsee bumps a package out of the new queue.  hurrah!
[12:32] <bobbo> RainCT: Thats the debdiff fixed for bug #66174
[12:32] <ubotu> Launchpad bug 66174 in showfsck "Man page is incorrect" [Low,Confirmed] https://launchpad.net/bugs/66174
[12:33]  * RainCT looks
[12:51] <rexbron> Hi, What is the appropreate size for an icon to go with a .desktop? Currently upstream ships an svg only.
[12:53] <Amaranth> rexbron: you should have 16, 22/24, 32, 48, and scalable (svg)
[12:53] <persia> rexbron: I like 32x32 XPM + 48x48 - 128x128 PNG (anywhere in the range).  Also, if there is an SVG, most newer WMs can display it.
[12:54] <Amaranth> but if you only have svg that's the best of the bunch to only have
[12:54] <persia> Amaranth: All of those?  Doesn't the WM typically auto-scale?
[12:54] <Amaranth> persia: Not well
[12:54] <persia> Amaranth: Ah.  True.
[12:54] <rexbron> but which icon size/format should I use in the .desktop? :P
[12:54] <Amaranth> rexbron: none
[12:54] <persia> rexbron: None.  Just use the bare icon name.
[12:55] <Amaranth> rexbron: should just be Icon=foo
[12:55] <Amaranth> then the icon theme machinery in your DE/WM will find the appropriate icon based on the size requested and the theme being used
[12:55] <rexbron> persia: This is in relation to genpo, I got one of the guys in #ubuntustudio to do an icon up
[12:55] <persia> (where foo.xpm is in /usr/share/pixmaps, lots of different foo.png files are in the specific size directories, and foo.svg is in the scalable icon directory)
[12:56] <Amaranth> eh, xpm
[12:56] <persia> Amaranth: Required to support menu files, which are required to support fluxbox.
[12:56] <Amaranth> People use that? :P
[12:56] <rexbron> would someone be able to link me to the reference docs?
[12:57] <rexbron> Amaranth: Fluxbuntu ftw
[12:57] <Amaranth> I don't think any GNOME app ships an xpm unless they're old enough to have been around when xpm was the thing to use
[12:57] <persia> Amaranth: Lots of people.  It's our 5th most popular WM
[12:58] <persia> Amaranth: For those, Debian usually ships an XPM (although it's not always included in Ubuntu)
[13:00]  * rexbron noticed that a _huge_ amount of .desktop files and icons are shipped in /usr/share/applications and /usr/share/app-install/desktop and icons ...
[13:00] <rexbron> but the packages are not installed
[13:00] <persia> rexbron: I think http://standards.freedesktop.org/icon-theme-spec/latest/ar01s07.html is the relevant documentation
[13:01] <persia> rexbron: /usr/share/app-install is special, and includes slightly mangled versions of all .desktop files available in Ubuntu + a bunch of local ones where a normal .desktop file isn't appropriate.
[13:03] <slicer> Can you get pdebuild to run lintian and linda appropriate to the distribution it's compiling for, same as debuild does?
[13:03] <rexbron> alright
[13:04] <rexbron> hm
[13:04] <rexbron> I am now rather confused as to best practices
[13:05] <persia> slicer: The code isn't shared much, so you likely have to change pdebuild (a patch for that would be welcome)
[13:05] <Hobbsee> pbuilder, but not pdebuild
[13:05] <Hobbsee> see pbuilder hooks
[13:05] <Hobbsee> persia: ???
[13:06] <persia> Hobbsee: To run lintian & linda for the target distribution rather than the local distribution?
[13:06] <Hobbsee> oh, i'm not sure of which version of linda/lintian it uses
[13:06] <Hobbsee> install the newer lintian/linda on the old system?
[13:06] <persia> Hobbsee: I believe it's the version installed on the host system, rather than one in the chroot.
[13:06] <Hobbsee> persia: quite likely.
[13:07] <persia> slicer: That's the standard practice: use the backported lintian & linda.
[13:07] <Hobbsee> persia: i thought you were saying that pbuilder did not have the capacity to run lintian/linda as hooks.
[13:07] <slicer> It is the one on the host, and the host doesn't have 3.7.3 standards etc etc.
[13:07] <persia> Hobbsee: No, just not to differentiate based on the build target.
[13:08] <Hobbsee> persia: true
[13:08] <persia> slicer: For that, you'll need to backport the Debian lintian manually (sync is pending, and backport will follow).  There's no 3.7.3 linda yet, but hardy is pretty close.
[13:32]  * persia has discovered a new load-testing method: simultaneously run linda & dpkg-source -x on seamonkey.
[13:34] <StevenK> Well, all Linda will do is add a bunch of I/O load
[13:34]  * StevenK has an evil plan to drop Linda's I/O wait
[13:35] <StevenK> But, it requires me being motivated to work on Linda
[13:36] <persia> StevenK: Yes.  It's the combined IO load of linda + dpkg-source -x on a 50MB package that does it.
[13:36] <persia> Regarding linda, what would be a good source of motivation?  Does the new policy help?
[13:36] <StevenK> You know, I've been trying to answer that question in my head for months.
[13:37] <persia> heh.
[13:37] <StevenK> Someone else taking an interest and submitting patches might help. *subtle hint*
[13:37] <persia> Could I convince you that tar-in-tar is annoying, and the test directories should be unrolled in the source to make patching easier?
[13:38] <StevenK> The test directories? You mean the labs?
[13:38] <persia> Sounds fine.  There's still one patch in BTS not in Ubuntu yet, and a couple other bugs that seem trivial.  I'll prep a candidate over the next week.
[13:38] <persia> Yes.  The labs.
[13:38] <StevenK> My evil plan is for labs to not exist
[13:38] <persia> My last linda diff was painful, as I needed to update the labs
[13:38] <persia> How would that work?
[13:39]  * persia hopes the answer will not be "Don't bother testing"
[13:40] <StevenK> The components of the .deb are unpacked in memory and I run the equivalent of file over the first 200 bytes of the member to determine what it is and stuff it into a dictionary
[13:40] <StevenK> For source packages, I'm still thinking about it. It becomes harder for non-native source packages since I have a patch to apply
[13:41]  * StevenK waits for persia to run screaming
[13:41]  * persia is only wishing it weren't 10 minutes past bedtime, as reading the source to better understand would help (as would actually knowing python)
[13:42] <StevenK> Parts of Linda are *messy*
[13:42] <persia> StevenK: Yes.
[13:42] <StevenK> And I completly and utterly ignore OO abstraction rules
[13:43] <persia> Yes
[13:43] <StevenK> (Oh, I'm really selling it, aren't I?)
[13:44] <persia> Still, it works, and provides a nice cross-check to lintian, and has a few reasonable requests outstanding.  I'll see what I can close.  Are there any untriaged bugs in the BTS that you don't want fixed?
[13:44] <StevenK> Personally, I'd rather work on getting Linda to be a speed demon first.
[13:45] <StevenK> She used to be faster than lintian, too
[13:45] <persia> StevenK: Hmm.  Optimisation in a language I don't know isn't really my strong point :(
[13:45] <StevenK> persia: I daresay figuring out how to read files in tarballs using python's objects is 80% of it
[13:46] <LucidFox> What in inkblot is copyrighted by the X Consortium and the Free Software Foundation?
[13:46] <persia> Just ripping the files directly, rather than unpacking?  How does one apply diff.gz?
[13:47] <persia> LucidFox: I forget.  grep is your friend.  I think it was related to translations.
[13:47] <StevenK> persia: Just grabbing the files into memory, yes. How one applies the diff.gz is an unsolved problem
[13:48] <persia> That would certainly speed her up a bit (assuming a solution to that problem).  Still, lintian unpacks a lab, and finishes before linda for very huge sources.  Am I correct that linda is unpacking multiple times in a single run?
[13:49] <persia> (or is it just the unpacks for the internal tarballs?)
[13:49]  * persia goes off to read source to answer these questions
[13:50] <StevenK> Linda only unpacks once
[13:50] <RainCT> if a ubuntuwire guy is arround, what's about adding links to launchpad.net/ubuntu/+source/<package> in http://qa.ubuntuwire.com/uehs/no_watch.php ?
[13:51] <persia> RainCT: Would the link be from the "Name" field?
[13:51] <RainCT> persia: yes
[13:52] <oly_> anyone around who is able to give me a hand, what ever i do i can not figure out what i am doing wrong, and why the files from my program still do not end up in my deb file
[13:53] <oly_> i was wondering if the program being called usm-core could cause a problem, because it uses a hyphen
[13:53] <persia> oly_: Are your sources available for download somewhere?
[13:54] <oly_> i can upload them, what do you need the original tar and the debian folder ?
[13:54] <oly_> or shall i try using that dput command ?
[13:55] <RainCT> oly_: upload .dsc, .orig.tar.gz and .diff.gz, or yes, better just use dput
[13:56] <oly_> okay give me a sec whyile i figure out how to use dput
[13:56] <persia> oly_: If you've not used dput before, it might be easier to upload using another method the first time.
[13:56] <oly_> oky
[13:57] <oly_> dput is the next thing after i can build this package :)
[13:58] <persia> RainCT: My PHP isn't up to a fix: could you paste a patch against http://paste.ubuntu.com/2578/ ?
[13:59] <RainCT> persia: sure, one moment
[14:00] <RainCT> persia: uhm.. is the paste right?     http://paste.ubuntu.com/2578/plain/ there are many cut lines..
[14:01] <RainCT> like: "Select id,mpop_inst,name,version,bytes,up_version,watch_warn, up_changes from p
[14:01] <persia> RainCT: Not sure.  I grabbed from my terminal.  Let me put the code somewhere easier...
[14:01] <RainCT> ah, then the terminal cut it :P
[14:02] <persia> RainCT: http://people.ubuntuwire.com/~persia/no_updated.php.txt
[14:18] <oly_> http://poke.servebeer.com/debtest/
[14:19] <oly_> the files are there, sorry for the delay my hosting is not workign so had to find another place to upload
[14:19] <txwikinger> Does anybody have a reference in how to debug the loading of Modules in perl?
[14:20] <oly_> so if anyone can take a look and see if they have any better luck building these into a package, if you need any other files let me know
[14:20] <LucidFox> Reuploaded inkblot
[14:24] <persia> LucidFox: Looks good.  I won't comment, as I can't test it.  Thanks for the quick turnaround.
[14:25]  * RainCT suggests some bored sponsor having a look at bug 66174
[14:25] <ubotu> Launchpad bug 66174 in showfsck "Man page is incorrect" [Low,Confirmed] https://launchpad.net/bugs/66174
[14:26] <persia> Ubulette: I've just commented on seamonkey.  That's a huge amount of work you've done, but there's a bit more to go...
[14:26] <Ubulette> you mean 1.1.6 or 1.1.7 ? 1.1.6 was indeed huge, a full repackaging in fact
[14:27] <persia> Ubulette: Most of the work seemed to be for 1.1.6.  My comments were for 1.1.7.
[14:29] <Ubulette> hmm, ok, most of those comments apply to debian too
[14:29] <Ubulette> (iceape)
[14:30] <persia> Ubulette: Yep.  REVU is fairly strict :)
[14:30] <LucidFox> Speaking of seamonkey, shouldn't iceape now made transitional?
[14:30] <LucidFox> *be made
[14:30] <Ubulette> persia, i don't mind as long as it's reasonable ;)
[14:30] <Ubulette> LucidFox, it is
[14:30] <persia> bobbo: Looking at the 4th debdiff: there's one bit still needs doing: the version should be 1.3ubuntu1 rather than 1.4.  Other than that, it looks fairly clean.
[14:32] <persia> Ubulette: You've it hardest, as mozilla is a strange beast to package, and it's not easy to understand the results.  Thanks for trying, and I'm glad to see this here, as I feared your prism experience had frightened you away.
[14:32] <RainCT> oly_: dget: wget usm-core_0.2.orig.tar.gz http://poke.servebeer.com/debtest/usm-core_0.2.orig.tar.gz failed
[14:33] <Ubulette> persia, would it be possible to let that release go (for the security fixes), then i work on -0ubuntu2 to fix the rest ?
[14:34] <Ubulette> persia, i still think it's awfully long and painful to obtain sponsorship.
[14:34] <oly_> okay will see what i can do RainCT,
[14:34] <persia> Ubulette: Hmmm..  Last time I ran rmadison, I thought it told me seamonkey was new.  As an update candidate, that's likely good, but I'm not up for reviewing the comparison with 1.1.6 just now.
[14:34] <Ubulette> i like fixing stuff up to the minute, i just hate to wait in the dark
[14:35] <RainCT> persia: http://paste.ubuntu-nl.org/47536/plain/   sorry that it took so long, was busy in RL..
[14:35] <persia> Ubulette: I'd suggest pushing an interdiff in a bug to the sponsors queue: that way you're not waiting for Mondays, will likely get it in faster, and won't have people complaining about every little lintian informational note.
[14:35] <persia> RainCT: Thanks.
[14:35] <oly_> try it now,
[14:35] <Ubulette> persia, i posted that in the bug
[14:36] <RainCT> oly_: ok, works now
[14:36] <Ubulette> bug 174739
[14:36] <ubotu> Launchpad bug 174739 in seamonkey "[upgrade] seamonkey 1.1.7" [Undecided,Confirmed] https://launchpad.net/bugs/174739
[14:36] <oly_> because i have been making so many changes here and there trying to make it work
[14:36] <persia> Ubulette: Ah.  It seems to have been a slow week for sponsoring.  Feel free to ignore my REVU comments until you have time.
[14:37] <Ubulette> persia, the md5 stuff is disturbing btw.
[14:37] <oly_> do not really mind how i get this to work, as long as i can make acceptable packages for ubuntu, all they really need todo is copy the files to relevant location and run the postinst
[14:37] <persia> Ubulette: Yes, a bit.  That would be a sponsorship blocker too, as I couldn't build it at all.
[14:38] <oly_> seems a bit complicated just todo that, packaging seems to be aimed at c type code where you use make files, making it more confusing to me :p
[14:38] <Ubulette> persia, how is that possible? did you regenerate it ?
[14:39] <persia> Ubulette: Nope.  Just dget followed by sbuild.
[14:41] <Ubulette> persia, http://paste.ubuntu.com/2579/
[14:42] <persia> Ubulette: Strange.  I've not seen a corrupted download in a while.  I'll try again when I'm not about to sleep.
[14:45] <oly_> RainCT, do you think its worth me trying to use that cdbs for packaging see if i have any better luck
[14:45] <oly_> or am i just as likely to hit the same problem
[14:48]  * RainCT is still downloading the source
[14:50] <oly_> yeah, thats fine just i knwo yesterday you said you use cdbs for python, wondering if it might work better for me i dont really know the difference
[14:50] <oly_> i just followed a tutorial on making packages
[14:53] <Ubulette> persia, i just wget the tarball from revu, md5 matches mine.. so it could be on your side :O
[14:53] <persia> Ubulette: Very likely on my side.
[15:00] <bobbo> Can a MOTU check my  fix for bug #66174 please?
[15:00] <ubotu> Launchpad bug 66174 in showfsck "Man page is incorrect" [Low,In progress] https://launchpad.net/bugs/66174
[15:02] <Ubulette> persia, is XSBC-Original-Maintainer really useful ?
[15:03] <persia> Ubulette: It's mostly about giving credit to the person in Debian who worked on the package.
[15:04] <Ubulette> it's not used for anything else ? bots of some kind?
[15:07] <RainCT> Ubulette: it makes it possible to know who the Debian maintainer is without checking packages.debian.org..
[15:07] <RainCT> ('apt-cache show' displays it)
[15:07] <Ubulette> i just ask if it's needed here as i doubt debian will care about seamonkey
[15:08] <Ubulette> well, i'll add it, hoping it will not create issues
[15:09] <bluefoxicy> I heard vmware released vmware-tools as open source software or something nutty like that
[15:09] <RainCT> oly_: strange upstram tarball...
[15:09] <persia> Ubulette: If you're basing on Debian packaging, it's nice.  If you're not using their packaging, no point.
[15:09] <bluefoxicy> will Ubuntu 8.08 fully support running as a vmware guest?
[15:09] <oly_> what do you mean RainCT ?
[15:09] <bluefoxicy> VMware 2.0 will use VMI, which Linux supports.  Will Ubuntu 8.08 support running in a VMI environment?  :D
[15:10] <RainCT> oly_: having etc and usr folder.. I had never seen anything like that before xD
[15:10] <bluefoxicy> Xen doesn't export VMI.  Can we stab the Xen dev team in the face, and then take Xen away from Citrix and fork it and stab Citrix in the face and add VMI support?
[15:10] <RainCT> oly_: well.. i know what the problem is now
[15:10] <oly_> well i structured it that way :p
[15:10] <Ubulette> persia, i've forked at 1.1.4 and almost changed everything. you've read the changelog ;) https://edge.launchpad.net/ubuntu/+source/seamonkey/
[15:10] <RainCT> oly_: you're doing nothing with those files..
[15:10]  * bluefoxicy idle battery of random questions in the morning.
[15:10] <oly_> seemed to make sense at the time
[15:11] <persia> Ubulette: Your call.
[15:11] <RainCT> oly_: 1. you can remove all makefile bits from debian/rules are there's no makefile there
[15:11] <oly_> i thought that, thats why they where commented out
[15:11] <oly_> i will remove all otgether
[15:11] <RainCT> oly_: 2. put a file called "install" in the debian directory
[15:13] <RainCT> oly_: and there you have to list what files you want to install and where.. like this http://paste.ubuntu-nl.org/47537/plain/
[15:14] <RainCT> oly_: 3. call dh_install in the changelog, in the binary-indep section
[15:15] <oly_> okay, sounds good, was no mention of an install file in the packaging from scratch doc i was using
[15:15] <RainCT> oly_: well, as you said that's written for packages with makefile mainly.. :P
[15:15] <RainCT> oly_: if it's a web application I'm not sure if /usr/share is the right place to put the files
[15:15] <oly_> the reason i structured the folders like that was because i thought thats how it figured out where to put the files
[15:16] <RainCT> ah yes, it is
[15:16] <oly_> okay, its a bit of a tricky one because it runs sub processes as well
[15:17] <oly_> which run independatly, like for backups
[15:17] <oly_> okay will try that out
[15:17] <oly_> can you use * in the install folder or just specify folders ?
[15:17] <oly_> or do i have to put all files
[15:17] <RainCT> oly_: *, look at this: http://paste.ubuntu-nl.org/47537/plain/
[15:18] <oly_> yeah i saw just after writting that :p
[15:18] <oly_> silly me
[15:18] <RainCT> oly_: the homepage in debian/control should be in the source section
[15:18] <RainCT> after the "Maintainer:" line for example
[15:18] <oly_> okay will rearrange that
[15:19]  * RainCT thinks the description needs some more work, too :P
[15:20] <RainCT> oly_: tell me if you want me to have a look at it once you get it working
[15:20] <oly_> okay, will look at that as well
[15:20] <oly_> yes that woudl be useful, i need to make sure the application actually works and that i included all the correct files
[15:28] <oly_> yay, i have a 21.1mb deb now instead of a 2.2kb deb now :-D
[15:28] <oly_> thxs for the help RainCT, will go tidy up and test it now :)
[15:29] <RainCT> oly_: great :). np
[15:34] <RainCT> persia: I'm working on your suggestion for what-patch
[15:34] <RainCT> what do you recommend to get the "packagename_upstream-revision"?
[15:35]  * dsop is still searching for a second motu to advocate
[15:35] <persia> RainCT: You may be interested in Debian bug #452215<PHONE_NUMBER>21
[15:35] <ubotu> Debian bug 452215 in lintian "Add a check to make sure the .diff.gz is clean when debian/patches is used" [Wishlist,Open] http://bugs.debian.org/452215
[15:39] <Ubulette> persia: about the unclear X11R5 licence. http://paste.ubuntu.com/2580/   Should I use MIT ?
[15:39] <jonnymind> hello
[15:39] <persia> Ubulette: You'd do best to track down the X11R5 sources, and use that license.
[15:40] <persia> (the person integrating the source should have done that)
[15:40] <Ubulette> X11R5 is MIT
[15:40] <jonnymind> I have succeeded in splitting my binary packages as wished. May I kindly ask reviews for needs-packaging bug 174470?
[15:40] <ubotu> Launchpad bug 174470 in ubuntu "Package for the Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
[15:40] <jonnymind> Cute. I did that?
[15:41] <Ubulette> you did
[15:42] <jonnymind> :-)
[15:43] <Ubulette> debian bug 191717
[15:43] <ubotu> Debian bug 191717 in automake1.6 "automake1.6: install-sh licensing nightmare?" [Serious,Fixed] http://bugs.debian.org/191717
[15:44] <RainCT> persia: nice, but there's no patch there
[15:44] <persia> RainCT: Yes :(
[15:45] <RainCT> and    lsdiff -z ../$(basename `pwd` | sed s/-/_/)-*.diff.gz    isn't definitely the best option
[15:45] <bluefoxicy> ... apport is reporting slocate failed to upgrade (it succeeded, it just bitched)
[15:45] <bluefoxicy> specifically, apport is sending the same bug report like 15 times
[15:45]  * RainCT is looking at that parsechangelog thing
[15:50] <RainCT> dpkg-parsechangelog | grep "$(basename `pwd` | cut -d "-" -f 1) ("       isn't very convincing neither..
[16:22] <effie_jayx> what is the rationale for not including any php4 in gutsy?
[16:24] <RainCT> effie_jayx: it won't be supported anymore soon
[16:25] <RainCT> (if they haven't dropped support for it already)
[16:25] <RainCT> (not sure about the exact date..)
[16:25] <effie_jayx> RainCT,  many apps still depend on php4
[16:26] <Ubulette> persia, could you be more specific about point 11 and 14 for seamonkey ?
[16:26] <RainCT> effie_jayx: then it's upstreams problem to fix them, php4 is dead
[16:26] <effie_jayx> RainCT,  I see...
[16:26] <RainCT> effie_jayx: hosting providers are also switching to php5 now (mine allows to use both since over 6 months already, configuring it with a .htaccess)
[16:27] <RainCT> (but they will drop php4 soon)
[16:29] <txwikinger> Bug #175106 is reade for sponsoring if someone like to do it :)
[16:30] <ubotu> Launchpad bug 175106 in freedict "Spelling mistake in main description of package" [Undecided,In progress] https://launchpad.net/bugs/175106
[16:33] <pochu> dfiloni: ping - wxwidgets. How's it going? Could you please upload it to REVU, as today's REVU day? ;)
[16:35] <limac> ubotu: How do u get info on the new bugs as soon as they arrive?
[16:35] <dfiloni> pochu: is an hard work. I can upload <IP_ADDRESS> version that work great. Actually I'm working at <IP_ADDRESS> but I don't think I can finish today.
[16:36] <dfiloni> pochu: do you think I should upload <IP_ADDRESS> version?
[16:36] <RainCT> how can I check if a var is empty?
[16:37] <RainCT> in bash?  it has multiple lines so -n or -z don't work
[16:39] <pochu> dfiloni: pretty please, yes. You can upload <IP_ADDRESS> later when you have it.
[16:39] <pochu> dfiloni: but we need an wxwidgets update as soon as possible. :)
[16:40] <dfiloni> pochu: I have <IP_ADDRESS> now, but lintian show me a lot of warnings that I want to fix
[16:40] <dfiloni> Today I will upload <IP_ADDRESS>
[16:44] <pochu> dfiloni: cool, thank you!
[16:44] <pochu> dfiloni: let me know once you upload it :)
[16:45] <dfiloni> pochu: ok
[16:47] <RainCT> persia: got it working :)
[16:51] <cdm10> I asked here about packaging Python apps for Ubuntu, and was directed to learn how to use distutils... I have, and now that I've learned to put together a setup.py file, I now need to learn how to make a .deb out of it. I can use checkinstall, but that really doesn't put out proper results, it's mainly for personal use... so can someone help me figure out the proper tool for the job, and show me how to use it?
[16:54] <azeem> cdm10: did you take a look at a couple of existing python packages?
[16:55] <cdm10> azeem: source packages? Yes, I looked at pypolicyd-spf, but I can't make sense of the rules file.
[16:55] <azeem> try some others then, maybe
[16:56] <cdm10> azeem: ok, i'll look into that... I'm assuming most will be the same, though.
[16:56] <cdm10> azeem: do you know anything about what I'm trying to do here?
[16:57] <pochu> cdm10: using cdbs + python-distutils rule is really easy
[16:57] <cdm10> pochu: any sorta guide for that?
[16:57] <cdm10> pochu: or can you walk me through it? :)
[16:58] <pochu> cdm10: http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
[16:58] <cdm10> pochu: thanks, i'll read that
[16:58] <pochu> cdm10: basically add the debhelper rule and the python-distutils one, and you are done
[16:59] <pochu> (that for debian/rules, you need to tweak debian/control too)
[16:59] <oly_> RainCT, i have reuploaded to same place as before if you want to take a look
[16:59] <cdm10> pochu: yeah, i know the control stuff
[16:59] <RainCT> oly_: what was the url for the .dsc?
[17:00] <oly_> http://poke.servebeer.com/debtest/usm-core_0.2.dsc
[17:00] <RainCT> cdm10: see http://wiki.debian.org/DebianPython/NewPolicy
[17:00] <cdm10> ok
[17:00] <RainCT> cdm10: there is an example with cdbs there
[17:00] <cdm10> RainCT: alright, thanks
[17:00] <RainCT> np
[17:01] <cdm10> RainCT: oh, can you maybe answer a quick distutils question?
[17:02] <RainCT> cdm10: I can try, but I don't know much about it...
[17:03] <cdm10> RainCT: ok, well, might as well give it a try: I'd like to have my modules put into a subfolder of /usr/lib/python2.5/site-packages rather than just spewed into that folder, do you know what options to give it to do that?
[17:04] <cdm10> Oh, and what do I use to generate the debian filestructure?
[17:04] <RainCT> cdm10: I think it should create a subfolder there by default
[17:04] <cdm10> RainCT: what should?
[17:04] <cdm10> RainCT: oh, ok
[17:04] <cdm10> RainCT: well, it doesn't... I'll look into it further.
[17:05] <RainCT> cdm10: and cdbs + distutils will put the files automatically on their place
[17:05] <cdm10> RainCT: ok
[17:05] <RainCT> cdm10:  what you have to take care of are menu entries, icons, manpages, etc
[17:05] <RainCT> well, for manpages just create a file called "manpages" and write their name there
[17:05] <cdm10> RainCT: well, my setup.py does that.
[17:05] <RainCT> oh ok
[17:06] <RainCT> cdm10: then it should do everything automagically
[17:06] <cdm10> it's got my glade and .desktop files and all that.
[17:06] <cdm10> ok
[17:06] <RainCT> didn't know setup.py handles desktop files..
[17:06]  * RainCT will have to take some time to look at it
[17:06] <cdm10> RainCT: it can handle any data files you tell it to handle
[17:07] <pochu> cdm10: you need python-support or python-central for installing the module in /var/lib/python2.X/site-packages
[17:07] <cdm10> pochu: ok...
[17:08] <pochu> RainCT: well it doesn't handle them automagically, but you can tell them to install some files to some folders with data_files.
[17:09] <RainCT> pochu: ah. well, with the automagically I mean that cdbs will do everything if the setup.py is ok
[17:10] <RainCT> oly_: are you still arround?
[17:11] <oly_> yep
[17:11] <pochu> RainCT: I was talking about distutils and random files :)
[17:12] <RainCT> oly_: ok, let's see..
[17:14] <RainCT> oly_: 1. use same email in the changelog and in the control files
[17:14] <RainCT> and same name
[17:14] <oly_> okay
[17:14] <RainCT> oly_: 2. there are 2 build-depends fields in debian/control
[17:15] <RainCT> as I said before, the homepage should go above, near where the "Maintainer:" line is
[17:16] <oly_> hum, thats wierd i did move it, probably got confused with all the files
[17:16] <RainCT> Vcs-Bzr is for a repository containing the package source, not for upstream's
[17:16] <RainCT> (and the url is wrong anyways :P)
[17:16] <oly_> shall i just remove that line altogether then
[17:17] <RainCT> if you won't put the package source on any repository, yes
[17:17] <oly_> well i guess theres no point putting the source anywhere because its python
[17:17] <oly_> the app is the source :p
[17:18] <RainCT> debian/copyright: "Author(s)" should be either "Author" or "Authors". Also replace "usmteam" with the names and email's of the developers
[17:18] <RainCT> on the upstream authors part, "usmteam" as copyright holder is fine
[17:20] <RainCT> oly_: remove the comments on the top of the debian/rules file
[17:20] <RainCT> and the make stuff
[17:21] <oly_> okay think i have done all of those
[17:21] <RainCT> (actually, I would recomment switching to cdbs as then you could drop the rules file completly)
[17:22] <oly_> okay, i may have a try and see :)
[17:22] <oly_> would i still need the install file in debian with cdbs ?
[17:23] <RainCT> yes
[17:23] <oly_> okay,
[17:24]  * RainCT is away
[17:24] <jpatrick> !away > RainCT
[17:25] <RainCT> jpatrick: I know, but oly_ might want to know that I'm away
[17:25] <RainCT> :P
[17:37] <StevenHarperUK> Does anyone know when the next Community - Council meeting is (https://wiki.ubuntu.com/CommunityCouncil) - the event isn't in the calendar (http://fridge.ubuntu.com/event/2007/12/01/month/all/all/1) - but it appears that they are every 2 weeks - the last was on the 29th November - so will the next be on the 13th Dec? (also it would be great if the correct date was posted on the wiki page)
[17:43] <cdm10> I'm trying to used cdbs to package my python program (which uses distutils)
[17:43] <cdm10> How do I generate the debian/ filestructure?
[17:44] <azeem> dh_make can generate a skeleton for you
[17:44] <bigon> cdm10: you can use dh_make to have a basic structure
[17:44] <cdm10> bigon: ok
[17:44] <cdm10> thanks
[17:45] <cdm10> bigon: what do i need to have in that directory for dh_make to work?
[17:46] <cdm10> bigon: it seems to want a tarball of some sort
[17:46] <bigon> you should have a tarball in the parent dir with the name project_version.orig.tar.gz
[17:46] <bigon> I thinks
[17:47] <bigon> s/s/
[17:47] <cdm10> bigon: hmm, got it to work without that
[17:47] <bobbo> If you have made a debdiff for a launchpad bug, how do you get it into Universe?
[17:48] <cdm10> I'm not sure what debian-native means...
[17:49] <lionel> bobbo: attach your debddiff on the launchpad bug and subscribe ubuntu-universe-sponsors
[17:49] <bigon> cdm10: where debian/ubuntu is upstream
[17:49] <bobbo> lionel, i have done that, do i just need to wait until someone decides to have a look at it now?
[17:49] <bigon> so you don't have an upstream tarball (and thus no diff.gz generated)
[17:50] <lionel> bobbo: yes, we process the queue quite frequently
[17:50] <bobbo> ok thanks lionel
[17:50] <lionel> bobbo: is it waiting there for a long time?
[17:50] <lionel> do you have a bug  number ?
[17:50] <bobbo> not really, just since this morning
[17:50] <bobbo> lionel its bug #66174
[17:51] <ubotu> Launchpad bug 66174 in showfsck "Man page is incorrect" [Low,In progress] https://launchpad.net/bugs/66174
[17:51] <bigon> is there any bash guru around?
[17:52] <cdm10> bigon: sorry, i'm new to packaging... what does that mean?
[17:52] <cdm10> bigon: (what you said before)
[17:52] <Ubulette> where is "new Debian menu structure" described ?
[17:54] <RainCT> Ubulette: http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5
[17:54] <dfiloni> pochu: wxwidgets2.8 uploaded :)
[17:54] <Ubulette> RainCT, thx
[17:54] <bigon> cdm10: if you package you have a tarball that comes from upstream, this tarball is normally never modified (same md5sum) all the changes you made (ie:adding a debian) is stored in a diff file
[17:55] <cdm10> bigon: so, a debian-native package never came from a tarball, and the .deb is the package released by upstream?
[17:56] <bigon> cdm10: no, a native package don't have a diff file because upstream is debian or ubuntu
[17:56] <pochu> dfiloni: great! thank you :)
[17:57] <bigon> cdm10: you can usually see if a package is native by looking at his version ( 1.0 is native and 1.0-1 is not)
[17:58] <cdm10> bigon: ok, so... debian/ubuntu is the releaser of the software?
[17:58] <bigon> yes
[17:58] <cdm10> alright.
[17:59] <cdm10> bigon: now, maybe you can help me with something else
[17:59] <cdm10> I've got a proper debian/ structure created by dh_make
[17:59] <cdm10> with a rules file and all that
[18:00] <cdm10> but dpkg-buildpackage gives me the error make[1]: *** No targets specified and no makefile found. Stop.
[18:00] <bigon> ok
[18:01] <bigon> you should modify the debian/rules to tell cdbs you package use distutils
[18:01] <cdm10> bigon: can i pastebin it?
[18:01] <RainCT> cdm10: http://wiki.debian.org/DebianPython/NewPolicy follow the instructions in section "CDBS + distutils"
[18:02] <pochu> Pretty please can any MOTU review wxWidgets 2.8? dfiloni has just uploaded it. I'll buy a beer or a drink to whoever does it ;-) Thanks in advance! Link is http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8
[18:04] <cdm10> RainCT: I copied their example debian/rules file, but I'm getting this error:
[18:04] <cdm10> debian/rules: 6: include: not found
[18:04] <cdm10> debian/rules: 7: include: not found
[18:04] <cdm10> debian/rules: 8: include: not found
[18:04] <LucidFox> Speaking of CDBS
[18:05] <dfiloni> pochu: why you need wxwidgets2.8?
[18:05] <LucidFox> Is CDBS preferable to plain debhelper?
[18:05] <pochu> dfiloni: aMule.
[18:05] <bigon> cdm10: do you install the cdbs package?
[18:05] <dfiloni> pochu: 2.20 version?
[18:06] <pochu> dfiloni: well it's a bug fix in a library and a lot of packages will benefit for it.
[18:06] <pochu> dfiloni: I can build 2.2.0 with current, but I want the bug fixes ;)
[18:06] <pochu> (In fact I built it yesterday)
[18:06] <bigon> LucidFox: question of taste, cdbs has maybe less granularity over plain debhelper
[18:06] <dfiloni> pochu: I know, for example filezilla 3.0.3 needs wxwidgets <IP_ADDRESS>
[18:07] <pochu> dfiloni: needs, as in requires?
[18:07] <cdm10> bigon: yes
[18:07] <cdm10> bigon: and, i tried dpkg-buildpackaging a source package i downloaded, and it workjed
[18:08] <dfiloni> pochu: when it build if you don't have <IP_ADDRESS> version it returns an error message
[18:08] <pochu> dfiloni: odd... another reason for uploading <IP_ADDRESS> ;)
[18:08] <cdm10> bigon: and i checked the paths... they exist.
[18:09] <cdm10> bigon: should i pastebin the file?
[18:09] <cdm10> http://pastebin.ca/810103
[18:15] <zul> afternoon
[18:16] <bluefoxicy> hi zul
[18:18] <zul> hi bluefoxicy
[18:20] <bluefoxicy> I wonder the potential for a 186MB xfce-based Ubuntu livecd
[18:21] <bluefoxicy> (for mini-CDR)
[18:21] <crimsun> sure, just remove a lot of the stuff that normally ships in -desktop
[18:21] <crimsun> (heck, one could probably do one GNOME-based)
[18:21] <bluefoxicy> crimsun:  I once figured I could fit an X server and XFCE4 core desktop on Damn Small Linux inside 30MB
[18:22] <bluefoxicy> (talking about kdrive vesa, not xorg)
[18:23] <bluefoxicy> iirc all the xlibs and such come down to 2MB compressed
[18:28] <bluefoxicy> yawn.
[18:28] <bluefoxicy> so I want to dig up some stuff from earlier and bounce some ideas around.  Any good place for this?
[18:30] <crimsun> ideapool/braindump?
[18:30] <crimsun> (I use tiddlywikis.)
[18:30] <dfiloni> persia: are you here?
[18:38] <bluefoxicy> crimsun:  I have a bunch of stuff from 3 years ago ... january 2005 heh.  Lemme upload it somewhere.
[18:38] <bluefoxicy> maybe I'll ping devel-discuss
[18:41] <bluefoxicy> argh this is pissing me off I can't argh argh arghhhhh... hmm.
[18:41]  * bluefoxicy figures out a way to host web sites from inside vmware
[19:03]  * pochu looks for a MOTU to review wxwidgets! http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8
[19:32] <Ubulette> LordKow, something like that http://paste.ubuntu.com/2591/ ?
[19:32] <LordKow> okay, thanks :)
[19:33] <LordKow> yea same thing. i was thinking that somewhere along the lines of using the hardy trees i messed around with policykit and/or user/group permissions because the only bug report about the problem was made by me with 0 comments
[19:33] <Ubulette> but I don't see that at home.
[19:34] <LordKow> i made a test package undoing some of the permission changes in rules and in the overrides but i feel its still not going to work because pulse gets built with configured policykit support now.
[19:34] <LordKow> i really dont use sound that much let alone ESD so i ended up uninstalling pulseaudio.
[19:35] <LordKow> brb
[19:35] <bigon> any (ba)sh guru here?
[19:36] <desertc> I think perhaps mplayer is a required for the package dvdauthor
[19:37] <Ubulette> bigon, ask your question directly
[19:38] <bigon> well pbuilder-dist is currently broken and I cant figure why
[19:38] <geser> what problem do you have?
[19:40] <bigon> on chroot creation I get E: Type '' is not known on line 1 in source list /etc/apt/sources.list
[19:41] <geser> have you tried to create the pbuilder base.tgz without that script and mv the base.tgz to the location the script expects?
[19:42] <bigon> pbuilder is working fine
[19:43] <ikonia> crimsun ping
[19:43] <crimsun> ikonia: the reason that Bart converted the installation to postinst is that if the tarballs fails download, it will block essential packages from updating.
[19:43] <crimsun> s/tarballs/tarball/
[19:43] <LordKow> meh i'll just use ESD, nottin wrong with it. :)
[19:43] <ikonia> crimsun: yes, I can see the reasoning behind that, but in doing so it's also created a false installation result
[19:44] <ikonia> crimsun: it's a double edged sword
[19:44] <crimsun> ikonia: what md5sum are you getting with 9,0,115,0?
[19:44] <ikonia> crimsun: let me see f I can access my gutsy box, one moment
[19:45] <ikonia> crimsun: ./install_flash_player_9_linux.tar.gz' saved [3036127/3036127]
[19:45] <ikonia> I'm getting the same file size as you
[19:45] <ikonia> just getting checksums
[19:47] <crimsun> (it sure would be nice if upstream placed the precise version string in the filename...)
[19:47] <ikonia> crimsun: gutsy is still using flashplugin-nonfree_<IP_ADDRESS>.2+really0ubuntu12_i386.deb
[19:47] <ikonia> yes
[19:47] <ikonia> that would make it easier
[19:47] <crimsun> ikonia: yes, and IIRC there's a gutsy-backports request
[19:47] <ikonia> yes, there is in launchpad
[19:50] <ikonia> crimsun: have you got any information on the progress of that?
[19:51] <ikonia> crimsun: also I'd be very interested in looking at alternatives for the post section to valdiate the install before installing the ubuntu actual meta package
[19:51] <ikonia> synaptic users see it as "installed" when it is not
[19:52] <crimsun> ikonia: the real solution is to kill that source package and its generated binary package completely.
[19:52] <ikonia> yes, totally
[19:52] <ikonia> thats the ideal senario
[19:52] <SlimG2> Is there a global irc channel on freenode dedicated to ubuntu translation?
[19:52] <crimsun> ikonia: as for the processing of that source package, that's up to an archive admin.  I believe they generally work business hours (save a few volunteers).
[19:53] <pochu> SlimG2: #ubuntu-translators maybe?
[19:53] <pochu> SlimG2: dunno if it's official though ;)
[19:53] <ikonia> crimsun: yes, I don't think that would work on an individual archive basis
[19:53] <ikonia> I hadn't thought of it like that
[19:54] <SlimG2> pochu: Thanks, there's atleast some people there :)
[19:54] <jpatrick> hmm, how can I be sure that my gpg key is on the Accepted: lists?
[19:55] <RainCT> bigon: ubuntu-dev-tools from gutsy or hardy?
[19:55] <jpatrick> because I uploaded to the archives and it's not appearing in -changes, and I have no mail
[19:55] <bigon> RainCT: the bzr branch
[19:55] <bigon> RainCT: should also be broken in hardy
[19:55] <crimsun> without directly uploading a source package?  Create a junk branch of something hosted on bazaar.lp that uses ~ubuntu-dev
[19:55] <crimsun> ^ jpatrick
[19:56] <jpatrick> crimsun: no, I changed my gpg key and put it on LP days ago, and it doesn't seem to like it
[19:57] <RainCT> bigon: can you try if revision 35 worked?
[20:02] <crimsun> jpatrick: did you upload to keyserver.ubuntu.com?
[20:02] <jpatrick> crimsun: yes, like 3 days ago
[20:03] <jpatrick> crimsun: aha! just got the accepted email
[20:11] <crimsun> jpatrick: yeah, the ACCEPTED: lag is variable
[20:13] <LordKow> is there a shortcut for a run window or something with the same effect?
[20:14] <pochu> LordKow: Alt+F2
[20:15] <LordKow> danke
[20:26] <bluefoxicy> Finally
[20:26] <bluefoxicy> it took enough ssh hackery <_<
[20:26] <bluefoxicy> http://bluefox.kicks-ass.org:8080/plx/
[20:28] <bluefoxicy> that's all ages old stuff, and the Dazuko stuff is defunct (Fuse will have write-through support some day, the author has promised in 2.4), but eh.
[20:37] <LaserJock> afternoon
[20:37] <ScottK> LaserJock: Good afternoon.  Is what you pinged me about last night still relevant?
[20:38] <LaserJock> ScottK: probably not
[20:38] <ScottK> OK.  Just wanted to check.
[20:38] <pochu> C'mon folks, let's review wxWidgets, today's REVU Day! http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8
[20:39] <LaserJock> pochu: new upstream release?
[20:40] <Flare183> Flare183 is at Walmart
[20:40] <pochu> LaserJock: yup. dfiloni has packaged it.
[20:41] <limac> hey, when is the hardy release party? and is anyone invited to it or only the developers?
[20:41] <limac> hey Laser
[20:41] <limac> Jock
[20:41] <LaserJock> limac: what do you mean?
[20:42] <LaserJock> there are usually release parties all around the world and anybody is welcome
[20:42] <limac> LaserJock: When is the Hardy release party?
[20:42] <LaserJock> limac: after it's released
[20:42] <LaserJock> :-)
[20:42] <limac> LaserJock: The day it's released
[20:43] <LaserJock> well, sometimes the parties are a bit afterward
[20:43] <limac> LaserJock: And wat do u basically do in it?
[20:43] <LaserJock> I've never been to one
[20:43] <LaserJock> but I imagine have fun, install stuff, have more fun
[20:43] <limac> OK! thnx :)
[20:44] <limac> LaserJock: I/m planning to go to this one if on weekend
[20:51] <siretart> slomo: (or anyone else interested in ffmpeg and ppc): could you please have a look at svn+ssh://svn.debian.org/svn/pkg-multimedia/experimental/ffmpeg/debian and tell me if it builds on your ppc?
[20:51] <siretart> (you might to choose the http url on alioth instead)
[20:52] <TheMuso_> siretart: I'll have a look a bit later. I have a PPC, so can test build.
[20:54] <siretart> TheMuso: thanks!
[20:57] <siretart> TheMuso: you'll need to checkout from svn://svn.mplayerhq.hu/ffmpeg/trunk revision -r{2007-10-07}, and checkout the debian directory inside that. then you can build with 'debuild -b'
[20:57] <superm1> Hi can someone in ~ubuntu-backporters take a glance at bug 173684?  imbrandon asked for a build log to make sure it built fine
[20:57] <ubotu> Launchpad bug 173684 in gutsy-backports "Please backport mythstream 0.18.1 from hardy" [Undecided,New] https://launchpad.net/bugs/173684
[20:58] <siretart> TheMuso: the debian branch can be checked out like this: svn://svn.debian.org/pkg-multimedia/experimental/ffmpeg/debian
[21:03] <TheMuso> siretart: Ok thanks.
[21:03] <bigon> RainCT: the 35 revision doesn't work
[21:15] <jpatrick_> superm1: you should subscribe ubuntu-archive
[21:15] <superm1> jpatrick_, needed to get an ack from the backporters team first?
[21:16] <jpatrick_> ah right
[21:57] <siretart> mh. rebuildd on hardy seems to require still some tweaks..
[21:59] <proppy> oy
[22:00] <bigon> RainCT: I don't find how to fix the issue with pbuilder-dist :/
[22:00] <norsetto> proppy: yo
[22:01] <pochu> Who wants a hug?  I've got dfiloni asking for it all night :)
[22:03] <pochu> DktrKranz: wasn't that me? :)
[22:04] <RainCT> bigon: sorry, I've to go..
[22:04] <RainCT> good night
[22:04] <DktrKranz> pochu, you helped him spreading the word :)
[22:04] <bigon> RainCT: gn
[22:05] <DktrKranz> night RainCT
[22:05] <siretart> has anyone already seen build failiures like this? http://dpaste.com/27444/
[22:05] <DktrKranz> siretart, yes
[22:05] <RainCT> bigon: if you file a bug on https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools explaining what happens I'll try to have a look at it
[22:05] <DktrKranz> gcc 4.2 does not support anymore INT_{MAX,MIN}
[22:06] <siretart> DktrKranz: *gulp*
[22:06] <siretart> DktrKranz: and what's the fix for that?
[22:06] <DktrKranz> siretart, IIRC, defining two macros which do the job
[22:07] <siretart> DktrKranz: since when does gcc 4.2 do that?
[22:07] <siretart> gcc-4.2_4.2.2-4 at least didn't
[22:07] <DktrKranz> I've seen something similar in a fix by doko
[22:08] <siretart> hrmpf
[22:09] <crimsun> that seems a bit obtuse
[22:09] <crimsun> aren't climits or limits.h included?
[22:09] <pochu> DktrKranz: heh. wanna volunteer? ;)
[22:09] <crimsun> s/aren\'t/isn\'t/
[22:10] <siretart> DktrKranz: where have you seen doko fixing something like that?
[22:11] <DktrKranz> siretart, I'm looking
[22:14] <crimsun> yeah, I can't find anything stating that gcc-4.2 explicitly does not support INT_M{AX,IN}
[22:15] <Kmos> anyone knows how to fix this FTBFS: http://pastebin.com/d775d5a4d
[22:15] <Kmos> i've added libexpat1-dev to build-depends, but it doesn't fix it
[22:16] <siretart> more interestingly, there is no reference to INT_MAX in the cdio source
[22:16] <siretart> so it seems some included header is broken
[22:24] <persia> Ubulette: 11) is that I'm seeing copyrights I recognize for things like sqllite, libjpeg, etc., and I don't see build-depends for all of them.  This makes me suspicious that there is a security issue waiting to happen.  14) Is that the "Apps/foo" is deprecated.  Look in /usr/share/doc/menu/menu.txt.gz after installing the menu package.
[22:24] <persia> pochu: Taking a look at wxwidgets: Are you happy with the update?
[22:25] <pochu> persia: do you mean with the packaging or with the new release?
[22:25] <persia> pochu: Both.
[22:25] <persia> (or each, separately, if you like)
[22:25] <pochu> New release - yes. Update - haven't looked yet :P
[22:30] <pochu> persia: downloading
[22:31] <persia> pochu: Thanks.  Also, is there an upgrade bug?
[22:31] <Ubulette> persia: this is mentioned in the copyright file because those sources are in the tarball, yet, we build with their system equiv.
[22:32] <pochu> persia: yes, bug 133888
[22:32] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the <IP_ADDRESS> release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[22:32] <persia> Ubulette: That's perfect then.  I just didn't see everything in Build-Depends, but perhaps that's due to me not chasing recursion.  If you're sure, feel free to ignore 11)
[22:33] <Ubulette> libsoftokn3.so
[22:33] <Ubulette>         libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb7eff000)
[22:33] <persia> pochu: That'd be a good place to attach a build log if you like the update :)
[22:33] <Ubulette> well, I'm sure. i've build those mozilla beasts enough to be sure :)
[22:35] <persia> Ubulette: That's the important part: ignore it then.  Essentially, when I get to around 10) I start just noting things I notice that are suspicious, rather than doing a full investigation for each one.  I figure it's better to have a long list of things that need a look than half a list with the other half randomly appearing when the next upload happens.
[22:36] <Ubulette> indeed, that's better
[22:41] <Ubulette> do we really need to open merge bugs with "Please upload merge foo" now ?
[22:43] <persia> Ubulette: I like to open merge bugs whenever I'm working on a merge so that others know it's being worked on.  If you need sponsorship, having a bug is the best way to get sponsors attention.
[22:43] <Ubulette> i'm talking about the wording
[22:44] <Ubulette> before, the wiki used to say "Please merge foo" and "Please sync foo"
[22:44] <persia> Ubulette: That's a little odd.  Usually I use "Please merge foo" or "merge of foo", depending on how nice I want to be to the merger (me).
[22:45] <Ubulette> Set the bug title to: Please upload merge <sourcepackagename><debian-version> (repository) from Debian <repository> (<component>)
[22:45] <persia> Ubulette: Did the wiki change?  Which page? (I think that's wrong).
[22:45] <Ubulette> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[22:45] <Ubulette> https://wiki.ubuntu.com/UbuntuDevelopment/Merging#head-32f94fb74efce0c3a0123e984fc5292245272e32
[22:45]  * persia notes that it's essential to strike a balance between having the wiki be useful for new contributors and having it be accurate for long-term developers
[22:46] <Ubulette> Bug 175175
[22:46] <ubotu> Launchpad bug 175175 in valgrind "Please upload merge valgrind 3.2.3-3 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/175175
[22:47] <Ubulette> that sounds weird to me
[22:50] <Ubulette> persia, i have all the changes ready (except the menu one) for seamonkey but I need a sponsor for the version already posted 1st. could you do it ? asac already approved
[22:50] <Ubulette> or someone else, i don't mind :)
[22:51] <persia> Ubulette: I don't have time now (need to leave in 10 minutes), and I wonder why asac didn't upload when approving: would the sponsor not just be duplicating his review?
[22:51] <persia> Ubulette: Also, please check https://wiki.ubuntu.com/UbuntuDevelopment/Merging to see if the wording changes make sense to you.
[22:52] <Ubulette> yep, sounds better
[22:53] <Ubulette> persia, asac is not back yet.
[22:54] <persia> Ubulette: Ah.  No keys.  I understand :)
[23:26] <totopalma> ciao :), stacco.