#ubuntu-motu 2009-12-28
<slicer> Hi. Is there somewhere I can check the state of imports from testing? Alternately, does anyone know how often syncs are done?
<micahg> slicer: http://people.ubuntuwire.com/~lucas/merges.html
<persia> slicer: syncs are done by a script the archive admins run on their respective archive-admin day, so it's usually about once a weekday, except when someone is busy/sick/on holiday/forgets/etc,
<slicer> persia: Aha, and this being the holidays, that would explain the delay :) I'll wait a week then.
<slicer> micahg: Thanks.
<persia> slicer: Is there something you *need* pulled that's blocking your work?
<persia> If so, you may be able to find an archive admin to help, or find some minor bug that needs fixing to justify an Ubuntu upload (assuming you have the time to go get it back in sync later)
<slicer> persia: Not really, just had a user ask why it wasn't available yet. I have no problem telling them to wait a week though :)
<persia> If not, better to just wait :)
<persia> Yeah, when it comes to user queries, that's the best option :)  Might be a couple weeks, as most of the archive admins seem to be on holiday, and there may be some backlog on the buildds when they return.
<slicer> As long as it happens before the import freeze, I'll be happy.
<persia> Should do, I'd think.
<slicer> Isn't that february sometime? :) The imports shouldn't be THAT lagged.
<BLUG_Fred> hi everyone, doing my first package (a python program) and I have a few question. I'm trying to work out the control file and more specifically the "depends" section. How do i specify that the application depends on wxgtk2.6 and not wxgtk2.8? Also from the examples I looked at, the package full name must be specified: does it make my deb Ubuntu specific or will it work on debian as well?
<Locke> What would be changed in a source package to cause dh_make to debianize for autotools, when it previously used (and should still) cmake?
<freeflying> BLUG_Fred: Depends: python-wxgtk2.6
<BLUG_Fred> freeflying: hey! morning! so no need for the full ubuntu package name?
<freeflying> BLUG_Fred: for packaging, ubuntu is nearly 100% compatiable with debian
<freeflying> BLUG_Fred: no
<BLUG_Fred> freeflying: ok thanks.
<freeflying> BLUG_Fred: np
<BLUG_Fred> freeflying: and since wxgtk2.6 only works with python 2.4 to 2.6, python >=2.4 is enough?
<BLUG_Fred> freeflying: actually i wrote Depends: python (>=2.5.2) so far
<BLUG_Fred> freeflying: but the apps won't work with >=3
<freeflying> BLUG_Fred: dpkg will solve the revert dependency automatically, just let it depends on python-wxgtk is enough
<freeflying> BLUG_Fred: since pyhton-wxgtk2.6 has specified its dependency already, so you needn't write it in your package
<BLUG_Fred> freeflying: oh.. so not even necessary to specify python then... i see!
<freeflying> BLUG_Fred: no
<BLUG_Fred> freeflying: great! thanks a lot.
<freeflying> BLUG_Fred: np, dude
<Locke> What would be changed in a source package to cause dh_make to debianize for autotools, when it previously used (and should still) cmake?
<freeflying> Locke: cmake is different from autotools
<Locke> I know
<Locke> And the programmer has used cmake from the beginning, but now when I debianize his source, the rules and control reflect autotools rather than cmake
<freeflying> Locke: you mean upstream switch from cmake to autotools?
<Locke> It not. Upstream says it is still cmake, as it's always been.
<freeflying> Locke: then whats your issues?
<Locke> If I used the rules and control from an older version I've built, it builds fine. If I use the rule and control that dh_make provides for this version, it fails.
<freeflying> Locke: fails at which step?
<Locke> My issue i that dh_make is generating the wrong rules/control file now, when it didn't in the past.
<Locke> Lemme get some output for you.
<freeflying> well, I goona go, ttyl
<Locke> http://launchpadlibrarian.net/37187459/text_outputs.tar.gz
<Locke> Ok
<jmarsden> Locke: Sounds like either the CMakelists.txt is missing or moved, or there is a configure.ac or configure.in which wasn't there before ?
<wgrant> Locke: Why are you running dh_make if a package already exists?
<Locke> jmarsden: I'll check the source package
<Locke> wgrant: I'm packaging newer, unbuilt and unpackaged versions of this.
<jmarsden> Locke: wgrants point is valid -- if you already have debian/* files from an earlier version, use those as a starting point.
<wgrant> You still shouldn't be using dh_make, unless you want to create about AN AWFUL LOT more work for yourself.
<wgrant> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
<Locke> wgrant: I'm not submitting these to the repo's, they're just for me and the people I play with. dh_make is simple when all I am making is a simple package.
<Quintasan> Locke: this package is using cmake?
<Locke> Yes
<Quintasan> Locke: is this kde related?
<Locke> Not particularly.
<Quintasan> Locke: Did you try cdbs
<Quintasan> ?
<Quintasan> well
<Locke> I did not, but I'm curious why it functioned properly previously, but now generates debian/ wrong.
<Quintasan> maybe some compatibility problems, we have new debhelper :P
<Locke> Ack
<Quintasan> Locke: You can try copying your old rules files to somewhere and put "import /usr/share/cdbs/1/class/cmake.mk" into rules
<Quintasan> also add cdbs to build-depends and try building
<Locke> Will do
<Quintasan> Mind showing me the rules you have now?
<Locke> The ones that work, or the ones that don't?
<Quintasan> The ones that don't work
<Quintasan> Hmm though the working ones would be good too
<Locke> http://launchpadlibrarian.net/37187459/text_outputs.tar.gz
<Locke> They're in there.
<Locke> The one labeled 0.44-rules are new and don't work, the 0.40-rules are old and do work, when I use them to build 0.44.
<Locke> Perhaps the templates changed during an update..... The original source is not debianized.
<Quintasan> hmm, cmake.mk should really solve everthing
<Quintasan> cdbs does magic sometimes :P
<Locke> :) I'll try that. I've never used it. I'm not a packager or anything, just a casual user trying to make this work; and if possible let upstream know why it's not debianizing correctly.
<jmarsden> Quintasan: Which is why quite a few packagers prefer dh to cdbs -- less magic :)
<Quintasan> IMHO It's wrong for upstream to provide debian/ dir :P
<Locke> I agree
<Quintasan> jmarsden: well I like dh too, but packaging KDE releases would be a PITA with no cdbs :P
<Quintasan> Well it's 3am here, I'm going to bed, good night
<jmarsden> Quintasan: Maybe so (I've not tried!) but this is just a simple application that has already been packaged once... using the existing working set of debian/* files to work from would seem more logical than starting over with dh_make (especially if issues occur, which seems to be happening here).
<jmarsden> Locke: You can and should ask upstream not to provide a debian/ directory in their source tarballs.
<Locke> I just feel that it functioned before, but does not now. If I had not done this previously and already had proper rules, it would have been a pain. Some other casual packager like myself trying to do this for the first time with this source would fail and not have proper rules to make it work.
<Locke> jmarsden: They don't, I am generating them.
<jmarsden> Ah.  OK.
<Locke> Thats the issue: they are generating wrong now, when they generated correctly with previous versions.
<jmarsden> Where is the original (current) source tarball ?
<Locke> Launchpad; lemme find an address for you.
<Locke> https://launchpad.net/springlobby/+download
<Locke> I packaged 0.38, 0.39, and 0.40 when they were current without a hitch.
<jmarsden> Locke: There is a file in the top level called configure -- was that present in the earlier version?
<jmarsden> I strongly suspect that is what is confusing dh_make
<Locke> it is there. I diff'd it, and it was the same.
<Locke> locke@pimpshit:~/my_build$ diff springlobby-0.40/configure springlobby-0.44/configure
<Locke> ^^ returns no output.
<jmarsden> mv configure oldconfigure ; dh_make ; mv oldconfigure configure     # works for me...
<jmarsden> By convention a script called configure at the top level of a source tree implies autotools... using that exact name for a non-autotools script is asking for trouble, really.
<Locke> So I guess I'm asking: What changed? configure existed in previous versions, and is identical to the current configure. dh_make generated the proper debian/ in previous versions (and still does) and generates an incorrect debian/ in the current version
<Locke> I know how to get around it and make it work, but I'd rather know what changed so I can fix it, instead of doing workarounds
<jmarsden> Sounds like someone changed the way dh_make checks what kind of configuration system a package has, probably to fix things for some other use case.
<jmarsden> If you want to check on it, grab the dh-make source package and take a look, including reading the changelog
<Locke> So your guess is possibly an update to one of the dh*/debhelper packages isn't compatible with this somehow?
<Locke> I'll be sure to do that.
<jmarsden> Since there *is* a trivial workaround, and you aren't packaging for Ubuntu or Debian, I'm not very convinced it's worth the work, but OK.
<jmarsden> I'd guess a bug fix or update to dh-make changed its behaviour for your particular source package.
<Locke> :) It's something for me to do when I'm bored, that is why I started building and packaging in the first place. :)
<jmarsden> Then take it to the next level and actually package the thing properly and get it submitted to REVU or sponsored into Debian unstable!
<Locke> I've considered "proper" packaging :) I should consider it further.
<Locke> The process is laid out pretty forwardly in the wiki then, yes?
<jmarsden> Yes.  https://wiki.ubuntu.com/PackagingGuide/Complete is one starting point.
<Locke> That is a pretty thick guide: thorough I'd imagine. I'll read through that and try with the next batch of stuff I build.
<jmarsden> Go for it :)  Ask questions here if you get stuck.
<Locke> I'm sure I will :) Thanks.
<jmarsden> You're welcome.
<Locke> I'm out for the night; thanks for the effort with my issue guys. Later.
<wgrant> I don't think he understands the purpose of dh_make.
<dhillon-v10> wgrant, so from what I understand, using debuild -S -sa reduced a lot of work while packaging
<wgrant> dhillon-v10: How were you doing it before?
<dhillon-v10> wgrant, using dh_make
<dhillon-v10> wgrant, thanks for that tip
<wgrant> They serve completely different purposes.
<dhillon-v10> wgrant, hey i have another question: I am packaging a little ppa that doesn't have anything that needs compiling, so debuild works fine, but launchpad make .deb packages that are like 2.4 kbs. while the orig file is 43 mgs
<dhillon-v10> wgrant, here's my directory structure: http://paste.ubuntu.com/347784/
<wgrant> dhillon-v10: Have you told it to install files into the package?
<dhillon-v10> wgrant, please elaborate, are you referring to the rules file, I am not too good at packaging from scratch
<jmarsden> dhillon-v10: man dh_install and read https://wiki.ubuntu.com/PackagingGuide/Complete for more info.  You probably need to create a debian/install file indicating which files to install where.
<dhillon-v10> jmarsden, thanks I didn't know that i have to make a /install file
<jmarsden> dhillon-v10: Seriously, read that Guide :)
<dhillon-v10> jmarsden, alright will do :D
<bddebian> dhillon-v10: Sorry was/am afk off and on
<dhillon-v10> bddebian, nah that's okay plus Scott said that we shouldn't be talking on that channel, I think I figured out what the problem is thanks anyways god ;)
<ScottK> bddebian: FYI, there a a graphviz update needed for the Python 2.4 transition in Debian (it's QA maintained at the moment).  I'm working on it.
<bjsnider> dh_make should create a rules file that installs the files into the package
<bddebian> ScottK: OK cool, let me know if/when you need an upload
<bjsnider> the install target name needs to match the package name in the control file
<ScottK> Will do.
<dhillon-v10> bjsnider, alright thanks it works now :D
<bjsnider> cool
<lfaraone> Wheere could I find an example get-orig-source for a package which uses git upstream?
<porthose> https://wiki.ubuntu.com/MOTU "Joining MOTU" Is this the correct procedure for applying for MOTU?
<crimsun> lfaraone: nouveau-kernel-source
<lfaraone> crimsun: thanks
<BLUG_Fred> hi again! I was wondering whether the trunk code needs to be modified to reflect packaging constraint (file locations specifically) or you just manually change it every time you package?
<BLUG_Fred> the application is a python app.. sorry
 * BLUG_Fred hopes the question was clear enough.
<diwic> BLUG_Fred: it needs a little background information for newcomers such as myself
<diwic> BLUG_Fred: what trunk?
<BLUG_Fred> diwic: well I am (trying to...) packaging a python application which has never been packaged. Everything runs from the same directory. Now in order to follow Linux directory structure I need to move some files and modify the code to reflect those changes.
<BLUG_Fred> diwic: should this code modification only be used everytime I package or should I commit them to the application trunk?
<diwic> BLUG_Fred: if you have access to commit things upstream, that seems to be the best way...?
<BLUG_Fred> diwic: doing so will break compatibility with Windows I guess, so maybe i need to add OS detection and.. well I have a few questions as you see.
<diwic> BLUG_Fred: aha
<BLUG_Fred> diwic: yes
<BLUG_Fred> diwic: i started as a translator and well.. i'm doing a bit more now
<diwic> BLUG_Fred: ok then I'll suggest you use the build/install process to move them
<ghostcube> whats the sense of this now ? DONT WORK AS TRANSLATOR YOU GET LOST IN YOUR WORK
<BLUG_Fred> diwic: since it's a python program it could be used on Linux, MAC and Windows...
<ghostcube> heh
<tjingboem> is this the place to ask for getting software placed in the repo from ubuntu?
<BLUG_Fred> diwic: what is the build/install process?
<BLUG_Fred> tjingboem: please shoot! I'd be interested in the answer as well ;-)
<tjingboem> i know that Csound 5.11 is available for debian
<diwic> BLUG_Fred: Do you know the difference between a source package and a binary package?
<BLUG_Fred> diwic: and we use the application on at least Linux and Windows regularly
<tjingboem> i would like it to be available for Ubuntu
<BLUG_Fred> diwic: yes. but in python everything is... source somehow
<tjingboem> right now there is Csound5.10
<tjingboem> but 5.11 has important updates for me
<diwic> BLUG_Fred: in this case I would say the source package would have the files in one dir, but the binary would have it in FHS structure
<diwic> tjingboem: Ubuntu has local changes to csound, it needs someone to merge them
<tjingboem> who can that be?
<BLUG_Fred> diwic: ok. clear. so my changes to the source code should be considered as the building process? is that what you suggest?
<tjingboem> should i come back later and just try again hoping that person is there?
<diwic> tjingboem: If you just need to use a newer version of csound, download the source package from Debian and build it for yourself
<tjingboem> that is something i was hoping to avoid :)
<diwic> tjingboem: download the binary package from "testing" then and pray that it works ;-)
<BLUG_Fred> diwic: should I upload those changes somewhere in the source repository then (in case someone else takes over)?
<diwic> BLUG_Fred: changes to the source code should be done with patches
<diwic> BLUG_Fred: otoh, as you're an upstream developer, your interest would be to make it work for all linux distros, not just debian
<BLUG_Fred> diwic: right
<BLUG_Fred> diwic: i was planning to supply a deb and a rpm
<BLUG_Fred> diwic: (alien-ized rpm.. hehe)
<diwic> BLUG_Fred: btw, what is it in your python code that needs to be platform specific?
<BLUG_Fred> diwic: icons, documentation and po files I guess
<BLUG_Fred> diwic: documentation is actually 48 lessons on how to program in python
<BLUG_Fred> diwic: in html
<diwic> BLUG_Fred: To sum up, my recommendation (as a python layman, I must point out) is to 1) what needs changing in the actual source code, commit that upstream, and for moving files, use a makefile
<diwic> BLUG_Fred: you can look at the makefile I wrote for codecgraph for inspiration, see https://launchpad.net/~diwic/+archive/ppa/+packages
<BLUG_Fred> diwic: i will look as all is not quite so clear for me yet. Thanks a lot for your help!
<diwic> BLUG_Fred: the makefile in debian packaging is called debian/rules, btw.
<BLUG_Fred> diwic: ah.. yes I am at the rules file stage actually
<diwic> BLUG_Fred: but that one often just calls other files
<BLUG_Fred> diwic: and the copying file stage...
<diwic> BLUG_Fred: hmm...looking at my own code, I see that upstream actually supplied that makefile.
<diwic> BLUG_Fred: it probably makes sense for your upstream to do the same
<BLUG_Fred> diwic: you mean that I should upload a copy of control and rules into the source svn?
<diwic> BLUG_Fred: no, no debian directory upstream
<BLUG_Fred> diwic: sorry for my  total lack of knowledge on the topic. I read 10 pages on packaging and got even more confused.. and the "simple" tutorials don't touch about source svn
<diwic> BLUG_Fred: for the moving files stuff, have a look at codecgraph
<diwic> BLUG_Fred: it has a simple file-moving Makefile in its top directory
<diwic> BLUG_Fred: learning how to package takes time. Try not to take it all in at once.
<BLUG_Fred> diwic: well I think I am ok with the "how to move files", but if i do so without changing the source code, the application will not work
<diwic> BLUG_Fred: assuming upstream ships a Makefile which moves files, upstream should of course also work with the files moved.
<BLUG_Fred> diwic: but those changes are Linux specific
<BLUG_Fred> diwic: ok... that answers my question
<BLUG_Fred> diwic: not the easiest path, but a clear answer...
<persia> porthose: Yes, that is the correct procedure.
<porthose> persia, thx, :)
<slytherin> Does anyone know how to typecast char * to const char *?
<diwic> slytherin: (const char *)
<slytherin> doesn't seem to work.
<diwic> slytherin: depends on the situation then
<diwic> slytherin: but basically the question is, if the string is really constant, why wasn't it const char in the first place?
<slytherin> Actually it is i18nized string. Sadly gettext returns it as char * instead of const char *. And GTK+ meny requires that the label be const char *.
<slytherin> there is a wrapper around gettext in glib but that requires me to bump the glib dependency version.
<diwic> slytherin: seen from ubuntu'
<diwic> s perspective, bumping glib dependency wouldn't be a problem...?
<slytherin> diwic: Hardy has an older version. And I want this application to be installable on hardy for as long as possible. :-)
<diwic> slytherin: ok. Then look at the source for how glib did it ;-)
<slytherin> yes that's the last resort.
<jezier> hi... I have a question about package versioning... lets say that I want my pacakges with suffix "foo"...  and for example I have patched iptables... (current deb filename is iptables_1.4.4-1ubuntu1_i386.deb)... what name should I choose so that package manager will know that mine is new version... iptables_1.4.4-1ubuntu1foo1_i386.deb ?
<maco2> i usually go with 1ubuntu1~foo1
<maco2> er wait... no you want +
<hyperair> + is right
<maco2> ~ makes official package supercede yours
<jezier> oh.. ok :)
<jezier> I know about ~ but it is opposite of what I want :)
<jezier> ok.. will try +
<jezier> thx
<hyperair> you can test by using dpkg --compare-versions
<hyperair> e.g.
<hyperair> $ dpkg --compare-versions 1.0 gt 1.0~1 && echo yes || echo no
<hyperair> yes
<asac> Lutin: thx. only the launcher now missing ;)
<Lutin> asac: I assumed either mterry or jamie would be updating the REVU package or uploadding it, but maybe they're busy with other work/holidays
<asac> Lutin: its uploaded ... just not bin NEWed
<asac> waiting for archive admin push
<Lutin> asac: ah, ok. as I didn't see any reply on REVU, I assumed nobody had been working on it, sorry
<asac> np
<sbalneav> If I wanted to build a package from a git repo checkout, what would be the naming convention?
<sbalneav> pkgname_x.xx.x-git.orig.tar.gz?
<persia> sbalneav: I'd recommend using '+' rather than '-' to separate the base upstream and the checkout.
<persia> For a more robust scheme, consider pulling the base version, and applying the checkout patch as a patch in the packaging, rather than attempting to construct a tarball based on the checkout.
<sbalneav> ok
<persia> e.g. 1.2.3-4ubuntu2 where the difference between -4ubuntu1 and -4ubuntu2 is the updates from the upstream git repo.
<sbalneav> I also happen to be upstream for this gnome, project, one supposes I could just ping the gnome release manager, and bump my configure.ac version numbers a bit early, and release a new upstream tarball a few days sooner than expected :)
<sbalneav> might be easier :)
<sbalneav> persia: Thanks!
<persia> sbalneav: Either works.  I just usually try to avoid having too many tarballs floating around, because it's harder to verify the trust path on the code, etc.
<sbalneav> Well, I'm running into the "I'd like people to test before I make an upstream release, but no-one knows how to compile code anymore, so unless I make a package, no one can test it" problem :)
<persia> Heh.  I understand.
<persia> For that, you might try 1.2.3~rc1-0ppa1 as a version-revision string.
<persia> And then go from 1.2.3~rc1 to 1.2.3 when there is an actual release.
<sbalneav> Ah, good idea!
<sbalneav> perfect.
<persia> If you end up having issues, 1.2.3~rc2 >> 1.2.3~rc1, so you can do multiple rcs.
<sbalneav> Bingo
<persia> And, just as importantly, 1.2.3-1 >> 1.2.3~rc* which means that when the release happens, everyone will get upgraded.
<persia> Note that this only makes sense when you *are* upstream.  If it's someone else's git checkout, it's less right to call it "~rcX", and applying the patches in packaging may make more sense :)
<sbalneav> right.
<maxb> If you really feel the need, 1.2.3~git20091228+g03c5f9a is an option
<randomaction> Is there any difference between "Recommends: iceweasel | firefox | www-browser" and "Recommends: iceweasel | firefox | abrowser | www-browser"? Is seems to me that there isn't as both firefox and abrowser depend on packages providing www-browser, so either nothing of firefox will be installed.
<micahg> randomaction: it pulls in the first one that in recommends by
<micahg> default
<micahg> that's available
<randomaction> Yes, so that would be firefox (if there's no browser) or nothing (is there is), regardless of whether abrowser is in Recommends.
<randomaction> I'm asking because it's our delta for nip2 package and I wonder if it should be kept.
<micahg> well, if abrowser in installed, then it wouldn't try to pull in another browser
<micahg> randomaction: yes
<randomaction> (This has been carried forward for a long time, maybe there's a reason I miss)
<micahg> randomaction: abrowser is our version of iceweasel
<randomaction> Yes, I know.
<randomaction> "Yes" as in "Yes, keep it"?
<micahg> randomaction: yes, I think it should be kept
<randomaction> OK, thank you
<geser> abrowser provides firefox so the unmodified recommends will be fulfilled when abrowser is installed
<micahg> geser: hmmm, let me ask asac about it then
<randomaction> Indeed, so I think it's only advertising.
<micahg> randomaction: I can ping you when I find out
<randomaction> thank you
<asac> yes. its advertising
<micahg> randomaction: it's advertising per  asac
<randomaction> ok, so intentional and should be kept
<micahg> randomaction: yep
<polac> Beginners question about Bug #439256 which is tagged as needs-packaging. Upstream source allready contains debian folder. Should I work together with Upstream mainteiner or override debian folder completely or try to build it and if success just replace the package maintainer info?
<ubottu> Launchpad bug 439256 in ubuntu "[needs-packaging] java bindings for sqlite" [Wishlist,New] https://launchpad.net/bugs/439256
<Laney> polac: you could ask the upstream maintainer if he is interested in (co)maintaining the package in Ubuntu/Debian
<Quintasan> Good evening
<highvoltage> hi Quintasan
<polac> Laney: Ok. Thanks.
<geser> Hi Quintasan
<polac> Laney: Can you say why there is a debian folder? I cannot find that package from the Debian or any other debian based distro. Or at least google can't
<Laney> polac: it's probably unofficial, upstreams often like to ship .debs to make it easier to install
<Laney> but with help they might be receptive to making it an official package
<polac> This is going to be my first contribution to ubuntu community and first attempt to create/maintain package. Maybe I should start from some other package. That upstream fellow might not appreciate the help if he needs to guide me all the time. :)
<Quintasan> polac: well, it's not like packaging is a very hard thing all of the time, you just have to try. IMHO developers providing debian/ dir in tarball are doing it wrong, they should provide it somewhere else :P
<polac> Quintasan: And it is even easier when almost everything you need to do comes with the tarball. ;)
<Quintasan> lol, I wonder how we are supposed to manage this since Debians policy forbids modyfing the upstream tarball
<Laney> source format 3.0 helps here
<polac> Quintasan: What would be the correct way to distribute tarball without the debian folder and still allow people to create unofficial .debs simple?
<polac> Laney: Any suggestions?
<Quintasan> polac: a) Provide it as a separate tar b) provide all required information like dependecies, all authors (with emails!) and supply LICENSE file (some developers forget this!)
<Quintasan> Ad b) Thos information would be best in a file called PACKAGING or something like this
<polac> Ok. I try to work something out with the upstream fellow.
<Laney> polac: they can maintain the packaging data in a separate branch
<Laney> and use that to build their .debs
<polac> Laney: One tip more. Thanks.
<ari-tczew> in lucid if I want to do merge on package based unstable (not yet testing), can I do it or do I need to wait for migrate package into testing?
<geser> ari-tczew: if you have a reason to merge from unstable instead of testing, you can do it
<sebner> huhu geser :D
<geser> Hi sebner
<geser> your notebook working again?
<sebner> geser: I have my laptop back :D but lucid is not stable here so I have to use karmic ^^
<ari-tczew> geser, so I prefer to waiting for migrate -> testing
<ari-tczew> there is no reason
<bjsnider> is there a way to use dpkg-source -b so that it creates an untouched orig tarball, ie. leaves out the debian directory?
<geser> why would you need that?
<bjsnider> why would i need an orig tarball?
<geser> ah, so you don't have an orig tarball?
<bjsnider> if i do a git or svn instead of downloading it
<geser> svn export
<bjsnider> svn export creates an orig tarball?
<geser> you can use it to create a tarball which is your orig tarball (if you rename it to the expected name)
<christoph_debian> svn export creates a checkout without .svn dirs
<geser> which is good as you usually don't want .svn  inside the tarball
<bjsnider> well, dpkg-source -I also leaves out the svn directories.
<bjsnider> how could i alter the destination directory in a cdbs package?
<crimsun> bjsnider: same way as other packages
<bjsnider> i can't add any commands to the rules filebecause it results in "commands commence before first target.  Stop."
<asac> bjsnider: thats a make syntax issue most likely
<asac> in rules
<asac> accidential whitespaces or something i guess
<crimsun> dhillon-v10: qa.ubuntuwire.org/ftbfs
<dhillon-v10> crimsun, alright
<bjsnider> actually i think this is the problem. this is a very rough package. there is a built target but no install target. so can i add an install target in a cdbs rules file?
<Duck-> Hi, does anyone know where I can find a cracked version of inbunto 9?
<directhex> !ops
<ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds!
<Quintasan> nice, cracked version of Ubuntu? :D
<bjsnider> what did he ask?
<directhex> something stupid
<Quintasan> really stupid
<sladen> did seem quite draconian
<sladen> we could have explained how Ubuntu is already legal to copy and modify
<elky> sladen, he's been trolling other channels
<directhex> it was clearly trolling
<Quintasan> It's very amusing to see that it's possible to from questions that don't make any sense so much.
<bjsnider> too bad you can't send the user an electric chock when they get kicked from an ubuntu channel
<elky> bjsnider, yes, it's such a shame we can't potentially kill people with heart issues.
<Quintasan> I think we would  already have a deficiency of users :P
#ubuntu-motu 2009-12-29
<bluefoxicy> how does totem play midis?
<bluefoxicy> O_O
<directhex> bluefoxicy, via gstreamer, most likely
<bluefoxicy> directhex:  yeah but I mean, midi output?
<bluefoxicy> midi doesn't contain sound.
<directhex> libwildmidi
<directhex> which recommends freepats which has midi voices in it
<bluefoxicy> heh
<bluefoxicy> so timidity-ish.
<directhex> yes
<bluefoxicy> k. Same patch set, hmm.
<bluefoxicy> I'm assuming nobody gives a crap (I don't) to cut up some high quality samples into patches
<bluefoxicy> (yes, there's a pile of public domain very-high-quality instrument samples out there)
<directhex> it *must* be DFSG-free
<directhex> if so, then freepats accepts patches
<bluefoxicy> actually.
<bluefoxicy> http://freepats.zenvoid.org/samples/imis/
<bluefoxicy> AFAIK nobody's cut these up yet.
<bluefoxicy> http://freepats.zenvoid.org/samples/imis/LICENSE
<bluefoxicy> there's an http://freepats.zenvoid.org/sf2/acoustic_piano_imis_1.sf2 but that's all I see.
<bluefoxicy> it also comes under a license I don't believe has been validated by OSI yet
<bluefoxicy> 'You can redistribute it and/or modify it under the terms of the "Do What The Fuck You Want To Public License", Version 2. The license text is reproduced below.'
<bluefoxicy> I'm not sure the DWTFYWTPL is officially OSI validated O_o
<dhillon-v10> bluefoxicy, lol
<bluefoxicy> http://freepats.zenvoid.org/sf2/acoustic_piano_imis_1.txt however here's the full text.
<directhex> bluefoxicy, actually, WTFPL 2.0 is explicitly DFSG-free
<directhex> and was written by a former debian project leader
<bluefoxicy> ... XD
<directhex> and the FSF approve it as Free
<bluefoxicy> haha
<persia> directhex: bluefoxicy: Try fluid-soundfont-gm if you want decent MIDI samples.  If you find another DFSG-free soundfont, that'd be great, but I'd encourage you to follow the directory convention for fluid-soundfont
<persia> maxb: The issue with ${potential-version}~git${date}+${sha} is that there is no guarantee that ${SHA} will increase, which can be annoying when one makes a mistake on upload and needs to wait a day to reupload (and then ends up with a potentially different snapshot, potentially with new bugs)
<maxb> I was hoping that no one would ever need to import a new upstream snapshot twice in one day :-)
<persia> In an ideal world, every upload is perfect, but we are mostly human, and therefore it remains best to set guidance to allow for mistakes.
<zooko> Greetings, people of #ubuntu-motu!  I have read the Lucid release plans and https://wiki.ubuntu.com/LTS and I'm wondering what target deadline I should set for the Tahoe-LAFS project to upload a new release of Tahoe-LAFS for inclusion in Lucid.
<persia> zooko: For best resuts, you want to make sure it gets uploaded (to Ubuntu or Debian) by 28th January, and I'd recommend giving at least a few days for upload delays, so trying to do something by the 20th or so.  More specifics at https://wiki.ubuntu.com/LucidReleaseSchedule
<persia> Note that it is possible to upload stuff past PartnerUploadDeadline (apparently unless one is an "OEM Partner"), but it's decidedly unlikely that it will get into the next release without substantial help at that point (and you'd already be in touch with a developer who was driving it and specifically advised you that a couple more days were safe).
<persia> porthose: Don't forget to send the "quick heads-up" to motu-council@l.u.c about your application (this seems to be the most frequently missed step)
<porthose> persia, will do :)
<ScottK> zooko: How's the feedback on Tahoe-LAFS on Karmic?
<zooko> persia: thanks!
<zooko> ScottK: fine!  We have a few users who use it in Karmic, and people recommend to each other that they should use that version if they have Karmic.
<zooko> For example, here is the ad hoc Tahoe-LAFS grid that has been set up at the Chaos Communications Congress: http://events.ccc.de/congress/2009/wiki/Tahoe-LAFS_Workshop
<zooko> Oh wait, I mean here are the installation instructions that these CCC folks give: http://events.ccc.de/congress/2009/wiki/Tahoe-LAFS_Grid
<rawang> hello everyone, anyone have time to look at http://launchpadlibrarian.net/37262448/buildlog_ubuntu-karmic-i386.mono-uia-atkbridge_1.0-2~pre1_FAILEDTOBUILD.txt.gz ? I can't figure out what's the problem, thanks a lot!
<wrapster> how do i find out the version of the pkg installed on my machine?
<_ruben> dpkg -l packagename will show you
<rawang> _ruben, hey
<wrapster> _ruben: and can i see the full contents of this pkg anyway?
<wrapster> _ruben: referring to somethign like dpkg -c pkgname
<wrapster> but thats on a newly created .deb how about an isntalled one?
<wrapster> installed
<_ruben> wrapster: dpkg -L pkgname
<wrapster> thanks
<rawang> hi anyone has time to look at http://launchpadlibrarian.net/37262448/buildlog_ubuntu-karmic-i386.mono-uia-atkbridge_1.0-2~pre1_FAILEDTOBUILD.txt.gz ? I can't figure out what's the problem, thanks a lot!
<randomaction> there were errors during configuration of mono-gac, which is a build dependency
<randomaction> but I have no idea why is that
<rawang> randomaction, ok, i'm trying to build my pkg on my PPA, seem like my libmono-uia3.0-cil wants to install some files to system the have been denied.
<rawang> lidaobing, hey
<lidaobing> rawang, mail me if have any issue
<rawang> lidaobing, ok, thanks :)
<rawang> lidaobing, alright, sent.
<doctormo_> Does anyone understand why my iscan package would fail to upload?
<doctormo_> https://launchpad.net/~doctormo/+archive/doctormo-epson-scanners/+build/1418715
<doctormo_> I'm a bit lots trying to pick through the wreckage.
<xnox> doctormo_: What's the reject email?
<xnox> Ohhh
<xnox> that looks weird
<wgrant> doctormo_: More of a #launchpad question, but you deleted/superseded the source before the build finished.
<wgrant> Oh. No.
<wgrant> It's a bug in your package.
<wgrant> 2009-12-28 23:07:39 WARNING 	Unable to find source package iscan/2.23.0-4doctormo4.ltdl7 in karmic
<wgrant> ".ltdl7"!?
<wgrant> That's not in the source version.
<wgrant> doctormo_: Also, why is it native, and why on earth are there binaries in there?
<doctormo_> wgrant: Your guess is as good as mine, it's LGPL, source, just a matter of pulling it apart, i think I might ditch the debian dir that came with it and use my previous one.
<wgrant> doctormo_: The nativity in this case is just because you did not place a correctly named orig.tar.gz in the parent directory.
<wgrant> doctormo_: There are binaries matching *.so in the source package. That seems wrong.
<doctormo_> wgrant: When I did place one, it couldn't find it.
<wgrant> doctormo_: You didn't name it properly, I suspect.
<doctormo_> wgrant: No what I mean is, when it had a orig file it was rejected by the ppa upload system, instead of the build system like this example.
<wgrant> doctormo_: Rejected how? Checksum mismatch?
<doctormo_> wgrant: Rejected: Unable to find iscan_2.23.0.orig.tar.gz in upload or distribution.
<wgrant> doctormo_: You didn't debuild with -sa
<doctormo_> no
<wgrant> That is the problem.
<doctormo_> wgrant: debuild -sa fails, says that's not valid args.
<wgrant> doctormo_: debuild -S -sa
<doctormo_> No wonder this packagaing lark has special people running it, I'd never fit in as a motu ;-)
<doctormo_> good, that looks more healthy.
<doctormo_> Thanks for your help wgrantand xnox
<wgrant> doctormo: But there is still the matter of your strange mangling of the binary versions.
<wgrant> I haven't looked at that code; it sounds scary.
<doctormo> It does, if I had noticed myself I would be scared.
<doctormo> wgrant: Same failure in build, I assume it's the binary problem.
<wgrant> doctormo: The upload log will tell you for sure.
<doctormo> I think I'll give up on the package for now, it's too much trouble for what it's worth.
<doctormo> Thanks agaain for your help wgrant
<damo22> how do i build an ubuntu source package with a .dsc file and orig.tar.gz and diff.gz
<Laney> debuild -S
<damo22> Laney: thanks, do i need to untar and patch first? then copy the dsc into the tree and run it?
<Laney> wait, what do you want to do?
<Laney> build a deb?
<damo22> i want to compile a deb for karmic using a source package
<Laney> oh, alright
<damo22> actually its a bunch of debs
<Laney> the quickest way is to dpkg-source -x foo.dsc, cd into the directory and run debuild
<Laney> you'll need the build deps first though
<damo22> cool
<slytherin> damo22: Ideally you should use pbuilder or sbuild.
<damo22> do i run debuild -S or without the s flag
<Laney> you don't use -S to build debs
<Laney> that is to build the source package
<damo22> ahh ok
<damo22> it overwrote my source package
<damo22> lol
<damo22> lucky i have it backed up
<damo22> im building an old version of the ATI fglrx driver which doesnt have a package for karmic
<rawang> how to trigger ppa rebuild my package?
<rawang> Laney?  :)
<Laney> there's a button somewhere in the ppa
<Laney> probably where it tells you the build failed
<rawang> k
<damo22> some idiot wrote a deb using sh instead of bash and tried to call pushd/popd from sh
<damo22> part of the ATI driver
<damo22> :S
<damo22> i dont know where to find the script to change it
<kamalmostafa> How can I fetch the "glib2.0" source package with bzr/launchpad?...   bzr branch lp:ubuntu/glib2.0  ... gets an error "glib2.0 in ubuntu has no default branch."
<randomaction> according to https://code.launchpad.net/ubuntu/+source/glib2.0, "There are no branches for the âglib2.0â package in Ubuntu in Launchpad."
<kamalmostafa> randomaction: so what source package builds the "libglib2.0-0" binary package?  I got "glib2.0" from...  apt-cache showsrc libglib2.0-0
<randomaction> that's right, glib2. There's just some problem with its branches.
<randomaction> (I mean, glib2.0)
<kamalmostafa> ah ha...  Also of note:   bzr branch lp:glib   does fetch a "glib" source package, but it is 9 months stale.
<geser> glib2.0 has import failures (see http://package-import.ubuntu.com/failures/.bzr/failures/glib2.0)
<randomaction> Don't know whether it's of any help for you, but there's an upstream git repo.
<kamalmostafa> randomaction: no, I actually do need the ubuntu source package.
<randomaction> you cat "apt-get source" it
<geser> you need to use the fallback: apt-get source glib2.0
<sebner> geser: when doing a merge, after launching bzr commit I don't need to generate a .changes file etc to upload it with dput? bzr takes care of everything?
<randomaction> or you can ask at ubuntu-distributed-devel@l.u.c if you really need the branch
<geser> sebner: you still need to do an upload, we don't have BuildFromBranch yet
<sebner> geser: until then it smells pretty much like double double work to me :\
<dhillon-v10> hi all, I remember reading on the wiki that its possible to perform merges using bzr how is that done
<geser> only the "bzr push" and "dput" is double-work, you can use the branch to build the source package
<randomaction> dhillon-v10: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
<ikt> heya, anyone around?
<dhillon-v10> randomaction, thanks a lot
<geser> ikt: perhaps, perhaps not
<matti> dhillon-v10: Hello Sir!
<dhillon-v10> matti, hi there :D
<matti> ;]
<ikt> geser: I'll take a chance on perhaps :P
<ikt> https://bugs.launchpad.net/debian/+source/electricsheep/+bug/372040 <- simple program, just want to confirm it'll have the right package in 10.04
<ubottu> Ubuntu bug 372040 in electricsheep "Request Package of electricsheep 2.7 due to 2.6 EOL" [Medium,Confirmed]
<randomaction> ikt: apparently EzraR is working on it (bug 484013)
<ubottu> Launchpad bug 484013 in electricsheep "Please merge electricsheep 2.7~b12+svn20090708 (universe) from Debian testing (main)" [Undecided,In progress] https://launchpad.net/bugs/484013
<ikt> cheers randomaction
<dhillon-v10> randomaction, i am trying to merge Bug 499335 goldendict, how do I find the URI of this package
<ubottu> Launchpad bug 499335 in goldendict "Please sync goldendict (0.9.1~git20091117-1) from Debian Testing" [Wishlist,New] https://launchpad.net/bugs/499335
<randomaction> I think you branch lp:ubuntu/goldendict and merge lp:debian/squeeze/goldendict into it
<ikt> https://merges.ubuntu.com/e/electricsheep/REPORT <- :s
<dhillon-v10> randomaction, how do we identify that, meaning is there a proper way to a new user to know which one to branch and which one to merge into
<dhillon-v10> randomaction, I see that it goes by package name
<randomaction> why, you want to merge from Debian testing (squeeze) into Ubuntu, hence these branches
<dhillon-v10> randomaction, thanks again
<jjlee> dpkg-genchanges: error: cannot read files list file: No such file or directory
<jjlee> what's likely to be at fault there?
<dhillon-v10> nixternal, hi :D I was working on this merge for bug #499335 and here's the diff: http://paste.ubuntu.com/348672/ I used bzr to do this and can you tell me if it looks right
<ubottu> Launchpad bug 499335 in goldendict "Please sync goldendict (0.9.1~git20091117-1) from Debian Testing" [Wishlist,New] https://launchpad.net/bugs/499335
<jjlee> I was missing this line from debian/rules: include /usr/share/cdbs/1/rules/debhelper.mk
<alex_mayorga> Hi
<alex_mayorga> !info virtualbox-ose
<ubottu> virtualbox-ose (source: virtualbox-ose): x86 virtualization solution - base binaries. In component universe, is optional. Version 3.0.8-dfsg-1ubuntu1 (karmic), package size 6182 kB, installed size 24292 kB (Only available for amd64 i386 lpia all)
<alex_mayorga> what does it mean that it's in "Outstanding merges"?
<randomaction> alex_mayorga: Debian has a newer version
<randomaction> which may or may not be imported directly because Ubuntu package is modified
<zooko> What's thebest URL for the pretty graphic of the Lucid schedule as a garden with flowers and a snail?
<zooko> persia: I'm quoting your advice on tahoe-lafs to the tahoe-dev list.  Want to be named "IRC user 'persia'"?
<zooko> Or "Emmet Hikory", or something else?
<dhillon-v10> hi all, I am trying to build this package in pbuilder, and then I get this "configure: error: The intltool scripts were not found. Please install intltool. make: *** [config.status] Error 1" I did put intltool in the control file but it still doesn't build, any help here
<geser> dhillon-v10: could you pastebin your build log?
<dhillon-v10> geser, just a sec.
<dhillon-v10> geser, this is all I can get out of the cli: http://paste.ubuntu.com/348762/
<geser> you added "intltool" to Build-Depends and it didn't help?
<dhillon-v10> geser, yah do you want to see the control file
<geser> I trust you, but a look doesn't hurt
<dhillon-v10> geser, here: http://paste.ubuntu.com/348764/
<dhillon-v10> geser, thanks :D
<geser> dhillon-v10: why "intltool | libz-dev"?
<dhillon-v10> geser, I don't know, I am actually updating a package, so I used the control file from the last package that was debianized, that's how I saw it in the tutorial on wiki
<geser> as you have also zlib1g-dev in your Build-Depends which also provides "libz-dev" this dependency is also fulfilled and intltool not installed
<dhillon-v10> geser, so its the placement of the dependencies, if I change it, it will work
<geser> try using only "intltool" -> "..., zlib1g-dev, intltool, autotools-dev, ..."
<geser> it's not the placement but the OR combination
<dhillon-v10> geser, OH i just saw that bar, it means this package OR the other one
<geser> yes
<dhillon-v10> geser, thanks a lot, you are awesome. So what happens after i update this package successfully, does it go to REVU
<geser> it's an update of an existing package right?
<dhillon-v10> geser, yes
<geser> then attach a debdiff to the bug for sponsoring (file the bug if needed)
<dhillon-v10> geser, the bug was already filed, but what happens to the new .orig file that I got from upstream
<geser> it's a new upstream version?
<dhillon-v10> geser, yah the upstream released a new version, someone filed a bug "needs-update" and I packaged it with this new build dependency here: https://bugs.edge.launchpad.net/ubuntu/+source/pcsx-df/+bug/403635
<ubottu> Ubuntu bug 403635 in pcsx-df "Please upgrade pcsx-df to 1.10 version" [Wishlist,Confirmed]
<geser> I'd say provide the link so the sponsor can get it himself (a verify it's integrity)
<dhillon-v10> geser, alright thanks again, I see the package needs some more build depends so I'll just add them :D
<randomaction> dhillon-v10: in this case, you should post a .diff.gz, not a debdiff
<geser> dhillon-v10: I just saw that the package got removed from Debian (and also already from lucid). Any good reason to have it back?
<geser> dhillon-v10: and got Debian bug #514446 resolved? as this was also the reason for the removal
<ubottu> Debian bug 514446 in pcsx-df "possible upstream license violation" [Serious,Fixed] http://bugs.debian.org/514446
<dhillon-v10> geser, nah, its an emulator, and a lot of people use it, so should I mark the bug invalid and not worry about the package ?
<geser> is the issue resolved (I didn't look yet). if it's not then there is no reason to package the new upstream version as it probably won't get accepted into the archive
<geser> and as the package has no Debian maintainer anymore, is the package important enough to get packaged by MOTU and be kept maintained (be whom)?
<dhillon-v10> geser, alright then, I'll leave the package alone, in Debian they just closed the bug and remove the package from unstable
<geser> you can set it to "Won't fix" (with a comment describing the situation)
<dhillon-v10> geser, alright did that
<dhillon-v10> geser, hey if debian doesn't have a newer package that was released by the upstream, should I bother packaging the newer version
<geser> you could try to work with the Debian maintainer on the new package so both Debian and Ubuntu benefit
<dabaR> How are you guys finding tasks for yourself to do?
<geser> it depends slightly on your interests
<dabaR> geser: what do you do in particular?
<geser> e.g. the gnome desktop team has a page listing the upstream package version, the debian package version and the ubuntu package version so they know what packages need updating
<geser> they also look at bugs, etc.
<dabaR> geser: I don't have a specific interest really yet.
<dabaR> geser: I would like to shadow someone working on their tasks, and learn from there.
<geser> I'm mostly fighting FTBFS, NBS, unmetdeps and use the lists displaying the data or the output of "apt-cache -i unmet"
<ScottK> dabaR: http://qa.ubuntuwire.com/ftbfs/lucid.html is a good place to look for things to do.
<dabaR> geser: are you working on one of those right now?
<dhillon-v10> dabaR, fixing FTBFS is a *huge* pain sometimes, and it needs a lot of love so you could try there
<geser> not right now, but I've a small list of packages where I already looked at the build log and have an idea what's need to be done
<dabaR> ScottK: Thanks. What do you think, is it realistic to hope that someone would talk along while doing a task? I just think it is too hard for me to pick anything in that list - it is too long.
<ScottK> dabaR: Depends on the person.
<ScottK> I think it's better to just pick something, dive in, and ask questions.
<dabaR> ScottK: what would you do if you landed on that page?
<dabaR> ScottK: click on some of the reds in the column for the arch I use?
<ScottK> dabaR: Yes, particularly if there is a package there you use or are familiar with.
<dabaR> And then read that, and start to understand what those contain, etc. OK, that sounds doable.
<EagleScreen> if I know how to compile and install a pieze of software, is it suposed that I can debianize it? or do I need anymore?
<dabaR> So, does this error: 'sh: gcc: not found'
<dabaR> mean that gcc is not a command recognized on the system in question?
<dhillon-v10> ScottK, do you have like 2 mins. I can't find much about v3 package format (the problem you said MoM had) I did google it though
<geser> dabaR: you can ignore that line, it's in every build log (even the successfull ones)
<geser> dabaR: do you know the basics of packaging python apps?
<dabaR> geser: For linux?
<dabaR> geser: Either way, no.
<geser> dabaR: yes, more specifically as debs
<geser> ok, so I try to find an other FTBFS for you to try
<geser> C/C++ knowledge?
<dabaR> I would not mind learning the basics of packaging python apps.
<dabaR> Mostly have interest with python, ruby, php, bash
<dabaR> s/with/in
<geser> dabaR: then try to look at  http://launchpadlibrarian.net/37025668/buildlog_ubuntu-lucid-i386.atheist_0.20091130-1_FAILEDTOBUILD.txt.gz
<dabaR> OK, slightly less huge file. Is there sections of it that I can ignore?
<dabaR> I expect these files have a structure...
<geser> they have (more or less)
<dabaR> Like, <stuff></stuff><some-other-stuff></some-other-stuff>
<geser> the first part is the update of the build environment (you can skip over it in most cases)
<geser> then the build-dependencies are installed (look for "Build started at 20091221-1944
<geser> ")
<geser> after that the real interesting part comes: the output of dpkg-buildpackage
<geser> and after that the clean up
<dabaR> are there any scripts set up to parse these files that any of you commonly use?
<geser> so I always jump first to the end (before the clean up part) to see why it failed
<geser> I don't know of any
<dabaR> That is probably the first thing I will write if there are not any, unless you guys know something I don't
<geser> there are many different reasons why a build might fail
<dabaR> So, what denotes the start of the dpkg-buildpackage in that file?
<geser> look for the line "------------------------------------------------------------------------------" after the installation of the build depends
<dabaR> ya, I thought it was that
<dabaR> after 'Toolchain package versions:'?
<geser> line 611
<geser> exactly
<dabaR> until ********?
<geser> and the reason for the FTBFS can be mostly found a few lines before "dpkg-buildpackage: error: debian/rules build gave error exit status 2"
<geser> yes
<dabaR> actually, until the next ------
<dabaR> Is the error that python2.5 is not installed??
<geser> yes
<dabaR> OK, slightly odd error....
<geser> the package build-depends on python
<geser> so python is installed but the default python version in lucid is python 2.6
<dabaR> and in Lucid python is 2.6, I get it.
<dabaR> So you change the build script to use python instead?
<dabaR> or 2.6?
<dabaR> And test
<geser> yes
<dabaR> Or make it build-depend on 2.5?
<dabaR> The simplicity of the solution makes me excited....
<dabaR> Heh, weird sentence.
<geser> that would be the alternative (if using python 2.6 doesn't work out)
<dabaR> geser: is this a bug you noticed yourself?
<dabaR> I mean, a thing you were gonna fix, that you mentioned previously?
<dabaR> You mentioned previously that you reviewed some FTBFSs and have a few you are going to work on. Is this one of those?
<geser> yes, it's listed on http://qa.ubuntuwire.com/ftbfs/ (package is atheist) and I look at the build logs to see if I know how to fix it
<dabaR> geser: Now, is the bug an Ubuntu only bug, or a Debian bug as well?
<geser> I've looked at the build logs once and made me a note (so I don't forget what I already figured out :) but I didn't had time yet to work on it
<dabaR> geser: do you happen to know.
<dabaR> Meh, stupid question, I guess.
<bjsnider> package is atheist? the package doesn't believe in god?
<geser> Debian did't switch to python2.6 yet, so for now it's a bug that affects Ubuntu only but will affect Debian later too
<dabaR> But, to fix it, you are changing a debian package source, right?
<dabaR> OK, sorry to jump from topic to topic so fast...just kinda answering my own questions...
<geser> yes, I take the Debian package, patch it, test-build, upload and provide the patch to Debian (if they are affected too)
<dabaR> A-ha.
<dabaR> OK, just cause if they don't make the change, then it is a merge from there on, right?
<geser> yes
<dabaR> geser: Great, thanks so much.
<geser> and don't forget to check if lucid and Debian has the same package version
<dabaR> geser: cause debian could have changed it already?
<geser> so you don't waste time to fix something that is already fixed in Debian but got not yet into lucid
<dabaR> right right, then you request a sync if it is changed, right?
<dabaR> geser: so, do you then basically click each red box in turn, scroll to the deb-buildpackage error message, and read that to see whether you can fix it?
<dabaR> Just as a process question...
<geser> depends, as we are still in auto-sync mode, I just wait for the next auto-sync (if the change is already in testing) or wait till it gets into testing
<geser> dabaR: exactly
<dabaR> geser: A-ha, so it is more complex...
<dabaR> geser: I think I am totally gonna write me a Mechanize script for these.
<dabaR> geser: again, thanks very much. Talk to you again soon.
<dabaR> Is my browser unpacking a txt.gz for me? Do you happen to know?
<directhex> browsers tend to open .gz due to gzip compressed html stuff
<jjlee> I'm packaging a python library and want to build debian packages from a fork of the original git repository.
<jjlee> That means that I need to create orig tarballs from the in-development sources in the repository.
<jjlee> python's setuptools wants to build tarballs named like this: figleaf-0.6.1.dev-20091229.tar.gz
<jjlee> hmm, I was about to ask what I should rename it so that git-buildpackage --git-pristine-tar tries to find the correct pristine-tar tag, but I see the problem is that git-buildpackage is looking for a filename without ".orig" in it
<jjlee> so I guess I should rename the tarball to have the ".orig" in the filename
<jjlee> is there a command to get the appropriate .orig.tar.gz filename from the changelog?
<jjlee> I'm already using dpkg-parsechangelog, but that doesn't give the source package filename
<jjlee> is there a better way that just running dpkg-parsechangelog, grabbing the Version: line, splitting off everything after rightmost "-" in that version string, prepending source package name and appending ".orig.tar.gz"?
#ubuntu-motu 2009-12-30
<directhex> jjlee, let me know if there is, i carry that baggage around in debian/rules all the time
<jjlee> bleh
<jjlee> I guess git-buildpackage gets it from somewhere...
<jjlee> or I guess it's actually dpkg-buildpackage or something below that
<jjlee> I'm not sure where to get the source package name from, either
<jjlee> is there a command to parse that out of debian/control?
<mahngiel> if i wanted to get involved developing a better gnome menu bar... where would i start?
<bddebian> freedesktop.org?
<bddebian> The Gnome project?
<mahngiel> i meant... as far as finding source, to hack at, and then propose
<mahngiel> bddebian: do you know where the menu bar module can be found? i've only been able to find bits and pieces, but not the parent
<bddebian> No idea, sorry
<bjsnider> mahngiel, how do you mean the menu bar?
<mahngiel> ya, didn't think so. i've found children in ~/.config/menus and /etc/xdg/menus. but nothing about the actual parent. it HAS to have a parent, it's referenced in languages and themes
<mahngiel> bjsnider: i mean the "Applications, Places, System" menu bar
<bjsnider> mahngiel, forget it
<mahngiel> bjsnider, hm?
<bjsnider> it's dead code. it's not being worked on anymore
<bjsnider> gnome-shell is replacing it and that's the code that's being worked on now
<mahngiel> bjsnider: ok, well if i wanted to break into it, and make it work-able for distros prior to lucid?
<bjsnider> it's a gnome-panel app
<mahngiel> hackable?
<bjsnider> i don't know why anyone would accept patches though
<mahngiel> no, but people still use hardy :/
<bjsnider> take a look at the source for gnome-panel and look at the applets
<mahngiel> if i wanted to break into the code, and adjust it for current use in karmic... could you point me in the right direction to find it's parent?
<bjsnider> i forget which one it is
<mahngiel> alright, thanks
<bjsnider> you can right-click on the panel and go throught he list until you find it
<mahngiel> i know it's called 'menu bar'. just trying to find the main parent. the user/system files i've found are just children
<bjsnider> so you'd have to change it and make it work and then release a ppa version of gnome-panel i suppose
<mahngiel> that's not an issue, finding the s.o.b. HAS been
<mahngiel> but looking through gnome panel is a new start.
<bjsnider> what is so terribly broken about it? and you know there are alternatives
<bjsnider> there's a project called "ubuntu system panel" out there for one
<mahngiel> i'm not aware of any alternatives, and it's not that it's 'broken'... it's just that it's not customizable to my regards
<bjsnider> there's an alternative already in there
<bjsnider> i forget what it's called
<mahngiel> end effect, i would like to expand it's .menu holders from 3 to more/less depending on the user, and the names
<mahngiel> the files accessible through local files only replicate what can be accomplished through the 'menu edit' mod
<bjsnider> in a year's time i don't know how many users will still be using gnome-panel
<mahngiel> well, that's refreshing to hear. but in that same regard, people (including myself) still use XP :)
<mahngiel> it's just a matter of being able to get something unique and enjoyable to the end user. and being an end user and hobbying hacker, i'm trying to figure how to customize the damned menu bar
<mahngiel> i'm not sure the plan for implementing task/tool bars in lucid, but i'm sure there'll be a reciprocative effect of what is the current menu bar, unless the plan is to be more like win/mac to attract users
<bjsnider> great idea but several years too late
<mahngiel> however it goes, my friend, people enjoy *nix systems due to customability. everything should be customizable, and being GPL and open source, finding homes to things they'd like to hack ought to be attainable
<bjsnider> actually if you want to talk to the gnome devs about this, you can go to irc.gnome.org #gnome-shell
<bjsnider> i suspect the features you're talking about were left out intentionally, because if you give the user the power to screw up the menu bar, they'll screw up the menu bar
<mahngiel> hahaha. truth preached my friend. unless the capable hacker comes along and provides a howto. such as we seen grub2 f*ck ups before public documentation. hahaha
<mahngiel> anyways, thanks for the chat.
<mahngiel> you sure that was #gnome-shell? room was empty
<bjsnider> irc.gnome.org
<bjsnider> not freenode
<mahngiel> that's what i get for drinking. :) carry on.
<MTecknology> kimi: aparently I was able to register for two classes that happen at the same time....
<MTecknology> ^ wrong chan; sorry
<persia___> zooko: Sorry for the delay: I have fairly large latencies in my connection now (10-100 Ksec).  I'm not particular about how I'm quoted, although using my name in  email may make it easier for someone to find me for a direct quote, and using my nick may be easier if you want to paste IRC log and reference http://irclogs.ubuntu.com/2009/12/29/%23ubuntu-motu.html
<superm1> bjsnider, why is your 190.53 driver package depending on "libvdpau"?  there's no need for such a dependency
<superm1> if something else is using vdpau, shlibs will cause the package to depend on libvdpau1 (which is appropriate)
<superm1> the nvidia driver package itself doesn't need libvdpau to operate (and if it did, it would be libvdpau1 not libvdpau)
<zooko> persia: FYI here is the plan for Tahoe-LAFS v1.6 (such as it is): http://allmydata.org/pipermail/tahoe-dev/2009-December/003436.html
<Marcham89> Hello
<AnAnt> Hello, is there a team on Ubuntu for scientific/electronic packages ?
<rawang> hello, any ubuntu motu who conduct ppa here?
<rawang> I have the questions about ubuntu ppa
<slytherin> rawang: just ask
<rawang> slytherin, alright, I just successfully built a package, and build another package which depends on it. when ppa install that package, it runs into error, and I can't figure out what's the problem.
<rawang> http://launchpadlibrarian.net/37265946/buildlog_ubuntu-karmic-i386.mono-uia-atkbridge_1.0-2~pre1_FAILEDTOBUILD.txt.gz
<rawang> slytherin, it said when it wants to install some assemblies, it failed, but i manage to install it locally
<slytherin> checking
<slytherin> rawang: are you sure you have specified correct dependencies?
<slytherin> rawang: and in regards with mono directhex is the best person to ask for help.
<rawang> slytherin, he saw, and I've tried his suggestion with no luck
<rawang> E: installing Assembly /usr/lib/mono/accessibility/UIAutomationProvider.dll failed
<rawang> ppa just say it failed, but without any details about why it failed
<rawang> slytherin, would PPA be more verbose when building a package?
<rawang> s/would/Could/
<AnAnt> I have a question, in Ubuntu there are geda-* (version 1.4.x) source packages , currently geda upstream unified all source tarballs into one (using a unified build system), and that is in Debian unstable now (and the geda-* source packages got RM'ed), will Ubuntu be able to sync that situation for lucid ?
<slytherin> rawang: won't make a difference. The failure here is to install one of the build dependencies. Not some problem with package you are trying to build.
<slytherin> AnAnt: Provided it enters in Debian testing.
<AnAnt> slytherin: ok
<AnAnt> slytherin: and the old geda-* packages would be removed from lucid too ?
<rawang> slytherin, yes, that makes sense, but why it failed at installing one of the build dependencies while preparing build environment? do you have any idea? :)
<slytherin> AnAnt: Ubuntu archive admins keep watch on removals in Debian and carry out same removals in Ubuntu too.
<slytherin> rawang: Nope. I don't do mono development/packaging.
<AnAnt> good, thanks
<rawang> slytherin, k, but thanks all same :)
<rawang> slytherin, btw, would you have a chance to sponsor my package? i have been waiting for almost 7 month.....   https://bugs.launchpad.net/ubuntu/+bug/380496
<ubottu> Ubuntu bug 380496 in ubuntu "[needs-packaging] strongwind" [Wishlist,New]
<slytherin> rawang: I work mainly on java packages. And I usually stay away from python. So can't help here. :-)
<rawang> slytherin, alright, so who is the right person that i'd better to ask? :)
<slytherin> Can't say.
<rawang> slytherin,  np, thanks a bunch :)
<geser> porthose: I've added a comment to your merge proposal for bpython
 * porthose looks
