[00:00] <persia> No.
[00:00] <persia> Look up virtual package in the policy doc.
[00:03] <ari-tczew> persia: I can't found, lol
[00:11] <ari-tczew> persia: I need a break in packaging, bye
[00:57] <PATX> can anybody review http://revu.ubuntuwire.com/p/fastpatx
[01:09] <aboudreault> hi<
[01:10] <aboudreault> does anyone uses cowbuilder here ? I got strange library path in a chroot: see the last -L option: http://pastebin.com/m1fa5b3ff
[01:13] <persia> That doesn't seem like an unreasonable place for it to be: is that not the default unpack location?
[01:14] <aboudreault> don't know where this come from
[01:15] <aboudreault> the problem is all those spaces in the path
[01:16] <aboudreault> http://pastebin.com/m2b623a0
[01:17] <aboudreault> more log
[01:17] <persia> Those are real spaces, not just artifacts?  Oh my, that is wrong.
[01:17]  * persia has no idea
[01:18] <aboudreault> strange :/
[02:01] <flupke> hi, I'd like to better understand the .debs build process in the repositories, is there documentation somewhere on this subject ?
[02:02] <persia> Are there any specific aspects that interest you?  I don't know of an overall brief.
[02:03] <flupke> I'd just like to know what the process is like, for example are the .debs built from the same packages you get from apt-get source ? is this done automatically ?
[02:03] <persia> Yes, and kinda.
[02:04] <persia> Developers upload source, and Soyuz dispatches those to the buildds.
[02:04] <persia> The buildds build, and the upload the binary packages.
[02:04] <persia> I say "kinda" automatic, because the trigger is a developer uploading something, or pressing the "give-back" button.
[02:05] <flupke> and is there some kind of standardized build platform ?
[02:05] <persia> Yes, but I don't know that the details are well documented.  You might get some information from the Soyuz source.  I know that a custom version of sbuild is used at the bottom layer.
[02:06] <flupke> the reason for my question is that I'd like to kind of automate building customized .debs, and I often have problems on my desktop karmic
[02:07] <persia> Oh, then you're not interested in that at all :)
[02:07] <lifeless> use PPA's
[02:07] <lifeless> :>
[02:07] <persia> You don't need *anywhere* like the infrastructure required to run a distro for that.
[02:07] <flupke> so, now I know this must be because of the pile of junk installed on it, I'll look for details on soyuz and sbuild
[02:08] <lifeless> flupke: just sbuild/pbuilder should be all you need. Though really; PPAs.
[02:08] <persia> PPA work, of if you need it local, look at any of the mini-archive tools.  deb-o-matic is one that I used once-upon-a-time (but no longer remember clearly)
[02:08] <flupke> (I was wondering if the .debs were built by hand)
[02:08] <persia> No.
[02:08] <persia> Use a ppa, or install pbuilder/sbuild.
[02:09] <persia> That will take care of 95% of what you need.
[02:09] <flupke> ok I'll look into PPA and pbuilder/sbuild, many thanks :)
[02:09] <persia> deb-o-matic or falcon or something would get you to 99%.
[02:09] <jcastro> plus with a PPA you get other arches for free!
[02:09] <persia> jcastro: For a very limited definition of "other", being approximately "ones that one can build on the same hardware" :)
[02:10]  * jcastro loosely changes what "free" means depending on the day
[02:10] <RAOF> Yeah.  Nothing exotic like PPC or I64.
[02:10] <persia> PPC isn't exotic!
[02:11] <persia> But I can't find ia64 in the shops, and the few sparcs I can find seem old.
[02:11] <persia> (and big and noisy etc.)
[02:11] <persia> But PPC is widely available in retail.
[02:12] <lifeless> qemu qemu qemu
[02:12] <RAOF> It would be nice to have PPC in the PPA; that way people could use nouveau on their slightly exotic hardware.
[02:13] <persia> RAOF: I thought people could use nouveau on their non-exotic PPC hardware by using squeeze or lucid.
[02:13] <persia> Did that not happen yet?
[02:13] <RAOF> They can, yes.
[02:14] <RAOF> But it would have happened sooner, and they won't be able to test 3D with lucid.
[02:14] <persia> Oh.
[02:14] <persia> Well, I suppose packages could be built locally, but yeah :(
[02:14] <persia> Unfortunately, I have ATI on my PPC, so I can't test anyway.
[02:14] <RAOF> And they won't be able to verify fixes, because I can guarantee the first thing nouveau upstream will ask of bug reports is “does it still happen with git kernel, ddx and libdrm”?
[02:15] <PATX> persia, are u busy with reviewing?
[02:15] <persia> PATX: No, busy with bugfixing
[02:15] <PATX> ah
[02:15]  * persia is currently frustrated with make function call semantics
[02:15] <PATX> will u ever have time to look at http://revu.ubuntuwire.com/p/fastpatx
[02:15] <PATX> lol
[02:16] <persia> PATX: I have that page open in my browser, and have had it so for a while.  It's #2 on my review list for when I'm reviewing again.
[02:17] <PATX> :) thanks! :)
[02:17] <PATX> not rushing (or trying to) im just new to this so i am ansois
[02:17] <PATX> ansois?
[02:17] <PATX> anxious
[02:17] <PATX> lol
[02:23] <kamalmostafa> Hello motu's -- please note bug 524183 -- have I followed the FFE request process properly?
[03:06] <flupke> I have a pbuilder environment (I followed https://wiki.ubuntu.com/PbuilderHowto ), but it fails building a package (gdal), saying "Aptitude couldn't satisfy the build dependencies"; how can I investigate on the problem ?
[03:13] <kamalmostafa> flupke: the problem there looks like you're trying to build a package on Karmic which will only build on Lucid, due to a newer version of a library on Lucid...
[03:13] <cyphermox> flupke, usually pbuilder will tell you a bunch of things in addition to "couldn't satisfy dependencies", it would be a little higher "up" in the output -- e.g. <package name> is a virtual package, or <package name> will not be installed
[03:13] <kamalmostafa> scroll back in your pbuilder log there, and you'll see:
[03:13] <kamalmostafa>     Depends: libhdf5-serial-dev (>= 1.8.3) but it is not installable
[03:14] <kamalmostafa> Then, you can do    apt-cache policy libhdf5-serial-dev   there on your Karmic system, and you'll get:
[03:14] <kamalmostafa>   Candidate: 1.6.6-4ubuntu2
[03:15] <kamalmostafa> Note that the version number there is indeed *not* >= the version 1.8.3 that your 'gdal' package requires.
[03:15] <kamalmostafa> Lucid does have a version of libhdf5-serial-dev that will work here, and the package looks like it at least proceeds to start building with a pbuilder-dist for Lucid.
[03:21] <flupke> kamalmostafa, I see "Depends: libhdf5-serial-dev which is a virtual package." in the log
[03:21] <flupke> (with a bunch of other virtual packages)
[03:21] <kamalmostafa> flupke: The very next line, I think, will be the "... is not installable" line I mentioned.
[03:21] <flupke> so I just do : sudo pbuilder update --distribution lucid --override-config ?
[03:22] <kamalmostafa> That's not the method I use.   I use "pbuilder-dist" (which is just great :)    See the man page for "pbuilder-dist" for instructions on how to set it up.
[03:22] <flupke> I don't see any "... is not installable" line
[03:23] <flupke> ok, thanks
[03:25] <kamalmostafa> flupke: if you want to capture your pbuilder log (with --logfile {filename}) and paste it to a pastebin, I'll be happy to take a look.  I'm correct that you're running on Karmic, yes?
[03:25] <flupke> yes I'm on karmic
[03:27] <kamalmostafa> flupke: ok, well, that version of gdal won't build *for* Karmic due to the older libhdf5, but yes, pbuilder-dist will let you build a Lucid-targeted version of gdal on your Karmic system (if that's interesting to you).
[03:28] <flupke> kamalmostafa, here is the log : http://paste.pocoo.org/show/179981/
[03:32] <kamalmostafa> flupke: yes, your log does look different than mine.   Have you done?:    sudo pbuilder --update
[03:33] <flupke> yes
[03:34] <kamalmostafa> flupke: well, I don't know why our logs differ there -- sorry.
[03:34] <flupke> kamalmostafa, heh no problem, anyway I'm targeting jaunty, maybe it'll work for it
[03:35] <kamalmostafa> flupke: well, I haven't actually tried it, but I think pbuilder-dist can build for Jaunty as well -- but if Karmic doesn't have the libhdf5 you need, Jaunty won't have it either I expect.  good luck!
[03:36]  * flupke tries with pbuilder-dist
[03:36] <flupke> it's a dev machine I'm working on, maybe it's too broken and I should make a VM
[03:37] <flupke> I disabled the PPAs that I'm using to get the latest gdal and Qt but maybe there are things left
[03:38] <kamalmostafa> Oh, actually, we never compared versions.  I'm just testing with "apt-get source gdal" from the Lucid source base:  gdal_1.6.3-3.dsc
[03:38] <flupke> anyway this is very interesting, I always wondered how it worked, thanks for the infos I have tons of fun things to do now :)
[03:39] <flupke> I tried on gdal_1.5.4-4.dsc
[03:40] <kamalmostafa> flupke: ok, well best of luck.  FWIW, my   pbuilder-lucid-amd64 gdal_1.6.3-3.dsc   did build successfully.
[03:48] <flupke> kamalmostafa, just a last question, I'm going to make a VM to have a clean environment, is it best to use the same platform I'm targeting (e.g. build for jaunty from jaunty) ?
[03:51] <kamalmostafa> flupke: i don't honestly know.  I use pbuilder-dist (running on my Karmic machine) to build packages for Lucid regularly and it has worked flawlessly for me, but I have no experience building for Jaunty.  But if you're going to make a VM anyway, then you may as well go ahead and just build on the release you're targeting for.  sorry that's not much of an answer.  :-)
[03:52] <flupke> hem yeah silly question, I could as well just install build-essential
[03:53] <flupke> but the reason I'm doing all this is that building gdal from sources failed on the jaunty machine
[03:53] <flupke> I wonder where the .debs come from :)
[03:56] <kamalmostafa> flupke: https://launchpad.net/ubuntu/+source/gdal says that your gdal_1.5.4-4 as building successfully in Karmic, but Jaunty has an earlier version of gdal.
[03:57] <kamalmostafa> (in reference to "where the .debs come from")
[03:58] <kamalmostafa> oops... I must step away.  good luck, flupke.
[03:59] <flupke> thanks for all, bye :)
[05:51] <flupke> kamalmostafa, just to let you know, everything compiles smoothly in the VM... my machines are somewhat broken as an ubuntu build environment
[05:51] <kamalmostafa> flupke: good news.  congrats!
[08:21] <dholbach> good morning
[08:24] <slytherin> Do we have any policy for/against keeping KDE3 apps in universe?
[10:14] <davidekholm> Hi. I'm the founder of Jalbum (http://jalbum.net). We've just adopted our web photo album software for Ubuntu and packaged it as a .deb package. Can anyone here give me guidance on how to get Jalbum into "Ubuntu Software Center"? We're true freeware, no crippleware, but Jalbum is only 50% open source - generic code under LGPL but still some core code not opened.
[10:15] <davidekholm> Jalbum is very popular on Windows and Mac with over 5 million downloads and over 26 million published web albums to servers all over the world. Now we want to give Ubuntu users a proper experience of our software. I figure, getting into "Ubuntu Software Center" is the ideal path.
[10:16] <c_korn> hello, can I get a FFe for scilab ? bug 511864
[10:17] <c_korn> seems the bot is still sleeping: https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/511864
[10:18] <c_korn> oh, there it is. I was tabbing fro ubutto :)
[10:18] <davidekholm> Anyone with input on this?
[10:31] <dholbach> davidekholm: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[10:35] <sebner> dholbach: As MOTU remains after Archiv-reorg, u-u-s remains too am I right? Because I just renewed membership .. :)
[10:36] <dholbach> sebner: I wanted to discuss it in the next TB meeting
[10:36] <dholbach> I think it'd make sense to merge the teams
[10:37] <sebner> dholbach: oh, kk. :)
[11:48] <shadeslayer> anyone around?
[11:49] <Rhonda> If you have a question, just ask it and people might answer you, even without your question wether someone is around or not. :)
[11:58] <slytherin> does anyone know how to know exactly if plymouth is working on an installation or not?
[12:23] <slytherin> #ubuntu-x
[12:31] <fagan> directhex: do you package monodevelop?
[12:31] <directhex> fagan, i've taken care of the past few updates, yes
[12:31] <fagan> The -java -python..etc cant be installed
[12:32] <directhex> in lucid?
[12:32] <fagan> yep
[12:33] <fagan> Bug #524388
[12:33] <fagan> directhex: ^
[12:35] <fagan> It looks like the version number just needs to be changed
[12:35] <fagan> for the depends I mean
[12:36] <directhex> fagan, looks like some missing syncs
[12:36] <directhex> fagan, monodevelop-boo is fine fr'example
[12:36] <directhex> let me build the list
[12:36] <fagan> -boo is fine here too
[12:37] <directhex> just a bunch of syncs needed
[12:38] <fagan> ah ok
[12:38] <fagan> its just -java -python and -database that are broken
[12:38] <fagan> oh and -vala
[12:39] <fagan> directhex: cool so at least its easily fixed
[12:40] <directhex> Sync request filed as bug #524396: https://edge.launchpad.net/bugs/524396
[12:40] <directhex> Sync request filed as bug #524397: https://edge.launchpad.net/bugs/524397
[12:41] <directhex> and so on
[12:42] <fagan> directhex: cool thanks for the help
[12:42] <directhex> fagan, i didn't notice than my request for 2.2.1 had been syned, which is how i missed this
[12:43] <directhex> there, that's all of them
[12:43] <fagan> thanks
[12:43] <slytherin> Do we have anything policy in regards with removal of KDE3 applictions?
[12:44] <fagan> slytherin: what needs removal?
[12:44] <slytherin> fagan: kiso, it hasn't seen a release since 2005, KDE3 app and functionality available in other programs.
[12:47] <fagan> slytherin: well I dont think we have any formal policy for removal but if you ask one of the motu kde people they could maybe do it for you
[12:47] <slytherin> fagan: That is why I asked here.
[12:47] <fagan> maco2: you around ^
[12:48] <directhex> fagan, in the meantime, it *might* be possible to use my karmic ppa without issue. i have all the 2.2.1 stuff from sid in there
[12:49] <fagan> directhex: I can wait for the sync ill close my bug when its fixed
[13:16] <slytherin> fagan: Wow. Quick post. :-)
[13:17] <fagan> slytherin: yep
[13:17] <slytherin> fagan: In case you don't know, I usually come across such packages when dealing with NBS problems.
[13:18] <fagan> slytherin: NBS?
[13:19] <slytherin> fagan: Not Built from Source. Usualy deals with the libraries which are no more built but have rdepends. http://people.canonical.com/~ubuntu-archive/NBS/
[13:19]  * fagan hates acronims 
[13:20] <shadeslayer> fagan: acronyms :P
[13:20] <and`> fagan: about your blog post: archive "cruft" is something not that easy to get rid of, most of the times there's alwais a reason to keep a package or better people may have different opinions about removing or not a certain software
[13:21] <and`> fagan: also, it would be nice to check for such packages in Debian first, to avoid work-duplicates
[13:21] <and`> fagan: it's nice blogging about it, but not easy to fix the current situation :)
[13:22] <fagan> and`: very true but it is needed IM
[13:22] <fagan> *IMO
[13:22] <didrocks> fagan: hey
[13:22] <Laney> who's the judge of whether a program is worthy?
[13:22] <and`> fagan: agreed, but the MOTU team is usually overloaded by a lot of things starting from sponsoring to merge new stuff, so it will be hard
[13:22] <didrocks> fagan: did you advance on Quickly doc side ? ;)
[13:23] <and`> Laney: usually the maintainer need to give his / her ack before having the package removed
[13:23] <fagan> didrocks: oh I forgot to ask dpm
[13:23] <Laney> and`: no, we don't have maintainers
[13:23] <and`> Laney: Debian side
[13:23] <didrocks> fagan: also, Mallard can be used now, see my comment on philip's post
[13:23] <Laney> this isn't a question about Debian
[13:23] <slytherin> and`: Laney: You can always check certain parameters like if it is maintained upstream, if the functionality is something not easily available in other packages. etc.
[13:23] <and`> Laney: low popcon, RC bugs, no one caring about it
[13:24] <Laney> since it's really not possible there
[13:24] <Laney> slytherin: I don't know if lack of upstream activity is enough
[13:24] <Laney> buggy, unmaintained maybe
[13:24] <shadeslayer> does pbuilder just require the .dsc to build a package?
[13:24] <Laney> but just not having releases, ...
[13:24] <and`> yes, RC bugs + unmaintained
[13:24] <shadeslayer> i cant really figure out the wiki
[13:25] <slytherin> Laney: That is why I specifically asked. The package in question is a KDE3 app. I didn't know if we are still keeping KDE3 apps.
[13:25] <slytherin> shadeslayer: yes
[13:25] <Laney> right, the question broadened somewhat from your original one
[13:25] <shadeslayer> slytherin: nothing else in the chroot?
[13:25] <slytherin> Laney: That is fagan's fault. :-D
[13:25] <fagan> didrocks: well I dont have a clue how to use mallard atm
[13:25] <Laney> slytherin: also, an imporant thing for the one you asked about is that it's an ubuntu-local package
[13:26] <and`> shadeslayer: pbuilder requires a .dsc target to build a package yes, but before you should debuild it
[13:26] <Laney> so we have no debian maintainer to lean on
[13:26] <slytherin> shadeslayer: Have you created a pbuilder chroot?
[13:26] <shadeslayer> slytherin: its downloading
[13:26] <didrocks> fagan: neither do I, but you can ask to robert_ancell when he's around, he worked on that
[13:26] <Laney> I am much less tolerant of those packages
[13:26] <fagan> didrocks: Ill have a look into it
[13:26] <and`> Laney: well, usually it's nice to ping the Debian maintainer anyway to see what's going on if the package is not being updated or it is buggy
[13:26] <didrocks> fagan: sweet, thanks
[13:26] <shadeslayer> and`: so like first debuild -S -sa and then /path/to/dsc_file_generated ?
[13:27] <fagan> didrocks: first ill go ask dpm about the translations of what we have
[13:27] <slytherin> Laney: Right. I had forgot about that. So it is good candidate for removal.
[13:27] <didrocks> fagan: ok
[13:27] <and`> Laney: that's why removing packages in Ubuntu is directly related to Debian
[13:27] <slytherin> and`: In this particular case, package was never present in Debian.
[13:27] <Laney> and`: I know all of this. I'm a big proponent of convergance
[13:27] <Laney> we're talking about both a principle and a specific case
[13:27] <Laney> and actually this case is quite different from the norm
[13:28] <and`> shadeslayer: debuild -S -sa (depending on orig upload or not) and then pbuilder --build /path/to/dsc/file (or if you use different tarballs use the --basetgz option)
[13:29] <and`> Laney: sure, wasnt following the specific case, was just telling how this generally works for most packages
[13:29] <shadeslayer> and`: different tarballs ? i dont understand
[13:29] <Laney> thanks, although I think I am aware of how best to work here :)
[13:29] <james_w> didrocks: I've played with Mallard a little too
[13:30] <fagan> it would require some help from debian but if the package doesnt have a maintainer and hasnt been updated it could be removed
[13:30] <and`> shadeslayer: e.g if you have a lucid tarball and a sid one
[13:30] <shadeslayer> and`: oh..
[13:30] <didrocks> james_w: oh really? Do you have any documentation pointers (<- fagan)
[13:30] <and`> shadeslayer: but I guess you just have a base.tgz one :)
[13:30] <shadeslayer> and`: so what does it do with both the tarballs?
[13:30] <shadeslayer> and`: the one pbuilder creates right
[13:31] <james_w> didrocks: fagan: http://projectmallard.org/about/learn/index.html
[13:31] <didrocks> james_w: rock! Thanks
[13:31] <shadeslayer> and`: some of the packages failed to download... i just run pbuilder update to get them right?
[13:31] <and`> shadeslayer: if you want multiple chroots with different systems in it you can have them by specifing the distribution, the basetgz location and the mirror you wanna use
[13:32] <and`> shadeslayer: yes
[13:32] <james_w> didrocks: fagan: http://gitorious.org/empathy-mallard/empathy-mallard
[13:32] <and`> shadeslayer: it will update your tarball fetching latest contents
[13:32] <shadeslayer> and`: ah...
[13:32] <shadeslayer> and`: ok
[13:32] <and`> shadeslayer: let's say you want a sid chroot, you will do
[13:32] <shadeslayer> and`: so it builds against those chroots
[13:33] <didrocks> james_w: ok, I'm copying the link to the bug report to have it into an handy place (I hadn't the time yet to have a look at it, but I'm sure we should use mallard now)
[13:33] <didrocks> james_w: thanks a lot
[13:33] <shadeslayer> like i want to test the package on both karmic and lucid.. so i need both of those chroots
[13:33] <and`> shadeslayer: pbuilder --create --basetgz /path/to/it/sid.tgz --distribution sid --mirror http://ftp.debian.org or whatever
[13:33] <shadeslayer> and`: ok i get it :)
[13:33] <and`> shadeslayer: that will make a sid chroot, if you want a karmic chroot just change the variables above and you're done
[13:33] <fagan> thanks james_w for the link
[13:34] <james_w> didrocks: mallard rocks
[13:34] <shadeslayer> and`: ok im starting to get this :)
[13:34] <and`> shadeslayer: so, in the end, you can build against multiple distributions :)
[13:34] <fagan> james_w: im just sad because I only got to grips with docbook in september :/
[13:35] <slytherin> shadeslayer: wiki has a very nice example of pbuilderrc containing configuration for multiple chroots.
[13:35]  * Laney just uses pbuilder-dist
[13:35] <shadeslayer> slytherin: yeah im reading that too... for the past half an hour...just a bit slow on understanding it... first time packager :)
[13:36] <slytherin> hmm
[13:37] <shadeslayer> slytherin: i used PPA's till now... didnt actually package something new.. until today :P
[13:38] <shadeslayer> just did apt-get source blah , copied and modded the debian/ contents.. and then debuild -S -sa
[13:38] <shadeslayer> and then the final upload
[13:40] <danblick> Could anyone help me get started with a small project?  I want to try checking out the code for the 'scala' package for Ubuntu, updating it to use the latest version of scala, and then pushing it to my PPA on launchpad.  I thought 'apt-get source scala' would get me the source for this package, but it didn't -- what should I start with?
[13:40] <Laney> you need a lucid deb-src line
[13:41] <nigelb> danblick: alternatively, you can go to packages.ubuntu.com and do a dget of the dsc file
[13:42] <danblick> nigelb: thanks, i'll try that
[13:43] <danblick> Laney: oh -- right, development build. thanks for point that out.
[13:43] <danblick> pointing*
[13:44] <Laney> or there is pull-lp-source and pull-debian-sorce in ubuntu-dev-tools
[13:44] <Laney> source*
[13:45] <danblick> ls
[13:53] <fagan> didrocks: could you grab my pot anyway and start translating it on launchpad?
[13:53] <didrocks> fagan: will it be compatible if we switch to mallard?
[13:54] <fagan> well the pot will be similar not the exact same but I could write a script to find and replace the differing syntax
[13:54] <fagan> its not that different
[13:54] <didrocks> (that means, are there any <> in the pot?)
[13:55] <fagan> Well I dont know if the syntax for code segments..etc is the same but the words would be the same
[13:55] <fagan> It shouldnt be too hard to change afterwards
[13:56] <fagan> So the pot is the same but the words may move a little and the markup would be different but ill sort it out
[13:56] <didrocks> fagan: well, I'm just unconfortable if we ship a pot which will be invalid in 10 days because we use mallard and the markups invalidate all strings
[13:56] <didrocks> fagan: if you can do the job, ok
[13:57] <didrocks> fagan: where is your pot file, already?
[13:57] <fagan> didrocks: its in the branch that I submitted for the merge in /data/templates/ubuntu-application/help
[13:58] <didrocks> fagan: right, I'm asking for your merge proposal link, you removed last one I had
[13:58] <fagan> didrocks: the default ubuntu docs wont be changed before lucid+1
[13:58] <didrocks> fagan: simple-scan is in ubuntu and is using Mallard
[13:58] <fagan> and empathy too
[13:58] <fagan> but the default docs wont move till lucid+1
[13:59] <fagan> https://code.edge.launchpad.net/~shanepatrickfagan/quickly/quickly_docbook didrocks
[13:59] <didrocks> right, but if we can have the right techno in the first launch, that's why I asked you to look at mallard a long time ago :)
[14:00] <fagan> didrocks: well when you asked no one was using mallard and it was a lot of work just to bring it over to docbook
[14:00] <fagan> if you want full docs for this release it kinda has to be docbook because I dont have the time rewrite it again
[14:00] <fagan> but for translations we are fine
[14:01] <didrocks> fagan: ok, you just need to figure out how the doc can use the mo files once built
[14:02] <fagan> didrocks: I just asked dpm :)
[14:02] <didrocks> cool :)
[14:02] <hakaishi> would anyone be interested in https://launchpad.net/~hakaishi/+archive/qt-program-starter ?
[14:08] <hakaishi> qt-program-starter is a program to start any command or program. It is able to save any output or error output each into a text file and to start at a certain time, to shutdown or just quit, after the process is finished.
[14:08] <shadeslayer> i need a better server for pbuilder
[14:10] <hakaishi> I don't know if I should upload qt-program-starter, this is why I ask.
[14:12] <sebner> hakaishi: upload where?
[14:12] <hakaishi> to revu
[14:13] <sebner> hakaishi: well, we are already past FF so you have to wait for lucid+1 anyways
[14:16] <hakaishi> sebner: what I wanted to know is if anyone would be interested in such a program, because I am thinking of uploading it to revu. If nobody is interested, why should I upload it?
[14:16] <sebner> hakaishi: guess you should ask in #ubuntu then ;
[14:16] <hakaishi> sebner: okay, I'll try. Thank you.
[14:20] <BlackZ> if I have made a new upstream release of a program, and I have puted lucid in debian/changelog file, how can I upload new upstream version?
[14:21] <maco2> fagan: i think removal of package needs archive admin
[14:21] <Rhonda> BlackZ: I fear not anymore because lucid is in featurefreeze
[14:27] <shadeslayer> http://pastebin.ca/1802675 << error on running pbuilder create
[14:27] <shadeslayer> any ideas?
[14:31] <BlackZ> shadeslayer: which ubuntu version do you have?
[14:32] <shadeslayer> BlackZ: karmic.... Riddle helped me out
[14:32] <BlackZ> shadeslayer: sudo pbuilder create --distribution 9.10 \
[14:32] <BlackZ>         --othermirror "deb http://archive.ubuntu.com/ubuntu 9.10 main restricted universe multiverse"
[14:32] <BlackZ> shadeslayer: then sudo pbuilder update
[14:39] <lfaraone> BlackZ: that won't work. you have to use codenames, not version numbers.
[14:40] <lfaraone> BlackZ: so it's sudo pbuilder create --distribution karmic  --othermirror "deb http://archive.ubuntu.com/ubuntu karmic main restricted universe multiverse"
[14:41] <BlackZ> lfaraone: oh true, that was a my fault :p
[15:18] <shadeslayer> yay... i finally have a chroot :P
[16:01] <Laibsch> git-buildpackage in lucid currently does not handle dpkg v3 which I guess is a pretty serious thing.  The version in testing and unstable does.  I think there is a minimal patch available that could be backported to the lucid package but I wonder if it isn't better to still try a merge instead.  Opinions?
[16:01]  * Laibsch is afraid we may end up backporting just about everything
[16:05] <hyperair> Laibsch: which feature of v3 doesn't it support?
[16:05] <hyperair> Laibsch: file a FFe
[16:05] <Laibsch> just about everything in v3 ;-)
[16:05] <Laibsch> support was only added 0.4.64
[16:05] <hyperair> Laibsch: oh yeah? i've got v3 packages maintained in git-buildpackage.
[16:05] <Laibsch> (see the changelog)
[16:06] <hyperair> i mean maintained using git-buildpackage.
[16:06] <hyperair> the only thing that doesn't work is multi-tarball
[16:06] <hyperair> everything else works.
[16:06] <Laibsch> Have you tried git-import-dsc?
[16:06] <hyperair> no.
[16:06] <Laibsch> try it ;-)
[16:06] <hyperair> but that's git import-dsc
[16:06] <hyperair> not git buildpackage
[16:06] <hyperair> they're different tools, in the same suiet
[16:06] <hyperair> suite*
[16:07]  * Laibsch points to http://packages.debian.org/changelogs/pool/main/g/git-buildpackage/git-buildpackage_0.4.65/changelog (entry for 0.4.64)
[16:07] <hyperair> Laibsch: and you said that it doesn't support anything in v3, which i disproved >_>
[16:07] <Laibsch> hyperair: you want to split hairs or fix bugs?
[16:07] <hyperair> hmph.
[16:07] <hyperair> i said file an FFe, didn't i?
[16:08] <Laibsch> I was mixing packages (git-buildpackage package) and tools (git-import-*), my apologies
[16:08] <Laibsch> but look at the changelog
[16:08] <hyperair> when i asked what didn't it support, i really meant what new things does the debian version mean?
[16:08] <Laibsch> and trust me, I ran into this problem
[16:08] <Laibsch> the question remains whether to backport patches or merge 0.4.65
[16:09] <hyperair> merge it.
[16:09] <Laibsch> OK
[16:09] <hyperair> you'd probably end up backporting every thing anyway
[16:09] <Laibsch> Hehe
[16:09] <hyperair> and you'll still need a FFe anyway
[16:09] <Laibsch> I was sort of thinking the same thing
[16:09] <Laibsch> about backporting everything
[16:09] <Laibsch> thanks
[16:10] <hyperair> what's the ubuntu delta anyway?
[16:10]  * Laibsch hasn't done a merge for at least a year or so
[16:10] <hyperair> anything we can't shove upstream?
[16:10] <Laibsch> not much
[16:10] <Laibsch> yes, ubuntu-specific
[16:10] <hyperair> i see.
[16:11] <Laibsch> http://launchpadlibrarian.net/39095621/git-buildpackage_0.4.63_0.4.63ubuntu1.diff.gz
[16:11] <Laibsch> that's the Ubuntu delta
[16:11] <Laibsch> but easy to merge
[16:11] <hyperair> thanks
[16:11] <hyperair> ah i see
[16:12] <Laibsch> Can I merge something that's not on merges.ubuntu.com, yet?
[16:12] <hyperair> yes.
[16:12] <hyperair> use git
[16:12] <hyperair> you're a git-buildpackage user aren't you?
[16:12] <hyperair> just use git merge
[16:12] <Laibsch> well, there is no lucid branch
[16:12] <Laibsch> nothing to merge
[16:13] <hyperair> git import-dsc ;-)
[16:13] <Laibsch> Oh, I see
[16:13] <Laibsch> Exactly
[16:13] <Laibsch> of course ;-)
[16:13] <hyperair> =p
[16:13] <Laibsch> does Ubuntu provide git branches by now?
[16:13] <Laibsch> or still only bazar?
[16:14] <Laibsch> s/Ubuntu/Launchpad or Soyuz or whatever it's called/
[16:16] <Laibsch> I think we need something like git.ubuntu.com, the same as git.debian.org (which I'm a heavy user of)
[16:21] <shadeslayer> Laibsch: hehe
[16:21] <shadeslayer> Laibsch: i would *love* that
[16:21] <Laibsch> I guess you and me are not the only one
[16:21] <Laibsch> Who can we bug about it?
[16:22] <shadeslayer> Laibsch: hmm
[16:23] <shadeslayer> Laibsch: well well have to either put it up on brainstorm
[16:23] <shadeslayer> ( where itll probably be never looked at :P )
[16:27] <Laibsch> I'd prefer a person to talk to in this case
[16:28] <Laibsch> The obvious reason it hasn't happened is bzr
[16:28] <Laibsch> But I wonder how long Canonical wants to ride on that horse
[16:39] <geser> Laibsch: have you read the discussion on ubuntu-devel ml? https://lists.ubuntu.com/archives/ubuntu-devel/2009-December/029776.html
[16:39] <geser> Laibsch: why should Canonical switch to git when they pay the bzr developers and redo all parts where bzr is involved?
[16:40] <Laibsch> Thanks for the link
[16:40] <Laibsch> I'll have a look
[16:40] <Laibsch> I'd turn that question around
[16:41] <Laibsch> Why should Canonical spend money now that there is git?  I know the situation was still different when bzr got started.
[16:41]  * Laibsch goes reading
[16:41] <oojah> Laibsch: Haven't you answered your own question?
[16:41] <Laibsch> nope
[16:42] <Laibsch> unless, the answer is "legacy", but Canonical intends to phase out bzr
[16:42] <Laibsch> and I haven't heard anything to that effect, yet
[16:42]  * Laibsch goes back to reading
[16:49] <hyperair> Laibsch: canonical intends to phase out bzr?
[16:50] <hyperair> where did you hear that from?
[16:50] <Laibsch> man unless
[16:50] <Laibsch> ;-)
[16:50] <Laibsch> read again
[16:51] <hyperair> Laibsch: i still don't quite see it >_>
[16:52] <oojah> hyperair: Remove the commas and replace "but" with "and".
[16:53] <hyperair> oojah: ah!
[16:53] <oojah> (I presume)
[16:53] <hyperair> sorry, the fuzzy level of my language parser drops drastically at wee hours
[16:54] <oojah> It was confusing :)
[16:54] <hyperair> i still have to walk back to my hostel
[16:54]  * hyperair sighs
[16:54] <ivoks> does someone knows; are there plans to build ffmpeg with support for h264?
[16:54] <ivoks> in multiverse, of course
[16:56] <geser> siretart: ^^
[17:21] <om26er> when a package is being uploaded to universe for the first time should Its changelog be changed? (except for 'initial release')
[17:22] <persia> om26er: How do you mean changed?  If there was prior changelog for some reason, that might be interesting, but might not.  If you mean on changelog creation, I usually note any patches as well as Initial Release, just so there is a referent if I mention the patches in later changelog entries.
[17:54] <lightnin> Hello! Is there a debhelper script to autogenerate postrm / postinst (and register application / filetype, etc.?)
[17:57] <persia> lightnin: Many of the debhelper scripts generate maintainer script fragments.  What precisely are you trying to accomplish?
[17:59] <lightnin> persia: Ah! Good to see you again :)
[18:00] <lightnin> persia: Register .sb files as associated with scratch. Add scratch to menu system. Install icons.
[18:02] <persia> lightnin: In reverse order: to install icons, stick them in the directories from which the icon cache is drawn.  There are two ways to add to the menu system: please use both a Debian menu file, and an XDG .desktop file.  To associate .sb files, define a MIME type, and register scratch as a handler for that MIME type in a .desktop file.
[18:05] <lightnin> persia: ok - thanks! Will look into. In terms of "Section" in control field, what would you recommend? Scratch is a free programming language for kids... I don't see an educational section though.
[18:08] <persia> lightnin: Debian menu documentation is available from the menu package.  The freedesktop stuff (MIME registration, .desktop files, icon-cache, etc. are on freedesktop.org)
[18:08] <persia> lightnin: For Section, I'd probably pick "interpreters", if I understand scratch correctly.
[18:15] <shtylman_> so I have questions about the mysql packages and the dependency chain
[18:15] <shtylman_> http://packages.ubuntu.com/lucid/libmysql++-dev
[18:15] <shtylman_> that says it depends on libmysqlclient-dev
[18:15] <shtylman_> http://packages.ubuntu.com/lucid/libmysqlclient-dev
[18:15] <persia> shtylman_: You probably want to ask in -devel or -server , although someone here might know.
[18:16] <persia> And note that packages.ubuntu.com 1) is often out of date, and 2) provides a limited view into the packaging database.
[18:16] <persia> The tools in dctrl-tools are a bit richer, as is apt-cache if you have a chroot or install.
[18:17] <shtylman_> the problem I have is that libmysqlclient16 also gets pulled in
[18:18] <persia> OK.  How is this a problem?  Is a library not required to build against it?
[18:36] <fabrice_sp> it seems the problem is because mysql 5.0 conflicts with mysql5.1: mysql5.1 provide libmysqlclient15-dev as a virtual package, to ease the migration from 5.0 to 5.1, but mysql 5.0 provide it as real, so even rebuilding package is not enought
[18:37] <fabrice_sp> anyone know if its planned to remove mysql5.0? Or we should change the 77 packages that still depends on libmysqlclient16-dev ?
[18:37] <fabrice_sp> s/libmysqlclient16-dev/libmysqlclient15off/
[18:38] <fabrice_sp> this transition sould be solved by deleting libmysqlclient15-dev
[18:38] <fabrice_sp> bbl
[19:04] <hyperair> dh_desktop(deprecated), dh_installmime?
[19:08] <persia> hyperair: Those do entirely different things :)  But dh_desktop is deprecated because it's been entirely replaced with a cleaner implementation in a trigger.
[19:08] <hyperair> persia: i know. but lightnin asked for two things, i.e. register application and filetype.
[19:09] <persia> Right, but in XDG environments, one actually registers MIME types with .desktop files, that are processed by the trigger that replaces dh_desktop.
[19:09] <persia> dh_installmime does something entirely different.
[19:10] <persia> (and we have lousy support for that MIME handler in Ubuntu due to ignorance and neglect)
[19:11] <hyperair> ah i see. the whole mime type handling thing is something that has always kind of eluded me, since i didn't need to do anything.
[19:11] <hyperair> the upstreams generally appear to do it themselves.
[19:12] <hyperair> anyway dh_installmime is for adding support for new mime types, right?
[19:13] <persia> Not precisely.
[19:14] <hyperair> er basically registering that new mime types exist?
[19:14] <persia> No.  I was trying to find some docs, but I'm failing.
[19:14] <persia> Anyway, Debian has a mime-support system, that has a central registry of MIME types for use by applications.
[19:14] <fabrice_sp> Squeeze will have only mysql-5.1 but Lucid has both mysql 5.0 and mysql5.1. Shall request the removal of mysql 5.0?
[19:15] <persia> There's an entirely separate XDG MIME DB.
[19:15] <hyperair> ah i see
[19:15] <persia> Our primary environments prefer entries in the XDG DB over the Debian system, and we haven't historically paid enough attention to make sure everything works with mime-support.
[19:16] <hyperair> i see
[19:16] <hyperair> so dh_installmime is kinda like dh_installmenu in that sense
[19:16] <hyperair> in the sense that it's debian-specific i mean
[19:16] <persia> fabrice_sp: Check first with the #ubuntu-server folk, but I don't see why not (although someone might complain and block the removal request).
[19:16] <fabrice_sp> will do. Thanks persia!
[19:17] <persia> hyperair: Yes, which doesn't mean it doesn't do useful stuff, and doesn't mean our users won't be happy to use it, but does mean that it's different.
[19:17]  * hyperair finally understands
[20:13] <siretart> geser: sorry? ffmpeg supports h264 even in main
[22:21] <Migi32> Hope this is the right place to ask. I'm a dev of an open-source game that's in the official Ubuntu repo's. We're about to release a new version, but I don't have a clue how to get the .deb in these repo's updated. Ideas?
[22:27] <Migi32> I know how to build a .deb, I just don't know how to get it updated in the repo's
[22:27] <persia> Migi32: Last week, the procedure was roughly "Tell us about it".
[22:27] <persia> We're now in FeatureFreeze, so an update would require a freeze exception.
[22:27] <persia> we don't upload .deb files: we only upload sources, and the launchpad buildds generate the .deb files.
[22:28] <persia> So, which game?
[22:28] <Migi32> Globulation 2
[22:28] <Migi32> this game is not shipped by default, so why is there a feature freeze on it?
[22:29] <persia> OK.  So, the best way to get that updated is to work with the pkg-games team to get the source updated in Debian, and then file a FeatureFreeeze exception detailing how much better this version is than the last, an sync the source from the Debian repository.
[22:29] <persia> There's a freeze on the entire archive: we do this to have some time to try to make sure everything works together.
[22:29] <Migi32> how long does it last?
[22:30] <persia> In the case of a game that has no packages that depend on it, and does not require any new versions of any libraries, it ought be fairly easy to get it approved.
[22:30] <persia> The freeze is from now until release (in late April), when we start pulling new versions of everything for our next release.
[22:31] <cjwatson> the closer to release we are, the harder it is to get exceptions.  early on (like now) it tends to be "have you actually thought about this?  ok."
[22:31] <kreuter> hello again, #ubuntu-motu.  am I correct that the only way to run a service as a non-root user under upstart is to have the upstart init script invoke something like a SysV init script?
[22:32] <Migi32> so from now until late April "apt-get update" will only get me feature-freeze exception?
[22:32] <Migi32> exceptions*
[22:32] <cjwatson> Migi32: and bug fixes, which don't come under feature freeze
[22:32] <Migi32> ah
[22:32] <Migi32> I thought this feature freeze was only for things that shipped with the Ubuntu CD
[22:33] <cjwatson> kreuter: the mechanisms for dropping to non-root privileges in upstart jobs are exactly the same as those in init scripts
[22:33] <kreuter> cjwatson: so I could invoke start-stop-daemon in the upstart script?
[22:33] <persia> Migi32: No, it's for everything.  Otherwise we'd end up with all sorts of bugs in the rest of the archive.
[22:33] <kreuter> (that's how I've run things in sysv init scripts)
[22:33] <cjwatson> kreuter: i.e. use start-stop-daemon (note that it can change user without actually starting a daemon process; read its manual page) if you don't need a PAM session; if you need a PAM session, ask an expert :)
[22:33] <persia> Migi32: Your software might be perfect, but I'm sure you've encountered some that isn't :)
[22:34] <Migi32> emm... it's not perfect :)
[22:34] <cjwatson> kreuter: upstart replaces most uses of start-stop-daemon, but not this one
[22:34] <kreuter> cjwatson: thanks!
[22:34] <Migi32> but nothing depends upon it. It's just a game
[22:34] <cjwatson> Migi32: it's more the other way round, we have to be careful that your game is depending on the same sets of libraries as everything else, etc.
[22:35] <cjwatson> Migi32: anyway, being a game doesn't excuse a package from feature freeze, but it does mean that getting an exception is not likely to be difficult
[22:35] <cjwatson> somebody will need to ask rather than Just Uploading It, that's all
[22:36] <Migi32> we were actually planning to release on friday, to get a weekend of busy servers full of people who got the announcement mail, but are you saying the sooner we release the higher the chances we get our updated .deb in the repo's?
[22:36] <cjwatson> (and I know that two months seems like a long time for that kind of thing, but imagine doing this for ten thousand packages)
[22:36] <cjwatson> days won't make a noticeable difference
[22:36] <persia> Migi32: But, as importantly, the team that maintains Gobulation 2 in Ubuntu also maintains it in Debian, and would certainly prefer to upload to Debian and pull to Ubuntu to make sure it's the same version, because there's no good way to pull from Ubuntu into Debian.
[22:37] <cjwatson> kreuter: oh, the other thing that sometimes makes sense is to modify the service itself to drop privileges, rather than doing it at the upstart job or init script level
[22:38] <Migi32> ah ok, I think I got it. Where do I contact this Debian pkg-games team?
[22:39] <superm1> kreuter, i actually did something like what cjwatson is suggesting for mythtv-backend recently if you want some pointers on how to have the app drop it's permissions: http://svn.mythtv.org/trac/changeset/23521/trunk/mythtv/programs/mythbackend/main.cpp
[22:39] <persia> Migi32: Our mailing list is debian-devel-games@lists.debian.org : I've not worked with globulation 2 before, so I'm not 100% confident with the update, when I know there are people with greater familiarity.
[22:39] <persia> But if nobody else gets back with a response in a few days, I'll see how I can help.
[22:41] <Migi32> ok I'll mail to them. And where do I file a FeatureFreeze exception request,
[22:41] <Migi32> ?
[22:42] <blueyed> channel topic is cut at the end?!
[22:42] <Migi32> nevermind it's on the wiki
[22:42] <persia> Migi32: You'd file a bug on the glob2 package in launchpad.  We tend to watch games updates fairly closely, so we should be able to do this shortly after the upload in Debian.
[22:43] <persia> blueyed: Unfortunately, the topic got stuck, and fixing it needs help :(
[22:43] <blueyed> what's that alternative to MoM again? (MoM does not have miro)
[22:43] <persia> people.ubuntuwire.com/~lucas/merges.html I think
[22:44] <cjwatson> superm1: pedantry: for 100% revocation you should run setgroups before setgid
[22:44] <blueyed> thanks, persia
[22:44] <cjwatson> just in case root has some supplementary groups for some reason
[22:44] <Migi32> thanks persia for all your help :)
[22:45] <cjwatson> blueyed: does not have miro> is MoM stuck again or something?
[22:45] <persia> Migi32: Thanks for letting us know when you're doing a release.  Close coordination helps us all to deliver the latest and greatest to the users :)
[22:45] <cjwatson> oh, no, it's just that MoM operates relative to testing not unstable
[22:45] <geser> blueyed: you want to merge the version from unstable, right? MoM is tracking testing
[22:46] <cjwatson> I'd hope that lucas' page does the same
[22:46] <blueyed> oh.. has that been the case for like always?!
[22:46] <blueyed> yes, it does.
[22:46] <geser> blueyed: if 'always' == 'for lucid' then yes
[22:46] <persia> lucas's page is tracking testing.
[22:46] <blueyed> thanks.. I'll just wait then..
[22:46] <superm1> cjwatson, hmm. thanks.  i'll make a note to improve that and send it back their way
[22:46] <persia> blueyed: Tracking testing is new for lucid: I don't know if it's decided if we go back to sid for lucid+1
[22:47] <cjwatson> persia: I believe that is the understanding
[22:47] <cjwatson> it's OK to manually pull something from unstable if you know what you're doing and are following bugs on the package closely (both Debian and Ubuntu)
[22:47] <cjwatson> we're just trying to reduce problems for the bulk of packages
[22:47] <blueyed> oh.. so for LTS we track testing and otherwise unstable? maybe this should depend more on where in the dev cycle we currently are.. but ok.
[22:48] <cjwatson> there's no value doing it at an intra-cycle level - once you pull everything in from unstable at the start of a cycle, most of the damage you're going to do is done.
[22:48] <persia> blueyed: Changing the rules based on timing is tricky: even with the current all-testing-all-the-time model we've ended up with some stuff that is RCbuggy
[22:49] <persia> Switching at some point would only preserve already uploaded bugs, while not getting updates.
[22:50] <cjwatson> it's an experiment for this LTS; we'll decide whether to carry on like this for next LTS (or in general, I suppose, but I think more likely for next LTS) based on whether it seems to have been successful
[22:50] <geser> does someone remember what was the proper replacement for build-depending on "locales-all"?
[22:50] <cjwatson> depends.  what does your package actually need?
[22:51] <blueyed> If I understand correctly, it has not entered testing because of build failured on mips?! (http://qa.debian.org/excuses.php?package=miro)
[22:51] <geser> that I don't know yet, I've just seen that it's in DEPWAIT because of locales-all
[22:51] <blueyed> cjwatson: makes sense re LTS. good to know. Thanks.
[22:51] <cjwatson> figure that out first - the replacement will differ depending on the answer
[22:51] <huats> If I need to do a rebuild without a change (to build against a new lib version), a package that was in sync with debian, do I use the ubuntu1 suffix or build1 ?
[22:51] <cjwatson> mips> seems plausible, it's a Debian release arch
[22:52] <cjwatson> huats: build1
[22:52] <huats> cjwatson, thanks
[23:55] <lightnin1> persia: Got a minute?