[00:00] <jtimberman> there:   Uploading stompserver_0.9.9.orig.tar.gz: done.
[00:03] <mathiaz> jtimberman: great - thanks
[00:09] <DktrKranz> kirkland: re bug 415771, I can confirm package can be overwritten. It's in sync with Debian except for some little adjustments available in Debian version
[00:10] <kirkland> DktrKranz: cheers, thanks, drop a note in that bug, and i'll sync -f now
[00:10] <DktrKranz> done, thanks ;)
[00:11] <kirkland> DktrKranz: done ;-)
[00:11]  * DktrKranz hugs kirkland 
[00:12] <mathiaz> jtimberman: hm - the patches fail to apply on stompserver: http://paste.ubuntu.com/256002/
[00:13] <mathiaz> jtimberman: you may need to refresh the patches according to the series
[00:13] <mathiaz> jtimberman: and is the etcdir patch still necessary now that the fhs patch is there?
[00:13] <mathiaz> jtimberman: or could both be combined?
[00:13] <jtimberman> i'll combine
[00:13] <jtimberman> and make just fhs patch
[00:14] <jtimberman> mathiaz: added comments to chef, will upload in a moment.
[00:14] <mathiaz> jtimberman: ok - thanks.
[00:21] <jtimberman> mathiaz: stompserver updated
[00:26] <mathiaz> jtimberman: you've left stompserver-0.9.9/debian/.pc/.version
[00:26] <mathiaz> jtimberman: in the latest stompserver upload
[00:26] <jtimberman> bah!
[00:27] <mathiaz> jtimberman: and debian/patches/add_etcdir.patch
[00:27] <mathiaz> jtimberman: even though it has been removed from the series file
[00:28] <jtimberman> fixed
[00:28] <jtimberman> uploading
[00:28] <jtimberman> mm
[00:28] <jtimberman>   Uploading stompserver_0.9.9-0ubuntu1.dsc: 553 Could not create file.
[00:29] <jtimberman> ah. waiting a few minutes
[00:29] <mathiaz> jtimberman: right - it may take some time on the REVU side to clean things up
[00:29] <jtimberman> ya
[00:29] <mathiaz> jtimberman: I've fixed it in my local tree
[00:29] <mathiaz> jtimberman: and keep doing the review
[00:29] <jtimberman> :D
[00:30] <mathiaz> jtimberman: the reason for also uploading to REVU is for the other reviewer
[00:30] <mathiaz> jtimberman: who would also get the dsc, diff.gz and tar.gz files from REVU
[00:30] <mathiaz> jtimberman: (and not my local tree)
[00:30] <jtimberman> Yeah.
[00:32] <jtimberman> reuploaded stompserver, should have the .pc dir and the etcdir patch gone.
[00:33] <mathiaz> jtimberman: left another bunch of comments
[00:34] <jtimberman> pedantic is right, removing that path :)
[00:35] <james_w> it should contain a copy of the LGPL to comply with the license
[00:35] <mathiaz> jtimberman: actually - it's a lintian at level Warning  (the line starts with W)
[00:35] <mathiaz> jtimberman: so that should definetly be fixed before an upload to the archive
[00:35] <mathiaz> jtimberman: pedantic lintian messages are prefixed with a P
[00:35] <jtimberman> mathiaz: yeah i removed the aboslute paths
[00:37] <jtimberman> okay, stompserver updated.
[00:37] <mathiaz> jtimberman: trying to install the package leads to this error: http://paste.ubuntu.com/256011/
[00:37] <jtimberman> ah
[00:38] <jtimberman> stompserver creates the paths specified in the config file.
[00:38] <mathiaz> jtimberman: that's probably due to the fact that the daemon is running under a unpriviled account
[00:38] <jtimberman> but runs as the user
[00:38] <jtimberman> ya
[00:39] <jtimberman> what is the preferred way to create the directories?
[00:40] <mathiaz> jtimberman: what's the use of etcdir?
[00:40] <mathiaz> jtimberman: AFAICT it's only used for qstore=StompServer::ActiveRecordQueue.new(@opts[:etcdir], @opts[:storage])
[00:40] <jtimberman> mathiaz: not sure, we use stompserver with storage in memory.
[00:42] <mathiaz> jtimberman: http://paste.ubuntu.com/256015/
[00:42] <jtimberman> mathiaz: removing from the config file. whats the preferrred way to handle creation and ownership of /var/log/stompserver and /var/lib/stompserver? preinst?
[00:42] <mathiaz> jtimberman: that's the usage of etcdir
[00:42] <jtimberman> mathiaz: yeah looks like for running a queue in a rails app or something.
[00:42] <mathiaz> jtimberman: it expects a database.yml
[00:43] <jtimberman> if its used.
[00:43] <mathiaz> jtimberman: set ownership of /var/{lib,log}/stompserver/ in the postinst script
[00:43] <mathiaz> jtimberman: as the directories are part of the package (via the dir file)
[00:43] <mathiaz> jtimberman: they will be created when the package is installed
[00:43] <jtimberman> ok
[00:44] <mathiaz> jtimberman: ownership and permission should be set in the postinst script
[00:45] <jtimberman> a la http://paste.ubuntu.com/256018/?
[00:45] <jtimberman> er, http://paste.ubuntu.com/256018/
[00:45] <mathiaz> jtimberman: you don't need to mkdir the directories
[00:46] <mathiaz> jtimberman: they're part of the package and will be created by dpkg during the installation
[00:46] <jtimberman> o
[00:46] <mathiaz> jtimberman: however the ownership and permissions need to be set
[00:46] <jtimberman> so just the chown line
[00:46] <mathiaz> jtimberman: I've found a bug in http://paste.ubuntu.com/256015/
[00:46] <mathiaz> jtimberman: yes
[00:46] <mathiaz> jtimberman: storagedir is not used at all in the initialize function
[00:47] <mathiaz> jtimberman: #{configdir}/stompserver_development should be #{storagedir}/stompserver_development
[00:47] <jtimberman> I'll file a bug upstream
[00:48] <mathiaz> jtimberman: and if you could fix the bug in the package too that would be great.
[00:48] <mathiaz> jtimberman: other wise stompserver is going to store data in /etc/stompserver/
[00:48] <mathiaz> jtimberman: which is not something we wanna encourage
[00:48] <jtimberman> yeah and that's not fhs
[00:48]  * mathiaz nods
[00:50] <mathiaz> jtimberman: note that this bug is properly introduced by the fhs patch.
[00:50] <mathiaz> jtimberman: hm well may be not.
[00:51] <jtimberman> i added a patch for it
[00:53] <jtimberman> uploaded
[00:54] <mathiaz> james_w: the LGPL license is mentioned in the copyright file because the setup.rb script is under LGPL
[00:54] <mathiaz> james_w: however all the upstream code is under MIT
[00:54] <mathiaz> james_w: which is listed in the README.txt in the upstream tarball
[01:00] <jtimberman> mathiaz: oops, fixed missing descriptoin in that patch, also uploaded chef.
[01:00] <mathiaz> jtimberman: right - and you've also left the change in lib/stomp_server/queue/activerecord_queue.rb
[01:00] <mathiaz> jtimberman: $ lsdiff -z stompserver_0.9.9-0ubuntu1.diff.gz
[01:00] <mathiaz> jtimberman: lists stompserver-0.9.9/lib/stomp_server/queue/activerecord_queue.rb
[01:00] <jtimberman> quilt refresh ; quilt applied ?
[01:01] <mathiaz> jtimberman: hm - the clean target should take care of that unapplying all the quilt patch
[01:01] <mathiaz> jtimberman: etcdir was also remove from debian/stompserver.conf
[01:01] <mathiaz> jtimberman: why?
[01:02] <jtimberman> might have had wrong config file open in my edit window
[01:03] <mathiaz> jtimberman: I still think etcdir is needed in the stompserver.conf file
[01:04] <mathiaz> jtimberman: however that means that /etc/stompserver/ needs to be added to the dirs file
[01:04] <jtimberman> it should be in dirs then, and added to postinst for chown
[01:04] <mathiaz> jtimberman: and ownership set correctly in posting
[01:04] <jtimberman> can that be chowned stompserver?
[01:04] <mathiaz> jtimberman: yes
[01:05] <mathiaz> jtimberman: all of the directories should be create and have correct ownership before the stompserver is started
[01:05] <mathiaz> jtimberman: since all of the code to do so is placed before the #DEBHELPER# token
[01:06] <jtimberman> interesting.
[01:06] <jtimberman> magic
[01:06] <mathiaz> jtimberman: which is where the init script start call is put by dh_installinit
[01:07] <jtimberman> not sure why that activerecord file is getting in
[01:10] <jtimberman> clean wipe and recreate works :)
[01:10] <jtimberman> mathiaz: uploaded stompserver again, gotta run for a couple hours.
[01:10] <mathiaz> jtimberman: sure - np.
[01:11] <jtimberman> mathiaz: thanks for your help!
[01:11] <mathiaz> jtimberman: ze IntraWebs will be around for some more time
[01:11] <mathiaz> jtimberman: you're welcome !:)
[01:11] <jtimberman> mathiaz: oh, can you look at the chef package now?
[01:11] <jtimberman> should have all the copyright stuff in etc.
[01:12] <mathiaz> jtimberman: yop - looking at it.
[01:12] <mathiaz> jtimberman: I'll leave my comments (if any) there.
[01:12] <jtimberman> great, thanks!
[01:56] <binarymutant> does 'bzr branch lp:ubotutn' just work in Ubuntu or does it work with all bzr?
[01:57] <Ampelbein> binarymutant: works at least in debian/unstable, too.
[01:58] <binarymutant> ty Ampelbein :D
[02:31] <pochu> anybody around running jaunty + gnome?
[02:33] <pochu> nevermind
[06:19] <dholbach> good morning
[06:19] <fabrice_sp> Hey dholbach!
[06:19] <dholbach> heya fabrice_sp
[06:37] <fabrice_sp> dholbach, about bug #414561 and the FTBFS. It has to be synced after #414558. I've just updated the bug report.
[06:37] <dholbach> fabrice_sp: does it need a depends or build-depends or something then?
[06:38] <fabrice_sp> there is already a build-depends. It's only that the version is not in the build-depend
[06:39] <dholbach> ah, I see
[06:39] <dholbach> ok, thanks
[06:39] <fabrice_sp> also according to ttx, it's better not to try to fix any maven package it in Ubuntu: it's a moving target in unstable actually
[06:39] <dholbach> ping me once the sync and binary-new-ing has happened
[06:39] <fabrice_sp> yw :-)
[06:40] <fabrice_sp> ok
[06:40] <fabrice_sp> so, some volunteer to sponsor bug #414558 ? :-)
[06:41] <dholbach> Daniel Holbach  wrote 30 minutes ago:
[06:41] <dholbach> ACKed.
[06:41] <dholbach> fabrice_sp: ^
[06:41] <dholbach> you're a bit late to the party :)
[06:41] <fabrice_sp> ah coool :-)
[06:41] <fabrice_sp> I know :-) My email has some lag ;-)
[06:42] <fabrice_sp> you're right: I missed that email. Thanks! :-)
[06:43] <dholbach> no worries
[08:58] <stochastic> Is there any way to find all the packages in the repos that contain a particular filetype (similar to 'dpkg -s .file' but that only works on installed packages) ?
[09:06] <wgrant> stochastic: Try apt-file.
[09:13] <slytherin> Has anyone tried voice and video in pidgin already? :-D
[10:53] <blackmoon> hi, how can i check if a config file already exist when a deb package is installed? (and show to user: take old version, install new version or show differences) there is a specific way or i must do it with a bash script?
[10:56] <sistpoty|work> blackmoon: if it's marked as a conffile, dpkg will already do that for you. By default, everything under /etc is marked as a conffile
[11:04] <blackmoon> sistpoty|work: the config file are under /etc, so i don't do nothing, right?
[11:27] <ghostcube> hi
[11:30] <binarymutant> I'm having problems with sourceforge in my watchfile, right now I'm using "http://sf.net/{project name}/{filename}-(.*)\.tar\.gz". It was working all year without problems, but what's up with it now?
[11:31] <pochu> binarymutant: it uses a redirection in Debian, maybe that's down?
[11:32] <pochu> btw your syntax seems correct according to uscan(1)
[11:34] <binarymutant> pochu, so I should just give it awhile for the redirect to come back up?
[11:35] <pochu> binarymutant: maybe :)
[11:35] <binarymutant> thanks for the input pochu
[11:35] <pochu> yw
[11:38] <sistpoty|work> blackmoon: yep
[11:41] <Laney> it's a known problem with the sf redirector
[11:41] <Laney> binarymutant: ^
[11:41] <blackmoon> sistpoty|work: ok, thank you
[11:41] <Laney> try #debian-qa
[11:41] <sistpoty|work> np
[11:41] <binarymutant> Laney, ty
[11:49] <directhex> which is why i just use mirrorservice.com for SF
[11:51] <binarymutant>  /me checks it out
[11:56] <slytherin> binarymutant: by the way you can improve the syntax to ([\d\.]+).tar.gz to only detect release versions i.e. skip the tarball with beta, rc in name :-)
[11:58] <binarymutant> slytherin, thankfully upstream doesn't ever do that, but if it becomes an issue I'll change the regex
[11:58] <pochu> ember_: you're in Debian NEW! :)
[12:00] <Laney> Bah
[12:00] <Laney> I hate it when differences between buildds and sbuild/pbuilder crop up
[13:49] <juli__> Hello! Could somebody advise me where I can read about "Section" filed in control file. I mean which Section  (java, libs, etc.) I should choose in different cases. Thanks in advance.
[13:49] <james_w> hi juli__, I'm not aware of a location for that unfortunately
[13:50] <c_korn> juli__: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[13:50] <directhex> was about to say, debian policy
[13:50] <james_w> but that doesn't say why you should choose
[13:51] <directhex> james_w, you guess, get it wrong, and ftpmaster overrides it to what THEY think it should be
[13:51] <Laney> try this http://packages.debian.org/unstable/
[13:51] <directhex> in special cases they'll even invent a new section for you without consulting you
[13:52] <james_w> that's not particularly constructive
[13:52] <Laney> that's the best I know of
[13:52] <james_w> juli__: if you pastebin your debian/control then we can try and give some advice
[13:52] <james_w> sorry Laney, I didn't mean you
[13:52] <Laney> juli__: ^ that was to you, sorry
[13:52] <Laney> james_w: I know :)
[13:54] <sistpoty|work> maybe that has some hints about sections: http://lists.debian.org/debian-devel-announce/2009/03/msg00010.html
[13:55] <james_w> yeah, good point
[13:55] <james_w> if it's libsomething-java then ftpmaster feels it should probably be in java
[13:55] <Laney> pick the most specific section you can
[13:55] <Laney> I think is a good rule
[13:55] <juli__> james_w, thanks! I just though there is more clear explanation then debian-policy. I'm  updating libnb-javaparser-java and just curious which section it should belong. May be "java" is better for this package.
[13:56] <Laney> "Everything about Java", seems good
[13:56] <directhex> sections are such a broken concept
[13:56] <Laney> debtags 4eva
[13:56] <james_w> yeah, sounds like java is the best bet for that package
[13:57] <juli__> hm.. ok. But is there any difference between Section for source package and for Section for binary packages?
[13:57] <ttx> asac: about bug 416387... easymock doesn't compile with gcj-jdk. Setting it to default-jdk would break in Debian, so creates a unmergeable delta (until they switch default-jdk there) so I guess in this precise case it makes sense to keep forcing openjdk-6-jdk ?
[13:57] <directhex> Laney, exactly. how useful is a "java" section? why no "c++" section? consistency is in short supply
[13:58]  * Laney shrugs
[13:58] <james_w> juli__: they can be separate sections if needed
[13:58] <Laney> just do what the boss wants you to do
[13:58] <james_w> juli__: e.g. if it builds a -doc package as well, then the source and the main binary would be "java" and the -doc package "doc"
[13:58] <juli__> Laney, the boss?
[13:59] <Laney> ftpmaster
[13:59] <sistpoty|work> directhex: don't complain, you already got your mono section :P
[13:59] <asac> ttx: yes. please drop the comment in the bug and i set it to wont fix to reflect that its ok
[13:59] <ttx> asac: sure. Thanks for your help, btw :)
[13:59] <asac> ttx: if you disagree on other bugs let me know
[14:00] <directhex> sistpoty|work, we didn't *want* it! especially not with a mono-specific name, given the work that goes into allowing you to use any cli framework (which, yes, we only have mono packaged right now, but it's like having an "openjdk" section)
[14:00] <slytherin> ttx: debian has already switched default-jdk
[14:00] <ttx> slytherin: ah-ah.
[14:00] <ttx> slytherin: since when ?
[14:00] <juli__> james_w, Laney Thank you!
[14:00] <sistpoty|work> directhex: tststs, there you get s.th. special and then aren't even grateful :P
[14:00] <slytherin> ttx: been about three weeks. Both unstable and testing have default-jdk pointing to openjdk on most arch.
[14:01] <ttx> slytherin: cool !
[14:01] <ttx> will fix that bug, then.
[14:01] <asac> ttx: ok ... so we can do that now?
[14:01] <asac> great.
[14:01] <asac> ttx: maybe drop the argument in the bug ;)
[14:01] <asac> (why its in fact ok to keep it ;))
[14:02] <asac> ttx: also if there are questions, ping me explicitly. i am bad at reading my bugmail
[14:11] <slytherin> ttx: will you have some time over weekend for a package review? I am working on something and should have package ready by Sunday.
[14:12] <ttx> slytherin: I won't promise anything. It's pre-FF madness already here. But yes, ping me about it.
[14:12] <slytherin> thanks. :_)
[14:13] <dholbach> nhandler: james_w was thinking we could do another on-call review session in the packaging training world - unfortunately I can't attend, I have the global jam meeting at the same time
[14:17] <RoAkSoAx> DktrKranz, heya there!! Please don't forget to review lekhonee when you have some free time :)
[14:17] <DktrKranz> RoAkSoAx: I gave it a go some days ago, did you upload a new version?
[14:21] <RoAkSoAx> DktrKranz, oh no. I just noticed that you commented on it, I havent been around the past few days, sorry :) I'll take a look at it. thanks
[14:21] <DktrKranz> RoAkSoAx: no hurry, I'm out for work today, so I can't have a look at it until tomorrow/weekend
[14:22] <RoAkSoAx> DktrKranz, ok :) I'll ping you when ready. Thanks
[14:52] <mcnicholls> Just been looking at the netplug ftbfs and found it's quite simple to fix, but the package is patchless. Am i best emailing the Debian maintainer explaining the fix and seeing if he can release a new version or should i try to add a patch system to the Ubuntu package?
[14:54] <Laney> mcnicholls: Please submit your patch to both Debian and Ubuntu, but don't add a patchsys
[14:55] <Laney> If the Debian maintainer fixes it quickly then you can request a sync, so it might be worth leaving it for a few days in the BTS to see
[14:56] <mcnicholls> Laney: BTS? would i be best just submitting a diff to a bug report on launchpad to submit it to Ubuntu? Not sure how i submit to debian.
[14:57] <thom> hey guys; i have motu on launchpad, how do i get revu to acknowledge that? (account name is thombot, for reasons best known to the sabdfl way, way back when)
[14:57] <Laney> mcnicholls: reportbug -B debian
[14:58] <Laney> thom: you need a REVU admin
[14:58] <Laney> (no, I don't know)
[14:59] <jtimberman> Any MOTU around able to review http://revu.ubuntuwire.com/p/merb for upload?
[15:01] <mcnicholls> Laney: cheers, think i am best filing it with Debian and checking my patch is ok, can then see how long before they rebuild to see if it needs patching in Ubuntu or jsut a sync
[15:01] <Laney> yes
[15:01] <mcnicholls> s/jsut/just
[15:02] <Laney> FTBFS bugs are RC so if the maintainer is unresponsive then you can get it uploaded to Debian anyway
[15:03] <bddebian> Heya gang
[15:04] <Laney> hi hi
[15:04] <sistpoty|work> hi bddebian
[15:04] <bddebian> Hi Laney, sistpoty|work
[15:04] <mcnicholls> RC?
[15:04] <geser> Release Critical
[15:04] <mcnicholls> oh release critical
[15:05] <mcnicholls> ;-)
[15:08] <mcnicholls> only other thing is it ftbfs because of not checking the return value from write, but i guess this isn't a priority for them in Debian? Although sticking to the above course of action is still appropriate?
[15:08] <sistpoty|work> thom: done
[15:09] <Laney> if it doesn't ftbfs in Debian then it's not RC there
[15:10] <mcnicholls> no, but i should still file a bug there or just fix it for Ubuntu?
[15:10] <Laney> sure, go ahead
[15:10] <Laney> but I wouldn't expect the maintainer to prioritise an upload for it
[15:13] <mcnicholls> no, so the most likely outcome is that it will be fixed in Debian eventually, but i may need to fix it in Ubuntu until that fix is uploaded to Debian and synced down.
[15:13] <Laney> sounds right
[15:13] <iulian> Hey bddebian.
[15:15] <mcnicholls> ok thanks for that. will have a got at submitting it to Debian.
[15:19] <thom> sistpoty|work: tyvm :)
[15:19] <sistpoty|work> np ;)
[15:22] <bddebian> Hi iulian
[15:46] <mcnicholls> should diff's submitted as patches be created from something like diff -rcu source-orig source-modified > patch.diff
[15:46] <mcnicholls> should diff's submitted as patches be created from something like diff -rcu source-orig source-modified
[15:47] <mcnicholls> opps sorry about that. only meant it once.
[15:47] <mcnicholls> just want to include my diff on the Debian bug report, but want to make sure it is in a useful format
[15:52] <mcnicholls> hmmmm i suspect maybe -ru is what i am after.
[15:53] <jtimberman> mathiaz: stompserver should be good to go now. lintian clean on built and source package, installs and purges cleanly, and of course the service starts properly :)
[15:54] <dholbach> mcnicholls: you could try debdiff - https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[15:54] <mathiaz> jtimberman: I've seen the uploads - reviewing it now
[15:54] <dholbach> mcnicholls: ... if you're not diffing across new upstream versions (in that case you'd end up with the upstream changes in the diff also)
[15:55] <dholbach> mcnicholls:     diff -ruN project-{oldversion,newversion}/debian    maybe?
[15:55] <dholbach> as usual: there's more than one way :)
[15:55] <Laney> debdiff | filterdiff is useful I find
[15:58] <mcnicholls> cheers guys. in the end i went for diff -ru oldversion newversion but it was just for one file anyway, just so i could illustrate the changes in the source as a suggested patch.
[15:59] <mcnicholls> not used filterdiff before, used to filter out certain files from a diff?
[15:59] <Laney> out or in, your choice
[16:01] <mcnicholls> so in the event that i do submit a bug and patch to Ubuntu (because the Debian upload will not be for a while) is it useful for me to link the Ubuntu bug to the Debian one?
[16:02] <Laney> the other way round
[16:04] <mcnicholls> I would somehow use the Debian bug tracker to link that bug to the one in Ubuntu?
[16:05] <jtimberman> mathiaz: thanks :D
[16:23] <gilir> persia: when you will be around, please add me to the ubuntu-universe-sponsors team
[16:36] <persia> gilir, Done.  Welcome.
[16:37] <gilir> persia: thanks :)
[16:50] <micahg> nmap warnings aren't SRU worthy are they?
[17:07] <c_korn> can I tell dh_install to dereference links? so if there is a libfoo.so in the source tree which links to out/libs/libfoo.so I just enter libfoo.so in the install file and actually get the file in out/libs instead of the link ?
[17:24] <EagleScreen> hello
[17:24] <EagleScreen> is it useful if I sync requested packages to my ppa?
[17:25] <prefrontal_> Coin3D Systems in Motion has switched away from using the package SoQt. they developed new software called Quarter to replace it: http://www.coin3d.org/lib/quarter
[17:27] <prefrontal_> SoQt is in the repositories but Quarter is not, even though SoQt is deprecated. SoQt hasn't been touched in 2 years, Quarter is undergoing active development
[17:27] <prefrontal_> unfortunately this means I cannot put our software into the universe unless I also package Quarter. but it seems like Quarter would be something the motus would want to bring into the fold..
[17:27] <prefrontal_> thoughts?
[17:52] <EagleScreen> hi
[17:53] <EagleScreen> I want to make  a sync of a newer Debian version of a package that there is already in Ubuntu, how must I proceed?
[17:54] <EagleScreen> what must I do with the changelog?
[18:00] <c_korn> EagleScreen: https://wiki.ubuntu.com/SyncRequestProcess
[18:20] <EagleScreen> i mean make the sync myself, not requesting a sync
[18:20] <EagleScreen> i am learning uubntu packaging
[18:21] <EagleScreen> is there any programm that makes the syncs automatically, or are syncs made by developpers by hand?
[18:23] <joaopinto> EagleScreen, have you read the wiki :) ?
[18:23] <EagleScreen> this wiki?  https://wiki.ubuntu.com/SyncRequestProcess
[18:24] <joaopinto> yes
[18:24] <EagleScreen> yes
[18:24] <EagleScreen> it is for requesting a sync
[18:24] <joaopinto> so you missed the part where it refers who performs the sync
[18:24] <sebner> EagleScreen: contributors *must* file sync requests, MOTUs have to ACKnowledge them and then an archive-admin processes the sync by hand
[18:25] <joaopinto> "Ubuntu developers should subscribe (NOT assign) the ubuntu-archive team to the bug directly. This team will process the request and close the bug when it is complete. Please only subscribe ubuntu-archive to a bug once you have a clear action for the archive team to perform. Do not ask ubuntu-archive to help you decide what to do. "
[18:26] <kaushal> hi
[18:26] <kaushal> when is pidgin 2.6.1 going to be available under Ubuntu Hardy ?
[18:27] <kaushal> http://pidgin.im/download/
[18:27] <EagleScreen> yes, but i don't want to request any sync by the moment, because it is already requested, i am interested in technical packaking methods for syncing
[18:28] <kaushal> EagleScreen, are you referring to me ?
[18:29] <EagleScreen> not kaushal, but i am interested in learning and practice packaging, i may do a backport package fot pidgin 2.6.1
[18:29] <kaushal> great
[18:29] <fabrice_sp> kaushal, it has to go first in karmic
[18:29] <sebner> EagleScreen: there is nothing to do regarding packaging when requesting a sync, maybe testbuilding but you don't do anything with the source package from debian
[18:30] <kaushal> whats the next version of karmic
[18:30] <kaushal> I mean next release of ubuntu after karmic
[18:30] <dholbach> Ubuntu Global Jam meeting in 30m in #ubuntu-meeting
[18:30] <kaushal> I believe its not yet released to public by Mark Shuttleworth
[18:31] <fabrice_sp> kaushal, it has to go first in Debian, anyway (debian has 2.5.9)
[18:31] <EagleScreen> negative it is not public yet
[18:31] <EagleScreen> sebner: then how is a sync made?
[18:32] <kaushal> fabrice_sp, ok
[18:33] <EagleScreen> dveloppers who make syncs don't use Debian source package?
[18:36] <fabrice_sp> EagleScreen, sync is perfomr by archive admin
[18:36] <fabrice_sp> EagleScreen, if you want to practice some packaging, you can do a merge or fix a FTBFS
[18:37] <EagleScreen> I dont know if you are understanding me, i want to be a MOTU developper in the future, i am getting started in Debian/Ubuntu packaging, and i need to learn to do things, for instance, to sync packages from Debian, I can start by practice syncs from Debian to me ppa
[18:37] <jtimberman> EagleScreen: MOTU don't sync packages from Debian.
[18:38] <fabrice_sp> you will learn a lot more fixing bugs (FTBFS, for example), than just syncing (fdonwloading/uploading)
[18:38] <EagleScreen> who sync packages that goes in universe?
[18:38] <fabrice_sp> a sync a just a downlaod and an upload
[18:38] <jtimberman> EagleScreen: Archive admins.
[18:38] <fabrice_sp> EagleScreen, Archive admin, as I told you before
[18:38] <EagleScreen> yeah
[18:38] <EagleScreen> okay
[18:39] <jtimberman> One more advocate needed for stompserver - anyone available to review? http://revu.ubuntuwire.com/p/stompserver
[18:39] <jtimberman> mathiaz: i'm going to update chef with some of the things we've worked through on stompserver.
[18:40] <mathiaz> jtimberman: great - I'll wait for a new upload of chef then
[18:40] <EagleScreen> i already have made debdiffs fixing small bugs in packages, what is the next step?
[18:50] <porthose> EagleScreen, https://wiki.ubuntu.com/SponsorshipProcess
[18:54] <jtimberman> mathiaz: uploading now, looks like just logrotate, as we're not creating a user.
[19:08] <fabrice_sp> !packaging | fabrice_sp
[19:27]  * hyperair grumbles about codelite being problematic
[19:35] <mathiaz> jtimberman: reviewing chef - the clean target doesn't work as expected: InstalledFiles and .config are left in the source tree
[19:38] <mathiaz> jtimberman: regarding ttx T1 remark: even though the dh-make template script is wrong (return 1) the chef init scripts could still return the correct value
[19:38] <mathiaz> jtimberman: logging a bug against dh-make would be helpful in addition
[19:44] <jtimberman> mathiaz: how do i test the clean target? run dh_clean from the source tree?
[19:44] <mathiaz> jtimberman: debclean
[19:47] <jtimberman> ah
[19:51] <jtimberman> hurm, clean target does rm -f $(DEB_SRCDIR)/.config and $(DEB_SRCDIR)/InstalledFiles...
[19:58] <Zhenech> hyperair, accepted!
[20:04] <mathiaz> kirkland: when you run licensecheck and see a bunch of file with "*No copyright* UNKNOWN", what do yo do?
[20:09] <jtimberman> mathiaz: what creates InstalledFiles and .config?
[20:10] <mathiaz> jtimberman: I guess the setup.rb file
[20:10] <mathiaz> jtimberman: I'm not familiar enough with the ruby setup infrastructure.
[20:10] <mathiaz> jtimberman: it may have been transient
[20:11] <mathiaz> jtimberman: I'm almost finished with another round of comments
[20:11] <jtimberman> mathiaz: on chef? or something lese?
[20:11] <mathiaz> jtimberman: chef
[20:11] <jtimberman> :)
[20:11] <jtimberman> Thanks
[20:11] <mathiaz> jtimberman: just before next upload check that the diff.gz has only files in debian/.
[20:11] <jtimberman> yeah
[20:14] <mzz> I've had lintian yell at me because of that, although I'm not sure if it only does it if it notices a "proper" patch system is also in use
[20:15] <mathiaz> jtimberman: hm - while trying to install chef chef-server chef-indexer chef-server-slice I get xulrunner-1.9 pulled in
[20:15] <mathiaz> jtimberman: that's probably an issue in one of the dependency though
[20:15] <jtimberman> Yeah..
[20:15] <jtimberman> because we sure don't need it for chef.
[20:15] <mathiaz> jtimberman: and rails gets pulled in as well
[20:16] <jtimberman> oohh.
[20:16] <jtimberman> mathiaz: chef-server requires couchdb, which requires erlang, which has a tcl/tk gui.
[20:16] <mathiaz> jtimberman: just out of curiosity why use stompserver for the messaging component?
[20:16] <jtimberman> so a bunch of X stuff gets installed.
[20:17] <hyperair> Zhenech: !!
[20:17] <jtimberman> mathiaz: thats what it was written with originally. version 0.8.0 of chef is going to use something else.
[20:17] <mathiaz> jtimberman: rabbitmq is another great solution
[20:17] <hyperair> Zhenech: now, to sync it =D
[20:17] <jtimberman> mathiaz: yup, and i believe that is what 0.8.0 uses.
[20:17] <Zhenech> hyperair, prolly not for karmic :P
[20:17] <mathiaz> jtimberman: cool.
[20:17] <mathiaz> jtimberman: when is 0.8.0 scheduled for?
[20:17] <hyperair> Zhenech: aw, why not? FF is 6 days away!
[20:18] <jtimberman> mathiaz: not set schedule yet, but we have an alpha release branch in the source and are testing it internally.
[20:18] <Zhenech> hyperair, huh? I thought debianfreeze was lang ago
[20:18] <jtimberman> Zhenech: feature freeze, not import freeze.
[20:18] <jtimberman> debian import freeze was a couple weeks ago. feature freeze is next Thursday
[20:18] <Zhenech> hm ok
[20:18] <hyperair> debian freeze is when autosyncs stop, isn't it? so this requires a manual sync request
[20:20] <Zhenech> then sync me rott please :)
[20:28] <bdrung_> Zhenech: hi
[20:34] <Zhenech> huhu bdrung_
[20:35] <Zhenech> bdrung_, if you want anything sponsored, give it now, I leave for a week in 16hours :)
[20:36] <bdrung_> Zhenech: i have many packages. ;)
[20:36] <bdrung_> Zhenech: but nothing with "colors" in it.
[20:37] <bdrung_> Zhenech: http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=esperanza
[20:37] <Zhenech> bdrung_, ok :)
[20:37] <bdrung_> Zhenech: http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=xmms2-scrobbler
[20:37] <Zhenech> It appears like this package is not owned by you.
[20:37] <Zhenech> meh
[20:37] <bdrung_> Zhenech: not owned, but i am an uploader.
[20:38] <bdrung_> Zhenech: i can give you a package that i own. :)
[20:38] <Zhenech> nah I'm not able to see the package at all
[20:38] <Zhenech> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=esperanza
[20:38] <Zhenech> thats the link I need
[20:38] <Zhenech> but xmms2 - no thanks :P
[20:39] <bdrung_> Zhenech: do you have something against xmms2?
[20:40] <hyperair> Zhenech: sync you rott?
[20:40] <Zhenech> hyperair, the "rott" package would be nice to have updated in ubuntu
[20:40] <hyperair> ah
[20:40] <hyperair> i see
[20:40] <Zhenech> bdrung_, "nix wirksames" :P
[20:41] <Zhenech> bdrung_, no nothing against it, just not using it and thus no real testcase here
[20:41] <bdrung_> Zhenech: :D
[20:48] <jtimberman> hurm, I have a chef-0.7.8/patches/remove_rubygems.patch is in the diff.gz, but also in debian/patches...
[20:49] <mathiaz> jtimberman: you mean that remove_rubygems.patch is actually applied in the diff.gz?
[20:49] <jtimberman> problem of not setting QUILT_PATCH directory?
[20:49] <jtimberman> mathiaz: yea
[20:49] <jtimberman> i think so
[20:50] <mathiaz> jtimberman: try to unapply the patch manually in the src tree
[20:50] <mathiaz> and rebuild the source package
[20:50] <jtimberman> unapply w/ quilt?
[20:51] <mathiaz> jtimberman: yes
[20:51] <jtimberman> do i need to have the QUILT_PATCH variable set in my shell?
[20:51] <jtimberman> er, QUILT_PATCHES.
[20:52] <jtimberman> ah geez, yes.
[20:54] <hyperair> mok0_: ping
[20:55] <hyperair> mok0_: bugs #416555 and #415092 (codelite bugs which cropped up over the past few days)
[20:55] <hyperair> it would be nice if you could upload the change that fixes both bugs for me. =)
[20:56] <bdrung_> Zhenech: if you are not busy enough, then you could sponsor pwdhash, too. http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=pwdhash
[20:57] <Zhenech> bdrung_, "not busy enough" does not exist in my language :P
[20:57] <Zhenech> but I look
[20:57] <bdrung_> Zhenech: "nicht ausgelastet genug" :)
[20:58] <Zhenech> bdrung_, pwdhash_1.7.orig.tar.gz (md5sum does not match) ...
[20:58] <bdrung_> Zhenech: or doesn't exists it in german?
[20:58] <bdrung_> wtf?
[20:59] <Zhenech> bdrung_, says dget compared to the orig in the archive
[20:59] <jtimberman> argh.
[20:59] <jtimberman> now all the patched files are in the diff.gz
[20:59] <Zhenech> bdrung_, forgot --pristine-tar?
[21:01] <bdrung_> Zhenech: debian/gbp.conf: pristine-tar = True
[21:01] <Zhenech> hmmm
[21:01] <Elbrus> what is the most proper way to rename files in the source? Upstream uses .po files with only to letters (limitations for Windows) while I want to use pt_BR. I thought a mv in config and in clean back... (conditionally)
[21:02] <Zhenech> % md5sum pwdhash_1.7.orig.tar.gz*
[21:02] <Zhenech> 4fdb294b53703803e8acb3e05960e5d3  pwdhash_1.7.orig.tar.gz
[21:02] <Zhenech> b97d4abfeecdd9e972f118353b1fabff  pwdhash_1.7.orig.tar.gz.archive
[21:02] <Zhenech> (.archive is the one in debian)
[21:03] <bdrung_> Zhenech: yes, even the file size differs
[21:04] <Zhenech> then fix it :)
[21:04] <bdrung_> Zhenech: done.
[21:04] <bdrung_> Zhenech: same location, correct orig file now.
[21:05] <Zhenech> yupp, sane now
[21:05] <Zhenech> what was it?
[21:05] <bdrung_> Zhenech: the version in debian and the pristine version differs
[21:07] <bdrung_> Zhenech: the pristine version is the version released by upstream, the orig file in debian is a repack
[21:08] <Zhenech> bdrung_, why repack?
[21:08] <bdrung_> Zhenech: don't know. same content, different compression rate / timestamp.
[21:09] <Zhenech> hmmm
[21:09] <Zhenech> ok
[21:09] <Zhenech> try to fix for next upstream version :)
[21:10] <bdrung_> Zhenech: yes. i maintain it since 1.7-2 in debian
[21:10] <LLStarks> hi.
[21:10] <LLStarks> libgtk1.2 needs to be packaged for karmic
[21:10] <bdrung_> LLStarks: isn't it outdated?
[21:10] <Zhenech> LLStarks, why?
[21:10] <LLStarks> libjsw packages like jscalibrator rely on it.
[21:10] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/gtk+1.2/+bug/416628
[21:10] <LLStarks> then remove jscalibrator or configure it for libgtk2.0
[21:11] <LLStarks> why is it in the repos if it can't be used?
[21:11] <mok0_> hyperair, got you message from earlier, will take a look
[21:12] <LLStarks> i technically could manually install libgtk1.2, but that's tedious
[21:12] <bdrung_> LLStarks: you are right. either should someone make it libgtk2.0 compatible or it should be removed.
[21:12] <ScottK> LLStarks: gtk1.2 has been removed because it's ancient and unsupportable.  It won't be added back.
[21:12] <bdrung_> LLStarks: it probably depends on upstream.
[21:12] <ScottK> bdrung_: That's correct.
[21:13] <LLStarks> i have to install 3 libgtk1.2 packages otherwise.
[21:13] <bdrung_> libgtk1.2 should be history. :)
[21:15] <ScottK> LLStarks: That or stick with an LTS release like Hardy that still has it.
[21:15]  * Elbrus going to bed...
[21:15] <LLStarks> jaunty has it
[21:15] <ScottK> That too.
[21:15] <LLStarks> so, should i ask for a libgtk2.0 repackaging?
[21:17] <jtimberman> mathiaz: heh, the log file is one of those weird merb things :)
[21:20] <mathiaz> jtimberman: could a symlink to /var/log/chef/ be added?
[21:20] <Zhenech> bdrung_, Iceweasel could not install this item because "install.rdf" (provided by the item) is not well-formed or does not exist. Please contact the author about this problem.
[21:20] <Zhenech> 3.5.2 that is
[21:20] <jtimberman> mathiaz: nah, i fixed it by specifying the log file on the merb commandline
[21:20] <jtimberman> the DAEMON_OPTS
[21:21] <mathiaz> jtimberman: even better :)
[21:22] <jtimberman> var/cache/chef on package removal, as in postrm scripts?
[21:23] <mathiaz> jtimberman: yes
[21:23] <jtimberman> ok
[21:23] <mathiaz> jtimberman: under a remove) - not a  purge)
[21:23] <bdrung_> Zhenech: found it.
[21:23] <Zhenech> bdrung_, -2 works
[21:24] <bdrung_> Zhenech: fix coming soon (with more testing)
[21:24] <Zhenech> :)
[21:30] <bdrung_> Zhenech: done. now it installes without errors.
[21:30] <bdrung_> same localtion as before
[21:31] <Zhenech> ok
[21:31] <Zhenech> what was the problem? :)
[21:32] <bdrung_> Zhenech: i have patches the install.rdf file and oversaw one point
[21:33] <Zhenech> k
[21:33] <jtimberman> mathiaz: new upload
[21:33] <Zhenech> whats the purpose of the patch anyways?
[21:33] <Zhenech> just removing :RDF everywhere?
[21:34] <Zhenech> but yes, works now
[21:34] <bdrung_> yes, removing :RDF.
[21:35] <Zhenech> what for?
[21:35] <bdrung_> the example extentions do not have the :RDF and with the :RDF mozilla-devscripts had problems parsing the file.
[21:36] <bdrung_> i want to use ${xpi:Depends}
[21:36] <Zhenech> ah, ok
[21:36] <Zhenech> then, please add this to the changelog and the header of thepatch
[21:36] <bdrung_> i implemented this feature together with asac
[21:36] <Zhenech> then I'll upload
[21:36] <Zhenech> *nitpick*
[21:37]  * bdrung_ documents the patch.
[21:38] <bdrung_> Zhenech: Remove :RDF from install.rdf for making it parsable by mozilla-devscripts.
[21:38] <bdrung_> thats the text
[21:38] <Zhenech> sounds ok
[21:41] <bdrung_> Zhenech: done. debian/change update, too.
[21:42] <Zhenech> bdrung_, thanks, fetching
[21:42] <jtimberman> mathiaz: ah, nm that one fails to build.
[21:45] <Zhenech> bdrung_, done
[21:45] <bdrung_> Zhenech: thanks
[21:46] <Zhenech> yw
[21:46] <bdrung_> Zhenech: now there are only xmms2 related packages remaining
[21:47] <Zhenech> bdrung_, "not-for-us" as buildds would say :P
[21:47] <bdrung_> :(
[21:49] <bdrung_> Zhenech: that means that i have to find someone else?
[21:50] <Zhenech> bdrung_, prolly yes
[21:50] <Zhenech> as said, I leave for a week of (hopefully) sunny spain
[21:50] <Zhenech> maybe I have more time after the trip
[21:51] <Zhenech> but I tend to sponsor only stuff I can use :)
[21:52] <bdrung_> Zhenech: i would like to find a sponsor sooner, because next week is feature freeze and these updates are needed.
[21:52] <Zhenech> then bother -mentors :)
[21:53] <bdrung_> Zhenech: already done.
[21:54] <bdrung_> Zhenech: CCed some people, who previously sponsored it / are maintainer.
[21:54] <Zhenech> maybe bdefreese wants to do when hes online
[21:54] <Zhenech> he loves cleanup :)
[21:55] <bdrung_> Zhenech: thanks. i will keep it in mind. in wich timezone do he live?
[21:56] <Zhenech> US something
[21:57] <porthose> bdrung_, I believe he is UTC -0500
[21:57] <porthose> not sure though
[22:02] <bdrung_> Zhenech: how long does it take till a package hits incoming?
[22:06] <Zhenech> when I get the accepted mail iirc
[22:29] <Laney> ScottK: geordi is uninstallable
[22:39] <jtimberman> mathiaz: okay, fixed.
[22:39] <whiteshep> Question for the group.  I recently switched from Windows to Ubuntu server.  Problem is in Windows when a program calls a directory of files it gives them alphabetical.  But under Ubuntu it gives the files in random order.  This random order messes up some gallery scripts and programs when it comes to sorting.  Aside from having to reprogram everything.  Is there a way to tell Ubuntu's file system (using ext3 atm) to give
[22:39] <whiteshep>  programs who request files in alphabetical order?
[22:40] <whiteshep> Hope that all got through?
[22:45] <jtimberman> whiteshep: how are you getting the directory contents for your listing?
[22:45] <jtimberman> hmm, though this may be more appropriate conversation on #ubuntu-server, rather than motu :)
[22:47] <whiteshep> I'm getting them through a compiled program I have writen as well as gallery scripts users are using.
[22:48] <whiteshep> Since the move the art files no longer come up in alphabetical order and users are complaining.  I was hoping there was like a tunefs option or perhaps a different file system that automaticly sorted files in alphabetical?
[22:48] <joaopinto> whiteshep, the support channel is #ubuntu, not here :)
[22:49] <whiteshep> Ah I'm sorry.  I'll keep looking.  Thanks anyways.
[22:55] <jtimberman> so when a package in revu has two advocates, about how long until it is uploaded?
[22:55] <jtimberman> when an archive admin gets to it?
[23:01] <mathiaz> jtimberman: are you refering to merb?
[23:02] <jtimberman> mathiaz: sure :)
[23:02] <jtimberman> mathiaz: generally speaking though, since stompserver needs just another advocate, and hopefully chef will soon as well.
[23:03] <mathiaz> jtimberman: it depends - if there are two advocates it will get uploaded soon
[23:03] <mathiaz> jtimberman: then an archive admin needs to accept it
[23:03] <mathiaz> jtimberman: which can take some time these days :/
[23:03] <jtimberman> :-o
[23:19] <jtimberman> thanks :)
[23:22] <ScottK> Laney: How so? (geordi)?
[23:26] <Laney> ScottK: geordi (= 20090818T0046-0ubuntu1): FAILED geordi (= 20090818T0046-0ubuntu1) depends on missing: - libboost1.35-dev
[23:38] <jtimberman> mathiaz: are you able to give chef another review?
[23:39] <mathiaz> jtimberman: a bit later
[23:40] <jtimberman> mathiaz: cool, thanks :)
[23:54] <Zhenech> bdrung_, its in incoming now :)
[23:54] <bdrung_> :)
[23:55] <bdrung_> Zhenech: 3 new mails coming in my inbox
[23:55] <Zhenech> bdrung_, oh and it says override disparity, could you take care of this?
[23:55] <bdrung_> Zhenech: how?
[23:55] <bdrung_> the package should be in optional
[23:57] <Zhenech> bdrung_, http://lists.debian.org/debian-devel-announce/2009/08/msg00001.html
[23:57] <Chase_> I'm developing an app that using QSslSocket through Qt, which itself is linked against openssl, and I want to release it under GPLv2
[23:57] <Zhenech> bug against ftp.debian.org
[23:57] <Chase_> I see in https://wiki.ubuntu.com/PackagingGuide/Basic#Copyright that there may be an issue with GPL and openssl linking, even indirectly
[23:57] <bdrung_> Zhenech: with reportbug?
[23:57] <Zhenech> Chase_, just say you allow it to link against openssl
[23:57] <Chase_> is this really an issue since I'm only using openssl through qt?
[23:57] <Zhenech> bdrung_, yes
[23:58] <Zhenech> bdrung_, but see the link for correct subject etc
[23:58] <Chase_> Zhenech: I can, but I'd prefer it to be as simple and basic gpl as possible
[23:58] <Zhenech> Chase_, its not as long you add the openssl-excemption
[23:58] <Zhenech> basic gpl is not linkable to openssl
[23:58] <Chase_> Zhenech: ok, thanks