[00:56] <kklimonda> Sarvatt: maybe you should make ubuntu-desktop depend on modaliases? most people get wary when they notice it's being removed.
[03:32] <micahg> persia: ping
[04:44] <aalex> Hello. Can my package get into Lucid? I would really like it to be in the current LTS for the next 2 years.
[04:45] <aalex> It's called scenic. It's on a PPA: http://launchpad.net/~sat-metalab/+archive/metalab/+packages
[04:45] <aalex> It's a high-quality audio-video-MIDI bidirectional streaming software
[04:45] <crimsun> no, you can't. Lucid frozen over a month ago.
[04:46] <crimsun> froze *
[04:46] <aalex> Even in the Universe?
[04:46] <crimsun> yes, even.
[04:46] <crimsun> the *entire* archive.
[04:46] <micahg> aalex: if you get it in maverick, you can add get it added to -backports if it doesn't need any other new dependencies
[04:46] <aalex> Ok then. If it's on Debian testing before June 24th it should be in Maverick?
[04:47] <crimsun> unstable.
[04:47] <aalex> micahg, That's very interesting. Way to go.
[04:47] <aalex> crimsun, unstable? even easier! :)
[04:47] <micahg> aalex: https://help.ubuntu.com/community/UbuntuBackports
[04:48] <aalex> Scenic is a desktop application, so that would make sense to backport it.
[04:53] <aalex> Do I have to wait until Maverick is out before to file that bug ? :)
[04:53] <RAOF> There's also going to be a new process for “cool new apps on lucid”, but it's basically a work around for some technical problems in -backports.
[04:54] <aalex> I guess my bug should point to the package in Maverick, so I should at least wait until it's on Ubuntu's web site.
[04:55] <RAOF> Once it's in Maverick you can file the backport bug.
[04:55] <aalex> ok! thanks guys. :)
[05:00] <aalex> Can I already create a pbuilder with maverick as a $DIST? If so, I could build my package right away...
[05:00] <aalex> At least test it.
[05:00] <aalex> Well... it must be only after the 24th. I'm better to get it uploaded to Debian
[05:03] <arand> aalex: Yes maverick is available for pbuilder on lucid, at least.
[05:04] <aalex> arand, cool! :)
[05:07] <mase_wk> hey guys,  i have a git branch which contains my ./debian directory. Is there a) a way to tell lintian to ignore my .git directory as its not included in my debian/rules and b) construct the orig.tar.bz2 automagically ?
[05:11] <RAOF> aalex: And, yes, you're better off trying to get it uploaded to Debain :)
[05:12] <RAOF> mase_wk: You can build your package with git-buildpackage; this can do both.  Although you almost certainly want to also have a .orig.tar.bz2 (or .gz) somewhere public, too.
[05:12] <aalex> There is no tools such as a hg-buildpackage, eh?
[05:12] <RAOF> Actually, I think there is.
[05:13] <RAOF> But it's probably not as well developed as {svn,bzr,git}-buildpackage.
[05:15] <mase_wk> RAOF: ok i'll have a look at git-buildpackage. I don't currently have anywhere that hosts a tar.bz2 and to be honest i don't see much point considering people have access to the entire git repo ,if they want the plain source they can get any revision/ branch they want with git.
[05:15] <RAOF> mase_wk: And is every revision of your software equally useful?
[05:16] <mase_wk> in master yes, or unless i mess up, all of the tags are equally useful.
[05:17] <mase_wk> i'll build stable packages for debian but people will need git for unstable/ experimental
[05:17] <cpscotti> Hey, anyone there from the sru team? Could you check bug 480772 ? I believe the sru is ready for evaluation.
[05:19] <RAOF> It's nice to have publically accessible release tarballs, too; among other things, we have tools which inform us when there's a new release if you've got a well-defined tarball location.
[05:19] <fabrice_sp> cpscotti, a normal sponsor can check your debdiff, test the fix, and upload it to -proposed. After that, the ack from SRU team is required, but not at that point
[05:20] <fabrice_sp> I have the first steps (until upload to -proposed) in my todo list
[05:21] <cpscotti> ahh ok.. thanks fabrice_sp
[05:21] <fabrice_sp> yw ;-)
[05:21] <fabrice_sp> by the way, why the compilation flag is necessary?
[05:21] <cpscotti> (I fixed the issues you pointed.. )
[05:21] <fabrice_sp> cool: I have  more things to do before checking that
[05:22] <cpscotti> fabrice_sp: the new opencv uses c++
[05:22] <fabrice_sp> but I hope to be able to do it this morning
[05:22] <fabrice_sp> ok
[05:22] <cpscotti> fabrice_sp: so when compiling a C program that uses it.. you have two options: g++ or "gcc -x c++"
[05:22] <cpscotti> since the generated programs are indeed just C, we opted for the -x
[05:22] <fabrice_sp> ok: i knew about g++, but not about -x option
[05:23] <fabrice_sp> thanks for the explanation
[05:23] <cpscotti> I didn't know about it also.. but some guy sent it to me by mail and it felt just "right"
[05:24] <cpscotti> fabrice_sp: thanks for the evaluation and all
[05:24] <fabrice_sp> thanks to you for working on it!
[05:24] <cpscotti> have a nice day (I'm going to sleep now.. ehehe)
[05:24] <fabrice_sp> :-) Good night
[05:25] <cpscotti> thanks
[05:25] <cpscotti> bye
[05:25] <mase_wk> RAOF: k, i'll consider that in the future. I found the whole packaging process occupying more time than i really wanted to spend in order to make other peoples lives easier so for now just having a lintian approved .deb is more than adequate. I can make sure that ubuntu /debians version is kept up to date.
[05:34] <RAOF> mase_wk: What about other distributions?  That's another consideration.
[05:36] <mase_wk> RAOF: well i looked at fedora / Suse RPM's and they didn't seem much simpler so it's not something specific to debian. That is next weekends challenge. Slackware tgz's were pretty easy though =)
[05:37] <RAOF> mase_wk: I meant: making it easier for maintainers in other distributions to pick up your app is probably worth a little time, but you'll certainly be overtasked creating packages for *all* distributions.
[05:40] <mase_wk> well fedora and debian are using git now aren't they ? i assumed that by having everything in git, it would make life easier for them, i could accept patches specific to  the debian / fedora branches so they don't have to do much maintenance downstream
[05:41] <mase_wk> and ubuntu gets it's stuff directly from debian no?
[05:41] <RAOF> I'm not sure about Fedora; Debian doesn't have a (traditional) VCS at all.
[05:41] <mase_wk> oh ok
[05:41] <mase_wk> i was under the impression they were moving to git
[05:42] <RAOF> Some Debian maintainers use git, but that's entirely optional, and many use no VCS, many use svn, many use bzr, etc.
[05:43] <RAOF> We're moving to bzr, but slowly.
[05:43] <ScottK> I think Fedora/RH is still using CVS, but I'm not sure.
[05:43] <mase_wk> ScottK: pretty sure they just moved ( or will for next release) to git
[05:44] <ScottK> It wouldn't suprise me.  It's not something I particularly keep up on.
[05:44] <RAOF> I think they *are* planning to move to git, but they were in CVS last time I looked at a package.
[05:45] <mase_wk> just trying to find a way to make life easy for maintainers so they don't have to do much work, but also keep the distro specific stuff upstream so if j-random user wants to make debs/ rpms of a specific tree so that users can test something that they can do it easily enough
[05:48] <mase_wk> i mean, if we fix bugs that should be safe for the LTS releases we can push them into a branch at the time we do it, the maintainers can pull the branch and see exactly what we have changed and why
[05:48] <mase_wk> and theoretically merge with what they already have on the /debian or /fedora branch
[05:49] <RAOF> I tend to just make sure that ./configure --prefix=$HOME/.local does the right thing; that makes it trivial for motivated users to test locally, without breaking anything else.
[05:50] <mase_wk> well the software is not using autotools /make . infact i was disappointed that the debian/rules file had forced me to use make
[05:52] <RAOF> Does whatever build tool you're using have an equivalent feature?
[05:52] <mase_wk> still not sure why, there seems to be a build dep option in the config, so surely as long as the software needed to build the package is also  free software you should be able to use anything you like right?
[05:53] <mase_wk> RAOF: it's basically a clone of apache ANT in python i think
[05:54] <mase_wk> allows easy xslt translation
[05:54] <RAOF> debian/rules is (kinda) defined to be a makefile with specific targets.  It's basically just a simple build-oriented programming language.
[05:54] <mase_wk> i mean the whole make thing isn't a big deal but it meant i needed to duplicate work i'd already done
[05:56] <RAOF> Why?  Surely your build: target would just call your existing buildsystem; that's the intention.
[05:58] <mase_wk> well this maybe my lack of experience showing through, but i did try that , and i couldn't get it to give me any actual content in the package. The files don't need to be compiled, they are essentially just dynamic libraries that need to be copied from one place to another with a config file change.
[05:59] <mase_wk> i ended up having to add a whole bunch of dh_ prefixed utils in order to get it copied over
[05:59] <mase_wk> and even then i was still having trouble with getting the documentation installed.
[06:00] <mase_wk> when i have the files in front of me i'll post to the mailing list with some questions
[06:00] <ScottK> mase_wk: If you use distutils with setup.py, the whole of debian/rules only needs to be three lines.
[06:00] <mase_wk> i'm probably doing a few things wrong.
[06:01] <mase_wk> i ended up grabbing a few 'similar' applications and using lines from the rules file until it worked
[06:02] <mase_wk> ScottK: so if i use distutils can i still use git-buildpackage ?
[06:03] <ScottK> I would think so, but I don't use it, so no promises.
[06:03] <mase_wk> it's not all python. some is just xml files/xslt templates etc..
[06:04] <ScottK> You can install data files with distutils.
[06:05] <mase_wk> ok cool, i'll look into it . It seems everyone has their own way of packaging, I've spoken to a few people in here and everyone seems to recommend something different.
[06:05] <mase_wk> or are all these tools just wrappers around other tools for specific use cases ?
[06:05] <ScottK> There are many ways to do it.
[06:06] <ScottK> Python distuilts is a standard method of making Python distributions, so the Debian packaging tools understand how to use it to make a .deb (essentially).
[06:07] <ScottK> So when you use common upstream build systems in standard ways, it's generally pretty easy to make a sane package.
[06:07] <ScottK> If you use a less common build system, then you need to do more of the work yourself.
[06:08] <mase_wk> well what i'm using is common for people who use xslt alot :)
[06:08] <lifeless> all 2 of them
[06:08] <mase_wk> exactly
[06:09] <mase_wk> i has a very small use case
[06:17] <mase_wk> anyhoo thank you all for your help.
[08:15] <dholbach> good morning
[08:47] <tarzeau> good morning
[10:29] <Laney> urgh
[10:29] <Laney> anyone fancy uploading some no-change rebuilds?
[10:30] <Laney> http://orangesquash.org.uk/~laney/haskell-installability/armel.png — start at the top
[10:41] <kklimonda> Laney: lol?
[10:42] <kklimonda> Laney: is haskell really that bad at keeping stable abi (or whatever it's supposed to be keeping stable ;) )
[10:43] <Laney> they make no guarantees
[10:43] <Laney> :(
[10:44] <kklimonda> how do you generate this graph?
[10:45] <kklimonda> debtree |dot.. something creates uglier one
[10:45] <kklimonda> this one is actually readable
[10:45] <kklimonda> well, as readable as it can be
[10:47] <Laney> parsing the sources file from the archive
[11:04] <suji>  when i setup chroot for lucid in jaunty system i got this error http://ubuntu.pastebin.com/P1h34QsJ
[11:17] <siretart> hm. anyone knows what's wrong with maverick's libdirectfb-dev?
[11:32] <sebner> jdong: willing to ack a SRU?
[12:16] <om26er> patches are not applied during build process (debian/rules contain: http://pastebin.org/283067) what am I doing wrong?
[12:21] <om26er> my bad seems like I was making a mistake.. now the patch was applied.
[12:24]  * ricotz hopes sebner is talking about docky ;-)
[12:25] <sebner> heh
[12:25] <sebner> ricotz: indeed
[12:26] <ricotz> sebner, good :)
[12:33] <sebner> ricotz: I'm annoyed that you still can't place the system icons on the right freely, even though I saw a bzr commit about it once
[12:36] <ricotz> sebner, our docky icon will stay there, but if you don't like it you can turn it off in gconf
[12:37] <sebner> ricotz: nah, I mean the built-in stuff on the right like "Show Desktop", Trash etc
[12:37] <ricotz> sebner, we don't expose all setting-options to have a clean and simple preferences window
[12:38] <ricotz> sebner, ah sorry, you can file a wishlist bug, i think there isnt one yet
[12:39] <sebner> ricotz: so I was wrong? I thought I saw a bzr commit about it, that's not wishlist then :P
[12:41] <ricotz> sebner, you want to be able to put docklets on the left of the starter-window-manager
[12:41] <sebner> ricotz: not even that, just put around icons on the right side
[12:44] <ricotz> sebner, please file a bug and describe what you have in mind
[12:45] <ricotz> sebner, you want to rearrange their order with dnd?
[12:46] <sebner> ricotz: exactly, sorry for explaining it that bad
[12:47] <ricotz> sebner, this isnt possible, and there is a bug regarding this feature
[12:47] <ricotz> sebner, you can move them in docklet tab of the preferences window if you use the ppa version
[12:48] <sebner> ricotz: why isn't it possible? It's possible to configure the order in the settings, why not dnd
[12:48] <ricotz> sebner, this is a more code-design problem
[12:48] <sebner> ricotz: BUUGGGGG! :P
[12:49] <ricotz> yeah, i got it
[12:49] <sebner> ricotz: really weird though, it works on the "left" side with normal icons but not on the right side, wth is the code-design?
[12:50] <ricotz> sebner, you can move item inside a "container" but you can't move a container
[12:51] <sebner> ricotz: why don't make the right side a container itself?
[12:52] <ricotz> sebner, goto #docky
[12:52] <sebner> ricotz: right, pretty much OT
[13:44] <DeeJay1> hmm, where can I find debug symbols for /usr/lib/libexpat.so.1 ?
[13:46] <JontheEchidna> !find /usr/lib/libexpat.so.1
[13:46] <JontheEchidna> Perhaps there's a libexpat1-dbgsym package in the ddeb repo?
[13:48] <JontheEchidna> https://wiki.kubuntu.org/DebuggingProgramCrash
[13:49] <JontheEchidna> If it's not in the ddebs repo, then I'd say that you'd probably have to compile expat yourself
[13:51] <DeeJay1> ah, thanks
[13:51] <DeeJay1> looks like I'd have to compile it :/
[13:54] <geser> DeeJay1: which package version of libexpat1?
[13:56] <geser> DeeJay1: http://ddebs.ubuntu.com/pool/main/e/expat/ contains the ddebs for libexpat1
[14:03] <DeeJay1> no sparc ;)
[14:22] <jcastro> ScottK: ok so at the session the idea was to how to grow the -server channel for contributors, but we realized that the server community is too small, so splitting the channel didn't make sense
[14:22] <jcastro> ScottK: oops, wrong channel, sigh
[14:44] <bilalakhtar> My package gnome-media-player was uploaded to the universe 2 weeks ago. Now, it has been built and the binaries have cleared the new queue. The package closes a needs-packaging bug. But still it is not set to "Fix Released" When will it happen? Or will I have to set it?
[14:46] <JontheEchidna> bilalakhtar: For new packages, you will have to close the needs-packaging bug manually
[14:46] <bilalakhtar> JontheEchidna: oh
[14:47] <JontheEchidna> bilalakhtar: Since the needs-packaging bug isn't filed against a package, LP won't close the bug via the changelog file of the package, basically.
[14:47] <bilalakhtar> ok, got it,
[15:13] <ScottK> Which sort of highlights the pointlessness of needs-packaging bugs.
[15:15] <Rhonda> Hmmm, ITP bugs in the Debian BTS work. :)
[15:17] <sommer> is there a great package to use a debconf example?
[15:28] <ScottK> Rhonda: They do, but Debian works on a different scale.  Here you can pretty much look on REVU and see if the package you are interested in is there.
[15:31] <Rhonda> ScottK: here you can pretty much look on mentors and see if the package you are interested in is there?  ;)
[15:31] <Rhonda> Granted, mentors isn't as incorporated.
[15:31] <ScottK> Also DDs rarely upload their new packages to mentors for peer review.
[15:32] <Rhonda> Because any place is as good as :)
[15:33] <Rhonda> ScottK: No, we use experimental for that. ;)
[16:03] <solarion> anyone have recommendations on how to easily image a bunch (~100) of identical USB keys?
[16:03] <Rhonda> Get a huge usb hub
[16:38] <jariq> Does anyone have an idea how to make dh_fixperms work on files in /opt ???
[16:41] <azeem> jariq: why do you ship files in /opt?
[16:41] <azop> haha
[16:41] <azop> Rhonda: nice
[16:43] <jariq> azeem: I've seen that a lot of commercial software products ship files in /opt
[16:43] <azeem> that doesn't make it right
[16:43] <azop> azeem: but Google does it(!*@ :P
[16:46] <jariq> azeem: lintian also complains about files in /opt so you are most likely right
[16:47] <azeem> heh
[16:47] <azeem> jariq: I assumed you knew what you are doing and was trying to troll your usage of /opt
[16:47] <jariq> but does that mean debhelper and dh_fixperms cannot be used for creation of such package?
[16:48] <azeem> well, you'll have to fixup /opt yourself I guess
[16:48] <azeem> proper Debian packages are not allowed to ship stuff in /opt (except maybe for empty directories)
[16:49] <ScottK> The point of /opt is exactly for commerical stuff.
[16:49] <sommer> is there a way to determine package name in postinst?
[16:49] <azeem> ScottK: where commercial == too crappy to be submitted to policy
[16:50] <ScottK> For stuff you have to ship binary only, keeping vendor based namespace separation in /opt is not an unreasonable thing to do.
[16:51] <jariq> ScottK: that is exactly what I am trying to achieve
[16:51] <azeem> I still don't see the point, I think /opt should be left for manually installed stuff (or crappy installers)
[16:51] <azeem> but anyway
[16:51] <ScottK> jariq: If you want examples, look in Canonical's parter repository.
[16:51] <jariq> and I wanted to use debhelper the same way as I am using it for creation of my packages in universe
[16:53] <jariq> so I'll have to fix permissions manually.. crap :(
[17:00] <jariq> Is there any other easy way (other than dh_fixperms) for setting permissions? Something similar to *.install files..
[17:01] <azeem> chmod
[17:06] <jariq> azeem: i wanted to avoid calling chmod and chown directly but it seems to be the only way
[17:07] <azeem> maybe you can convince Canonical to patch some "Canonical Partner" mode into debhelper, which supports /opt ;)
[17:08] <virtuald> why not /vendor or /service while you're at it :p
[17:14] <jariq> thx for advice :) i will look closer at the terms and benefits of partnership
[17:16] <ari-tczew> can we sync new package manually if it will fix FTBFS for other packages?
[17:17] <ScottK> ari-tczew: There's no rush.  Just file the sync bug.
[17:25] <blueyed> andreserl: re etckeeper package: you have changed the version in the etckeeper spec file to match the ubuntu version. Can't this get automated? is the .spec file required after all - except to have the complete source in the source package?
[17:26] <micahg> blueyed: miro moving to webkit \o/
[17:27] <blueyed> micahg: nice. everybody finally follows konqueror ;)
[17:27] <andreserl> blueyed, huh?
[17:28] <blueyed> andreserl: /me talking about your merge 0.41ubuntu1 (etckeeper)
[17:28] <micahg> blueyed: one less thing to port fwd every/every other cycle :)
[17:29] <RoAkSoAx> blueyed: oh i see. IDK if this can get automated actually. Let me check first
[17:31] <RoAkSoAx> blueyed: Ok I now remember. I just updated the version since it already had an Ubuntu version. I just updated it to match the current at the time
[17:32] <blueyed> oh, I see. Do you see a way to change it automatically (for Ubuntu)?
[17:33] <blueyed> the Makefile handles it already.
[17:34] <RoAkSoAx> blueyed: IDK actually fi there's a way to do it automatically
[17:34] <blueyed> "make etckeeper.spec" should do it, though still needs manual invocation.
[17:34] <blueyed> ok, thx.
[18:35] <sommer> so I have a source package with multiple packages... is there a way to have one postinst that will adjust paths based on package?
[18:37] <sommer> if not is there a "lib" or some such file where I can place shared postinst code
[19:00] <ScottK> sommer: What specifically are you trying to install?
[19:00] <ScottK> install/accomplish
[19:01] <sommer> ScottK: creating an openldap-dit-core, openldap-dit-usersandgroups package... they have basically the same postinst and I was looking for a way of not creating openldap-dit-core.postinst, openldap-dit-usersandgroups.postinst, etgc
[19:02] <ScottK> sommer: The common way to do this is create a common core postinst and then a postinst.in for each binary and generate them at build time.
[19:02] <ScottK> clamav does this and I'm sure others do to.
[19:03] <sommer> ScottK: ah, I'll take a look at that.  thanks
[19:21] <ari-tczew> geser, persia: what about approve me to universe-contributors?
[19:37] <Riddell> fabrice_sp: ping
[19:38] <Riddell> fabrice_sp: you say "No need to " on lastfm on MoM, what's that about?
[19:38] <Riddell> (and how do comments get added anyway?)
[19:39] <kklimonda> Riddell: you can just click on a comment row and type a comment in, then press enter
[21:13] <Rhonda> azop: nice what? :)
[21:14] <fabrice_sp> Riddell, this is an old comments  (from Karmic or Lucid cycle)
[21:21] <fabrice_sp> I've deleted it
[21:21] <BlackZ> fabrice_sp: fixed the patch for librack-ruby, could you take a look?
[21:27] <fabrice_sp> bug number ?
[21:27] <fabrice_sp> (I'm too tired to look after it right now, but will check tomorrow morning)
[21:28] <fabrice_sp> bye
[21:31] <BlackZ> fabrice_sp: #533799
[23:43] <zimio> I have problems....
[23:43] <zimio> making a package