[01:20] <lfaraone> james_w: hm. I'm trying to merge via https://code.edge.launchpad.net/~lfaraone/ubuntu/karmic/etoys/lp301190/+register-merge into lp:ubuntu/karmic-proposed/etoys, and it's not a branch. What path should I give it?
[03:59] <MTecknology> Where did gnome-volume-manager go in lucid?
[04:01] <micahg> MTecknology: (Reason:          obsolete, gvfs/nautilus do that now, and ivman is a more ...)
[04:04] <MTecknology> micahg: thanks
[04:06] <MTecknology> micahg: http://dpaste.com/184401/ :(
[04:07] <micahg> MTecknology: you might not have hal installed as it was dropped from Ubuntu, idk about Kubuntu, but Xubuntu still uses parts of it
[04:07] <MTecknology> micahg: i A hal                                                                                - Hardware Abstraction Laye
[04:08] <micahg> MTecknology: try aptitude why-not halevt
[04:09] <MTecknology> Unable to find a reason to remove halevt.
[04:09] <MTecknology> micahg: that's a really neat trick :p
[04:09]  * micahg is out of ideas :-/
[04:10] <micahg> MTecknology: 1 more...try sudo aptitude install halevt
[04:10] <MTecknology> micahg: that's what got me to that error
[04:10] <micahg> MTecknology: do you want this package?
[04:11] <MTecknology> micahg: I think I do, I'm trying to magically mount a device in /media when plugged in - no nautilus
[04:11] <micahg> MTecknology: hal wouldn'
[04:11] <micahg> t be the way to do it in lucid
[04:12] <MTecknology> micahg: I thought I needed halevt for ivman..
[04:12] <MTecknology> oops
[04:13] <MTecknology> micahg: so what's the right way to do it if I don't want nautilus to deal wiht most of it?
[04:14] <micahg> MTecknology: idk, I use xubuntu
[04:14] <micahg> MTecknology: does udev handle that?
[04:15] <MTecknology> micahg: I tried having udev running and that didn't seem to help any
[04:16] <micahg> MTecknology: have you seen gnome-disk-utility
[04:18] <MTecknology> micahg: is that a daemon?
[04:18] <micahg> MTecknology: no
[04:18] <micahg> MTecknology: actually, idk
[04:19] <MTecknology> doesn't look like it
[04:19] <MTecknology> gah - I thought this would be extremely simple
[04:20] <MTecknology> pmount seemed to come close
[04:21] <MTecknology> how do you check reverse dependencies of a package?
[04:21] <micahg> MTecknology: have you tried +1 yet?
[04:21] <micahg> MTecknology: apt-cache rdepends PKGNAME
[04:22] <MTecknology> micahg: I'm on Lucid
[04:22] <micahg> MTecknology: I meant the channel :)
[04:22] <MTecknology> oh - ya
[04:24] <MTecknology> there's a usbmount package....
[04:25] <MTecknology> micahg: That seems to do exactly what I want - I think
[04:25] <micahg> MTecknology: cool
[06:41] <wrapster> it it possible to search the repo for a particular file?
[06:42] <wrapster> i mean if i want to know which pkg provides "layout.h" how do i find out?
[06:51] <YokoZar> Can anyone do a sync for me please? https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/555082  (FFE granted already and tested)
[06:52] <imbrandon> wrapster: via the web you can use package.ubuntu.com
[06:52] <imbrandon> wrapster: via the cli use apt-file
[06:53] <wrapster> imbrandon: i tried web. but could not find sys/layout.h
[06:53] <wrapster> need it for compilation purposes..
[06:53] <wrapster> apt-file --> command not found?
[06:56] <imbrandon> wrapster: sudo apt-get install apt-file && sudo apt-file update
[06:56] <wrapster> imbrandon: yes done that.
[06:56] <wrapster> sorry was a little too curious to solve this fast.
[06:56] <wrapster> that is solved.
[06:56] <wrapster> but does layout.h not come in any ubuntu release?
[06:56] <wrapster> i mean sys/layout.h?
[06:57] <wrapster> im trying to compile i18n
[06:58] <wrapster> and the repo does not show anything
[06:58] <imbrandon> what provides the layout.h your looking for
[06:58] <imbrandon> there are lots of layout.h's in the repo
[06:59] <imbrandon> but none are what your looking for i supose
[06:59] <wrapster> thats correct.. Im from solaris background and there its provided by SUNWctpls
[07:00] <imbrandon> then it sounds like a solaris specific api , you might try to find what the linux alternative is
[07:01] <wrapster> yes.. that was my next question.
[07:01] <wrapster> is there a way to figure it out?
[07:01] <imbrandon> automagicly ? no
[07:01] <imbrandon> porting code is far from automagic ;)
[07:02] <wrapster> :(
[07:02]  * Rhonda . o O ( I knew why I wanted wesnoth 1:1.8-1 synced and not wait for 1:1.8-2  *sigh* )
[07:02] <imbrandon> although with that said i'm sure your not the first to want to use a given api , there normaly are alternatives if ya dig a little
[07:03] <imbrandon> e.g. what does layout.h give you ? is it a gui layout ? a fs layout etc etc etc
[07:04] <wrapster> ok.
[08:19] <dholbach> good morning
[08:26] <imbrandon> moins dholbach
[08:27] <dholbach> hi imbrandon
[09:23] <kobrien> anyone got much experience with packaging Java programs?
[09:26] <ScottK> kobrien: You might have more luck in #ubuntu-java
[09:26] <kobrien> i'm trying :(
[09:34] <james_w> lfaraone: lp:ubuntu/karmic/etoys
[10:13] <YokoZar> ScottK: mind if I poke you personally?
[10:14] <ScottK> YokoZar: No
[10:14] <YokoZar> https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/555082  <-- I wanted a sync last night, FFE has been approved for a couple days and tested
[10:14] <YokoZar> Upstream intended this to be the version in Lucid
[10:14] <YokoZar> (and needed for online play and so on)
[10:14] <ScottK> YokoZar: You need an archive admin with shell access
[10:15] <YokoZar> I thought you had that
[10:15] <ScottK> (i.e. employed by Canonical)
[10:15] <YokoZar> ahh ok
[10:15] <ScottK> Nope
[10:15] <YokoZar> ok no wonder it went unanswered
[10:15] <ScottK> Maybe StevenK is in a generous mood.
[10:15] <ScottK> Maybe if you file a removal bug on something that will cheer him up.
[10:16] <StevenK> Not currently, I'm not.
[10:16] <StevenK> Crappy internet makes me grumpy
[10:16] <YokoZar> Isn't that always the case in Australia?
[10:16]  * ScottK thinks you aren't helping
[10:17] <StevenK> YokoZar: You're helping your case, really ...
[10:17] <YokoZar> StevenK: I'll fix Wine's libpng support tomorrow ;)
[10:18] <james_w> YokoZar: doing
[10:18] <YokoZar> james_w: thanks :)
[10:18] <james_w> impugning our good nature is a good way to get immediate action
[10:22] <james_w> done
[10:34] <YokoZar> james_w: Thanks :)
[11:44] <carstenh> there are three serious bugs in ubuntu lucid, two could lead to random packages to be purged when there are multiarch packages in ubuntu (e.g. when users upgrade from lucid to the following LTS release) and renders git repositories unusable when you ran for example tg help in them and deinstalled topgit later.  i guess i need to put lucid in the changelog and append ubuntu1 to the version, correct?  does the urgency matter, if it does, ...
[11:45] <carstenh> ... which urgency do I choose?  where do I ask for sponsoring?  a sponsor oder your buildds would rebuild the package anyway and mountall fails to configure when I try to setup a lucid chroot, so building in sid would be ok?
[11:45] <carstenh> s/renders/one renders/
[11:45] <carstenh> s/oder/or/
[11:46] <persia> The urgency doesn't matter at all (as defined in the changelog).
[11:47] <jpds> (Though it tweaks the build score).
[11:48] <persia> There are two acceptable ways to get an upload sponsored: one is to attach a debdiff to a bug and subscribe ubuntu-sponsors to the bug.  The other is to use bzr for the packaging changes, and submit a merge request against lp:ubuntu/lucid/${package}
[11:48] <persia> jpds: By less than waiting an hour.
[11:48] <persia> So it only really adjusts urgency against other packages uploaded within the same hour.
[11:48] <carstenh> ok, then I will choose neither, thanks for your time
[11:49] <persia> And it's also massively trumped by other modifiers (e.g. components)
[11:49] <persia> carstenh: Why neither?
[11:49] <persia> carstenh: What's the bug?  Is there a bug number?
[11:50] <carstenh> persia: there are bugs in debian (two of three, the other is not filed), but not in launchpad and i don't want to subscribe to weird things
[11:50] <carstenh> and I don't want to fight against bzr to fix bugs
[11:50] <persia> OK.  Which are the Debian bugs?
[11:52] <carstenh> bugs.debian.org/576221 but this bug report is not helpful to understand the problem
[11:52] <carstenh> and bugs.debian.org/539340
[11:53] <persia> Debian bug 539340
[11:53] <persia> debian bug 576221
[11:53] <carstenh> thedebfosterbug also misses a description of the problem
[11:54] <persia> carstenh: For 576221, I think it's relatively easy, but needs a description of the problem.
[11:54] <carstenh> debfoster removes packages which are orphaned, it will think non-orphaned packages would be orphaned if it does not strip :any from package names, deborphan has the same problem.
[11:55] <persia> For 539340: I think we need a patch.
[11:56] <carstenh> persia: a description attached to the debian bug?
[11:56] <persia> carstenh: That would work.  It's more work for us, because we have to copy&paste, but if you have fixes and an allergy to launchpad, we can help get the fixes in.
[12:14] <carstenh> persia: http://stateful.de/~carsten/tmp/100416v9Qgcml9Nyo/file7TRbHF
[12:15] <carstenh> persia: if you tell me the url where i can paste it into launchpad ...
[12:16] <carstenh> i already have an launchpad account
[12:17] <persia> carstenh: It needs a new bug.  If you're up for filing it, that's `ubuntu-bug topgit`
[12:17] <carstenh> i though you did this with this irc magic ;)
[12:17] <carstenh> thought
[12:18] <persia> No.
[12:19] <carstenh> what did you men by "I think we need a patch."?  some kind of nmu-diff?
[12:19] <carstenh> that is a patch against the package including patching debian/changelog
[12:19] <persia> Essentially, yeah.  It's not immediately clear to me from the debfoster bug description precisely what code needs changing.
[12:20] <persia> Doing a full patch including debian/changelog and everything makes it simpler for the uploader.  A targeted patch just fixing the code also works.
[12:21] <carstenh> but a proper diff.gz would not work?
[12:21] <carstenh> and .dsc
[12:22] <persia> Doesn't really matter: just the debdiff saves space on LP, but any format works to represent the changes.
[12:22] <persia> We prefer debdiffs because they transfer quick, generally.
[12:22] <carstenh> debian is a lot less complicated
[12:27] <carstenh> ok, I think I know everything I wanted to know, thanks :)  I'll start reading debfosters source later to find the right place to insert the few lines.
[12:28] <persia> carstenh: Excellent.  Thanks.  Did you file the topgit bug, or shall I?
[12:29] <carstenh> persia: you are more experienced with launchpad :)
[12:29] <persia> Sure, I'll file it then, using your description and patch.
[12:29] <carstenh> what about adding translation updates when fixing serious bugs?
[12:30] <persia> We're past string freeze, so if you need to change a string, you need approval from the docteam.  If it's just a translations update, those are typically welcomed, although it's best practice to check with the translations team.
[12:34] <carstenh> persia: my topgit fix is commited upstream, just in case you need to tag this patch somehow
[12:35] <carstenh> | X-Launchpad-Message-Rationale: Subscriber (deborphan in ubuntu)
[12:36] <carstenh> I got this a year ago, today I saw that there were bugs against deborphan which i never got
[12:36] <carstenh> does lp lose subscriptions?
[12:38] <persia> Shouldn't.
[12:38] <wgrant> carstenh: Nobody is subscribed to deborphan in Ubuntu at the moment.
[12:38]  * persia checks
[12:38] <wgrant> LP doesn't go around deleting them without you telling it to, no.
[12:39] <wgrant> Although there is talk about deleting the full Ubuntu subscriptions and forbidding future ones, source packages shouldn't be touched, and certainly haven't been yet.
[12:40] <persia> carstenh: According to https://bugs.launchpad.net/~heyc you're subscribed to that specific bug, but according to https://bugs.launchpad.net/~heyc/+packagebugs   you aren't subscibed to any packages.
[12:40] <persia> carstenh: If you want deborphan bugs, you can subscribe to them all from https://launchpad.net/ubuntu/+source/deborphan (in the upper left)
[12:51] <carstenh> i registered twice, once years ago and once 2008.  one of these accounts seems to be broken
[12:53] <persia> carstenh: Does bug #564616 (and the attachment) look right to you?
[12:56] <carstenh> persia: you forget to add 2
[12:57] <persia> carstenh: It fails anyway, with that test case.  `git add 2` didn't appear in http://stateful.de/~carsten/tmp/100416v9Qgcml9Nyo/file7TRbHF
[12:57] <carstenh> patch looks good, unless it's 3.0 (quilt)
[12:57] <persia> No, it's 1.0+quilt
[12:58]  * persia uploads
[12:59] <persia> Err, except the topgit maintainers might not like that
[12:59] <carstenh> thanks
[12:59]  * persia fiddles the maintainer
[12:59] <carstenh> madduck
[12:59] <carstenh> responsible via irc
[13:00] <persia> carstenh: Right, but we change the Maintainer field when we diverge from Debian.  I'm hoping that the fix gets into Debian from the patch you already submitted to the BTS.
[13:00] <carstenh> 13:34:30 < carstenh> persia: my topgit fix is commited upstream, just in case you need to tag this patch somehow
[13:01] <persia> I've referenced the BTS patch in the DEP3 header, which is likely enough.
[13:02] <persia> Ideally the patch will be dropped from Ubuntu for the next release anyway.
[13:03] <carstenh> i really don't see a problem here.  madduck forwarded this patch to upstream and he applied it.  after the next git pull it will be in his debian repository
[13:04] <persia> Right, and when we next sync against Debian, I'll get poked to double-check and override the Ubuntu changes.
[13:04] <persia> It ought all just work.
[13:05] <joaopinto> is it possible to force dpkg to set an /etc/file generated on a postinst script as installed from the package ?
[13:05] <james_w> no
[13:06] <joaopinto> ok :( I needed to have a dynamic config file, but it would be nice to have it associated with the creating package
[13:06] <joaopinto> otherwise purge does not clean the config
[13:06] <persia> joaopinto: If you create the script dynamically, you have to clean up after yourself in the maintainer scripts.
[13:06] <persia> joaopinto: Just put the necessary logic in postrm
[13:07] <joaopinto> ok, it would be more elegant if we could have dynamic config associated with the packages
[13:07] <carstenh> joaopinto: apt-cache show ucf
[13:07] <carstenh> (does not solve this problem but should be the package you need)
[13:14] <lfaraone> james_w: mk, I see. I proposed for karmic, jaunty, and intrepid
[14:19] <directhex> isn't having qemu-kvm-extras-static meant to allow "chroot /tmp/somearmchroot" to work?
[14:22] <ogra> directhex, only if you built it with qemu-debootstrap
[14:23] <directhex> ogra, i see. how do i integrate qemu-debootstrap into my pbuilder workflow?
[14:23] <ogra> directhex, if you have some arm chroot that doesnt have qemu-arm-static in it you need to copy it to $chroot/usr/bin/
[14:24] <ogra> directhex, i thought persia did that already
[14:25] <directhex> all the wiki pages are, like, use rootstock, it cures cancer! pbuilder barely gets a mention
[15:34] <geser> directhex, ogra: yes, persia fixed pbuilder-dist from u-d-t to be also able to create arm pbuilders
[15:46] <carstenh> how do use use pbuilder without a debootstrap that includes a lucid script?
[15:48] <geser> either get a backport of debootstrap that knows about lucid or create a karmic pbuilder and dist-upgrade it to lucid
[15:57] <carstenh> i couldn't find a cdebootstrap or debootstrap that supports lucid and the dist-upgrade failed in mountall's maintainerscripts.  but this is nothing that needs to be solved, i was just curious
[15:59] <persia> carstenh: What's your base environment?
[16:00] <carstenh> as i said this does not need to be solved. i checked versions in lenny, sid, karmic and luid
[16:00] <persia> geser: There's still a bug with that which I'm not sure I understand entirely.  It seems that now creating an i386 pbuilder on amd64 uses qemu-debootstrap uselessly.
[16:01] <carstenh> and i normally use lenny + sid chroots
[16:01] <persia> carstenh: Oh, so you have a debootstrap that supports lucid, but it just doesn't work?  I suspect that's archieve skew (we're way behind on buildd time right now, because everyone uploaded stuff at the last minute)
[16:02] <persia> carstenh: creating i386 chroots should always work.  Other architectures may or may not work depending on arch:all/arch:any skew (arch:all is built on i386)
[16:07] <lfaraone> persia: does http://sprunge.us/AKjX read like something that introduces new features?
[16:09] <sistpoty|work> lfaraone: looks bug fix only to me... which package is it out of curiousity?
[16:09] <lfaraone> sistpoty|work: typo3-src.
[16:10] <persia> I'M not the best person to ask about freeze exceptions either :)  That said, I'm unsure about 13252 ("changed behaviour"),
[16:12] <carstenh> persia: no I coudn't find a debootstrap that supports anything later than karmic
[16:12] <lfaraone> carstenh: use pbuilder-dist :)
[16:12] <sistpoty|work> persia, lfaraone: nah, that's a bug fix for sure ;)
[16:13] <lfaraone> persia: mk. looks like they pull out CSS variables from globals rather than hard coding them.
[16:13] <carstenh> lfaraone: how does asking a driver to drive my car help when I have no tires?
[16:14] <lfaraone> carstenh: Well, when I was on karmic, I had no problem passing lucid as the distribution to pbuilder.
[16:14] <lfaraone> sistpoty|work: it's in Universe, so I should just file a sync request rather than a FFe, right?
[16:14] <persia> FFe isn't component-specific: if it's bugfix only, you don't need it.  If it's not, you do.
[16:14] <sistpoty|work> lfaraone: yes. and check if it builds and works and if typo3-dummy also needs to get synced
[16:15] <lfaraone> sistpoty|work: of course.
[16:15] <persia> That said, *every* upload gets manual review right now.
[16:15] <sistpoty|work> :)
[16:15] <sistpoty|work> persia: nope, universe is just shoved through (manually, though)
[16:15] <lfaraone> persia: just asking, I wasn't clear how Final Freeze applies to Universe per se.
[16:16] <sistpoty|work> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-April/000705.html
[16:17] <sistpoty|work> lfaraone: unless on a CD (and unless it would take a week to build), final freeze for universe is at april 26)
[16:28] <carstenh> jtfr: the scripts in the latest debootstrap seem to be alphabetically ordered but aren't ...
[16:37] <lfaraone> sistpoty|work: done, bug 564772
[16:38] <sistpoty|work> excellent!
[17:01] <micahg> ttx: I just got phpmyadmin sync'd so we should be ok
[17:02] <RoAkSoAx> Can we still ask for FFe for packages in Universe?
[17:03] <persia> Absolutely.
[17:03] <RoAkSoAx> till when?
[17:04] <nigelb> faster the better
[17:05] <RoAkSoAx> ok then I'll get to work :)
[17:39] <RoAkSoAx> we can't request FFe for main anymore right?
[17:39] <sistpoty|work> RoAkSoAx: you can always request one, but the chances are next to zero that it'll get approved
[17:41] <RoAkSoAx> sistpoty|work, awesome then. :)
[17:57] <ScottK> Laney: Your docky upload reverts the maintainer change.  I'm going to reject.  Please reupload.
[17:58]  * sistpoty|work heads home now, and will be off until tommorrow.. cya
[18:30] <Laney> ScottK: You really think it needs a reject for that?
[18:30] <ScottK> Laney: If there wasn't time to redo it, I'd have accepted it, but there's plenty of time, so we might as well do it right.
[18:30] <Laney> Actually it was kind of deliberate since it's essentially a sync
[18:31] <Laney> I'll wait for the proper sync in that case
[18:47] <nigelb> bdrung, thanks for taking care of the vlc bug :)
[18:48] <maco> did i just get taken off the hook?
[18:48] <nigelb> maco, I guess so :)
[18:48] <nigelb> ok, so I hadn't even subscribed sponsors
[18:49] <maco> now i have to remember what the *other* packages i started on and didnt finish were the last few days...
[18:49] <maco> i think i surrendered to a new release of pdfsam
[18:49] <nigelb> haha
[18:50] <maco> if anyone who knows how to package java stuff is around, lemme know. i need some mentoring on this
[18:50] <maco> its a zip full of other zips
[18:50] <nigelb> I think slytherin does some java stuff
[18:50] <maco> i dont know how deeply the zip nesting goes, just that there's java at the end of the rainbow
[18:52] <nigelb> I wonder why vlc was ftbs for m
[18:52] <nigelb> me
[19:28] <ScottK> I have a package that FTBFS due to configure not being executable.  I could chmod +x configure in debian/rules, but someone that doesn't seem ideal.  Suggestions?
[19:32] <carstenh> ScottK: you could use "sh configure" instead of "./configure"
[19:33] <ScottK> Thanks.
[19:35] <ScottK> That works, so which should be preferred?
[19:38] <jdong> ScottK: chmodding +x is my preferred way; if the configure script requires a specific shell (like dash), I don't believe sh will reinterpret the shebang and start the requested interpreter
[19:39] <jdong> s/dash/bash
[19:39] <ScottK> Makes sense.
[19:42] <carstenh> configure shouldn't require a specific shell and even if it would, one only needs to read the first line to choose the correct shell.  on the other hand, i don't think anybody really cares
[20:06] <YokoZar> Does each upload need approval at this point or is that next week?
[20:07] <ScottK> YokoZar: The queue is on manual.
[20:07] <ScottK> You can upload
[20:07] <YokoZar> ScottK:  ahh, ok.  About to do a small ia32-libs and then a Wine rebuild then ;)
[20:08] <YokoZar> ScottK: I take that back. There is nothing "small" about ia32-libs.
[20:08]  * geser wondered since when was ia32-libs small :)
[20:08] <YokoZar> since lzma compression of course
[20:10] <carstenh> is this understandable and foolproof? "Don't know how to handle package relationship fields of package\n`%s'. One of them includes the string `:%s'.\n\nLooks like you have packages installed that adhere to a more recent\nversion of the multiarch specification than deborphan knows about.\n\nTo solve this, you probably need to install a later version of the\npackage deborphan. After this, you should be able to use it again.\nExiting.\n"
[21:40] <Caesar> Is it too late to get a new (not currently present in universe) package synced from Debian testing?
[21:42] <geser> yes
[21:44] <ScottK> Caesar: If you can convince me there's a really good reason, no.  It's not too late.
[21:46]  * ScottK is out for a bit.
[21:55] <Caesar> ScottK: I'm not sure if you consider "I'd like this piece of software to be available in Lucid" as a really good reason
[21:56] <ajmitch> it'd probably depend on what it was :)
[22:01] <Caesar> ajmitch: suricata
[22:17] <Caesar> ScottK: I've filed a sync request, I'll leave it in your capable hands
[22:34] <YokoZar> Caesar: ScottK can't do syncs at this point I think
[22:34] <YokoZar> Caesar: you need someone with shell access (ie employed by canonical)
[22:58] <Caesar> YokoZar: ok, I need to get the sync request approved/sponsored first. I assume ScottK can do that
[23:33] <distatica> I was told to ask this here; I'm having a hard time understanding ubuntu package creation. I'm trying to distribute a web application and have read http://webapps-common.alioth.debian.org/draft/html/ and the complete packaging guide, but everything either grabs an existing package and recreates it, or seems geared towards Makefile based compiled software. This is a django application though.
[23:34] <distatica> if anyone is experienced with this, and would be willing to lend a bit of a hand (PM would be nice) I could really use it.
[23:35] <distatica> I should say, I haven't read the full packaging guide, I'm still trying to work my way through it..
[23:59] <quentusrex> Anyone know how to use git to build nightlies? I use to be able to use the revision number with svn.