[03:06] <doctormo> I need a packager who can do start up scripts and varius other system niggles.
[04:10] <wrapster> i created a gpg key on my local box but most of my work deals with ssh'ing to a remote box and building pkg there.. is there a way i can export my public.key or do something so that i can sign it using my KEYID
[04:10] <doctormo> wrapster: Can you not just create a seperate key for your remote box and link it back?
[04:11] <wrapster> link it back?
[04:11] <lifeless> wrapster: you can copy the packages back and sign with debsign
[04:11] <lifeless> wrapster: or you can create a detached signing subkey
[04:11] <doctormo> Hey lifeless
[04:11] <lifeless> hi doctormo
[04:11] <wrapster> hmm thats fine but i dont want to shuffle around too much...
[04:12] <wrapster> lifeless: how do i do that?
[04:12] <lifeless> wrapster: do which
[04:12] <wrapster> detached signing key
[04:12] <wrapster> i want to use my existing key.. dont want too many things hanging around
[04:13] <lifeless> rsync remotebox:PACKAGE* .; debsign *.changes
[04:15] <wrapster> ok
[04:23] <wgrant> lifeless, wrapster: See also debsign -r
[04:24] <ajmitch> wgrant: is that the same as debrsign?
[04:24] <StevenK> No, wrong way
[04:24] <lifeless> kindof of the reverse
[04:25] <StevenK> debsign -r is you have your key remotely, and the .dsc and .changes locally
[04:25] <StevenK> debrsign is you have your key locally and the .dsc and .changes remote
[04:25] <wgrant> Er.
[04:25] <wgrant> debsign -r has the key locally.
[04:25] <ajmitch> I don't use either method very often
[04:25] <StevenK> Doh
[04:54] <doctormo> Does anyone know how to list files on a system that were not installed by packages?
[04:55] <StevenK> cat /var/lib/dpkg/info/*.list > all ; find . -type f > files ; diff -u all files # maybe?
[04:55] <StevenK> Er, fine /
[04:56]  * StevenK gives up
[04:57] <lifeless> doctormo: no; uhm the debrestore stuff probably does
[04:57] <zooko> There used to be a tool in debian named something like "cruft" to do that.
[04:57] <zooko> Many years ago.
[04:58] <wrapster> StevenK: i think debrsign is what i want.. the key i have that is machine that generated the gpg is local.. while the dsc and changes file are on the machine that i ssh into!!!
[04:58] <doctormo> zooko: cruft is a real package
[05:00] <lifeless> wrapster: thats debsign -r
[06:16] <Quintasan> jcastro: I have submitted my application for sponsor ship, could you check if it arrived?
[06:59] <nixternal> dho
[07:08] <dholbach> good morning
[07:15] <fabrice_sp> Hey dholbach!
[07:15] <dholbach> hiya fabrice_sp
[07:16] <fabrice_sp> is persia the right guy to ping to add me to the u-u-s team?
[07:16] <persia> Yep
[07:17] <andol> Regarding bug #128242. As there is an agreement with the Debian Maintainer about sticking to the stable branch of rdiff-backup. Is that enough to consider it as fix commited/released?
[07:19] <fabrice_sp_> thanks persia! :-)
[07:20] <wrapster> why would link: not work here http://pastie.org/635497
[07:22] <LucidFox> How do I switch from edge.launchpad.net to plain launchpad.net?
[07:22] <LucidFox> I have logged out, but it still redirects me to edge
[07:22] <andol> LucidFox: Still member of the team LP beta testers?
[07:23] <LucidFox> Ah, it depends on *that*!
[07:23] <LucidFox> But still, I'm logged out. Does it bind to IP or something?
[07:25] <andol> LucidFox: Well, that or some cookie hiding somewhere. *guessing*
[07:33] <wrapster> guys can anyone tell me why the pastie is not working? im a newbie here
[07:34] <wgrant> LucidFox: You probably logged out of edge but not production.
[07:35] <wgrant> LucidFox: Why do you want to switch to plan launchpad.net? If you just want to do it for a couple of hours, hit the 'Disable edge redirect' link at the bottom of any edge page.
[07:35] <wgrant> But that probably won't be there if you're logged out on edge.
[07:36] <wgrant> So go to launchpad.net and either log out or click the 'Disable redirect' button.
[07:36] <LucidFox> Okay, opened the plain site in a different browser
[07:36] <LucidFox> I just needed it for the OpenID links, recently I've become unable to use Launchpad as a delegated OpenID provider for my domain.
[07:37] <wgrant> I saw a bug on that.
[07:38] <wgrant> Unfortunately, recent versions of the code in question are proprietary.
[07:39] <LucidFox> :|
[08:37] <alourie> hello
[08:41] <alourie> I need an advice please
[08:41] <alourie> I've been splitting a wordpress package into 2
[08:41] <alourie> I edited the control, rules, dirs and install files, and pdebuild seems to pass.
[08:41] <alourie> How should I proceed with this?
[08:41] <alourie> thanks
[08:45] <jmarsden> alourie: "pdebuild seems to pass" ... if it creates the expected binary .deb files, then you can install and test them, that would be usual the next step.
[08:45] <alourie> jmarsden: yes, it does create them
[08:45] <persia> dpkg --contents might help to determine if it creates the expected binaries.
[08:45] <alourie> no, sorry
[08:45] <alourie> it creates dsc files
[08:46] <jmarsden> alourie: What exact command did you use to tell your pbuilder to create the .deb files ?
[08:49] <alourie> jmarsden: I just ran 'pdebuild'
[08:49] <alourie> and it created dsc file
[08:49] <jmarsden> And it ran with no errors, but created no .deb files at all?
[08:51] <alourie> jmarsden: yes
[08:51] <jmarsden> Where are you looking for the .deb files?  Have you used pdebuild successfully in the past?
[08:52] <alourie> jmarsden: well, I was looking for .deb files in the same directory as .dsc created
[08:52] <alourie> but maybe that's not right...
[08:53] <jmarsden> man pdebuild    the default buildresult directory is not .. it is /var/cache/pbuilder/result/
[08:53] <alourie> jmarsden: right :-) and there's a deb file
[08:53] <jmarsden> Are the missing .deb files in there?  OK.
[08:54] <alourie> jmarsden: so now I just install them?
[08:54] <jmarsden> Sure, or as persia said you can use dpkg --contents on them to see what they contain, if you prefer.
[08:55] <jmarsden> Basically they are now ready for you to test.
[08:58] <alourie> ok, I will try to install
[09:12] <slytherin> is this bug likely to be caused because of problematic video drivers? - bug 422807
[09:16] <Elbrus> My package (winff; I am the Debian maintainer) has an updated translation and two new translations. What is the prefered way of getting them into Karmic? Creating a debdiff and creating a bug with it attached (easy for me)? Or some launchpad way I haven't seen yet.
[09:18] <slytherin> Elbrus: are those translations in some Debian version already?
[09:19] <Elbrus> nope, not yet
[09:19] <Elbrus> but upstream also created a new version
[09:19] <Elbrus> and as we are past feature freeze
[09:19] <slytherin> Elbrus: then debdiff against the version in karmic is the best way forward.
[09:19] <Elbrus> I thought just getting the translations in
[09:20] <Elbrus> ok
[09:20] <Elbrus> do I need to subscribe any group in particular after filling the bug?
[09:20] <Elbrus> motu sponsors?
[09:21] <slytherin> yes, the team name is ubuntu-universe-sponsors
[09:22] <slacker_nl> hello to all
[09:22] <slacker_nl> https://bugs.launchpad.net/ubuntu/+source/guessnet/+bug/433677 << debian has just released a new version of guessnet, would that make karmic?
[09:41] <slytherin> slacker_nl: is that a new version or revision?
[09:42] <slacker_nl> slytherin: it includes the fix for the bug plus removes waproamd from suggests, so.. revision?
[09:43] <slacker_nl> slytherin: + new upstream release
[09:43] <slacker_nl> slytherin:  * New upstream release
[09:43] <slacker_nl>       + increased pcap timeout in netwatcher.cc. Closes: #529882.
[09:43] <slacker_nl>         Thanks to Dietz Pröpper and Vincent Lefevre for digging this out.
[09:43] <slacker_nl>    * Removed waproamd from suggests. Closes: #509394.
[09:43] <slacker_nl> oops, wrong paste
[09:43] <slacker_nl> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529882
[09:43] <slytherin> slacker_nl: The version in karmic is 0.49-1 and the one in debian is 0.50-2. So it will need freeze exception
[09:45] <slacker_nl> slytherin: would be nice if it could, but I guess it could do no harm leaving as is
[09:45] <slacker_nl> slytherin: if it is provided in -updates after the release..
[09:46] <slytherin> slacker_nl: If you can backport the fixes from upstream to 0.49 version then you can find someone to upload it.
[09:47] <slacker_nl> slytherin: could do that (although fairly new to debian packaging)
[09:47] <slacker_nl> slytherin: lemme see what I can do
[09:57] <_Andrew> hi guys
[09:57] <_Andrew> http://pastebin.com/d63f7449c
[09:58] <_Andrew> Is this correct for the rules file? I've never done an if statement in one before
[09:58] <_Andrew> Can't even find an example of one
[09:59] <persia> _Andrew, Consider instead modifying nvidia-cg-toolkit so that it builds a binary for lpia (just use the i386 binaries from nvidia: they are compatible).
[10:00] <_Andrew> oh really?
[10:00] <_Andrew> On lpia only machines?
[10:00] <_Andrew> Well that's made things simpler
[10:01] <persia> That said, it's probably worth just disabling it in every case if you're planning an upload to Ubuntu, as nvidia-cg-toolkit cannot be built on the buildds (requires build-time internet access).
[10:01] <_Andrew> I already packaged it
[10:01] <persia> Again?
[10:01] <_Andrew> yes
[10:01] <persia> There's an nvidia-cg-toolkit source package in multiverse.
[10:02] <_Andrew> But it requires internet access
[10:02] <persia> Yes, but anything else violates the license nvidia provides saying that one can't redistribute the downloaded tarballs except as binary modules to work with an operating system.
[10:02] <_Andrew> No it doesn't there is a linux exception
[10:03] <persia> So, unless the license changed, or I'm misinterpreting it, you can't redistribute the tarballs.
[10:03] <persia> If that's changed, then Great!  Keep at it!
[10:03] <persia> But check the license carefully.
[10:03] <_Andrew> Yes I already submitted a big about it to both debian and ubuntu about a year ago
[10:03] <_Andrew> a bug about it**
[10:03] <persia> Oh, so there was a change?  Cool.  It's been more than a year since I last checked that license.
[10:03] <slacker_nl> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff < step 4, is that correct information for motu?
[10:04] <persia> slacker_nl, There are many ways to generate a debdiff, but that also works.
[10:04] <_Andrew> Are there any examples of an if statement in the rules file?
[10:05] <slacker_nl> persia: i ment, the e-mail for the maintainer field :)
[10:05] <slacker_nl> is that correct
[10:05] <persia> slacker_nl, Yes.
[10:05] <slacker_nl> persia: k, thnx
[10:05] <persia> _Andrew, Well, it's correct make syntax, but it won't work the way you want.
[10:06] <persia> In makefiles, there are two different ways that conditionals are sometimes used: make conditionals and shell conditionals.
[10:07] <persia> In general, it's best to use make conditionals to set variables, and shell conditionals within a rule (although there are exceptions).
[10:07] <_Andrew> Actually if lpia is compatible with i386 binaries what I will do is if it's lpia copy files from a specific folder
[10:08] <persia> lpia is compatible with the ia32 instruction set.  Whether binaries are compatible is more complex, and probably requires some ABI analysis.
[10:08] <_Andrew> oh : /
[10:08] <_Andrew> Perhaps it's better just to disable it then.
[10:08] <_Andrew> But actually I want the cg toolkit for i386 and amd64
[10:08] <slytherin> _Andrew: You need to use logical constructs for make. The one you are using is for shell. Check this http://svn.debian.org/viewsvn/pkg-java/trunk/java-gnome/debian/rules?view=markup
[10:09] <_Andrew> That's perfect. Thanks
[10:10] <sistpoty|work> _Andrew: you can actually set up a lpia chroot on an x86 box
[10:10] <slytherin> _Andrew: so you will have to use - ifneq (,$(filter $(DEB_HOST_ARCH), lpia)) - This means if the arch is lpia.
[10:10] <persia> slytherin, Is that going to work inside a rule?  I usually use that sort of thing only to set variables, and use the (possibly empty) variable inside the rule.
[10:11] <slacker_nl> slytherin: i've created a debdiff for the fix of that bug
[10:11] <slytherin> persia: You have a valid question. And I have never used it inside a rule. :-)
[10:11] <slytherin> slacker_nl: attach it to the bug and subscribe ubuntu-universe-sponsors.
[10:12] <persia> Inside rules, I usually see the use of shell conditionals (but these need to be tab-indented, and one needs to take care to have the entire conditional processed as a single call from make)
[10:13] <persia> _Andrew, I'd recommend setting a new variable, say CG_EXTA_FLAGS, to either "--disable-cg" or "" using make conditionals, and then referencing ${CG_EXTRA_FLAGS} in your ./configure call.
[10:13] <slacker_nl> slytherin: will do, thnx
[10:13] <persia> (or just enabling lpia, but I'm not sure how many lpia+nvidia devices exist, so that may not be important)
[10:19] <_Andrew> persia: Yeah, actually I don't think it's important. I just find it annoying that a dependency wait shows it as a build failure in Ubuntu. Lots of people email me about it all the time even though they don't use lpia O_o
[10:21] <directhex> persia, if LPIA is basically Atom, isn't Ion LPIA?
[10:22] <directhex> (ion being an nvidia 9400m variant as a replacement netbook chipset for atom)
[10:22] <persia> directhex, I have no information to answer that question.  My opinion is that until the instruction set diverges from ia32, lpia is a marketing term.
[10:23] <directhex> wasn't there discussion of axing it at UDS?
[10:23] <persia> Yes.
[10:23] <persia> The decision was that the silicon vendors were still talking about possible divergence in the future that would make a difference, and it would be more trouble to kill it and restore it than to leave it and ignore it.
[10:24] <persia> But until I see chips that *are* different, rather than rumours that future chips will be different, I don't expect to put a lot of effort into it.
[10:25]  * sistpoty|work has some doubts that binary incompatibilty will happen anywhen soonish, as that's imho the only strength of atom
[10:25]  * directhex agrees
[10:26] <directhex> sad reality is: what's the point in an Atom which can't run windows?
[10:26] <persia> sistpoty|work, Maybe.  From what I've heard, the focus has been on optimisation, so that the line that currently provides the i7 focuses on raw throughput, whereas the line that currently provides the Atom focuses on throughput/watt.
[10:26] <sistpoty|work> directhex: exactly
[10:27] <persia> I've heard rumours that that specific application use case has caused significant annoyance to both camps.
[10:27] <persia> But anyway, divergence is a matter of time, as much as anything else.
[10:28] <persia> There's lots of bolt-on instruction sets that have been established over time.  Atom has lots less of these than i7.
[10:28] <persia> If any of these are critical enough for performance, or if Atom gets a set that can significantly optimise for power, then there may be instruction divergence (although most of that would be just processes capabilities analysis)
[10:29] <lifeless> are the compiler flags the same as i386 at the moment?
[10:29] <persia> lifeless, Not sure.  There was a special lpia flags wrapper deployed in very early karmic.  I haven't checked if it is still there.
[11:03] <slytherin> Which team handles mobile-meta package?
[11:11] <alourie> persia, jmarsden: the kit seems to contain everything I need, checked with 'dpkg --contains'
[11:12] <alourie> how should I proceed?
[11:18] <persia> alourie, So, you've modified and compiled a package, and installed it.  What beyond that did you wish to accomplish?
[11:19] <alourie> persia: how do I verify the quality is ok? what do I do next to "issue" the patch?
[11:20] <persia> alourie, My memory is that you were doing a package split, with no other bugfixes.  If that is correct, there really isn't any "quality" to measure, so long as all the files are still present.
[11:20] <persia> running debdiff between the original package and your modified package would generate a patch.
[11:21] <_Andrew> Is there a way to get launchpad to auto build a package if one that depends upon it is updated
[11:21] <persia> But unless there's some strong reason why something is broken otherwise, it is unlikely that your patch will be accepted in Ubuntu, as a package split requires significant maintenance and so needs commesurate gain.
[11:21] <persia> Why would you rebuild something because a dependency was updated?  Usually, it's the other way about, and no.
[11:22] <persia> While it's possible, it is often the case that when a dependency changes, some other change is required in a package (e.g. API changes for a library), so it benefits from human interaction.
[11:22] <persia> (well, usually.  Ask someone who has done too much NBS, and they will provide a counterargument)
[11:23] <_Andrew> ok
[11:24] <alourie> persia: so I just debdiff and attach the patch files to the bug?
[11:24] <persia> alourie, Yes, but unless the bug is part of some larger effort, don't expect it to be uploaded quickly, because package splits are expensive.
[11:25] <alourie> persia: no, it's something quite light
[11:25] <alourie> it's separation of language files from main wordpress installation
[11:26] <persia> Right.  That's expensive to maintain, because someone would have to merge every cycle.
[11:26] <persia> Mostly I'm just warning you that even if you did a spectacular job, it might not be considered a candidate for upload soon.
[11:26] <alourie> persia: oh, that's ok, I volonteered to help rolf
[11:27] <persia> Personally, for a package split, I'd recommend contacting the Debian maintainer, as it may also be interesting for Debian, and that would significantly reduce the burden (as it wouldn't have to be redone every six months).
[11:27] <ScottK> YokoZar: Would you please look at Bug 439218 and tell me of you think it makes sense?
[11:27] <persia> Ah, if you're doing it on request, that's another matter :)  You already have an uploader.
[11:27]  * ScottK waves t persia.
[11:27] <alourie> persia: r0lf offered mentoring on this and I almost done, just finishing up.
[11:27] <persia> Hey ScottK
[11:27] <persia> alourie, Then, yes, just attach the patch to the bug.
[11:28] <alourie> persia: I debdiff the dsc files, right?
[11:28] <persia> Right.
[11:28] <persia> And check the result, to make sure it only contains the changes you wanted.
[11:28] <alourie> ok
[11:28] <persia> And test the result against the unpacked original package with patch -p1 < debdiff to make sure it applies cleanly.
[11:28] <alourie> and I output it to a file which *is* the patch?
[11:28] <persia> Right.
[11:28] <alourie> ok
[11:29] <alourie> how do I test it against the original?
[11:29] <persia> dpkg-source -x ${orig}.dsc, cd ${packagedir}; patch -p1 < ${debdiff}
[11:30] <alourie> oh, great
[11:30] <persia> Just to make sure that your patch applies cleanly, etc.
[12:22] <alourie> persia: how do I run lintian to test the package?
[12:23] <pochu> lintian package.deb or lintian package.changes
[12:23] <alourie> pochu: thanks
[12:24]  * persia likes lintian -iIv, but that's more verbose than most prefer
[12:25] <pochu> I run lintian -i -I --show-overrides --allow-root --color always foo.changes
[12:25] <alourie> persia: oh, that was great! that's verbose-perfect :-)
[12:40] <Laney> which cdbs target is usually used for list-missing?
[12:41] <pochu> common-binary-predeb-arch I think
[12:42] <Laney> works for me
[12:42] <Laney> thanks
[12:42] <slytherin> Laney: target? Shouldn't it be a debhelper flag?
[12:42] <Laney> it comes with utils.mk
[12:43] <joaopinto> sox is not installable, because libgsm1 is not available, is this a temporary building problem or should I file a bug report ?
[12:43] <Laney> you should find out why and fix it :)
[12:43] <joaopinto> it affects more than 10 packages
[12:44] <joaopinto> Laney, I am asking if it' s known and someone is working on it to avoid wasting time :)
[12:45] <Laney> infact it is installable for me
[12:45] <joaopinto> karmic ?
[12:45] <Laney> yep
[12:45] <Laney> amd64
[12:46] <joaopinto> E: Package libgsm1 has no installation candidate
[12:46] <joaopinto> i386
[12:46] <joaopinto> hum, it's listed at http://packages.ubuntu.com/karmic/i386/libgsm1/download
[12:47] <Laney> can you install it manually?
[12:47] <joaopinto> you mean, dpkg -i on the deb ?
[12:48] <joaopinto> I am using the global archive, so it's not likely to be a mirror issue
[12:48] <Laney> apt-get install libgsm1
[12:48] <joaopinto> Laney, that E: is the output of apt-get install...
[12:49] <Laney> oh ¬_
[12:50] <joaopinto> Laney, which mirror are you using ?
[12:50] <Laney> gb
[12:50] <joaopinto> apt-cache policy libgsm1, please
[12:50] <Laney> neither of those packages has had an upload in weeks though, so it shouldn't matter
[12:50] <joaopinto> you probably had the package before it got removed from the archive, for some reason
[12:51] <Laney> it's not been removed
[12:51] <joaopinto> you have an install candidate for libgsm1 ?
[12:51] <Laney> yes
[12:53] <Laney> try apt-cache policy libgsm1
[12:53] <joaopinto> libgsm1:
[12:53] <joaopinto>   Installed: (none)
[12:53] <joaopinto> after changing to gb.
[12:54] <joaopinto> for sox:
[12:54] <Laney> candidate:?
[12:54] <joaopinto>         500 http://gb.archive.ubuntu.com karmic/universe Packages
[12:54] <joaopinto> yes, Candidate is what matters
[12:54] <joaopinto> ah
[12:54] <joaopinto> ops
[12:54] <joaopinto>   Candidate: (none)
[12:55] <Laney> works in a chroot too
[12:55] <joaopinto> hum, a 32 bits chroot ?
[12:56] <joaopinto> we are comparing different archs
[12:57] <joaopinto> rep -c "Package: libgsm1" /var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_karmic_universe_binary-i386_Packages
[12:57] <joaopinto> 0
[12:57] <joaopinto> g
[12:57] <Laney> it's in main
[12:57] <joaopinto> ops :\
[12:58] <joaopinto> grr, my error :P
[12:58] <joaopinto> tks and sorry
[12:58] <Laney> what was it?
[12:58] <joaopinto> I was playgin with my sources yesterday and forgot to re-enable main :P
[12:58] <joaopinto> playing
[12:59] <Laney> ¬_¬
[12:59] <joaopinto> that also explains the 0 updates from today :P
[13:00] <joaopinto> and I was so happy that it was beta freeze related :)
[13:17] <zooko> ia:
[13:28] <james_w> hello zooko, did the powerpc user find the right packages?
[13:43] <YokoZar> ScottK: are you asking me if the bug I filed makes sense?
[13:44] <ScottK> YokoZar: Yeah.
[13:44] <ScottK> YokoZar: I just hadn't looked at the bug to see who filed it.
[13:44] <YokoZar> Well, I don't think I'm out of my mind, so I should say that it does make sense
[13:44] <ScottK> Fair enough.
[13:44] <ScottK> I guess I should actually read the bugs first.
[13:45] <YokoZar> hah no problem ;)
[13:45] <YokoZar> I suppose I could merge it into the normal package but there's probably merit to having it split anyway (I'd like to see Wine icons as part of the normal icon themes anyway, as they can be drawn to match them in many cases)
[13:46] <ScottK> YokoZar: At this point in the release cycle it'd be better to leave it in the existing package and then split it out for Lucid.
[13:46] <YokoZar> ScottK: so what's less messy, uuencode or .sng ?
[13:46] <ScottK> So my preference would be for you to uuencode/decode them
[13:47] <ScottK> I don't know about .sng, using uuencode is pretty common
[13:47] <YokoZar> all right then, uuencode it is
[13:48] <ScottK> Thanks.
[13:48] <ScottK> I can't promise we'd get through New with a new package now, so this is safer.
[13:49] <alourie> dholbach: ping
[13:56] <dholbach> alourie: pong
[14:21] <lfaraone> Are there any plans to port AuthClientConfig from Ubuntu to Debian? I'm not sure how to have my package modify nsswitch.conf and still follow debian policy.
[14:58] <iulian> Errm.  Bloody Launchpad OOPSes!
[14:58] <iulian> I can't even change a status of a bug.
[14:58] <ScottK> File a bug, if you can ....
[15:00] <siretart`> lfaraone: write instructions in README.Debian
[15:05] <cgregan> Hello motu team. I am having a bit of a problem with gnome-do and was wondering if someone had a second or two to chat
[15:07] <ScottK> !ask | cgregan
[15:08] <cgregan> hehe
[15:10] <cgregan> So.....When I launch gnome-do from start-up applications it hangs and eats most of my processor cycles. After I kill it and relaunch, it is ok. I was wondering if a) there is a fix b) I can modify my start-up application entry to sleep the app for a bit c) I can change the order of the start-up application order to launch later.
[15:14] <jpds> cgregan: Does the same here sometimes, might be best to talk to #gnome-do about that.
[15:14] <cgregan> jpds: ah....no idea there was a #gnome-do
[15:14] <cgregan> jpds: so no way to adjust the order of starts in start-up applications applet?
[15:16] <cgregan> jpds: I was hoping it had a linear process (i.e. apps at the top start first...bottom last)
[15:34] <slytherin> cgregan: I believe there used to be a priority for startup applications. But I don't see it anywhere now (in jaunty at least).
[15:35] <cgregan> slytherin: Hmm....definitely not in Karmic either.
[15:35] <cgregan> I'll give #gnome-do a shot
[18:12] <wrapster> what are APT alternatives? can anyone let me know what it means?
[18:33] <Amaranth> wrapster: smart
[18:34] <wrapster> Amaranth: ?
[18:34] <Amaranth> !info smartpm
[18:35] <Amaranth> wrapster: basically it's an alternative way of resolving dependencies and downloading packages to feed to dpkg
[18:36] <wrapster> Amaranth: resolving dependency? could you be a bit more descriptive ,im a newbie here trying to learn
[18:38] <Amaranth> wrapster: Well, packages have dependencies. Certain other packages required for them to work. "Resolving dependencies" means figuring out what those are.
[18:39] <Amaranth> Which can get complicated with recursive dependencies, either or dependencies (I need this package or this package), and multiple packages providing the same dependency
[18:43] <wrapster> Amaranth: ok got it.. thanks for the info
[19:38] <jtimberman> fabrice_sp_: hey.. let me know if i can help with that chef upgrade ticket
[19:49] <fabrice_sp_> jtimberman, thanks :-)
[19:49] <fabrice_sp_> I'm just building the package, and will check for the changes
[19:49] <jtimberman> fabrice_sp_: github's migration was a bit rocky.
[19:49] <jtimberman> fabrice_sp_: the uscan works with the watch file line you posted in the LP bug?
[19:50] <fabrice_sp_> jtimberman, yes :-)
[19:50] <fabrice_sp_> If you agree, I'll update it in your package
[19:52] <jtimberman> that's fine, though we might move to creating our own tarballs and posting in the apt repository for a future release.
[20:14] <fabrice_sp_> jtimberman, why having a lot of cp in the rules file, and not .install files?
[20:15] <jtimberman> fabrice_sp_: iirc, i copied another package's example.
[20:15] <fabrice_sp_> :-)
[20:16] <fabrice_sp_> so please put in your todo list: make the rules file easier :-)
[20:16] <fabrice_sp_> Anyway: everything sounds good, so I'll upload it
[20:16] <jtimberman> thanks!
[20:17] <fabrice_sp_> thanks to you for your hard work :-)
[20:19] <jtimberman> looks like libmixlib-config-ruby isn't synced from debian yet. :/
[20:19] <jtimberman> LP bug 420674
[20:20] <fabrice_sp_> yeah: waiting for an archive admin to process it
[20:20] <fabrice_sp_> this mean that the package will FTBFS, right?
[20:20] <fabrice_sp_> or it will just fail to run correctly?
[20:22] <fabrice_sp_> jtimberman, ^
[20:22] <jtimberman> looking
[20:22] <fabrice_sp_> ok. Sorry :-)
[20:24] <fabrice_sp_> libchef-ruby1.8 won't be installable (because of the Depends)
[20:25] <jtimberman> yeah. because the package sets up the log_location as a file, iirc.
[20:25] <jtimberman> i didn't do any of the code work on that in chef or mixlib-config though.
[20:25] <fabrice_sp_> I'll upload it anyway, as the package will build fine
[20:27] <jtimberman> alrighty
[20:48] <Zelut> I'm having a PPA issue in that I can't figure how to upload for jaunty and karmic
[20:48] <jdong> the upload will go to where debian/changelog's top entry tells it to go
[20:49] <Zelut> jdong: which is what I assumed, and jaunty has been accepted and built. I'd now like to build for karmic so I changed the changelog but dput is rejected saying it already exists.
[20:49] <ChogyDan> Zelut: and don't forget to add 'jaunty' and 'karmic' to the version numbers
[20:50] <jdong> Zelut: dput rejects it because locally there's a .upload file
[20:50] <jdong> I believe it's a .upload extension
[20:50] <Zelut> jdong: i deleted the .upload file
[20:50] <jdong> Zelut: you may need to mangle the version number too
[20:50] <jdong> LP probably won't accept same package version uploads like that
[20:50] <ScottK> It won't.
[20:50] <Zelut> File origami_0.7.1.1-0ubuntu1.diff.gz already exists in PPA for Christer Edwards, but uploaded version has different contents.
[20:51] <Zelut> maybe increment the 0ubuntuX number? seems like a hack
[20:51] <jdong> Zelut: well ideally your version number should already be that the karmic version is higher than the jaunty version
[20:51] <jdong> i.e. look at how the Security team versions security updates
[20:52] <jdong> otherwise you might be causing your users some upgrading grief
[20:52] <ScottK> Zelut: I recommend avoiding revision numbers like would be used in the archive (e.g. 0ubuntu1) in a PPA.  I recommend a scheme like 0uubntu1~release1~ppa1.
[20:52] <Zelut> hmm
[20:52] <ScottK> This avoids namespace collisions both with normal release numbering and backports.
[20:53] <jdong> yup
[20:53] <ScottK> It also naturally gets you a higher version for newer releases
[20:54] <Zelut> so, in this case, we'll just have to deal with different naming in my PPA for two packages that come from the same upstream version?
[20:55] <Zelut> I guess I chalk this up to learning.
[20:56] <ScottK> Zelut: You uploaded 0.7.1.1-0ubuntu1 for Karmic?
[20:57] <Zelut> ScottK: for jaunty. I was going to push the same version to karmic.
[20:58] <ScottK> Then just add +ppa1 to then end for karmic
[20:58] <Zelut> ScottK: new upstream release today. Updated the jaunty PPA and wanted to add it to karmic as new.
[21:30] <sebner> ScottK: around?
[21:31] <ScottK> sebner: For a few moments
[21:32] <sebner> ScottK: I just uploaded a no change rebuild (monotone), waiting for approval, Makes it installable
[21:32] <ScottK> sebner: You aren't waiting for approval.
[21:32] <sebner> ScottK: yeah, that was the mistake I made
[21:32] <sebner> ScottK: the LP status is "Waiting for approval" <-- that's what I mean
[21:32] <ScottK> sebner: Well you were, but I'd just accepted it when you pinged me.
[21:33] <sebner> ScottK: great, thx
[23:21] <zooko> Wow, launchpad is sluggish today.
[23:21] <zooko> There's a bugfix release of pycryptopp which probably ought to go into Karmic.  I'm going to open a "request sync from Debian" request on launchpad if it ever lodas.
[23:23] <zooko> Dammit.  The redirect to apport is really irritating.  I'm nowhere near a Linux box, and I'd like to get this bug report in and make my next appointment.
[23:23] <zooko> Okay, that's my quota of complaining for the day.
[23:25] <geser> zooko: append ?redirect=no to the reportbug link
[23:25] <zooko> Okay success at opening the bug report.  bye for now!
[23:26] <zooko> geser: ooh, thanks.  :-)
[23:26] <geser> zooko: btw: how did you test that it builds if you aren't on Ubuntu right now?