<porthose> geser, I will look into it when I wake up, the sun is coming up and I should really get some sleep first before I mess with it :)
<geser> ok, no hurry and sleep well
<jjlee> can anybody suggest a simple python setuptools-based package to crib from?  What do people do to exclude debian/ from the setup.py sdist generated orig.tar.gz?
<Laney> jjlee: you're probably better off asking #debian-python @ oftc
<jjlee> thanks
<slacker_nl> are SRU's also sponsored? or need to be
<Laney> yes
<slacker_nl> aha.. can someone sponsor https://bugs.launchpad.net/bugs/350562
<ubottu> Ubuntu bug 350562 in gdesklets "gdesklets requires python2.5 without package dependency" [Undecided,Fix released]
<slacker_nl> ?
<Laney> needs sru ack first
<slacker_nl> so sru acks, then it goes into sponsering then magic happens and everyone is happy
<Laney> that's the idea
<slacker_nl> k
<Laney> (if you subscribe the sponsor team)
<slacker_nl> sru doesn't do that?
<slacker_nl> i'll keep an eye on my mailbox then
<Laney> i wouldn't count on it
<slacker_nl> thnx
<bjsnider> superm1, i have you now...
<bjsnider> the answer to the question why is libvdpau in the depends field in my 190 driver is that i based it on *your* 190 driver, and it is in the control file there
<bjsnider> observe:
<bjsnider> http://launchpadlibrarian.net/35457837/nvidia-graphics-drivers-190_190.42-0ubuntu1%2Bppa2.diff.gz
<bjsnider> Depends: nvidia-190-kernel-source (>= 190.42), libvdpau, x11-common (>= 1:7.0.0), ${shlibs:Depends}
<joe____> hello, I am trying to get into ubuntu development and packaging.  I am looking at the motu TODO for ideas. I figured I can work on stuff in harvest (more spefically patches) does that make sense?
<randomaction> yes you can review patches, convert them to debdiffs and ask for them to be uploaded
<fabrice_sp> joe____, you can also have a look at build failure, and you should also have a look at the sponsorship process, to know how to 'submit' your work for sponsorship
<fabrice_sp> (see topic for 'hot' topics ;-) )
<fabrice_sp> Hey randomaction !
<fabrice_sp> :-)
<fabrice_sp> I still hate baazar for sponsoring :-)
<randomaction> hello fabrice_sp
<geser> I get slowly used to it (if I don't stumble across bugs or out-of-date branches)
<randomaction> build-from-branch should change the game
<randomaction> is there a roadmap for it?
<fabrice_sp> I still think it's slower than sposoring a debdiff, and people don't review the previous changes as they should
<joe____> i look for build failure at debcheck on qa.ubuntuwire.com right?
<fabrice_sp> joe____, http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi is more up-to-date, IIRC
<geser> fabrice_sp: that are the results from lucas' last archive rebuild
<geser> the current archive FTBFS list is at http://qa.ubuntuwire.com/ftbfs/
<fabrice_sp> geser, I remember reading that the lucas's list was more accurate
<fabrice_sp> Anyway, I may be wrong or misunderstood
<randomaction> the official one lists only half as many packages
<geser> you probably need a combination of both lists: lucas to see what would fail in a archive rebuild and the other to see what is also currently failing to build
<randomaction> I think it's because packages which were not modified in this cycle weren't rebuilt
<geser> yes
<fabrice_sp> the archive will be rebuilt as soon as auto sync stop, right?
<fabrice_sp> I remember some comments saying that in this cycle, we won't deliver binaries that won't have been rebuilt at least once
<geser> don't know when lucas planned the next archive rebuild, but short after DIF would be nice
<geser> fabrice_sp: we won't ship binaries that fail a rebuild test
<randomaction> there was a proposal by ScottK to rebuild everything and remove binary packages
<geser> if the package was last modified in e.g. hardy but still builds it's ok
<fabrice_sp> very good idea, IMHO
<joe____> well in the one that fabrice sent me for example there is a failed build in f-spot but in the ubuntuwire one that doesn't exist and on LP it says it built
<geser> randomaction: yes, but we won't do (source-)uploads to test for it
<randomaction> sure
<geser> joe____: that only means that it build once in the past but not anymore
<fabrice_sp> joe____, it means that f-spot now FTBS, but not when it has been uploaded
<fabrice_sp> too slow :-)
<joe____> gotcha, thanks
<randomaction> by the way, that proposal was to rebuild+remove at the very beginning of the cycle, and it didn't happen, did it?
<fabrice_sp> AFAIK, no
<geser> no, it didn't happen yet
<randomaction> next logical point to do it is DIF
<ScottK> randomaction: The rebuild happened, but the analysis results aren't complete.
<geser> you also need to check if you don't break other packages with removing a binary (and what to do about it)
<DktrKranz> is it just me, or some Debian package branches are not up-to-date?
<geser> it's not only you
<geser> see http://package-import.ubuntu.com/failures/.bzr/failures/ for a list of packages where importing failed
<cyphermox> fabrice_sp, i see you reassigned yourself bug 495998. It is because I completely did it wrong or because you're looking at my merge request? :)
<ubottu> Launchpad bug 495998 in resolvconf "Please merge resolvconf 1.45 (universe) from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/495998
<lucas> geser: when is DIF?
<sebner> lucas: mid-february
<lucas> ok, I can do another rebuild before that too
<geser> lucas: around Feb 11th 2010 (https://wiki.ubuntu.com/LucidReleaseSchedule)
<sebner> lucas: ah you are mighty Lucas Nussbaum :D huhu there
<sebner> geser: ~aloha~
<geser> sebner: Hi
<asac> whats the single best resource for doing merges with bzr?
<asac> how about adding reference to that to the merges.html page on ubuntuwire.com?
<micahg> asac: probably this: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
<micahg> lucas: ^^
<asac> ok let me check
<asac> so we are going to native package everywhere?
<asac> ugly imo ... but well
<geser> asac: before you start check that the debian branch is up-to-date
<asac> sure
<siretart> asac: what makes you think so?
<asac> the fact that i only looked at resolvconf
<asac> ;)
<siretart> asac: btw, are the Xb-Npp- flags in the mozilla-plugin-vlc package still of any use in lucid?
<asac> so how dose bzr bd spot the pristine-tar thing?
<asac> siretart: why wouldnt they?
<asac> we still have a plugin DB ... and we will in future
<fabrice_sp> cyphermox, working on the merge :-)
<asac> you can put that into debian directly imo
<asac> it doesnt hurt and debian is slowly accepting innovation ;)
<asac> fabrice_sp: for me it looks good
<asac> (the merge)
<jjlee> I just got this error even though I just deleted the package from my PPA:
<jjlee> File python-figleaf_0.6.1.dev-20091230.orig.tar.gz already exists in PPA for python-figleaf, but uploaded version has different contents.
<siretart> asac: I've just uploaded 1.0.4-1 to debian and could have just added them, but I have no idea what package/program uses that information
<asac> jjlee: deleting doesnt remove origs
<fabrice_sp> asac, I'm fixing the postrm script
<jjlee> asac: why not?
<asac> siretart: its used to populate the online db for plugins
<fabrice_sp> otherwise, looks good, yes :-)
<siretart> asac: could you perhaps file a wishlist bug in debian with that information? I'll add that then to our git branch so that it can get included in vlc_1.0.4-2
<jjlee> asac: in this case, it's an orig I built myself
<asac> so based on that the firefox plugin finder can show proper debian packages for mime-types
<siretart> what's 'the online db'?
<asac> siretart: since you apparently do the merges in debian, i am sure you will remember on next merge ;)
<asac> siretart: its an online webservice that gives info what plugins exist for a given mimetype
<asac> so you get choice for flash: gnash, swfdec flashplugin
<asac> nonfree
<asac> etc.
<asac> and for all the other mime types we have
<asac> mozilla has its own online webservice, but since they have exactly one plugin in there, we run our own in ubuntu
<asac> like http://people.canonical.com/~asac/pfs/screens/pfs1.png (old screenshot from gutsy iirc)
<asac> jjlee: well. that means you first uploaded an orig that was different to the one you now try to upload :)
<asac> if you create the same orig two times thats usually the outcome
<asac> so you need to get the orig from the ppa somehow
<asac> (check the pool)
<asac> or you need to artificually bump the upstream version
<jjlee> asac: think I'll bump upstream, or it will get annoying
<asac> why?
<asac> just download the orig from pool ;)
<asac> and use that
<asac> but your decision ;)
<asac> as long as its not a package in real archive it doesnt really matter what version it is
<siretart> asac: no, please still file a wishlist bug with references to this online db, I'd like to read more about it and add some lines for that in the package
<matti> ;]
<asac> siretart: there isnt much info about that online db, except the initial spec.
<asac> its really old mozilla stuff that we just host on our own now
<asac> and we could host for debian
<asac> too
<siretart> asac: now you confuse me again. are these flags useful for a package in the debian archive at all or not?
<asac> they dont hurt. and if debian wants to adopt it we can use those flags
<asac> if it means that you can sync
<asac> its good to just add them to debian without thinking
<asac> if you have to merge anyway, then its not important until we decide to bring this service to debian
<siretart> I cannot sync anyway, because debian does not have libx284 (anymore)
<asac> so no. atm, it doesnt give any benefit for debian except that you can sync if you add the flags there
<asac> then dont bother. we would file bugs if we start a service like that in debian anyway
<siretart> ok, so in short: we have some magic webservice running on some ubuntu server that the firefox package uses to detect that mozilla-vlc-plugin could be useful for some mimetypes in the firefox package, right?
<asac> yes
<asac> we have that for all plugin packages
<asac> its potentially useful for all browser that can make use of nppapi plugins
<siretart> why not package that database? I cannot imagine that there are frequent updates to that
<asac> there are
<asac> also the whole online lookup stuff is already in firefox
<asac> so we just extended the same mechanism
<siretart> aha
<asac> also it merges results from the mozilla webservice
<asac> so you get mozilla results + our results
<asac> the url to the service is in the firefox pref called: pfs.datasource.url
<asac> the webservice and database population code is currently in the ubufox source
<jjlee> asac: does PPA system keep source packages forever?
<asac> it keeps the memory of them forever, yes
<jjlee> oh, just the hash?
<superm1> bjsnider, ah well that's totally a mistake then :) where did i have that published?
<bjsnider> superm1, in your ppa
<asac> jjlee: usually you remember to be more careful about origs in future after oyu bumped into this ;)
<superm1> bjsnider, ah i just used that for staging a while back, i'll delete it from there
<bjsnider> i'm planning on switching things over when alberto gets finished with the new scripts
<asac> jjlee: just like in real "archive" life ;)
<jjlee> asac: or you just say heck, Irebuild the thing
<jjlee> *I'll rebuild the thing every time
<bjsnider> siretart, should mplayer in karmic be able to play wmapro audio files?
<asac> jjlee: rebuild?
<superm1> bjsnider, in the interim can you just drop that dependency?
<superm1> it will keep people sane and prevent upgrade problems when they're using the mythbuntu PPAs
<jjlee> asac: a new .orig.tar.gz every time
<asac> why?
<asac> thats exactly what is causing the problem here ;)
<asac> dont rebuild origs ... reuse them
<bjsnider> superm1, sigh
<siretart> bjsnider: not sure, I don't think i have samples on my lapotop to test
<jjlee> won't cause a problem if it has a different upstream version (which it does, in build I just submitted)
<siretart> sebner: yes?
<bjsnider> well, at least i wouldn't have to upload a new source tarball
<superm1> bjsnider, we unfortunately get people trying all sorts of wacky combinations like that and reporting bugs :)
<bjsnider> siretart, i have one i can send you a link
<siretart> bjsnider: how about you try yourself? ;-)
<jjlee> asac: it's a useful feature for a package that has any visibility of course, but for this little PPA I've not told anybody about, it was just irritating :-)
<bjsnider> siretart, i did. it failed
<bjsnider> but rvm's ppa has an older mplayer that supposedly works
<bjsnider> i think he's using internal libavcodec
<sebner> siretart: hmm, might work here as well. I was told that you might be able to help me as you are related to sound stuff. The problem is burning stuff, to find out if a) the burner dies b) ubuntus fault or c) of the CDs
<bjsnider> superm1, is the vdpau nvidia driver pre-built? we don't build it against the libvdpau.h file?
<siretart> sebner: puh, I'm not sure what makes you think I was qualified for these questions.. ;-)
<superm1> bjsnider, the closed source libvdpau_nvidia, yes it's prebuilt
<superm1> bjsnider, the libvdpau drivers for all other applications using libvdpau will need to build against libvdpau.h
<bjsnider> so how do we know which version of vdpau they built it against?
<siretart> bjsnider: perhaps the auto detection of mplayer is a bit wacky. try forcing the available codecs to see if one of them works
<bjsnider> siretart, interesting you say that because it does say it has codecs for those files
<superm1> bjsnider, at this point it's "whatever was latest", but its irrelevant since their API for using it hasn't changed
<abogani> Hi All, Someone could upload a patch (I can provide it) for updating linux-rt package? Thanks in advance!
<abogani> ^ I meant for Lucid.
<superm1> bjsnider, so 190.53 will work with the latest libvdpau, 0.3-2
<ScottK> abogani: Are you an Ubuntu Studio developer?
<jjlee> by the way, what's the policy about upstream maintainers maintaining (non-native) debian packages?
<abogani> ScottK: Yes.
<asac> jjlee: what do you mean=?
<ScottK> jjlee: There isn't one, but we generally encourage it.
<asac> jjlee: in general we encourage upstream folks to maintain their stuff in ubuntu directly
<jjlee> ok
<bjsnider> superm1, is alberto ever in any of these channels? there's some info in the new control files that needs to be changed
<ScottK> abogani: I'd ask TheMuso to upload it since a: He can and b: he's involved in Ubuntu Studio.
<asac> its just that usually we do that as a service for them
<jjlee> by "in ubuntu", you mean that the package is uploaded to universe / multiverse, I guess?
<asac> yes
<asac> also main
<jjlee> cool
<ScottK> jjlee: Even better to maintain it in Debian so more people benifit from your work.
<asac> right ;)
<asac> but step by step
<asac> ;)
<jjlee> ScottK: sure
<jjlee> asac: quite!
<superm1> bjsnider, he's in #ubuntu-x when he is
<superm1> tseliot is his nick
<dabaR> geser: Are you around?
<geser> dabaR: yes
<dabaR> Cool. I have a follow-up question on our conversation from yesterday. Once you decide on how to fix some package, like atheist from yesterday, what is the process to get it applied?
<dabaR> For the fix to make it into Ubuntu
<ScottK> dabaR: Attach the fix to a bug and subscribe ubuntu-universe-sponsors to the bug.
<ScottK> (assuming the package is in Universe/Multiverse)
<dabaR> ScottK: so there is a bug for each of the FTBFSs?
<geser> dabaR: https://wiki.ubuntu.com/SponsorshipProcess
<ScottK> dabaR: As a rule, no.  You need to file one.
<geser> dabaR: no (unless you file it)
<dabaR> ScottK: So maybe, to start working on a FTBFS, you search whether there is a bug for it, and then you file a bug if there is not, then you make the changes, and attach a fix to the bug, and then subscribe the appropriate sponsors team?
<ScottK> dabaR: Yes, although there's really no point in filing the bug until you have a fix.
<dabaR> ScottK: how do you avoid working on the same bug as someone else? Does it just generally not happen?
<ScottK> dabaR: It happens every now and then, but there's 20,000 packages in Universe.
<dabaR> Not so many FTBFSs in Lucid ATM, though, right?
<ScottK> True
<ScottK> Still it's uncommon that two people work on the same thing.
<dabaR> But it is not a problem you have identified, right? I understand you are very involved in MOTU
<geser> but still more than person working on them
<dabaR> I meanm, you work on it quite a bit
<ScottK> dabaR: It happens, but rarely.  Yes
<ScottK> IMO it's more work to document what everyone is working on than is saved by it.
<dabaR> ScottK: And ubuntuwire FTBFS page, how often are new builds done?
<geser> the page itself is updated every 4 or 6 hours (don't know exactly)
<ScottK> qa.ubuntuwire.com/ftbfs is based on the current state of the archive.
<ScottK> So it only changes when a new package is uploaded or a build attempted.
<dabaR> So it polls for changes in the archive?
<geser> yes, it asks LP for all current builds that FBTFS and displays it in a nice overview
<dabaR> So Launchpad tracks similar information, do you know the URL for that?
<geser> it tracks it on per-package basis so there is no overview
<dabaR> Oh, OK, probably to do with how the packages can be tagged with releases...
<geser> dabaR: see e.g. https://edge.launchpad.net/ubuntu/+source/atheist/0.20091130-1 (look at Builds)
<dabaR> geser: how would you reproduce that bug on your system?
<dabaR> I mean, how would you try TBFS and fail?
<geser> I use pbuilder (others prefer sbuild)
<dabaR> geser: what about starting from open terminal
<dabaR> Do I apt-get source atheist?
<dabaR> And go from there
<geser> yes
<geser> but I prefer using pbuilder for test-building to not pollute my system with -dev packages that I won't need a few minutes later anymore
<dabaR> so what command do you run?
<dabaR> pbuilder atheist?
<geser> !pbuilder
<ubottu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<dabaR> Thanks
<geser> "apt-get source -d atheist" (don't unpack) and later "pbuilder build atheist.*dsc"
<dabaR> Where does dh_clean get defined?
<christoph_debian>  /usr/bin/ ?
<dabaR> dh_ which one
<dabaR> I mean, there is no dh_clean in /usr/bin on my computer./
<randomaction> dabaR: debhelper package
<dabaR> What creates a .dsc file?
<dabaR> is it dpkg-source?
<dabaR> I mIt is
<dabaR> So when I build a package with pbuilder, I specify the .dsc file, but the output seems to "dpkg-source: info: extracting atheist in atheist-0.20091130
<dabaR> Unpacks the orig tarball, and applies the diff.
<dabaR> Where do I apply the changes I make to the source package I downloaded?
<dabaR> In the unpacked directory that is in the same place where the orig and diff files are?
<dabaR> Or does that get overridden as shown in the pbuilder output?
<dabaR> OK, I think I got it. I make the changes in the unpacked dir, then I pdebuild, right?
<dabaR> So pbuilder creates a build environment for itself, right?
<randomaction> yes, or you can debuild -S, which will create .diff.gz and .dsc which you feed to pbuilder
<dabaR> pdebuild gives me errors about unmet dependencies. Should I somehow edit .pbuilderrc?
<dabaR> To point it to my base.tgz, or something?
<randomaction> did you enable universe in pbuilder?
<dabaR> Dunno
<dabaR> I will now
<randomaction> PbuilderHowto has a section for it
<dabaR> I see it in the howto
<randomaction> it's off by default, so you need to do it if some of build-deps are in universe
<dabaR> I've got a .build file now.
<dabaR> randomaction: do you use pbuilder?
<randomaction> yes
<dabaR> So I have modified my .pbuilderrc and still there is an error about unmet dependencies.
<dabaR> Is the command just pdebuild?
<randomaction> pdebuild I don't use :)
<dabaR> Should I just install its build dependencies? SHould I use the satisfy dependencies flag?
<dabaR> Oh, I see.
<randomaction> so, you enabled universe?
<dabaR> AFAICT
<randomaction> try to create a source package (debuild -S from the package directory)
<dabaR> So I have to have a valid GPG key to build the package?
<dabaR> In fact, why is it trying to sign with someone else's signature
<randomaction> no, if you don't you'll just be making unsigned packages
<randomaction> because it's the last entry in changelog
<dabaR> So I should change the changelog :)
<randomaction> use dch -i
<dabaR> And is there an option for debuild to not sign?
<dabaR> Or how do I prevent signing it?
<christoph_debian> -uc -us
<christoph_debian> or ignore the error
<dabaR> Oh, so it does make a file for me.
<dabaR> I see it there.
<dabaR> Heh, it seems to have worked :-/
<dabaR> So the change is in debian/control
<dabaR> What does the uploader for a debian package mean vs. maintainer?
<dabaR> Uploader is the person that packaged it?
<dabaR> Maintainer works on the software?
<christoph_debian> Maintainer is the main packager
<christoph_debian> uploaders help packaging
<MTecknology> !info openbox lucid
<ubottu> openbox (source: openbox): standards compliant, fast, light-weight, extensible window manager. In component universe, is optional. Version 3.4.7.2-5 (lucid), package size 266 kB, installed size 1432 kB
<dabaR> OK, so this package, atheist(stole it from geser's todo list), basically fails because in Debian, where we are getting atheist from, python by default is 2.5.
<dabaR> If I change XS-Python-Version: 2.5 in the control file to 2.6 it builds fine.
<dabaR> The other way to go about it would be to make it build-depend on python2.5, but that does not sound right to me anyway.
<dabaR> Is atheist_0.20091130-1ubuntu1.diff.gz, as created by debuild -S then the fix that should be attached to a bug that would be opened in Launchpad?
<randomaction> attach a debdiff, see https://wiki.ubuntu.com/Bugs/HowToFix
<randomaction> by the way, your original .diff.gz is probably screwed up because you ran debuild with updated package and unmodified changelog
<jbicha> dabaR: Debian is switching to Python 2.6 now, so you should report that to them also
<dabaR> Is Lucid auto-synching with testing or unstable? I read only the beginnings of the discussion./
<randomaction> with testing
<dabaR> jbicha: how likely do you think it is that there are many other packages with the same problem?
<dabaR> I mean, it just sounds like something that should break every single python package
<jbicha> dabaR: this has all of the known bugs with the Python 2.6 transition: http://tiny.pl/hqwjz 2.6 didn't change very much so packagers should have tested on 2.6 and updated the python-version to match
<dabaR> jbicha: so in other words, this guy did not notice, so if I tell him, he will be glad to hear about it, or whatever.
<jbicha> yeah, it sounds like a simple fix that would make things better :-)
<randomaction> is there a way to make it work for both 2.5 and 2.6?
<ScottK> Probably XS-Python-Version: (>= 2.5)
<ScottK> And build-depends python-all instead of python or python-all-dev instead of python-dev (depending on what's there already)
<dabaR> Well, I think the only reasonable thing to do with this is tell the debian dev.
<dabaR> Doing any other work seems to be unnecessary, since he will have to fix it.
<jbicha> I'm not sure if I'm doing it right, but I didn't even use XS-Python in my packaging, I just build-depends on python-support
<jbicha> and had an extra file named pyversions with the content: 2.5-2.7
<dabaR> Although, maybe I should check at some point later whether he made the chaqnge, and if it does not fail to build any more
<jbicha> >=2.5 would be bad if it doesn't work on Python3
<ScottK> jbicha: No.  XS-Python-Versions is only python 2 versions.
<ScottK> jbicha: python-support will use the pyversions file, but atheist uses python-central.  Both use XS-P-V, so that's preferred.
<jbicha> ScottK: thanks, I'm new to this and still learning :-)
<ScottK> No problem.
<jbicha> dabaR: I saw this on KDE's Planet this week: http://blog.ricodigo.com/2009/12/29/authors/Patrick/new-atheist-quote-plasmoid-update/foss
<bjsnider> what's the deal with flash packaging? we're not allowed to include the plugin itself in a package but we can package a script that downloads and installs it right? something like that?
<geser> yes
<geser> and there is also a package in the partner archive
<bjsnider> the script can download the plugin directly from adobe's site?
<ScottK> Yes.
<ScottK> We used to have that
<ScottK> Now we download from the partner archive.
<bjsnider> does the partner archive have the native 64 bit plugin?
<ScottK> No idea.
<ScottK> One of the rules I know is only final releases go there.
<ScottK> So if it's still beta, it won't be there.
<bjsnider> it gets sent in automatically by adobe?
<superm1> i doubt it's automatic
<bjsnider> what i mean is, it's not someone here uploading it. it's adobe
<bjsnider> but, it doesn't matter. i'm not interested in that one
<ScottK> AFAIK, Canonical controls uploads to Partner.
<porthose> geser, bug #501481 has been update, please have a look when you have time :)
<ubottu> Launchpad bug 501481 in bpython "Merge bpython 0.9.5.2-3 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/501481
<porthose> s/update/updated
<porthose> ScottK, I am working on the list you requested and will get it to you asap ty :-)
<ScottK> porthose: Great.
<geser> porthose: no need to mention the update of the maintainer field in the changelog and don't forget to mention your new changes in debian/changelog the next time (will do it now before uploading).
<MTecknology> ok... I'm going to try to package openbox again....
<Flannel> MTecknology: Isn't it already packaged?
<MTecknology> Flannel: 3.4.7.2 is
<MTecknology> Flannel: 3.4.9 isn't; and has a whole lot of changes
<bdrung> porthose: do you plan to become motu?
<MTecknology> Flannel: and I'm giving up - I'll just pester the maintainer until they get it :P
<porthose> geser, damn and I know better :(
#ubuntu-motu 2009-12-31
 * porthose makes mental note not to work on any packages until he has had at least one cup of coffee
<porthose> bdrung hopefully
<bdrung> porthose: your name pops up to often. ;)
<porthose> bdrung, is that good or bad?
<bdrung> porthose: it's a good sign and an indicator
<bdrung> debfx: i have responded to bug #500310
<ubottu> Launchpad bug 500310 in purple-plugin-pack "Update purple-plugin-pack to 2.6.1" [Wishlist,New] https://launchpad.net/bugs/500310
<debfx> bdrung: I haven't found a way to make the watch file work as the download links don't contain the filename (e.g. http://plugins.guifications.org/trac/downloads/34)
<bdrung> debfx: did you try something like this: http://git.debian.org/?p=pkg-xmms2/abraca.git;a=blob;f=debian/watch;h=facbcba11ff9acd233d6df5f17ac74dd73f3b74d;hb=0ec9073e012fe96e580a98d6ad1fb7a7a3ba737e
<debfx> bdrung: that won't work as the URLs don't contain the version number
<debfx> afaik uscan can only match URLs but not the link text
<bdrung> debfx: yes, you are right. after reading the uscan manpage twice, there is probably no way to check it. can you mention the download page and the reason in the watch file (as comment)?
<debfx> bdrung: is it still a valid watch file if it just contains comments or should I keep the old one?
<bdrung> debfx: it only contains comments then (you do not have to keep the old one)
<debfx> okay
<bdrung> debfx: http://lintian.debian.org/tags/debian-watch-file-is-missing.html
<bdrung> debfx: "If the package is not maintained upstream or if upstream uses a distribution mechanism that cannot be meaningfully monitored by uscan and the Debian External Health Status project, please consider adding a debian/watch file containing only comments documenting the situation. "
<RoAkSoAx> ScottK, Hey! I sent you and email. I gotta go know. Please take a look at it.
<thopiekar> hi
<fabrice_sp> hi thopiekar
<thopiekar> could you please help me getting navit packaged for ubuntu? I'm a launchpad user and I created packages for navit on my karmic x64, but got this on launchpad..
<thopiekar> http://launchpadlibrarian.net/37287651/buildlog_ubuntu-karmic-amd64.navit_0.1.1-1ubuntu0karmic3_FAILEDTOBUILD.txt.gz
 * fabrice_sp looking
<thopiekar> somehow it doesn't work but the i386 build, which give no error message like the x64 build .. where is the difference building in x64 and i386?
<evfire> could someone give a look to this? https://bugs.launchpad.net/debian/+source/openrpg/+bug/177560
<ubottu> Ubuntu bug 177560 in openrpg "OpenRPG current version is out of date." [Wishlist,Confirmed]
<fabrice_sp> thopiekar, is it a arch=all package?
<evfire> there are two patches, I don't know if they're good
<fabrice_sp> thopiekar, or arch=any?
<thopiekar> fabrice_sp: it is at all a "multi - source - package"
<thopiekar> it has 4 binary packages and more than 6 arch independent packages..
<thopiekar> mom. i will pastebin the debian/* files..
<fabrice_sp> thopiekar, it's not building anything in adm64. Only cleaning. Are you sure the package builds fine in amd64?
<thopiekar> for sure.. it's working well on my x64 computer.
<fabrice_sp> evfire, in the changelog, the bug number should be lp: #?????
<evfire> and how is it?
<thopiekar> control: http://pastebin.com/d62ea06f4
<thopiekar> rules: http://pastebin.com/d6cbdd9ad
<evfire> oh, damn... I've seen it
<evfire> should I fix it locally and re-upload?
<fabrice_sp> evfire, other than that, seems good
<fabrice_sp> yes, please
<evfire> okay :)
<fabrice_sp> ;-)
<evfire> fabrice_sp, is debdiff really useful?
<evfire> it's 7mbytes...
<fabrice_sp> nop :-)
<evfire> better :D
<fabrice_sp> thopiekar, why is binary-arch emplty?
<thopiekar> fabrice_sp: at the beginning I wasn't using something like "binary-arch" but the launchpad builders said that they can'T find "binary-arch" in the rules file so I added this "dummy"..
<evfire> fabrice_sp, updated
<thopiekar> I'm building 4 different versions of navit .. so but I'm think it should be possible to get the opengl and sdl versions together, but I will have to talk with the devs of navit about it first..
<thopiekar> have you found the problem?
<evfire> fabrice_sp, is it ok for uploading now?
<fabrice_sp> evfire, I need to have a deeper look before uploading it, but a quick look does not show anything big
<fabrice_sp> thopiekar, you should build your package in binary-arch target
<evfire> okay :)
<fabrice_sp> and use -install files instead of all that cp commands
<fabrice_sp> evfire, I have to attend my family now, but will have a deeper look later :-)
<evfire> :D
<evfire> good new year, anyway
<thopiekar> fabrice_sp: so the line 208 should be called "binary-arch: binary", right?
<fabrice_sp> thopiekar, please, have alook at http://www.debian.org/doc/debian-policy/ch-source.html, debian/rules part to understand what you should do
<fabrice_sp> binary, binary-arch and build target is explained
<geser> thopiekar: the i386 buildd uses the "binary" target while the others (like amd64) use the "binary-arch" target
<thopiekar> and after "binary-arch" "binary-indep", right?
<geser> you need to arrange that the arch:any package are created in binary-arch while the arch:all packages are in binarry-indep and binary depends on both (so both arch:all and arch:any are build on i386)
<thopiekar> good - seems that I catched what the debian-policy-page says.. on i386 "binary" will be call which all was points to "binary-arch" and "binary-indep", but on other targets it calls "binary-arch" and "binary-indep" seperatly.
<geser> yes (but as the architecture-independent (arch:all) packages got already build, binary-indep is not called once again)
<thopiekar> so if there are arch:all and arch:any packages listed in [debain/control] it should run "binary-indep" after "binary-arch", right?
<thopiekar> your message, geser, is confusing me :P
<geser> the i386 buildds calls always the "binary" target which is often "binary: binary-arch binary-indep" in debian/rules. And "binary-arch" and "binary-indep" do the real work. On the other architectures the buildd uses always only "binary-arch"
<thopiekar> ok got that but what about "binary-indep" in other archs?
<geser> it's not called as the i386 buildd already build the arch:all packages
<thopiekar> aha!
<thopiekar> makes sense..
<geser> binary-arch <=> build arch:any packages, binary-indep <=> build arch:all packages
<thopiekar> otherwise it would create the same files again..
<geser> yes
<thopiekar> thanks geser, fabrice_sp
<geser> if you have pbuilder, you can use "pbuilder build" for n build like on the i386 buildd and "pbuilder build --binary-arch" for a build like on amd64 to test if your package will build in both cases successfully
<thopiekar> is it possible to crossbuild with it, too?
<thopiekar> maybe to armel? I would like to build into armel for Nokia Internet Tablets...
<thopiekar> :/ fixed my problem with binary-arch and -indep but I get the same problem like before..
<thopiekar> http://launchpadlibrarian.net/37323660/buildlog_ubuntu-karmic-amd64.navit_0.1.1-1ubuntu0karmic5_FAILEDTOBUILD.txt.gz
<geser> can you pastebin your current debian/rules?
<geser> I've the suspicion that you missed -a (and -i) to some dh_* calls
<thopiekar> geser: for sure - mom
<thopiekar> http://pastebin.com/d489fbce4
<thopiekar> I just see now that I haven't corrected .PHONY ..
<thopiekar> btw. I taked with users at #ubuntu.de about .PHONY but we haven't come to an end what .PHONY really is for.. so could you please tell me what .PHONY is for?
<geser> thopiekar: as I'm very familiar with Makefiles, I'd have to read it up myself and hope to understand it
<geser> if you look at your binary-arch target it depends on your install.* targets but it doesn't build any debs
<geser> have you tried taking a look at an existing package to see how they do it?
<thopiekar> no
<thopiekar> I think binary.pkg would package everything for me..
<geser> yes, but you depend only in your binary target on it
<geser> binary-arch has no dependency on it
<geser> and if you don't specify anything dh_ operates on *all* packages in debian/control
<thopiekar> so I should make deb-files after a install.* has finished?
<geser> but as you don't build arch:all packages on the amd64 buildd you need to tell it to operate only on arch:any packages (-a)
<geser> let me find an example
<thopiekar> btw. do you know a package that builds debs like I need to do? I could take a look at the rules file of that pkg how they build it...
<thopiekar> yeah, thanks
<geser> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/tea/lucid/annotate/head%3A/debian/rules
<geser> look at the binary, binary-arch and binary-indep targets
<thopiekar> aah!
<geser> the binary-arch targets calls the dh_ scripts to work on arch:any packages (-a), and the binary-indep targets specifies to work in arch:all packages (-i)
<geser> the binary target makes sure that both (binary-arch and binary-indep) are called (e.g. for the i386 build)
<thopiekar> but it doesn't matter that they use first of all binary-indep then binary-arch, right? I'm asking that because we said that it should be called binary: binary-arch binary-indep
<geser> the order shouldn't matter
<thopiekar> great! thanks again geser!
<thopiekar> I will try that out on my debian/rules
<geser> thopiekar: is your navit the same navit as in Debian? (http://packages.qa.debian.org/n/navit.html)
<thopiekar> In Debian it's the current svn version and navit in Debian isn't even providing the osd-layouts..
<thopiekar> I've added them in may package build..
<geser> ok
<thopiekar> geser it's working! thanks again! ppa:thopiekar/navit
<sebner> geser: bahh, how is the correct usage of --logfile? I use sudo puilder --logfile /home/sebner/log build foo.dsc and it's not working (starting even)
<geser> sebner: exchange the order of build and --logfile: pbuilder build --logfile ... your.dsc
<sebner> geser: uhh, you are my hero \o/
<randomaction> hey, I'm applying for MOTU, so if anyone wants to leave a comment you can do so at https://wiki.ubuntu.com/IlyaBarygin/MOTUApplication
<LinuxAdmin> hi guys
<LinuxAdmin> I'm getting troubles with "pbuilder update" command, I get "/home/nuno/.pbuilderrc: line 1: restricted: command not found"
<LinuxAdmin> can someone help me?
<LinuxAdmin> I'm starting with ubuntu development community, I'm following the manuals but I can't find a solution for this
<LinuxAdmin> can someone help me?
<LinuxAdmin> is there anybody out there?
<Pici> LinuxAdmin: You'll have to wait longer for an answer here, but these are the folks who are best suited to answer your question :)
<randomaction> LinuxAdmin: first line of your .pbuilderrc is malformed
<LinuxAdmin> it is like the manual (https://wiki.ubuntu.com/PackagingGuide/GettingStarted)
<LinuxAdmin> COMPONENTS=âmain restricted universe multiverseâ
<LinuxAdmin> is there any problem with that line?
<randomaction> use straight quotes: "
<LinuxAdmin> thanks, copy-paste get this things
<LinuxAdmin> it's that
<wrapster1> how do i force install a pkg?
<dabaR> wrapster1: why force (-f)
<randomaction> Happy New UTC+3 Year :)
<geser> still 96 min till 2010 for me
<mrooney> okay, I think this is a question that has been answered many times probably, but do I need to do something special to dch -D lucid on karmic?
<sebner> geser: nahh, don't stick to the pc like me, go outside and enjoy it! ;)
<mrooney> is there a devscripts ppa or backport I need to install?
<geser> sebner: it's cold outside !
<sebner> geser: Ä¥ahaha! no excuses! :P
<davromaniak> hi
<davromaniak> I would like to know if anybody bought a Landscape licence, and the cost, to have a speedy estimation
<davromaniak> (dedicated server edition)
<jbicha1> prob $150 per "node" http://www.canonical.com/projects/landscape/dedicated-server
<davromaniak> jbicha1: what is a "node"
<davromaniak> is it a "master machine", which hosts the landscape server, or a "client machine" which is monitored using landscape
<jbicha1> each client I thought
<davromaniak> argh
<davromaniak> I think I will contact the sales service to have an estimated cost which can be announced and dislayed to my chief
<jbicha1> good idea
<davromaniak> landscape covers the features we need in our company network as all the computers (except for 3 persons) are running under linux, and will be migrated to ubuntu this year
<davromaniak> especially when we have to deploy some security upgrades
<davromaniak> cssh with a generic account on every machine can do the trick, but we need something "official"
<davromaniak> and userfriendly enough to be able to give this task to a newcomer in the sysadmin service, :)
<xnox> davromaniak: unattended upgrades for security?
<xnox> using apt?
<davromaniak> yes
<davromaniak> or any package deployment
<xnox> well set up apt repository
<xnox> and authenticate it for unattended upgrades
<xnox> you can do it for free now and very user friendly
<xnox> apt in ubuntu supports this
<davromaniak> do you have any howto I can rely on it to do a presentation to my chief ?
<xnox> are you running ubuntu now?
<MTecknology> If you guys want to have a little fun for newyears; there's ##ubuntu-newyears
<xnox> /etc/apt/apt.conf.d/50unattended-upgrades
<davromaniak> xnox: me, yes, at home and at work
<xnox> in that file
<xnox> you define "safe" repositories and/or block some packages
<davromaniak> ok
<davromaniak> for example, we can block kernel upgrade which will require a reboot
<xnox> than at each boot they are refreshed and upgrade from those destinations are performed
<xnox> and the root user is sent unix mail
<xnox> I have it forwarded to my gmail
<xnox> So sometimes I get emails that this and that packages have been upgraded
<davromaniak> :)
<xnox> try it out on your machine
<davromaniak> I will try it monday, when I'll be back at the office, :)
<xnox> davromaniak: kernel doesn't requite update
<xnox> if unattended upgrade happens
<xnox> next time machine is booted it is booted with new kernel
<davromaniak> I also have to "reconstruct" the backup system, and it takes a large amount of time
<davromaniak> xnox: the problem is the machines don't have to be shutdown
<xnox> unless you are running custom kernels....
<xnox> davromaniak: good luck ;-)
<davromaniak> (developers and admins are allowed to access it using a VPN connection)
<xnox> davromaniak: landscape imho is good when you have more than 100 computers with different configurations
<xnox> and different physical locations
<davromaniak> :)
<xnox> if you are in one building and it's less than 100 you can easily set it up to be managable
<davromaniak> we have offices is Paris and New York
<xnox> I do suggest having /home mounted on NFS and pulled from server that you back up
<xnox> that way you can nuke any machine and get anyone back to their "computer" with any harddrive ;-)
<davromaniak> not exactly /home, but the home directory is in a NFS file server, which he's backuped every night, :)
<davromaniak> so somebody can crush his system, we "only" need to reinstall it (using PXE of course, ^^)
<geser> sebner: my was similar. "waiting" with my parents for the new year
<geser> and currently watching the fireworks at the street and the tv transmission from berlin
<sebner> heh
<sebner> geser: Are you also thinking about doing some packaging work? ^^
<geser> right now?
<sebner> geser: sure :)
<micahg> is it common to have the minimum debhelper version as a package dep on the -dev package with it's own debhelper script?
<geser> hmm, doing the first european upload in 2010 would be nice :) (if nobody was faster)
<micahg> sebner: ^^
<xnox> micahg: yeap and merge if you can sponsor it
 * xnox got disconnected for a sec
 * micahg can't sponsor it, but I have a few comments that I'm adding to the merge
<micahg> geser: could you answer the question I posted above?
<sebner> geser: go go go
<geser> you have a -dev package shipping a dh_ scrip?
<micahg> geser: xnox wants to add dh_xulrunner to xulrunner-dev
<micahg> so I'm wondering what standard procedure is for depends/suggest/recommends debhelper
<xnox> geser: yes that's the standard way to extend dh
<xnox> eg. quilt package ships dh --with quilt
<xnox> and the dh_patch dh_unpatch
<xnox> and the updated sequence where/when to plug those it
<xnox> dh_xulrunner acts in a similar way
<xnox> it is run after shlibdeps, it scans all binaries, tries to identify whether xulrunner was used and adds correct xulrunner package as dependency
<xnox> such that manual NMU are not required anymore.....
<geser> I'm not familiar with "extending" debhelper, sorry
<xnox> which is new in the latest xulrunner-dev in debian they did it with xulrunner-1.9.1 transition
 * xnox will shut up now
 * xnox noticed that 2010 is not up on irclogs.ubuntu.com
<micahg> it's not 2010 yet
<geser> here is :)
 * micahg will research a little
<jmarsden> Research whether it is 2010 yet? :)
<xnox> micahg: there shouldn't be any d/s/r on debhelper
<micahg> xnox: don't you need it to use dh_xulrunner?
<xnox> it's an optional plugin which debhelper will pick up at runtime (that is buildtime of other packages)
<xnox> eg. I can develop using xulrunner-dev and just use tha
<xnox> that
<xnox> but when I'm building a debian package and if I'm using debhelper (I will depend on it already) I will be able to do dh --with xulrunner
<xnox> if I want to
<xnox> look at quilt package ;-)
<xnox> and python-support / python-central
<micahg> xnox: yes, but I'm wondering if dh_xulrunner uses any fancy features of debhelper
<xnox> they add the python stuff
<xnox> plus this is not something I created
<micahg> xnox: since we backport xulrunner all the way to hardy, we should mention is there is a minimum version of debhelper necessary to use it
<xnox> it's "merge from Debian"
<micahg> *if there is
<xnox> althought we do our xulrunner from scratch
<micahg> xnox: ok, I commented on teh merge
<micahg> xnox: with the changes I commented in the merge, +1 from me, but I'll let asac do the actual merge and push in case I missed something, he should be available tomorrow
<crimsun> I'd do the merge myself, but I'm rather busy with ALSA fixes
<dhillon-v10> hi all, I was working on this merge here: https://bugs.edge.launchpad.net/ubuntu/+source/goldendict/+bug/499335 using bzr and this is the debdiff in pastebin: http://paste.ubuntu.com/349716/ does it look right
<ubottu> Ubuntu bug 499335 in goldendict "Please sync goldendict (0.9.1~git20091117-1) from Debian Testing" [Wishlist,New]
<jmarsden> crimsun: Re FTBFS fixes... I just fixed the FTBFS for freeradius from the list, I have a debdiff (just adds a Build-Depends: quilt).  How do I get this uploaded somewhere useful to the team (I am not a MOTU)... I'm used to attaching debdiffs to bug reports... is there one for every FTBFS, or how should I proceed?
<xnox> jmarsden: if I were you I would create a FTBFS bug in lp, attached debdiff, subscribe ubuntu-motu-sponsors....
<xnox> jmarsden: Happy New Year ;-)
<crimsun> jmarsden: it is nowhere as straightforward, unfortunately
<jmarsden> That's what I was thinking, but I wondered if there was some new approach based on bzr now... and thanks, Happy New Year :)
<crimsun> jmarsden: it really needs a merge from Debian unstable
<crimsun> jmarsden: see the bug that I filed
<jmarsden> crimsun: OK, will do.
<crimsun> i.e., you also need to fix the linking against openssl, which is where the build really dies
<dhillon-v10> crimsun: to merge from debian testing, will something like this work (if I am using bzr) bzr branch lp:debian/sid/package_name
<dhillon-v10> * lp:debian
<crimsun> dhillon-v10: sid? [unstable?]
<dhillon-v10> crimsun: oh sorry, I was trying to merge from testing
<crimsun> dhillon-v10: I'm not the person to ask, unfortunately. I still merge by hand.
<jmarsden> crimsun: OK.  Bug Bug #501360  said it was bitesize ...
<ubottu> Launchpad bug 501360 in freeradius "[lucid] FTBFS due to missing build-dependency on quilt and linking to OpenSSL" [Medium,Triaged] https://launchpad.net/bugs/501360
<crimsun> jmarsden: it is a fairly straightforward merge, just requires methodical application of Ubuntu-specific patches to the existing Debian source package
<crimsun> dhillon-v10: I believe the DistributedDevelopment wiki page may have pointers
<jmarsden> crimsum: Oh, so the Debian package has the OpenSSL stuff fixed already?  I'll take a look.
#ubuntu-motu 2010-01-01
<dhillon-v10> crimsun: yah I found it thanks though
<geser> dhillon-v10: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging describes bzr merges
<dhillon-v10> geser: I remember you telling me that, I just forgot about it :)
<dhillon-v10> geser: can you have a look at this: http://paste.ubuntu.com/349722/ and tell me if it looks right, its for this bug: https://bugs.edge.launchpad.net/ubuntu/+source/goldendict/+bug/499335
<ubottu> Ubuntu bug 499335 in goldendict "Please sync goldendict (0.9.1~git20091117-1) from Debian Testing" [Wishlist,New]
<geser> dhillon-v10: as you merged our changes on the current version from testing the version should be: 0.9.1~git20091117-1ubuntu1 and target lucid (not karmic)
<geser> and as the merges change removes the file, telling "Adding a .desktop file" is wrong
<dhillon-v10> geser: alright thanks a bunch, I'll fix those
<dhillon-v10> geser: one question, how do you guys figure out what's wrong so quickly
<geser> experience :)
<geser> mostly it was looking at the changelog entry (check the version and target) and compare if the mentioned changes match the changes in the debdiff
<dhillon-v10> geser: ahh, that's why, just wait like 2 years and I might catch up to you
<geser> and also looking at the current changes if nothing was missed
<dhillon-v10> *might*
<propagandist> Happy New Year
<crimsun> ugh, nasty hacks.
<cornucopic> Hey all. I have a pure Python module which I want to package for Ubuntu, Where do I start? I am a total n00b in packaging
<bjsnider> cornucopic, there's a youtube video series by daniel holbach that you can find if you search for "ubuntu motu packaging"
<bjsnider> that will tell you what you'll need as far as the build system and commands like dh_make that you'll be using
<crimsun> see http://wiki.debian.org/Teams/PythonModulesTeam
<cornucopic>  hm. cool. thanks!1
<cornucopic> How good or bad is 'stdeb'? http://pypi.python.org/pypi/stdeb/
<cornucopic> ah that page also hints at making packages w/o stdeb and i think that is the way I would go..let
<cornucopic> let's see
<ScottK> cornucopic: You can also ask questions about packaging Python stuff in #debian-python on OFTC.
<cornucopic> ScottK, thanks. OFTC is a new IRC network?
<ScottK> cornucopic: Not new, but different.  irc.oftc.org
<ScottK> It's where all the Debian channels are.
<cornucopic> ScottK, oh..didn't know..
<cornucopic> what should be in my .changes file?
<cornucopic> I am creating a new PPA
<fabrice_sp> cornucopic, your changes file is automatically generated by debuild -sa -S
<cornucopic> looks like py2dsc doesn't do it..
<cornucopic> py2dsc is part of http://pypi.python.org/pypi/stdeb/
<cornucopic> Is there anyway I could 'write' the .changes file myself?
<fabrice_sp> debuild is part of the tools used to package an app
<fabrice_sp> you shouldn't need to write it by yourself
<fabrice_sp> !packagingguide
<ubottu> 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
<fabrice_sp> cornucopic, ^
<ScottK> cornucopic: stdeb isn't a tool that's generally used here, so you're unlikely to get a lot of help with things specific to it.
<crimsun> why is xca calling gcc instead of g++ ?!
<crimsun> no wonder this linker junk is failing
<cornucopic> ScottK, Ok. so no shortcuts in sight :( I need a point to start off, I want to distribute DEBs for a pure Python module
<cornucopic> I am starting off with https://wiki.ubuntu.com/PackagingGuide/Python and adapt it my Python module.
<marcham89> Hello
<cornucopic> just built my first debian package! yay.
<fabrice_sp> congrats :-)
<cornucopic> fabrice_sp, thank you :-)
<cornucopic> what's the diff between using pycentral and python-support?
<cornucopic> the python module I am creating a package for uses PSF, dh_make apparently doesn't support it. Should I choose GPL instead? (since PSF is GPL compatible?)
<fabrice_sp> tbh, ni idea
<cornucopic> in the debian/copyright file, only the package maintainer's name should be mentioned right?
<RAOF> cornucopic: No; that should list all the various copyright holders & the relevent licenses.
<RAOF> cornucopic: I quite like DEP-5 http://tinyurl.com/ktmyfb - it makes for a nice structure to build a correct file.
<cornucopic> RAOF, that looks great. thanks.
<cornucopic> I am getting a "secret key not available" while doing dpkg-buildpackage
<cornucopic> i have got my GPGKEY set properly..
<fabrice_sp> cornucopic, be sure that the name in debian/changelog match the name is your key
<fabrice_sp> s/is/in
<cornucopic> name is same
<etali> cornucopic: In particular, check your key for the comment part - I have my user name in the comment part, but didn't put it in the changelog and had that problem.
<cornucopic> etali, ah yes. i have a different name there
<cornucopic> so what should I do ?
<cornucopic> the comment part is different than the changelog
<etali> cornucopic: I had my key formated as "Lesley Harrison (Etali)" so just started using the whole thing in the changelog and it worked for me.
<cornucopic> let me try that.
<cornucopic> I get this: "can't connect to `/tmp/gpg-SJuSrC/S.gpg-agent': No such file or directory
<cornucopic> gpg: can't connect to `/tmp/gpg-SJuSrC/S.gpg-agent': connect failed
<cornucopic> ", though the package building seems to have passed fine
<cornucopic> yeah, its uploading to my PPA. which means the signature verification passed!
<etali> great :)
<cornucopic> Thanks all :)
<cornucopic> how long does it take for the package to "show up" in my PPA on Launchpad
<cornucopic> this was my changelog:
<cornucopic> pyevolve (0.6-0ubuntu1) koala; urgency=low
<cornucopic>   * Initial release (Closes: #00)
<cornucopic> which was rejected: "Unable to find distroseries: koala"
<cornucopic> what should be there?
<fabrice_sp> karmic
<fabrice_sp> or lucid
<cornucopic> how does this matter?
<cornucopic> what does it mean, rather?
<fabrice_sp> this is the exact name of the serie
<fabrice_sp> karmic is actual one, and lucid, next development version
<micahg> the adjective is the series, the animal is not
<cornucopic> so is it, the series on which I have built this package on?
<fabrice_sp> on which you will build the binaries, yes
<cornucopic> fabrice_sp, thanks.
<fabrice_sp> yw :-)
<slytherin> cornucopic: it is the target release for your package.
<cornucopic> slytherin, oh cool. thanks!
<cornucopic> so i get: "Upload rejected because it contains binary packages."
<cornucopic> I am following this:https://wiki.ubuntu.com/PackagingGuide/Python
<slytherin> cornucopic: what was the command you used for upload?
<cornucopic> dput ppa:amitksaha/pyevolve <source.changes>
<slytherin> cornucopic: what is the name of the .changes file?
<cornucopic> pyevolve_0.6-0ubuntu1_i386.changes
<slytherin> cornucopic: you need to upload source package only. So there must be a corresponding source.changes file in same directory.
<cornucopic> slytherin, right. let me try
<cornucopic> slytherin, i don't see any source.changes file. What am I doing wrong?
<fabrice_sp> Anyone willing to have a look at fceux (http://revu.ubuntuwire.com/p/fceux). It's a NES emulator
<fabrice_sp> cornucopic, do you run debuild -sa -S ?
<fabrice_sp> I'd like to have another review before uploading it
<cornucopic> I am using dpkg-buildpackage
<fabrice_sp> use debuild -sa -S better: it will also check your package with lintian
<cornucopic> ah good..uploading to PPA
<cornucopic> let's see
<cornucopic> accepted.  Thanks a lot folks :)
<slytherin> cornucopic: by default dpkg-buildpackage only builds binary package. You need -S -sa options to build source package.
<cornucopic> slytherin, hmm..will note it for the future.
<cornucopic> do I have to do anything for my package in PPA to build?
<geser> wait
<geser> there was a problem with the buildds that being fixed now and the buildds are now building all queued jobs
<cornucopic> geser, ok!
<ejat> is there any package for sun-java6 update 17 ?
<surfzoid> directhex: Hi, have you got few minutes to give me your point of view ?
<surfzoid> directhex: my i386 build ok but i have the same error on x86_64 machine and 2 other on 32 and 64 bit of debian : https://build.opensuse.org/package/show?package=Mono&project=home%3Asurfzoid%3ADebianUbuntu%3AMono
<cornucopic> I uploaded a new package version to my PPA and I get "File pyevolve_0.6-0ubuntu1.diff.gz already exists in pyevolve, but uploaded version has different contents."
<cornucopic> Should I bother?
<surfzoid> delete it before upload ?
<cornucopic> No..should I?
<bjsnider> cornucopic, how are you naming the packages in the changelog?
<cornucopic> bjsnider, didn't change that either..
<geser> cornucopic: are you trying to upload the same version a second time?
<cornucopic> geser, yes
<bjsnider> can't do that
<cornucopic> i had to fix a build dependency
<cornucopic> so, I delete the earlier on?
<cornucopic> *one?
<geser> that won't work, every version can only be uploaded once (if you get an accepted email)
<bjsnider> cornucopic, you should set up a pbuilder environment and take care of that stuff before you send it in to the ppa
<cornucopic> bjsnider, hmm..this is my first time.. :(. So what can I do now?
<directhex> surfzoid, dunno, looks weird. try it on a PPA, see if it's an opensuse build system issue?
<geser> cornucopic: bump the version and upload then (e.g. to 0.6-0ubuntu2)
<surfzoid> add an +1 in the rev, with an entry log like "fix dep.............
<cornucopic> and I can delete the earlier one?
<surfzoid> directhex: i tryed ppa but must admit it was dark for me
<bjsnider> cornucopic, is this your package, that you created out of your software?
<surfzoid> directhex: could you simply try my gz and dsc file on your ppa ?
<cornucopic> bjsnider, not my software, but one I contribute to. And yeah, I am creating the package
<cornucopic> bjsnider, I will be the maintainer..
<bjsnider> cornucopic, and there isn't a debian package of this yet?
<cornucopic> bjsnider, no
<bjsnider> and there isn't an ubuntu package...
<geser> cornucopic: you can delete your previous upload but this won't help you as LP remembers the version you last uploaded
<cornucopic> bjsnider, no
<cornucopic> geser, hmm.
<bjsnider> so i would take the "ubuntux" string off the name and replace it with ~ppax
<bjsnider> where x is a number
<surfzoid> cornucopic: increase your number version with an entry log like "fix dep........ ?
<cornucopic> my ppa is named as pyevolve. so I can use that I would guess.
<bjsnider> i would name the package pyevolve-0.6-0~ppa1
<bjsnider> cornucopic, but it would be better to use pbuilder to resolve dependency issues and build issues. there's an ubuntu wiki page that explains how to set it up and use it. after it builds in pbuilder send it in to the ppa
<cornucopic> bjsnider, cool. I will take care of if this time on. Thanks a bunch
<cornucopic> bjsnider, This should be the one I need to look at: https://wiki.ubuntu.com/PbuilderHowto ?
<bjsnider> affirmative
<bjsnider> also, make sure you've got the source code minus the debian directory as pyevolve_0.6-0.orig.tar.gz before you run debuild -S -sa
<ari-tczew> hello
<cornucopic> bjsnider, oh? It wasn't mentioned anywhere till now. what does it do/not do?
<ari-tczew> is someone alive? :-D
<ari-tczew> btw. happy new year 2o1o
<bjsnider> cornucopic, it builds the dpkg source based on the orig tarball, so that when you upload the changes file to the ppa, that tarball goes with it. then, if you have to make minor revisions or improvements, you can run debuild -S -sd and it will upload only the changes you've made, not the whole source code.
<cornucopic> hmm..looks like i did the correct thing unknowingly:)
<cornucopic> thanks.
<ari-tczew> needs to open task on hardy by someone from MOTU; bug 481631
<ubottu> Launchpad bug 481631 in mantis "mantis1.0.8-4 (ubuntu 8.04) vulnerable to remote exploit" [High,In progress] https://launchpad.net/bugs/481631
<DktrKranz> ari-tczew: only hardy?
<cornucopic> ok, so I have done 'sudo pbuilder create --debootstrapopts --variant=buildd
<cornucopic> '
<cornucopic> and its completed
<cornucopic> now, how I can a test the build of my package?
<bjsnider> sudo pbuilder build <filename>.dsc
<cornucopic> naice!
<cornucopic> learnt so many things in a day!
<cornucopic> not a bad start to the new year:)
<bjsnider> but that knowledge has pushed out things you already knew...
<bjsnider> such as how to eat and walk
<cornucopic> i walked a bit, didn't eat much:)
<ari-tczew> DktrKranz, yes only hardy
<DktrKranz> ari-tczew: done
<ari-tczew> thanks
<cornucopic> Bye all for now thanks a ton to all of ya!
<RainCT> Can somebody tell me what's the "incoming =" line in dput.cf for PPAs?
<micahg> RainCT: it's what PPA you're uploading to
<micahg> https://help.launchpad.net/Packaging/PPA/Uploading
<porthose> RainCT, ~<your account>/ppa/ubuntu
<RainCT> nah, was looking for "~%(ppa)s/ubuntu", but thanks :)
<RainCT> but it seems like Debian doesn't support this.. :/
<surfzoid> directhex: i m back home, so can yu please try my files in your ppa area ?
<directhex> surfzoid, built fine on my amd64 sid ppa
<directhex> um, pbuilder
<surfzoid> so we can conclude, OBS have a very large problem ?
<surfzoid> directhex: you have an idea, why debian don't find the linked file ?
<directhex> surfzoid, well, it works for me in a debian test build, so...
<surfzoid> localy ?
<directhex> yeah
<surfzoid> so i guess the conf file of OBS miss an essencial pkg wich contain this file
<surfzoid> directhex: is there a possible switch after -S to add the missing buildrequiere pkg in the dsc file ?
<directhex> surfzoid, there is nothing missing that i can see. it works in a fresh sid pbuilder.
<surfzoid> directhex: ho yeah, i don't see that, the problem is not anymore the missing file but a libtool and permission problem
<directhex> surfzoid, possibly OBS has an out-of-date sid repo, there were libtool problems recently
<diwic> crimsun: is it on purpose that current Lucid pulseaudio does not release unused ALSA devices the way Karmic does?
<crimsun> diwic: eh? Sure it does.
<diwic> crimsun: I'm in Karmic now, but when I tested Lucid earlier today, I saw it (with fuser -v) having control over my HDMI output, AFAIK without using it.
<crimsun> control as in /dev/snd/controlC* ?
<diwic> as in /dev/snd/pcm*
<crimsun> it will only hold on to it if some stream is active through it
<crimsun> was g-v-c or pavucontrol doing something with the device?
<crimsun> hmm
<diwic> crimsun: I'll do some additional research and file a bug if necessary the next time I'm in Lucid. I just needed to know if it wasn't on purpose
<crimsun> see changeset ef18beded8ddbaafdf4914bab209f77e60ae3a18 in sound-2.6, too
<crimsun> 'ALSA: hda - HDMI sticky stream tag support'
<diwic> with the talk of mic spying I was afraid it was a feature
<crimsun> don't ascribe to maliciousness what is simple incompetence
<diwic> crimsun: thanks for being around :-)
<surfzoid> directhex: a guy of OBS team answer me "it's not OBS's libtool. It's the libtool that mono ships that gets used." i m loose !
<directhex> well, relibtoolize.
<surfzoid> how ?
<surfzoid> directhex: i don't how thats work to relibtoolize
<directhex> autoreconf -f -i -s ?
<directhex> dunno. it's DEFINITELY building in a sid pbuilder.
<surfzoid> directhex: that s an infinite loop, the guy say same thing, add autoreconf -f -i, i saw yu already do that and i added it again after the dh_clean section
<directhex> surfzoid, well, there's nothing more for me to say. it builds in a debian pbuilder. there's something "bad" about the "doltlibtool" command being executed
<surfzoid> directhex: jut for info about the wall am i now, the answer of the OBS guy : "it's not OBS's libtool. It's the libtool that mono ships that gets used."
<surfzoid> :-)
<directhex> surfzoid, so? how many bloody times do i need to say it builds on debian? :/
<surfzoid> from #opensuse-buildservice
<surfzoid> directhex: hey, i say "for info", thousand thanks for your help
<surfzoid> i understand and i am agree with you
<ScottK> surfzoid: OBS is more than a little off topic here in any case.
<surfzoid> but that s a common situation where both....
<surfzoid> yes
<directhex> ScottK, however, unlike ppa's, it supports building for non-ubuntu distros. which is potentially useful
<ScottK> directhex: True, but still OT.
<crimsun> the progress of this build, thanks to colored CMake output, is really depressing
<RAOF> Why are discs so SLOWWWWWâ½  Or: why must pbuilder suck.
<crimsun> I need a build farm.
<jmarsden> RAOF: Creating your pbuilder in a ramdisk helps with the speed issue :)
<RAOF> Yeah; I should be doing this on my laptop with just such a setup.
<crimsun> see, using tmpfs for it would only help a negligible amount
<crimsun> setup and teardown is dwarfed by the compilation. e.g., VTK has wrappers for everything
<wgrant> RAOF: Why not use sbuild with LVM snapshots?
<RAOF> wgrant: I probably should set that up on this lappy.  On the other one, it's a fight between building-on-ramdisk for pbuilder and faster setup/teardown for sbuild.
#ubuntu-motu 2010-01-02
<crimsun> oh jeez, 46 different VIA codecs
<crimsun> well, that'll keep me occupied while I wait for VTK to build
<crimsun> 30% through the build!
<geser> in 90min? that's about 3h for the remaining 70% :(
<crimsun> geser: yep. And, there's clearly something wrong with this CMake progress
<sebner> geser: crimsun hhiuhu
<crimsun> it has been at 100% for five minutes on another box building Java bindings :-)
<geser> Hi sebner , still awake?
<sebner> geser: yeah I'm at a friends house and feeling like doing packaging work ^^
<geser> sebner: training a future MOTU? :)
<sebner> geser: nah, haXX0ring packages for Debian xD
<sebner> geser: working through maaaaany files for creating an acceptable copyright :\
<crimsun> man, I've cycled twice through the PID space just for docs generation
<crimsun> I think I'm going to escape back to the simpler world of kernel hacking
<bjsnider> there's no formatting requirement in a debian/rules file that would require 7 consecutive tabs on a line is there?
<RAOF> bjsnider: No.
<bjsnider> i swear i found it like this
<machina> I was working on packaging a new upstream version of xsensors for ubuntu, but chose instead to try and get the new upstream in debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446530
<ubottu> Debian bug 446530 in xsensors "xsensors: New upstream version (0.60) available" [Wishlist,Open]
<machina> unfortunately the debian maintainer is not very responsive
<machina> Should I wait a couple weeks, or should I go and try and get a new version in ubuntu?
<bjsnider> what do you need him for?
<machina> I was told on IRC that having a newer version than debian would cause sync problems..
<bjsnider> oh, i see.  you want to push the latst upstream code into debian. i thought you meant you wanted to pull the latest in debian into ubuntu
<machina> yeah, I also made the "debian directory" needed for the new version, but met a few stumbling blocks before I could finalize the debian/ubuntu package..
<bjsnider> like dependencies and such
<machina> I used most of the dependencies from previous versions, but I did notice another bug report about that.. my problem was mostly about the debian/copyright file (it's at the bottom of the bug report)
<ScottK> Particularly for Lucid/Squeeze where we are synchronizing release freeze it'd be good to keep the same version in Ubuntu and Debian.
<machina> Is that the cadence thing shuttleworth was talking about earlier? I couldn't find any updates on it.
<machina> So would that mean it's best just to patch the older version of xsensors?
<machina> I guess I'll just push the new upstream to ubuntu
<ScottK> machina: It may be better to do that, but your efforts to get Debian updated are good too.
<machina> cool, thanks for the advice
<w3asal> what exactly happens to the sync when there's a newer version in ubuntu than debian?
<ScottK> w3asal: Nothing until Debian gets a newer version.
<w3asal> so it's just good policy to try to push the new version into debian, but not necessarily bad for ubuntu if it doesn't happen?
<crimsun> sorry, unimplemented: inlining failed in call to '(!#$*': redefined extern inline functions are not considered for inlining
<crimsun> sigh, there goes that pile. Thanks, gcc-4.4 (and gcc-snapshot).
<foxbuntu> bjsnider, ping
<foxbuntu> bjsnider, thought I would let you know there is a bug in the nvidia packages in the in vdpau testing ppa
<foxbuntu> bjsnider, they are pointing to a depends on libvdpau, but the package name is really libvdpau1
<crimsun> foxbuntu: that isn't a bug.
<crimsun> $ apt-cache show libvdpau1|grep ^Pro
<crimsun> Provides: libvdpau
<foxbuntu> crimsun, The following packages have unmet dependencies:
<foxbuntu>   nvidia-glx-190: Depends: libvdpau
<foxbuntu> E: Broken packages
<crimsun> foxbuntu: and?
<crimsun> as long as you have libvdpau1 installed, your package manager shouldn't whine
<foxbuntu> crimsun, yes, but if you dont, it wont install the drivers
<foxbuntu> crimsun, so it is a bug
<foxbuntu> crimsun, the proper depends is libvdpau1 or better would be not at all, as libvdpau1 is not a required piece to the nvidia drivers
<crimsun> foxbuntu: I agree that it should be a Recommends, not a Depends
<crimsun> foxbuntu: however, I disagree that it is a bug
<foxbuntu> crimsun, how could it not be?
<foxbuntu> crimsun, I am not motu, but I am trying to understand
<crimsun> I just tried, and apt-get and aptitude both worked correctly
<foxbuntu> crimsun, from that ppa?
<crimsun> yes
<foxbuntu> crimsun, without libvdpau1 already installed?
<crimsun> now, if you manually used dpkg -i but did *not* include libvdpau1...deb, that still isn't a bug. That's your own fault.
<crimsun> foxbuntu: yes, from within a schroot.
<foxbuntu> crimsun, I was able to do the same once, but after attempting to upgrade to another build of libvdpau and that package it failed on the upgrade
<crimsun> well, certainly it could be made better with libvdpau1 | libvdpau
<foxbuntu> crimsun, agreed on that point
<happyaron> sorry if it's not suitable to ask here, does CC by-sa 2.5 compatible with LGPLv3?
<superm1> foxbuntu, crimsun no libvdpau shouldnt be a depends or recommends
<superm1> that's the bug
<superm1> it does nothing for the nvidia driver itself
<superm1> it's the applications that should be depending on libvdpau1 (by build-depending on libvdpau-dev and shlibs resolving libvdpau1)
<yuanyelele> Hi! Why don't we have a free version of mplayer, with patented codecs in a separate package?
<martoss> hey folks, i have two packages to review. I uploaded them to revu but they don't show up in revu.
<surfzoid> directhex: Hi, in the mono rule file you use autoreconf -i -f -s, the symlinks switch is really important, or it will be same to use libtool file of mono source rather link them to the system one ?
<cornucopic> yesterday, I used 'debuild -sa -S' to build my signed source package. What is the 'a' switch for?
<geser> -sa    Forces the inclusion of the original source.
<geser> i.e. the .orig.tar.gz
<cornucopic> and -S is for signing?
<cornucopic> or -S for source package and signing is the default behavior?
<geser> -S     Specifies  that  only  the  source should be uploaded
<geser> signing is the default behaviour
<cornucopic> thanks geser!
<geser> -us    Do not sign the source package.
<geser> -uc    Do not sign the .changes file.
<bdrung_> porthose: do you have some sponsor examples?
<porthose> bdrung_, I just sent you a mail listing all the bugs you have sponsored for me, there is also a list of bugs that I have worked on at https://wiki.ubuntu.com/CharlieSmotherman :)
<bjsnider> foxbuntu, i removed libvdpau from the depends list
<bdrung_> porthose: thanks.
<bdrung_> porthose: you are doing so many syncs, why not syncing ampache? 3.0 (quilt) is now supported in ubuntu.
<vadi21> I'm trying to create a package for a lua module, but having a hard time understanding lua5.1-policy-dev/Makefile.Debian.conf. Anyone know a good page that explains what values are supposed to be where?
<crimsun> some of these upstream "fixes" for gcc-4.4's more stringent CXX compliance are downright nasty
<crimsun> like, casting away a const char *? what the blazes?
<jreinhardt> Hi everybody. A year ago I packaged a tex package (#310015) and tried to get it through revu, but then lost the patience. Today a new upstream version was released and I updated my package. Is someone interested in revuing it? http://revu.ubuntuwire.com/p/pgfplots
<TomJaeger> Hi. I'm trying to convert a package to debhelper 7, and I can't figure out how I'm supposed to call dh_installman, dh_installchangelogs and dh_installdocs and I can't really find any documentation besides http://kitenet.net/~joey/blog/entry/cdbs_killer___40__design_phase__41__/.
<TomJaeger> What is the correct way to do this?
<ScottK> TomJaeger: Why are you converting it?
<TomJaeger> https://bugs.launchpad.net/bugs/502366
<ubottu> Ubuntu bug 502366 in easystroke "Please upgrade easystroke to 0.5.2" [Undecided,Incomplete]
<ScottK> TomJaeger: OK, but why redo the packaging?
<TomJaeger> Benjamin suggested to switch to debhelper v7.
<ScottK> OK, my view is generally to not make unneeded changes, but if there's a specific problem that switching to dh 7 solves, then go for it.
<TomJaeger> I don't really care either way, so I'm fine with keeping things the way they are.
<foxbuntu> bjsnider, thanks.
<dhillon-v10> hi all, I am packaging this ppa for this software that has a makefile, all the user needs to do is to run the makefile and everything is done, I got everything else but including autotools.mk class gives me an error that a configure file doesn't exist and this is the way its supposed to be
<ScottK> PPA packaging isn't on topic for #ubuntu-motu
<jmarsden> dhillon-v10: If there is a working makefile already, why use autotools.mk ?   Seems odd, if the upstream software does not use autotools, don't package with autotools.mk :)
<dhillon-v10> ScottK, which channel should I got to ?
<ScottK> dhillon-v10: I'd say #launchpad, but they'd say here.  There probably isn't one.
<dhillon-v10> jmarsden, so how do I get the debian/rules file to call the makefile
<dhillon-v10> ScottK, :)
<jmarsden> dhillon-v10: Just run make :)
<dhillon-v10> jmarsden, so wait just type in make in debian/rules ? that's it
<jmarsden> Yes.
<dhillon-v10> jmarsden, thanks a bunch :D
<jmarsden> Sounds like you need to go through the Package Guide and understand packaging some more...
<dhillon-v10> jmarsden, you are awesome it works  I read the package guide before, but I will read it again :)
<jmarsden> You're welcome.
<dhillon-v10> jmarsden, every time I encounter something new I document it, so that way I don't forget, this was something I had never seen before so...
#ubuntu-motu 2010-01-03
<bdrung_> james_w: you wanted to sponsor bug #330573 three month ago. do you forgot this bug? can i unsubscribe ubuntu-universe-sponsors?
<ubottu> Launchpad bug 330573 in madfuload "madfuload doesn't work" [Undecided,Confirmed] https://launchpad.net/bugs/330573
<Quintasan> bug #500218    anyone can reproduce this?
<ubottu> Launchpad bug 500218 in qemu-kvm "*** glibc detected *** qemu: free(): invalid pointer: 0x0000000000e44b10 ***" [Undecided,Confirmed] https://launchpad.net/bugs/500218
<dhillon-v10> Quintasan, I did see a conversation in the upstream kernel about glibc creating invalid pointers at the first available slot in the memory (0x0000000000e44b10) which is basically 0001 and its deleting the memory which causes it to crash, possible to run it from gdb
<Quintasan> dhillon-v10: well, thanks, I think my is exacly the same because the only thing that differs in mine case is the memory address
<dhillon-v10> Quintasan, can you do me a favour: give the same command but this time through gdb, I can read the stacktrace and see what happened :D
<Quintasan> hmm trough gdb?
<Quintasan> dhillon-v10: how do I do that?
<dhillon-v10> Quintasan, yup, I know running qemu would take a lot but just try it out
<dhillon-v10> Quintasan, just a sec. I'll give you the command :)
<Quintasan> dhillon-v10: just wondering, is there a package with debugging symbols for kvm?
<dhillon-v10> Quintasan, most likely there should be one, let me check but it might not work here, because we are dealing with memory addresses and memory being deleted before it can be called
<Quintasan> well okay, I was playing with dbg and I tried to run kvm from it but it said "no debugging symbols found"
<dhillon-v10> Quintasan, sorry no debugging symbols for kvm in synaptic
<Quintasan> dhillon-v10: okay, so how I'm supposed to provide you useful stacktrace? :)
<dhillon-v10> Quintasan, just a sec. I spilled coffee so I am getting yelled at :)
 * Quintasan pats dhillon-v10
<ScottK> crimsun: Your last vtk upload was a good start, but looks like it needs more.  You didn't by chance already start looking into it?
<crimsun> ScottK: bah, already? What're the rdeps dying on now?
<crimsun> (and why wasn't it fixed in Debian already?...)
<ScottK> Well I think we'd be better off if we'd stayed with Squeeze
<ScottK> crimsun: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533193 breaks gdcm
<ubottu> Debian bug 533193 in libvtk-java "libvtk-java: Wrong value for VTK_JAVA_JAR in VTKConfig.cmake" [Normal,Open]
<ScottK> crimsun: Also libopenmpi-dev and libgl2ps-dev needed for gdcm, slicer, and fslview
<ScottK> OK, that's necessary but not sufficient for slicer, /home/slicer-3.4.0~svn10438/Modules/EMSegment/Algorithm/vtkFileOps.cxx:197: error: invalid conversion from 'const char*' to 'char*'
<crimsun> standard crap C++ code
<crimsun> ok, I'll look at it in a few minutes. Have to make supper.
<ScottK> Thanks.
<ScottK> gdcm made it as far as Linking CXX shared library ../../bin/libvtkgdcmJava.so, /usr/bin/ld: cannot find -lvtkCommonJava with libvtk-java_5.2.1-11 from Debian.
<crimsun> good thing I still have it in ccache from yesterday
<ScottK> So I suspect just reverting the 11 -> 12 Java changes will fix that.
<randomaction> ScottK, fabrice_sp: thanks :)
<alkisg> I'm trying to have the following dependencies, but it's not really working with apt-get, can anyone see why?
<alkisg> Package "A" conflicts with "C". Package "B" depends on "C | D".
<alkisg> I want this: when users install "B", they also get "C", unless they have "A" installed, in which case they get "D" instead.
<alkisg> !info libsdl1.2debian-alsa
<ubottu> libsdl1.2debian-alsa (source: libsdl1.2): Simple DirectMedia Layer (with X11 and ALSA options). In component main, is extra. Version 1.2.13-4ubuntu4 (karmic), package size 212 kB, installed size 524 kB
<alkisg> !info libsdl1.2debian-pulseaudio
<ubottu> libsdl1.2debian-pulseaudio (source: libsdl1.2): Simple DirectMedia Layer (with X11 and PulseAudio options). In component universe, is extra. Version 1.2.13-4ubuntu4 (karmic), package size 211 kB, installed size 524 kB
<alkisg> Since Ubuntu uses pulse by default, shouldn't that be the opposite? libsdl1.2debian-pulseaudio in main and libsdl1.2debian-alsa in universe?
<verb3k> Please someone upgrade libfribidi to the 0.19, it's very very old in the repositories. See here https://bugs.launchpad.net/ubuntu/+source/fribidi/+bug/191241
<ubottu> Ubuntu bug 191241 in fribidi "New upstream version 0.19.1" [Wishlist,Confirmed]
<verb3k> the version in the repo is 0.10 which is very old
<verb3k> practically broken with mplayer and vlc
<ari-tczew> hello, I have trouble with pbuilder
<ari-tczew> I got in pbuilder build *.dsc: E: pbuilder-satisfydepends failed.
<ari-tczew> but if I'll send package on ppa, then build fine; what's wrong?
<geser> have you universe/multiverse enabled in your pbuilder?
<ari-tczew> I don't know ...
<geser> login into your pbuilder and check which components are enabled in /etc/apt/sources.list
<ari-tczew> huh, only main
<ari-tczew> deb http://pl.archive.ubuntu.com/ubuntu/ karmic main
<ari-tczew> how can I change this?
<ari-tczew> -bash: nano: command not found
<geser> !pbuilder
<ubottu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<geser> there is also a section about enabling universe
<ari-tczew> geser, this? https://wiki.ubuntu.com/PbuilderHowto#Universe%20support
<geser> yes
<ari-tczew> updating in progress...
<ari-tczew> it's working! thanks geer
<ari-tczew> geser *
<verb3k> Please someone upgrade libfribidi to the 0.19, it's very very old in the repositories. See here https://bugs.launchpad.net/ubuntu/+source/fribidi/+bug/191241
<ubottu> Ubuntu bug 191241 in fribidi "New upstream version 0.19.1" [Wishlist,Confirmed]
<verb3k> the version in the repo is 0.10 which is very old
<verb3k> practically broken with mplayer and vlc
<persia> verb3k: Firstly, asking on IRC doesn't improve over a bug report.  Secondly, fribidi is in main, so -devel is a more correct forum than this.
<ScottK> randomaction: If I sponsored anything else of yours, let me know.
<randomaction> ScottK: bug 430182 and bug 456231
<ubottu> Launchpad bug 430182 in crawl "crawl 2:0.4.5-0ubuntu1 FTBFS (missing header)" [Undecided,Fix released] https://launchpad.net/bugs/430182
<ubottu> Launchpad bug 456231 in givaro "FTBFS: Sync givaro 3.2.13-1 (universe) from Debian unstable (main)" [Low,Fix released] https://launchpad.net/bugs/456231
<ScottK> randomaction: Thanks.
<bdrung> ari-tczew: you destroyed my plan to clean the universe sponsor queue. ;) do you plan to become MOTU?
<ScottK> bdrung: Did you get my ping about the new lintian version?
<bdrung> ScottK: yes
<ScottK> OK.  Good.
 * bdrung forgot to post the debdiff
<bdrung> ScottK: bug report updated.
<ScottK> You have my opinion on it.  We'll see what others think.
<bdrung> ScottK: yes. let's gather more opinions. i will bow to the majority.
<ari-tczew> bdrung: yes, I plan to join MOTU
<ari-tczew> bdrung, I'll please you about opinion about my work - this is for MOTUApplication
<bdrung> ari-tczew: where is your Contributor application or do you want to become directly MOTU?
<ScottK> randomaction: Would you please link me to your application.  I've lost it.
<ari-tczew> bdrung: https://wiki.ubuntu.com/ArturRona/MOTUApplication I'll update it later because I don't start in MOTU Meeting this week
<ari-tczew> btw. Friday, 8th January 2010, 07:00 UTC this is 07:00 AM or PM?
<bdrung> ari-tczew: am
<bdrung> ari-tczew: the UTC time is in 24 h
<ari-tczew> OK, so I can't join IRC this time, therefore I don't starting this week
<ari-tczew> poor date
<bdrung> ari-tczew: it's for people with strange time zones ;)
<randomaction> ScottK: sure, https://wiki.ubuntu.com/IlyaBarygin/MOTUApplication
<ari-tczew> when will next MOTU Council Meeting?
<randomaction> I believe 28th Jan at 17 UTC
<bdrung> ari-tczew: https://wiki.ubuntu.com/MOTU/Council/Meeting
<ari-tczew> OK
<ScottK> randomaction: Nevermind.  I found it.
<ari-tczew> randomaction and porthose: good luck 8th
<bdrung> porthose: is my comment long enough?
<ari-tczew> I hope that we will not fighting in MOTU, just cooperate!
<bdrung> ari-tczew: why fighting?
<randomaction> who
<randomaction> who's fighting? :)
<randomaction> thanks ari-tczew
<ScottK> Mostly things are pretty good here.  Every now and then stuff happens.
<ari-tczew> I don't say that someone fighting, but... just wanna good start in MOTU :-)
<ari-tczew> bdrung, if you are not adding comments on wiki.ubuntu, maybe you'll add comment on my MOTUApp?
<bdrung> ari-tczew: i had no problems when i became motu (and before).
<bdrung> fabrice_sp: do you take the syncs?
<bdrung> ari-tczew: which comments on wiki.ubuntu?
<ScottK> randomaction: Updated.
<fabrice_sp> bdrung, which one?
<bdrung> fabrice_sp: there is one left
<Quintasan> \o
<bdrung> fabrice_sp: i am taking bug 502579 now.
<ubottu> Launchpad bug 502579 in xsmbrowser "Merge xsmbrowser 3.4.0-16.1 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/502579
<fabrice_sp> bdrung, ok :-)
<ari-tczew> bdrug, please left comment on my MOTUApp https://wiki.ubuntu.com/ArturRona/MOTUApplication as sponsor
<ari-tczew> hello quintasan :)
<bdrung> ari-tczew: can you fill out your application first?
<Quintasan> ari-tczew: well, hello there :D
<Quintasan> ari-tczew: hmm, so I see what you did there, good luck then
<bdrung> ari-tczew: why is in the diff for xsmbrowser version 3.4.0-16.1 in debian/changelog?
<bdrung> ari-tczew: you should remove "Encoding=UTF-8" from the desktop file
<ari-tczew> I don't understand why about version?
<ari-tczew> Quintasan, thanks
<bdrung> fabrice_sp: i am taking 502589, too.
<fabrice_sp> bdrung, ok. Taking 502504
<bdrung> ari-tczew: the diff between Debian and Ubuntu should only contain changelog entries from Ubuntu and none from Debian.
<ari-tczew> this is created by grab-merge
<fabrice_sp> ari-tczew, you should review the merge before submitting it, and not rely on tools
<ari-tczew> I did review
<ari-tczew> and I first one hear about none changes from Debian in debian/changelog
<bdrung> ari-tczew: and it fails to apply.
<fabrice_sp> in a debdiff between debian and Ubuntu, you shouldn't see any Debian entry
<fabrice_sp> only ubuntu one (even if I haven't looked at this debdiff in particular)
<bdrung> ari-tczew: it's not the first time grab-merge failed.
<ari-tczew> bdrung, second debdiff attached, refresh page
 * fabrice_sp always do the merge by hand :-D
 * bdrung does a merge by hand or with git / bzr
<ari-tczew> I'll do merges with bzr, but not this time
<bdrung> ari-tczew: debian/changelog is not correct. now there are changelog entries missing
<ari-tczew> omg...
<bdrung> ari-tczew: i recommend to read the diff file before posting.
<ari-tczew> bdrung, could you did correct diff for debian/changelog and paste anywhere? I'll update debian/changelog with your example
<bdrung> after a while you can read diffs faster than books ;)
<bdrung> ari-tczew: http://launchpadlibrarian.net/37381368/lineak-kdeplugins_0.9-6ubuntu1.debdiff and http://launchpadlibrarian.net/37382254/lintian_2.3.1ubuntu1.diff are good examples
<ari-tczew> because I got first trouble with debian/changelog, previously any sponsor won't reject my debdiffs because debian/changelog is wrong
<ari-tczew> ehh
<ari-tczew>  lintian (2.3.1) unstable; urgency=low
<ari-tczew> what is it? any changes from Debian?
<bdrung> ari-tczew: no, that are the sourrounding three lines for diff (look at the lines starting with + or -)
<ScottK> Merge-o-matic is dead, so you shouldn't be using grab-merge anymore in any case.
<fabrice_sp> ScottK, some time to review http://revu.ubuntuwire.com/p/fceux ?
<ari-tczew> ah, now I see what's wrong with xsmbrowser debdiff
<fabrice_sp> or any motu /motu applicants :-)
<ari-tczew> I propose to add section 'SRU SPONSORS' or something at http://people.canonical.com/~dholbach/sponsoring/index.html
<bdrung> yes, sru is missing there. contact dholbach for that.
<ari-tczew> generally I guess that SRU and Security updates are neglected
<ari-tczew> next main
<ari-tczew> universe has a lot of active sponsors
<fabrice_sp> :-D
<bdrung> ari-tczew: i uploaded lineak-kdeplugins
<ari-tczew> thanks
 * fabrice_sp is working in a VM, so builds is slower :-)
<bdrung> ari-tczew: SRU may be neglected, but Security?
<bdrung> fabrice_sp: didn't you use pbuilder?
<bdrung> fabrice_sp: i have a small check-sync script and a local mirror from lucid.
<bdrung> ari-tczew: do you have an updated debdiff for xsmbrowser?
<fabrice_sp> bdrung, I'm not on my normal computer (Linux based): I'm working on my normal work computer, based on Windows. I usually use sbuild (pbuilder is slower! :-) )
<bdrung> fabrice_sp: what's Windows? ;)
<fabrice_sp> lol
<fabrice_sp> The app we are developing is not working in Wine (and to be honest, nobody is willing to do it), so no luck for the moment to switch to Linux workstations
<ari-tczew> bdrung, wait for debdiff please
<bdrung> ari-tczew: i will
<fabrice_sp> bdrung, willing to have a look at fceux, now that there isn't anything to sponsor? :-D
<bdrung> fabrice_sp: i downloaded windows 7 last year (in October), but i had no time to install it
<fabrice_sp> by policy, we are still using Windows XP at work :-/
<bdrung> fabrice_sp: pbuilder finished building fceux
<fabrice_sp> cool :-D
 * Yagisan feels sorry for those poor souls tortured with a toy OS at work
<bdrung> fabrice_sp: you have to repack it: fceux source: source-contains-prebuilt-binary fceu/src/~attic/sexyal/convertgen
<fabrice_sp> bdrung, I already deleted a lot of binaries. certainly forgot this one
<bdrung> fabrice_sp: you should install the upstream changelogs
<bdrung> fabrice_sp: third fix old-fsf-address-in-copyright-file
<fabrice_sp> changelog: will do, right. About address: I'll check if I uploaded the right version, because lintian wasn't complaining anymore
<porthose> bdrung, that's fine, ty I appreciate it :)
 * porthose has already switched to using bzr to do his work ;)
<bdrung> porthose: you are welcome. btw, i am the man of the few words. ;)
<ari-tczew> bdrung, now I find what's the problem with debian/changelog: I did debdiff command on a wrong file :P now it's correct, fixed debdiff uploaded
<porthose> I hear yea, me to :)
<bdrung> ari-tczew: :)
<bdrung> fabrice_sp: there is desktop-entry-contains-encoding-key /usr/share/applications/gfceux.desktop:2 Encoding too
<bdrung> fabrice_sp: why do you want to upload fceux to Ubuntu and not to Debian?
<fabrice_sp> TBH, I find it a lot more difficult to upload to Debian
<fabrice_sp> and I was hosting it in my ppa since almost one year
<bdrung> fabrice_sp: it's not that hard. you only have to make it lintian clean - and then find a sponsor. finding a sponsor can be sometimes be tricky
 * Yagisan wonders why "I use Ubuntu" isn't simply a good enough answer
<ari-tczew> ~ubuntu-archive subscribed bugs over than 200!
<fabrice_sp> yeah: finding a sponsor is the part where I got stuck several time
<bdrung> ari-tczew: now your patch applies. ;)
<ari-tczew> ;-D
<bdrung> fabrice_sp: you can go to #debian-mentors and ask there (and upload it to mentors.d.n)
<ari-tczew> how many opinions I need to get on my MOTUAppl?
<fabrice_sp> bdrung, I know. I will try again, when fceux got a 'cleaner' opinion :-)
<randomaction> ari-tczew: https://wiki.ubuntu.com/MOTU#Joining%20MOTU
<bdrung> ari-tczew: there is not a minimum defined. having three would be good.
<bdrung> ari-tczew: quote: "A typical application will have three to five endorsements. "
<geser> ari-tczew: the more endorsements you get the better as it shows a good cooperation with other devs
<ari-tczew> ok so I'll ask for opinion bdrung, fabrice_sp and dholbach
<ari-tczew> but later, in the half January
<bdrung> ari-tczew: xsmbrowser.desktop has some encoding problems. have a look at GenericName[fr] and Comment[fr]
<ari-tczew> hmmm I think that these lines [5,7] can be deleted
<bdrung> ari-tczew: sorry, but i am in pedantic mode today
<bdrung> ari-tczew: it's the translation
<micahg> ari-tczew: PM?
<ari-tczew> so what's next?
<ari-tczew> micahg, let's go
<bdrung> ari-tczew: find someone, who can speak french and let him correct it [remove it otherwise]
<fabrice_sp> french, you said?
 * fabrice_sp is your man
<fabrice_sp> what do you want to translate?
<ari-tczew> fabrice_sp, look at debdiff in bug 502579
<ubottu> Launchpad bug 502579 in xsmbrowser "Merge xsmbrowser 3.4.0-16.1 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/502579
<fabrice_sp> ari-tczew, should be "Navigateur de rÃ©seau samba"
<fabrice_sp> the Ã© has been converted, it seems
<bdrung> ari-tczew: this should be fixed, too: http://paste2.org/p/591829
<bdrung> fabrice_sp: there is one more lintian warning: W: gfceux: manpage-has-bad-whatis-entry usr/share/man/man1/gfceux.1.gz
<fabrice_sp> strange: this one has been fixed by a patch... Maybe I lost something when I converted it to 3.0 (quilt) format
<bdrung> fabrice_sp: it's not 3.0 (quilt)!
<fabrice_sp> arghhh
<fabrice_sp> so I didn't uploaded the right package
<bdrung> seems so
 * fabrice_sp hides
<bdrung> :D
<bdrung> ari-tczew: let me know, when you have a updated debdiff for xsmbrowser
<fabrice_sp> bdrung, thanks for your comments anyway: I missed some things ;-)
<bdrung> fabrice_sp: np
 * ari-tczew pausing work for launch
<fabrice_sp> lunch, you mean? :-D
<ari-tczew> fish is today :D
<bdrung> ari-tczew: launch :D are you a rocket?
<fabrice_sp> lol
<ari-tczew> yee lunch buehehe
<ari-tczew> sorry man, but english isn't my 1st language
<bdrung> ari-tczew: english is my third language (1st Swabian, 2nd German) ;)
<ari-tczew> regards
<ari-tczew> my: 1st polish, 2nd english, 3rd german, 4th russian
<bdrung> 4th latin ;)
<ari-tczew> I prefer to speak one universal language like English, besides my country language
<bdrung> ari-tczew: i prefer to make German the universal language ;)
<fabrice_sp> not that bad! :-) Here French, Spanish, English and some German :-)
<fabrice_sp> no luck bdrung !
<fabrice_sp> Spanish is better ;-)
<ari-tczew> German is nice language, easier to learn than russian
<bdrung> fabrice_sp: don't destroy my dreams ;)
<fabrice_sp> lol
<bdrung> ari-tczew: instead of "Icon=/usr/share/pixmaps/gnome-term-linux2.png" you should use "Icon=gnome-term-linux2"
<bdrung> fabrice_sp: do you have time to do more sponsoring?
<ari-tczew> bdrung, "Type=Application" it's right?
<fabrice_sp> bdrung, yes: I'm fixing fceux right now (the good source is on my other computer, 1200 km away from where I am now :-) )
<bdrung> ari-tczew: check http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html
<bdrung> Type=Application is valid.
<bdrung> ari-tczew: it's categories. refer to http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html
<ari-tczew> lol, OK ;-D I'm making new debdiff
<ari-tczew> update-maintainer is nice script
<ari-tczew> dch -i too
<ari-tczew> bdrung, bug 502579 go ahead
<ubottu> Launchpad bug 502579 in xsmbrowser "Merge xsmbrowser 3.4.0-16.1 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/502579
<bdrung> ari-tczew: lintian still complains about menu-item-creates-new-section. please list your changes in debian/changelog
<jreinhardt> Is REVU still the way to go to get a package into universe? It looks so quiet over there.
<bdrung> jreinhardt: REVU or through Debian
<fabrice_sp> jreinhardt, yes
<fabrice_sp> (too late! :-) )
<ari-tczew> bdrung, the only change which I done is add .desktop file; what I need to add in debian/changelog?
<ari-tczew> bdrung, can't you upload like is right now?
<bdrung> ari-tczew: the modification done in the .desktop file.
<jreinhardt> I uploaded a new upstream version of a package I made to REVU http://revu.ubuntuwire.com/p/pgfplots. I already went through a review cycle, but then I could persuade nobody to review it again and lost the patience. Perhaps someone is interested in revu-ing it :)
<bdrung> jreinhardt: for new upstream releases you can open a bug report and link it to revu, and subscribe the sponsor team
<bdrung> ari-tczew: please fix the category in the desktop file. http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry
<jreinhardt> I already have a bug https://bugs.launchpad.net/ubuntu/+bug/310015, how do I subscribe someone?
<ubottu> Ubuntu bug 310015 in ubuntu "[needs-packaging] pgfplots" [Wishlist,Confirmed]
<bdrung> jreinhardt: https://wiki.ubuntu.com/SponsorshipProcess
<siretart> ... so many spurious hilights here...
<bdrung> siretart: ?
<siretart> my first name is 'reinhard'
<siretart> jreinhardt: isn't pgfplots included in texlive 2009?
<bdrung> ah
<siretart> (I honestly have no idea)
<kees> siretart: need to trigger on \breinhard\b :)
<siretart> kees: does irssi support that?
<kees> siretart: well, it's not pcre, so I do [^a-zA-Z] instead of \b.  /hilight -regexp
<kees> siretart: I also use the trigger.pl script
<siretart> jreinhardt: if pgfplots is included in TL2009, I'd refrain from packaging it seperately, but work on getting TL2009 included instead
<siretart> kees: ah, thanks.
<siretart> well, I wanted to get rid of irssi anyways in favor of rcirc, but useful to know anyways...
<doctormo> I'm trying to upload a release to launchpad using the lp-project-upload script, but it's expecting to find an asc file, I have no way of generating such a file, gnupg is rather cryptic.
<azeem> doctormo: sounds like a question for #launchpad
<jpds> doctormo: gpg --clearsign <filename>, will make filename.asc.
<doctormo> thanks jpds, it's amazing that the script doesn't do it
<jpds> It does.
<jpds> doctormo: Strange: http://bazaar.launchpad.net/%7Eubuntu-dev/ubuntu-dev-tools/trunk/annotate/head%3A/lp-project-upload#L88
<jpds> doctormo: Hmm, probably used the wrong command to sign it then...
<doctormo> huh, the error I'm getting now is in #launchpad
<jpds> doctormo: Try with: gpg --armor --sign --detach-sig tarball.tar.gz.
<fabrice_sp> in a format 3.0 (quilt) source format, the patches still goes into debian/patches?
<ari-tczew> bdrung, I've changed Categories=Settings; to Categories=System; is it correct now?
<doctormo> jpds: worked, thanks
<cyphermox> fabrice_sp, afaik, yes :)
<fabrice_sp> yeah: it seems that QUILT_PATCHES does not point to the right place in my case :-/
<cyphermox> it seemed to make sense to me to always have it as debian/patches, nevermind what others may say/think
<fabrice_sp> I have it set to debian/patches in my main workstation (not the one I ma using right now :-/ )
<bdrung> ari-tczew: sorry, you can change the category back. the lintian warning is about the debian/xsmbrowser.menu file. because we do not change it in ubuntu, we should not change it for a lintian warning
<ari-tczew> bdrung, so upload current attached debdiff
<ari-tczew> question, can all MOTU members give ACK on FFe request?
<Laney> no
<fabrice_sp> only motu-release members
<fabrice_sp> hmm: should be ubuntu-release, now
<bdrung> ari-tczew: uploaded
<bdrung> ari-tczew: no
<ScottK> fabrice_sp: We haven't merged yet.
<ari-tczew> what's the difference between motu-release and ubuntu-release?
<fabrice_sp> before the archive reorg, motu-release was responsible for universe/multiverse and ubuntu-release for main
<fabrice_sp> with the archive reorg, I can't remember if motu-release will be merged with ubuntu-release or not
<fabrice_sp> thanks ScottK. Missed your comment
<ari-tczew> so now how is it? no difference with subscribing ubuntu/motu -release?
<fabrice_sp> ari-tczew, for the moment: universe/multiverse => motu-release, main => ubuntu-release
<randomaction> why would you want do do it *now*, before FF?
<ari-tczew> information for future ;)
<adhorden> hi, whats the best way to create a meta package? Do I just need a control file that just depends on my other packages?
<jreinhardt> bdrung: thank you
<jreinhardt> siretart: Sorry for the noise :) Regarding texlive: pgfplots was also part of texlive 2008. I packaged pgfplots mostly to scratch my own itch. Do you know if there is any chance for texlive 2009 to arrive in the archives in the foreseeable future?
<geser> it depends on how fast texlive 2009 stabilizes in Debian
<randomaction> at least they already have it in unstable
<siretart> jreinhardt: well, in theory it is just a sync away, texlive has reached unstable since a couple of weeks already and the maintainer has already started a thread on debian-release about its migration to testing
<jreinhardt> ok, then I will keep the package in my ppa and not bother anybody about it anymore :) Thank you
<jreinhardt> what shall I do with the package on REVU? Can I somehow indicate that it is not necessary to review it?
<fabrice_sp> jreinhardt, you can 'delete' it in revu
<siretart> fabrice_sp: I implemented that button so that it is restricted to revu admins. has this been changed?
<siretart> jreinhardt: just make a comment, perhaps someone still finds the package useful
<jreinhardt> siretart: ok, thank you. I was still searching for the delete button :)
<fabrice_sp> siretart, IIRC, the uplaoder can delete his own package
 * fabrice_sp is checking
<fabrice_sp> ok: it's archive, not delete
<emma> unquery
<fabrice_sp> siretart, is revu aware of source format 3.0 (quilt)? I've just uploaded one, and it says that the package could not be extracted
<fabrice_sp> bdrung, if you're still here: http://revu.ubuntuwire.com/p/fceux updated
<siretart> fabrice_sp: AFAIR spooky still runs hardy, and it is well possible that hardy's dpkg-source does not understand format 3 yet
<siretart> yes, spooky is still in hardy, we would need a dpkg backport on sparc. then
<troy43> Hi!, some expert in PPA?, I own a PPA to distribute my program, it has a jaunty published package, how can I updated it to karmic? Am I supposed to recompile it in a karmic pc and upload it again or can the ubuntu buildroots do this for me from the ppa webpage?
<ScottK> troy43: How to work a PPA isn't on topic for this channel.
<troy43> Scottk: ok..
<maxb> Please ask on #launchpad
<troy43> maxb: thanks!
<crimsun> vtk is such a cluster of funballs.
 * ScottK waves to crimsun.
<ScottK> How's it going?
<crimsun> the -dev deps are kludged^Wfixed
<crimsun> just digging into -java now
<ScottK> crimsun: I noticed a lot of the rdepends problems were on powerpc.  I think it's due to archive skew, but if there's something ppc specific you need tested, I have access to a box.
 * ScottK thinks java will be most of the 'fun'.
<ScottK> java + vtk.  What's not to love.
<sebner> ScottK: everything :P
<crimsun> ok, vtk fixed
<bdrung> ari-tczew: instead of sending the whole debdiff to debian, you should extract the relevant part of it (in this case remove the changes to debian/changelog and debian/control)
<bdrung> porthose: first sync request, that i do not ack directly
<porthose> bdrung, yep should have been a merge :(
 * porthose fixes
<bdrung> porthose: time to sponsor your first merge? ;)
<porthose> cool will ping you when I have it ready :)
<bdrung> porthose: then hurry - i will go to sleep soon ;)
<porthose> bdrung, how about I ping you tomorrow then :)
<bdrung> dunno if i have time then
<ari-tczew> bdrung, I mean like you said, but I think hmmm - interesting whether Debian maintainer is very lazy for review attached debdiff ;-)
<bdrung> ari-tczew: the less work a maintainer have to do, the higher the change of getting it accepted.
<bdrung> ari-tczew: for example: i prefer sponsoring sync, because they are easier/faster to review than merges
<ari-tczew> bdrung, easy, I know Ubuntu politics for Debian - minimalize delta as smaller as possible, prefer to sync from Debian ;)
<bdrung> yes
<ari-tczew> bdrung, how are you think, do I have chance to join MOTU?
<bdrung> ari-tczew: from today i would say, that more experience won't hurt. why don't you apply for Ubuntu Contributor first?
<ari-tczew> why that?
<ari-tczew> what's the difference? what give me Ubuntu Contributor first?
<maxb> Contributing Developer is a special case of Ubuntu Membership where the membership-qualifying activity is packaging
<ari-tczew> wow
<porthose> bdrung, arrghhh this could take a while, the merged package fails to build :(
<ari-tczew> huh, not only me have problems today ;-]
<bdrung> ari-tczew: details: https://wiki.ubuntu.com/UbuntuDevelopers
<kkszysiu> hello
<ari-tczew> bureaucracy, bureaucracy, and one more bureaucracy... I don't have time for reading while a long articles on wiki.ubuntu, because I don't know about one phrase.
<ari-tczew> hello kkrzysiu
<bdrung> ari-tczew: then read only the "Ubuntu Contributing Developers" section
<kkszysiu> what I should do when I want to put my package into Ubuntu official repos?
<ari-tczew> kkszysiu, make this package
<ari-tczew> this is new package?
<kkszysiu> yes
<kkszysiu> gadu gadu support in telepathy
<ari-tczew> read about REVU
<kkszysiu> mostylu for users from Poland
<bdrung> kkszysiu: or bring it into Debian
<ari-tczew> kkszysiu I know what is gg :D
<kkszysiu> ah youre from PL xD
<ari-tczew> yeah, is it possible to pack only script into telepathy package?
<kkszysiu> nope, its stand alone package like other connection managers for telepathy
<ari-tczew> kkszysiu, from my point-of-view, better is create package in Debian first, this is more professionally
<kkszysiu> hmm
<ari-tczew> you will Debian Maintainer ;-)
<kkszysiu> any tuts, please? :P Because it is not standard package and I dont know how to generate setup.py and other stuff like that
<kkszysiu> for now Im using py2deb to generate package
<bdrung> ari-tczew: it's easier to bring new packages to ubuntu through debian.
<kkszysiu> but thats not pretty good
<ari-tczew> bdrung, I know
<bdrung> kkszysiu: it's easier to bring new packages to ubuntu through debian.
<ari-tczew> bdrung, I decided, that I'll try to join MOTU in April
<bdrung> k
<bdrung> ari-tczew: how long are you doing packaging?
<ari-tczew> I'm very busy now by very important project until end of March
<ari-tczew> bdrung, March 2009
<ari-tczew> I worked on my first package with you
<ari-tczew> gwget 1.0.1-0ubuntu1
<bdrung> :)
<dhillon-v10> bdrung, how many packages do you have to build before you can join MOTU, is there like a limit
<bdrung> ari-tczew: IIRC gwget was an example in our packaging jam session
<bdrung> dhillon-v10: there is no hard limit. it depends on the person; how fast they learn.
<bdrung> dhillon-v10: it's all about gathering experience.
<geser> dhillon-v10: there is no limit, but the DMB has to judge somehow your packaging expierence and sponsored uploads are a way to do it
<bdrung> dhillon-v10: i would recommend to work on ubuntu at least a half year, so that you go through a whole release cycle
<ari-tczew> now I think that it's better if I'll join MOTU for next development release (10.10)
<dhillon-v10> geser, I have had like 6 packages sponsored, and I filed quite a bit of sync/merge reports, I guess I still have to wait for a while, I still make some silly mistakes like the one you corrected the other day
<dhillon-v10> bdrung, I have been working with ubuntu since 9.04 so :)
<dhillon-v10> bdrung, well before that but started developing around that time
<dhillon-v10> geser, you are in DMB right? how many packages would you like to see getting sponsored, just an estimate
<bdrung> dhillon-v10: you should become Ubuntu Contributing Developers at least
<dhillon-v10> bdrung, what is that, like a middle step for MOTU, i read about something like that on the wiki
<bdrung> dhillon-v10: is it's a middle step. Ubuntu Contributing Developer will contain Ubuntu membership (with email address, etc)
<geser> I'm in the MC (which is currently being merged into the DMB). It's hard to tell, as you should contribute for around a release to know each phase (and its policies), getting one upload sponsored each week (on average) shouldn't be that hard, so that would be around 30 sponsored uploads
<dhillon-v10> bdrung, sorry I am taking a lot of your time, here's my wiki: https://wiki.ubuntu.com/dhillonv10/ do you think I'll make it to contributing developer
<dhillon-v10> geser, alright thanks :)
<dhillon-v10> geser, alright that seems sensible and not too hard :D so I'll wait for 10.10
<ari-tczew> dhillon-v10, you're welcome
<bdrung> dhillon-v10: how old are you?
<dhillon-v10> bdrung, I am 17
<ari-tczew> maybe 10?
<dhillon-v10> ari-tczew, no :)
<micahg> is there any special group for prospective developers?
<ari-tczew> dhillon-v10, could you change your IRC nick to more easier?
<bdrung> ari-tczew: he is the tenth clone (-> version 10) ;)
<dhillon-v10> ari-tczew, is my wiki that bad ?
<ari-tczew> bdrung, maybe 10 source format? :D
<dhillon-v10> bdrung, lol yup my other 9 clones are doing packaging :)
<bdrung> dhillon-v10: your irc nick indicated the 10
<dhillon-v10> bdrung, yah the 10th clone is the one talking to you :D
<ari-tczew> I think that if you'll have nick "Vikram", it's easier to write and remember
<dhillon-v10> ari-tczew, alright I'll change my nice :)
<dhillon-v10> *nick
<ari-tczew> specially if you want to join MOTU, you'll active on IRC, so I recommend you to change nick
<Laney> I don't think it matters
<vikram> ari-tczew, okay so how about now
<ari-tczew> Laney, IIRC you always have conservative point-of-views
<ari-tczew> vikram, looks better than previously
<Laney> I have what?
<bdrung> dhillon-v10: you are part of the community and know many people, you have contributed to ubuntu. six uploads is not much. if you want, you can apply for ubuntu-contributors. it will needs some week till then and in this time you can do some more uploads
<bdrung> vikram: ^
<micahg> so, 30 uploads is standard for universe-contributors?
<ari-tczew> Laney, it's hard to talk about in english, this is polish phrase
<bdrung> ari-tczew, vikram: i think it help, if irc nick = launchpad nick
<vikram> bdrung, alright thanks, should I change my nick back ??
<ari-tczew> bdrung, always my LP nick = IRC nick IIRC ;-)
<bdrung> vikram: use the nick, that you prefer
<geser> micahg: no, that's for MOTU (but no requirement more a personal rule of thumb)
<ari-tczew> 30 uploads including syncs?
<vikram> bdrung, most people know me as dhillon-v10 so I'll just stick to that, sorry ari-tczew
<geser> yes, syncs, merges, bug fixes
<ari-tczew> done
<Laney> I would imagine a range of work would help
<dhillon-v10> geser, my problem is that I contribute to upstream linux kernel and do patches there so they don't count for Ubuntu
<geser> micahg: for universe-contributors around 5 uploads would be nice (so we know that you mean it for real) (again that's no requirement)
<bdrung> dhillon-v10: but working upstream does not count as packaging ;)
<dhillon-v10> bdrung, that is true :)
<dhillon-v10> geser, so I am eligible for universe-contributors nice :D
<ari-tczew> hmmm, so Universe Contributors is like a queue for MOTU
<ScottK> dhillon-v10: You're eligible to apply, but that is also supposed to be based on sustained contribution.
<ScottK> ari-tczew: It can be if you want to become an Ubuntu member first.  It's not required.
<micahg> geser: is there an advantage for me to apply for universe-contributors as a stepping stone to MOTU since I'm already an Ubuntu member?
<cyberix_> lintian debugging tool gives me a warning of missing soname for libkunquat.so
<bdrung> ari-tczew: you can see it as probationary period
<cyberix_> libkunquat developer asks me how to test, if he has managed to fix the problem
<geser> ari-tczew: not directly, but your (sustained and substancial) contributions to Ubuntu development qualify for Ubuntu membership (other ways are e.g. bug triaging or LoCo work)
<cyberix_> So
<geser> micahg: not really (unless you want a badge more on your LP page :)
<cyberix_> How does one check, if an so-file is missing and soname or not?
<ari-tczew> heh, so what's doing MOTU? geser
<micahg> geser: not worth it...I guess I'll wait till after Lucid and maybe have enough uploads to apply for MOTU
<geser> MOTU gives uploads rights to the universe (and multiverse) component (and of course Ubuntu membership too)
<ari-tczew> I want to join MOTU because I want uploading packages themselve and ACKing syncs
<ScottK> Then there's really no reason to bother with UUC.
 * ari-tczew is confused
<dhillon-v10> ScottK, I guess I can just wait for a while until I have a bunch of uploads and then just apply for MOTU
<geser> ari-tczew: in what way confused?
<ari-tczew> as you said geser, MOTU and Ubuntu membership both gives uploads rights to the universe
<ari-tczew> so what's the difference between UUC and MOTU
<ari-tczew> ...
<bdrung> dhillon-v10: i recommend to become contributor first
<geser> no, Ubuntu membership gives no upload rights (but MOTUs are also Ubuntu members)
<ScottK> dhillon-v10: I would encourage you to be a little more focused and show clearly you know what you are doing.  I've seen you say you're going to do stuff and it doesn't happen.  My first interaction with you was when you gave a completely bogus reply to a soyuz question I'd asked.  If you get an reputation for unreliability, you may never get to be a MOTU.
<ari-tczew> nosense
<ScottK> ari-tczew: UUC is about membership.  Nothing to do with upload rights.
<ari-tczew> wow! (ironic)
<ScottK> How so?
<RAOF> cyberix_: âobjdump -x /path/to/libfoo.so | grep SONAME"
<cyphermox> bdrung, regarding Bug 502651, why a debdiff between debian and ubuntu rather than the one between the new and previous ubuntu version already there? because it's a native package?
<ubottu> Launchpad bug 502651 in piuparts "Please merge piuparts 0.37 (universe) from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/502651
<bdrung> ari-tczew: UUC gives you reputation, too.
<ari-tczew> nevermind... as I said previously, I'll join MOTU in April, I'll ready for work on 10.10
<ari-tczew> UUC? if I'll find time, of course
<dhillon-v10> ScottK, really? what question was that? I know I am stupid but now that stupid :)
<bdrung> ari-tczew: UUC = Ubuntu Contributing Developer = member of ubuntu-contributors
<bdrung> cyphermox: because it's a merge from Debian.
<Laney> cyphermox: because that shows the changes you made more clearly
<geser> cyphermox: a debdiff between Debian and Ubuntu makes the review easier (the remaining Ubuntu changes are easier to spot) as we usually don't review the Debian changes
<cyphermox> ok.
<ScottK> dhillon-v10: You told me I was supposed to mark if a response had resolved my question when I had already done so.  It makes me question if you have the attention to detail necessary for being a MOTU.
<cyphermox> because 501697 was uploaded and was a ubuntu-ubuntu debdiff, hence why I'm a little confused
<ari-tczew> ok guys, I'm going to bed, bye
<cyberix_> RAOF: thankyou
<bdrung> cyphermox: if the ubuntu -> ubuntu diff is small, you can attach it to the bug report, too (as addition)
<bdrung> hey guys. look at that: https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors
<cyphermox> bdrung, cool, sorry for the noise :) it seems the bzr branch wasn't even up to date anyway
<bdrung> cyphermox: no problem.
<geser> an empty u-u-s queue?
<Laney> surely not!
<bdrung> geser: yes. that was hard work
