[00:10] <AskHL_> (please tell me if this is not the right channel for this kind of question) I'm new to packaging and want to make a .deb with a Python program.  I use dh_make to generate some template files.  So should I add those files to version control and change them by hand when making new releases, or run dh_make to make new ones every time?  In other words I can make a package, but how do I do this *practically* when subsequent new releases are involved?
[00:11] <AskHL_> The question might be a bit unclear.  Specifically, the output files from dh_make: should I just add them to bzr (hosting on launchpad) and adjust them by hand in the future as needed?
[00:12] <jmarsden> AskHL_: Sure, you should work from the debian/* files for future releases, not start over again.  if you add them to the project's bzr repo, make sure you do *not* end up including them in any source code tarball releases the project makes.
[00:15] <AskHL_> jmarsden, thank you.  Then I might prefer to have two different repositories, one for the source (equivalent to tarball releases) and one for the packaging stuff.  Then I'll have scripts in the latter for actually generating the packages given a tarball.  Does this sound right?  (I don't want to reinvent the wheel too many times)
[00:16] <jmarsden> AskHL_: You could do that, or two different trees within one repository.
[00:18] <AskHL_> jmarsden, with bzr, a standard 'checkout' or 'branch' operation would consider just one 'tree', correct?
[00:19] <jmarsden> AskHL_: I'm not a bzr expert, I think you can use different URLs to get different sets of files within one repo just like in svn
[00:21] <AskHL_> jmarsden, I'll read up on the specifics.  Thank you very much for your help
[00:21] <jmarsden> No problem.  I think there are docs on wiki.ubuntu.com specifically about bzr integration wih Launchpad, which might be worth your while reading, by the way.
[00:22] <AskHL_> Nice
[00:22] <jmarsden> AskHL_: One starting point might be http://doc.bazaar-vcs.org/latest/en/tutorials/using_bazaar_with_launchpad.html
[00:39] <ari-tczew> !info gwget2
[00:40] <ari-tczew> !info gwget
[02:43] <Buuntu> what are some pre-requisites for joining?
[02:48] <Buuntu> hello?
[02:58] <Buuntu> is anyone there?
[02:58] <Buuntu> is this channel dead with 210 people?
[02:58] <ScottK> Buuntu: It's late Sunday night.
[02:59] <ScottK> The European half are probably sleeping and the American ~half are probably mostly busy with other things.
[02:59] <ScottK> The short answer is you don't need to join to start contributing.
[03:00] <Buuntu> ScottK, could I have a few pointers though, if you don't mind?
[03:00] <ScottK> You can ask.  I'm a bit busy with some other things.  I'll answer if I can.
[03:02] <Buuntu> ScottK, I don't really know where to start :P.  I know a programming language but not even sure if that's used for MOTU
[03:02] <ScottK> Buuntu: What do you know?
[03:03] <ScottK> The only programming that's essential for MOTU is a bit of shell.  Bonus points for understanding Make files and any programming you can do.
[03:03] <Buuntu> ScottK, basic python and some shell
[03:03] <ScottK> Perfect.
[03:03] <ScottK> Python is one of our preferred languages when writing Ubuntu specific tools.
[03:04] <Buuntu> ScottK, so i've heard - one of the reasons I chose it
[03:04] <ScottK> !contributing | Buuntu
[03:04] <ScottK> Rats
[03:04] <ScottK> Buuntu: See the contributing link in /topic.
[03:05] <ScottK> That might give you some ideas.
[03:07] <ScottK> Buuntu: Also, welcome.  I'm glad to have someone new, just a bit busy at the moment.
[03:09] <Buuntu> ScottK, thanks
[03:13] <Buuntu> ScottK, can I get a mentor for MOTU?
[03:14] <ScottK> You can do it one of two ways:
[03:14] <ScottK> 1.  Dive in and ask questions and people here will generally help you.
[03:14] <ScottK> 2.  Ask for a mentor via the mentoring program and wait for someone to be available.
[03:14] <ScottK> So yes, but i've no idea how it works.  I'm aware of the 2nd option, but know little about it.
[03:18] <Buuntu> ScottK, so I have to become a member of the bug squad to join???
[03:19] <ScottK> It's recommended, IIRC, but not required.
[03:19] <ScottK> Any MOTU will have to deal with bugs a fair amount and so learning about it is not a bad idea.
[03:20] <Buuntu> ScottK, so in your opinion what are the things I should learn about if I may ask?
[03:21] <ScottK> You'll need to learn about the technical aspects of debian packages
[03:21] <ScottK> You'll need to learn about Ubuntu policies and processes
[03:21] <ScottK> You'll need to learn how we work together and be a part of things.
[03:22] <ScottK> Part of that 2nd one is learning about how we deal with bugs.
[03:22] <Buuntu> ok
[03:23] <Buuntu> ScottK, ok, thanks - i'm going to sleep now
[03:23] <Buuntu> i'll try to come here more often and see what I can learn
[03:23] <ScottK> Buuntu: Good night.  Come on back when you're ready for more.
[03:23] <ScottK> Great.
[07:00] <porthose> would someone from MOTU-release please leave a comment on bug #442829 ty :)
[07:09] <dholbach> good morning
[07:09] <fabrice_sp> good morning dholbach :-)
[07:10] <dholbach> hi fabrice_sp
[07:13] <geser> good morning
[07:13] <dholbach> hi geser
[07:13] <fabrice_sp> hey geser!
[07:14] <highvoltage> good morning dholbach and all
[07:14] <dholbach> hi highvoltage
[07:18] <fabrice_sp> good morning highvoltage
[10:19] <AnAnt> kees: Hello
[10:20] <dholbach> AnAnt: kees is very likely sleeping
[10:21] <dholbach> he lives in UTC-9
[10:21] <AnAnt> he lives in a clock ?
[10:21] <dholbach> yes
[10:21] <dholbach> we tried to lure him out for years
[10:22] <AnAnt> haha
[10:22] <AnAnt> ok, I have a question about texlive
[10:22] <AnAnt> I see ubuntu did a change to texlive-base
[10:22] <AnAnt> http://changelogs.ubuntu.com/changelogs/pool/main/t/texlive-base/texlive-base_2007.dfsg.2-4ubuntu1/changelog
[10:22] <dholbach> try asking in #ubuntu-devel
[10:22] <dholbach> pitti might know about it too
[10:22] <AnAnt> I suspect that Debian recently fixed this bug in texlive-bin instead
[10:23] <AnAnt> ok
[10:30] <AnAnt> I filed this FFe: LP 440153, does it miss anything (except for subscribing motu-release) ?
[11:27] <AnAnt> nhandler: Hello, it seems that dh-make-perl still has problem in dh_auto_test
[11:29] <ebroder> AnAnt: there's a debdiff attached to bug #441950
[11:29] <ebroder> (It's about as simple as it gets)
[11:29] <ebroder> Err...although Geoffrey forgot to include the LP closer in the changelog
[11:40] <AnAnt> I see
[11:41] <AnAnt> ebroder: it's fixed in dh-make-perl 0.60 too
[11:42] <ebroder> AnAnt: Yes, but we didn't feel like fighting FeatureFreeze
[11:42] <AnAnt> ok
[12:17] <nhandler> AnAnt: I saw the bug. It is on my todo list for today
[12:18] <AnAnt> ok
[12:18] <AnAnt> can someone advise me about LP 440153 ? it is a branding package
[13:22] <lucas> for patches for bugs in packages in main, which team should I subscribe for review+sponsorship?
[13:23] <Laney> lucas: ubuntu-main-sponsors
[13:23] <lucas> thank you
[13:24] <lucas> subscribe, right? not assign?
[13:24] <Laney> correct
[13:27] <Lazy> hi, is there a chance to get bug #372040 fixed before karmic final?
[13:28] <Lazy> the current version does not work because the servers have been shut down
[14:12] <directhex> Lazy, unless someone prepares a package RIGHT NOW, unlikely
[14:12] <directhex> Lazy, we're WELL past featurefreeze, so you'd need to rely upon ~motu-release accepting a new version before FinalFreeze
[14:13] <hyperair> directhex: when is finalfreeze?
[14:13] <directhex> hyperair, 9 days iirc
[14:13] <hyperair> what?!
[14:13] <hyperair> eh i hope our banshee FFe acks last past finalfreeze..
[14:13] <directhex> October 15th
[14:14] <ScottK> directhex: Final freeze for Universe is somewhat later.
[14:14] <directhex> ScottK, oh? didn't know it had a different date
[14:14] <hyperair> ah
[14:14] <hyperair> october 15th eh..
[14:14] <hyperair> what an auspicious day..
[14:14] <ScottK> Let me double check
[14:15] <ScottK> directhex: For Universe it will probably be about the 25th, but we haven't decided for sure yet.
[14:15] <hyperair> ah
[14:16] <ScottK> Also for something like a screensaver, an FFe would be no problem at all if someone would have a package and prepare one.
[14:18] <slytherin> directhex: is banshee 1.6 likely to mek into karmic?
[14:18] <slytherin> make
[14:20] <Laney> there's a 1.6?
[14:24] <slytherin> Laney: I assumed there will be before final freeze.
[14:43] <directhex> slytherin, there won't be a 1.6 before finalfreeze. the current beta is more stable than the current stable though, so i've been unofficially told an FFe would probably be okay probably to go for the beta in karmic
[14:58] <ScottK> sistpoty|work: I was wondering if you might have a look at fgfs-atlas as it needs a rebuild for NBS and fails to build.  It looks like the Debian maintainer started on it and got stuck: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545593
[14:58] <ScottK> That one is definitely beyone me.
[14:58]  * sistpoty|work shutters reading atlas in the name :(
[14:59] <ScottK> sistpoty|work: Different atlas
[14:59] <sistpoty|work> ah :)
[14:59] <ScottK> Atlas as in a compendium of maps.
[14:59] <ScottK> It involves a flight simulator somehow, so it might need testing
[15:01] <sistpoty|work> ScottK: I'll take a look
[15:01] <ScottK> Thanks
[15:06] <jdong> asac: hey do you have any ideas on that nspluginwrapper+compiz-no-mouse-clicks bug?
[15:06] <jdong> seems like a pretty nasty one to release with :(
[15:07] <asac> jdong: seems at least not reliably not work
[15:07] <asac> so it works for me most of the time
[15:07] <jdong> asac: strange; on my machine (fglrx) it fails with 100% reliability on youtube
[15:08] <sharms> Can someone review lp #423755 for me
[15:08] <asac> i saw it too ... but normally it works ;)
[15:08] <asac> havent debugged it. was also hoping that we get 64-bit final shortly before release
[15:09] <jdong> I see
[15:14] <directhex> jdong, that bug is hellish
[15:14] <jcastro> https://wiki.ubuntu.com/UbuntuOpenWeek/Prep <-- still looking for speakers for open week!
[15:14] <jdong> directhex: yeah, for me I have to turn off compiz to use a flash site
[15:15] <jdong> directhex: and of course unlike KWin the compiz -> metacity switch doesn't preserve window/desktop layouts
[15:15] <ScottK> More sign you should switch to KDE ;-)
[15:15] <jdong> hahaha
[15:15] <directhex> jdong, does it "just work" when you kill compiz? doesn't fix it for me, but i haven't tried restarting my session or anything like that
[15:16] <jdong> directhex: for me a metacity --replace seems to make it work again
[15:17] <slytherin> sharms: Did you change the indentation in the glade file? The debdiff shows too many changes.
[15:18] <directhex> jdong, yeah, seems to work on my laptop... but killing compiz is not a fix in late 2009
[15:18] <jdong> directhex: fully agreed
[15:18] <jdong> directhex: have you tried the non nspluginwrapper 64-bit flash?
[15:21] <directhex> jdong, seems fine on this box... but then i can't use any Air apps
[15:21] <directhex> e.g. iPlayer
[15:21] <AnAnt> ScottK: can you have a look at LP 440153 ?
[15:21] <jdong> ah, right.
[15:21] <jdong> directhex: I seem to recall air apps working fine...
[15:21] <directhex> jdong, air needs 32-bit flash
[15:21] <jdong> directhex: at least I used the Pandora one under compiz
[15:22] <jdong> directhex: oh it needs firefox's 32-bit flash?
[15:22] <ScottK> AnAnt: Sure
[15:24] <directhex> jdong, it certainly does if there's any interop
[15:24] <AnAnt> ScottK: anything else I should add to this bug (other than subscribing motu-release) ?
[15:24] <directhex> jdong, e.g. if you trick air into installing, then switch to 64-bit flash, bbc.co.uk/iplayer will just kill your browser, no questions asked
[15:24] <Lazy> directhex: it would be pretty silly to ship eleectricsheep version 2.6 because it just does not work anymore. at least debian testing has new electricsheep package so it shouldn't be that big deal to upgrade ubuntu packages also?
[15:24] <ScottK> AnAnt: I think it's fine.
[15:24] <directhex> Lazy, see, that's a detail you hasn't previously mentioned
[15:25] <AnAnt> ok, subscribed motu-release
[15:25] <AnAnt> ScottK: thanks
[15:26] <Lazy> i think the original reporter had menioned it in his bug report dated 5.5.
[15:28] <directhex> Lazy, "fabrice_sp  wrote 7 minutes ago:" is the first mention of debian in that bug
[15:30] <iulian> AnAnt: Approved.
[15:30] <Lazy> directhex: sorry, i misunderstood that you meant that package not working anymore was first mentioned by me
[15:30] <sharms> slytherin: the entire glade file was pulled from upstream version 0.9.2 because the old one doesn't work with our libglade
[15:30] <AnAnt> iulian: thanks
[15:31] <sharms> slytherin: so that big change is that patch replacing that glade file to get parsed correctly, and one change to POFILES.skip to ignore the patch itself when building
[15:31] <slytherin> sharms: Is it possible to isolate the bug and fix it? It is kind of difficult to make sure that this glade file does not break anything else.
[15:33] <sharms> slytherin: I didn't want to edit the file since upstream said that the file would fix the failure to launch, since I am not familiar enough with the program to edit the file better than them
[15:34] <slytherin> hmm
[15:34] <slytherin> Then I leave this to be reviewed by someone familiar with grsync code.
[15:39] <ScottK> AnAnt: Your FFe is approved.  Please ping me when it's uploaded and I'll do the archive admin review (I can't do that if I'm the one that uploads it)
[15:40] <directhex> electricsheep 2.7 does NOT work on karmic as-is
[15:43] <AnAnt> archive = karmic new queue ?
[15:43] <ScottK> AnAnt: Yes
[15:44] <AnAnt> ok
[15:45] <directhex> "flam3" needs to be synced first
[15:45] <directhex> apparently it doesn't actually do anything useful for 10 minutes and this is normal (?)
[15:46] <Lazy> directhex: if you run it first time it might be downloading the "sheeps"
[15:46] <mok0> Is there a fix to ubuntu-dev-tools for jaunty?
[15:46] <ScottK> mok0: What's broken?
[15:46] <mok0> ScottK: pull-lp-source was destroyed by the recent upgrades to LP
[15:47] <ScottK> Ah.
[15:47] <ScottK> Is it fixed in Karmic?
[15:47] <mok0> ScottK: yes
[15:47] <ScottK> mok0: Simplest thing to do is ask for a backport.
[15:47] <mok0> ScottK: But there's a dependency there that doesn't go well with jaunty
[15:47] <ScottK> We can backport the depends too
[15:48] <ScottK> That makes backports better for this than an SRU
[15:48] <mok0> ScottK: ok, I haven't checked how far back in the dependency tree you need to go
[15:48] <slytherin> What if the fix requires minor change
[15:48] <slytherin> It should then be possible to do SRU.
[15:49] <mok0> The LP upgrade also broke a whole bunch of debian/watch files
[15:49] <mok0> "Thanks a lot, guys"
[15:50] <ScottK> slytherin: Possible, yes, but since it's a dev tool and you need other stuff from backports already for Karmic development work, I think backports is OK and easier
[15:50]  * slytherin has to leave. will login later.
[15:50] <mok0> ScottK: I'll take a look
[15:51] <mok0> ScottK: perhaps python-apt backports easily
[15:51] <ScottK> mok0: I've recently decided to take a break from reporting LP bugs because it was taking too much time and the LP devs apparently didn't appreciate my sarcasm.
[15:52] <mok0> ScottK: heh, well I guess they are stressed out already
[15:52] <ScottK> Well if they'd just take a break from making it worse, we'd all feel better.
[15:53] <mok0> ScottK: yeah... at least changing fundamental stuff like tarball paths and so on, they should be more careful
[15:54] <ScottK> I could understand the churn back when they were < 1.0, but come on ....
[15:55] <mok0> ScottK: at least, provide some kind of temporary compatibility with the old stuff
[15:55] <ScottK> Yes, add the new, run in parallel, deprecate the old, and later remove it is pretty standard stuff
[15:55] <mok0> ScottK: I have to say, I've actually become quite happy with LP
[15:56] <mok0> generally
[15:56] <ScottK> It's more stable that it used to be, so that's definitely good.
[15:56] <hyperair> i can't say that. i can't change my bug statuses with the new interface
[15:56] <hyperair> complains of some unknown error without even an error message
[15:56] <mok0> They DO need to make it faster
[15:56] <hyperair> they need to make it support git ;-)
[15:56] <ScottK> This last update seemed to predominately make information I'm interested in harder to find.
[15:57] <mok0> hyperair: Uhm, doesn't it?
[15:57] <ScottK> Plus breaking browser compatibility with the one I use.
[15:57] <ScottK> mok0: It can import from Git, but not use it.
[15:57] <hyperair> mok0: i mean native git support, not translating everything into bzr.
[15:57] <hyperair> i don't like the new change with the PPA webpages
[15:57] <mok0> ScottK: Ah, yes, import only
[15:58] <hyperair> i no longer see a list of my packages unless i go to +packages
[15:58] <ScottK> hyperair: I agree.
[15:58] <ScottK> The package pages are less useful too.
[15:58] <mok0> hyperair: I've thrown the towel in... and started using bzr
[15:58] <directhex> Lazy, the screensaver part of this does not work. i'm not sponsoring it.
[15:58] <hyperair> mok0: noooooooooooooo how could you
[15:58] <directhex> Lazy, just running it on the command line is working
[15:58] <noodles775_> hyperair, ScottK : Please help us improve them :)
[15:58] <hyperair> use git and i'll think about it ;-D
[15:59] <mok0> hyperair: I am a traitor :-)
[15:59] <noodles775_> hyperair, ScottK : I'd be happy to talk with you both about the reasoning behind the changes...
[15:59] <hyperair> mok0: you're not supposed to say that with a grin on your face =(
[15:59] <noodles775_> (we tried to involved everyone, but not many people responded)
[15:59] <mok0> hyperair: ... it's out of embarrasment
[15:59] <ScottK> noodles775_: Every time you  change the U/I, it doesn't matter if it actually is better or not, there is a substantial relearning cost.
[15:59] <hyperair> sheepish grins eh
[16:00] <mok0> hyperair: :-P baaaaaah
[16:00]  * hyperair facepalms
[16:00] <mok0> hyperair: I started using LP for a project and it is very nice for that
[16:00] <noodles775_> ScottK: yes, and one of the *big* changes here (as you know) was to make the ppa index more for users of your ppa, rather than developers. Of course that means relearning for developers - which is frustrating.
[16:01] <hyperair> mok0: i do like launchpad as a whole, but i really wish there's git support. bzr still drives me up the wall from time to time
[16:01] <mok0> hyperair: yeah
[16:01] <ScottK> noodles775_: We really need some stability
[16:01] <sistpoty|work> ScottK: http://spooky.informatik.uni-erlangen.de/~sistpoty/fgfs-atlas_0.3.1-1_fix_ftbfs.debdiff (can't upload from work though, -enosigningkey)
[16:01] <mok0> hyperair: I have now learned how to be on pretty much the same basic skill level as I am with git
[16:02] <sistpoty|work> ScottK: oh, I think I didn't adjust the maintainer field yet (my work box is not too good for ubuntu packaging *g*)
[16:02] <ScottK> sistpoty|work: Thanks.  I'll have a look
[16:02] <sebner> sistpoty|work: I think you'll do excellent, TM sistpoty. EPIC FAIL
[16:02] <noodles775_> ScottK: yes - the 3.0 UI changes were quite substantial right across LP, but will be much more settled now post 3.0.
[16:02] <mok0> hyperair: however, bzr is more difficult IMO, because the huge number of different ways you can use it
[16:02] <sistpoty|work> sebner: haha
[16:02] <ScottK> noodles775_: Wasn't that also said after 2.0?
[16:03]  * mok0 admits those PPA changes on LP has gone over his head
[16:03] <hyperair> mok0: i miss my staging area.
[16:03] <mok0> hyperair: huh?
[16:03] <Lazy> directhex: well, thanks anyway for checking it
[16:03] <hyperair> mok0: (talking about git)
[16:03] <sebner> sistpoty|work: /me starts learning maths (yes, after the first 2 hours) ;)
[16:03] <mok0> hyperair: ah
[16:03] <hyperair> well at least there's git-bzr
[16:03] <hyperair> but it isn't perfect
[16:03] <noodles775_> ScottK: I'm not sure - I wasn't around then - but I believe you.
[16:04] <sistpoty|work> sebner: good, good. /me didn't and flunked the first math test :P
[16:04] <hyperair> i always did find bzr's revnos a little confusing. there can be more than one commit with the same revno, depending on which branch you're looking at.
[16:04] <mok0> hyperair: yes! That is VERY confusing
[16:04] <ScottK> noodles775_: Also I have the impression very little usability analysis was done on this new U/I.  I find many tasks take more clicks and are harder than they were before.
[16:04] <hyperair> mok0: yeah, and so i still like my commit hashes at the end of the day
[16:05] <mok0> hyperair: we're on the same page here
[16:05] <hyperair> mok0: if there's one thing git seriously got right, it's this, imo.
[16:05] <sebner> sistpoty|work: haha. Well, no one cares as you are still "threre" but I hope I'm doing better :P
[16:05] <sistpoty|work> heh
[16:05] <mok0> hyperair: yeah. I also think git is better technology, but bzr ... works
[16:05] <directhex> Lazy, aha, fixed it
[16:06] <Lazy> cool
[16:06] <sistpoty|work> noodles775_: bugs.launchpad.net/<bugnumber> would be my absolute totally awesume super uber feature (as I never recall the url to a bugnumber correctly)
[16:06] <siretart`> sistpoty|work: please ping me on your next break ;-)
[16:06] <hyperair> mok0: did you ever see any of those "hai i've changed my repository version and now you can't merge from me anymore" situations?
[16:06] <directhex> Lazy, you need to file a sync request for flam3, though. then beg someone in ~motu-release to let it in
[16:06] <noodles775_> ScottK: We did our best to collect feedback based on the mockups - and went through a number of iterations (you can see the collected input feedback at: https://dev.launchpad.net/VersionThreeDotO/Soyuz/PPAUI/Inputs)
[16:06] <mok0> hyperair: ... and I really like the integrateion with LP branches.
[16:06] <hyperair> mok0: that was what drove me to look at git.
[16:06] <sistpoty|work> siretart`: ping ;)
[16:06] <siretart`> sistpoty|work: it's launchpad.net/bugs/$no
[16:06] <Lazy> directhex: what was the problem so i can put it in the bugreport also
[16:07] <hyperair> er not the LP branches, i mean the whole reopsitory version clash issue
[16:07] <noodles775_> sistpoty|work: launchpad.net/bugs/<bugnumber> ?
[16:07] <mok0> hyperair: I don't think bzr actually would work with a huge project like Linux, with hundreds of contributors and thousands of patches
[16:07] <directhex> Lazy, bad "--zoom 1" parameter in /usr/share/applnk/System/ScreenSavers/electricsheep.desktop
[16:07] <sistpoty|work> noodles775_: but why not +bug or +bugs? My brain always tries these first :/
[16:07] <directhex> Lazy, bug affects the debian package too
[16:07] <sistpoty|work> (anyway afk for a moment)
[16:08] <mok0> hyperair: It is acceptable with a smallish project like packaging or one with just a few contributors
[16:08] <hyperair> mok0: i'm sure the bzr devels would beg to differ ;-)
[16:08] <mok0> hyperair: actually, I think they tried importing Linux into a bzr repo and it didn't work
[16:09] <hyperair> lol
[16:09] <hyperair> that's sad
[16:09] <mok0> hyperair: saw that somewhere, in my random surfing
[16:09] <hyperair> heheh
[16:09] <ScottK> noodles775_: Another issue I have is the increasing use of icons.  I find it harder and harder to figure out how to do stuff (this in combination with the U/I churn is maddening)
[16:09] <mok0> hyperair: one thing is that git is the fastest CMS around
[16:09] <mok0> hyperair: AFAIR there's not a single operation where git is slower
[16:10] <mok0> hyperair: some of the other CMS'es might be similar fast in some operations, but not all of them
[16:10] <Lazy> how do i report a bug without lauchpad redirecting me all the time? :)
[16:11] <mok0> Lazy: bottom right hand corner "Disable edge redirect"
[16:11] <hyperair> mok0: heh that's not surprising
[16:11] <noodles775_> ScottK: yes - the understanding the icons should not be necessary - they should be an aid. There are some cases where this was hard (eg. builders page).
[16:11] <directhex> Lazy, a sync request you should use the "requestsync" command-line tool
[16:11] <Lazy> directhex: ok thanks
[16:11] <directhex> Lazy, unless you know to set all the required subscriptions by hand. without which a bug may go unnoticed
[16:11] <mok0> directhex: does that work after the 3.0 upgrade?
[16:12] <directhex> mok0, pass!
[16:12] <mok0> directhex: I ask because some of the other ubuntu-dev-tools are broken
[16:12] <hyperair> directhex: it still misses out on motu-release for FFes
[16:12] <directhex> bleh
[16:12] <ScottK> noodles775_: One example is I find https://launchpad.net/ubuntu/karmic/+source/quassel/0.5.0~rc2-0ubuntu1 far more readable for build status than https://launchpad.net/ubuntu/+source/quassel/0.5.0~rc2-0ubuntu1
[16:12]  * directhex declares computers to be "lame"
[16:13] <hyperair> well they can't walk, so strictly speaking, that's true, yes
[16:13] <mok0> ScottK: you're right
[16:14] <mok0> noodles775_: the download section should go back to where it was
[16:15] <mok0> noodles775_: ... the extra detail is nice, but it could be collapsed into an expandable section with a |> icon
[16:15] <noodles775_> mok0, ScottK: that's all great feedback, but I'm not responsible for those pages, so it'd be *great* if you could put that info into a bug so it can get scheduled etc.
[16:15] <mok0> noodles775_: which would make it render faster too
[16:15] <noodles775_> (well, I could be - if my manager assigns it to me :) ).
[16:16] <ScottK> noodles775_: I'm on vacation from LP bugs.
[16:16] <ScottK> Feel free to copy/paste from here if you want
[16:16] <mok0> ScottK: I'll do it
[16:17] <mok0> ScottK: if you promise to "affects me too" it
[16:17] <ScottK> mok0: Sure.  I'm reasonably certain that doesn't actually do anything, but I will.
[16:18] <noodles775_> ScottK: :), will do.
[16:20] <mok0> ScottK: what summary title do you want for the bug?
[16:20] <bddebian> Heya gang
[16:21] <mok0> Yo bd
[16:22] <bddebian> Hello mok0
[16:22] <ScottK> mok0: Whatever I'd pick would proabably be to sarcastic for their tastes.  I trust your judgement.
[16:27] <AnAnt> dholbach: remember that Roland guy ?
[16:27] <dholbach> AnAnt: do you have a little bit more context? :)
[16:27] <dholbach> I might remember :)
[16:28] <AnAnt> dholbach: when I had an issue with the attitude of someone who had a problem with sl-modem
[16:28] <dholbach> ah yes
[16:28] <dholbach> what happened?
[16:29] <AnAnt> dholbach: he started another one of those (but with the upstream maintainer of an Intel modem chip) on linmodems mailing list
[16:29] <dholbach> urgh
[16:29] <dholbach> :-(
[16:34] <mok0> ScottK: bug 443200
[16:36] <ScottK> mok0: Clicked.  Thanks.
[16:36] <ScottK> sistpoty|work: Uploaded.  Thanks.
[16:38] <mok0> noodles775_: done, see ^^
[16:38] <noodles775_> Thanks mok0 :)
[16:38] <mok0> noodles775_: you can still smile :-)
[16:40] <ScottK> sistpoty|work: I also sent your patch to the Debian bug.
[16:40] <AnAnt> bye
[16:51] <sistpoty|work> ScottK: thanks!
[16:52] <ScottK> sistpoty|work: Thank you.
[16:53] <Lazy> directhex: how did you get that debian version of electricsheep to work?
[16:53] <directhex> Lazy, by building it in karmic
[16:54] <Lazy> ok
[16:54] <Lazy> because i just tried downloading debian testing versions
[16:54] <Lazy> it works from commandline but screensaver doesn't work
[16:56] <directhex> did you fix /usr/share/applnk/System/ScreenSavers/electricsheep.desktop ?
[16:56] <Lazy> i tried removing that "zoom 1"
[16:57] <mok0> Can anyone explain this? gdebi tells me: Dependency is not satisfiable: python-apt (>= 0.7.9) but I have python-apt_0.7.9~exp2ubuntu10 installed.
[16:58] <ebroder> mok0: ~ comes before nothing
[16:58] <ebroder> So 0.7.9~exp2ubuntu10 is actually less than 0.7.9
[16:58] <mok0> ebroder: I know, but:
[16:58] <mok0> dpkg --compare-versions 0.7.9 le 0.7.9~exp2ubuntu10 |echo yes
[16:58] <mok0> ebroder, hang on
[16:58] <ebroder> mok0: That's not the invoke. It's dpkg --compare-versions 0.7.9 le 0.7.9~exp2ubuntu10 && echo yes
[16:58] <RainCT> mok0: the dependency should have been on ">= 0.7.9~" to work with backports
[16:59] <mok0> RainCT: yeah
[17:00] <hyperair> mok0: it's && echo yes || echo no
[17:00] <mok0> hyperair: yeah, I saw that after I pasted it here
[17:00] <hyperair> heheh
[17:00] <mok0> >< d'oh
[17:01] <hyperair> i had to conduct a small bash course once, and that's what i came up with in order to show people things.
[17:01] <mok0> hyperair: yeah, how dumb it is to pipe stuff into "echo yes" :-P
[17:02]  * RainCT just uses  ; echo $?
[17:02] <mok0> RainCT: ... ah, obfuscation optimized
[17:04] <hyperair> RainCT: well i use that too, but it's easier to show beginners this way =p
[17:05] <Darxus> So it looks like the hugin 0.8.0 merge is making it into karmic:  https://bugs.launchpad.net/ubuntu/+source/hugin/+bug/439396
[17:05] <Darxus> What about the libpano sync it depends on?
[17:06] <Darxus> Oh, there's another bug for that, checking.
[17:11] <Darxus> I believe both of these bugs have recieved sufficient acks and just require uploads:  https://bugs.launchpad.net/ubuntu/+source/hugin/+bug/439396 https://bugs.launchpad.net/ubuntu/+source/libpano13/+bug/440177
[17:11] <Darxus> (The latter is a dependancy of the former.)
[17:19] <ScottK> Darxus: It has now.
[17:19] <Darxus> ScottK: It has what?
[17:20] <ScottK> Darxus: Sufficient acks.
[17:20] <ScottK> The pano one needed a 2nd ack
[17:20] <Darxus> ScottK: Ah, thanks.
[17:20] <Darxus> So they need uploads?  How does that happen?
[17:21] <ScottK> Subscribe ubuntu-universe-sponsors to the bugs and someone will review for that
[17:22] <Darxus> Thanks.
[17:24] <Darxus> Done.
[17:31] <mok0> ScottK: there is a very long line of dependencies involved in backporting ubuntu-dev-tools
[17:32] <mok0> ScottK: python-setuptools: missing
[17:32] <mok0> python-zope.interface: missing
[17:32] <mok0> python-zopeinterface: missing
[17:32] <mok0> python-wadllib: missing
[17:33] <ScottK> I think you'll end up needing most of them for the LP stuff no matter how you do it.
[17:34] <mok0> Yeah... probably easier to upgrade
[17:49] <micahg1> are there any rules for fixing FTBFS for karmic, or do I just go after a package?
[17:49] <ScottK> You might mention here what you are going after so people don't duplicate work.
[17:49] <ScottK> Other than that, not really.
[17:56] <ari-tczew_> hello
[17:56] <ari-tczew_> [18:55] [Nick] Nickname already in use.
[17:56] <ScottK> Hello ari-tczew_
[17:56] <ScottK> It's not there now
[17:56] <ari-tczew_> my "ari-tczew" is already in use? wtf?!
[17:57] <ScottK> If you get bumped offline there is s timeout period for the old nick.
[17:57] <ari-tczew_> yhym
[17:57] <rrittenhouse> What would the (smartest) way to upgrade PHP to a newer version on my Live Ubuntu Hardy server LTS server? Are there any PPA's?
[17:58] <ScottK> rrittenhouse: This really isn't the channel for that
[17:58] <ScottK> I'd ask on #ubuntu-server
[17:58] <rrittenhouse> oo thx
[17:58] <_ruben> nickserv can boot off your ghost connections
[18:04] <ari-tczew> _ruben: thnx, but there is other problem
[18:05] <ari-tczew> if I'm connecting at startup to 2 channels, then one channel can't connect me ;-/
[18:08] <ari-tczew> I'm looking for ACK (complete FFe request): bug 427886
[18:36] <Darxus> Hah, I just figured out that debian/patches = quilt.
[18:37] <Laney> not necessarily
[18:49] <Darxus> Quilt can't be used to patch Build-Depends right?
[18:50] <ebroder> Darxus: quilt pretty much shouldn't be used to patch anything in the debian/ directory, only upstream source
[18:51] <ScottK> Darxus: It can
[18:51] <ScottK> Wait
[18:51] <ScottK> Misread it.  What ebroder said.
[18:51] <Darxus> Heh, thanks.
[18:51] <Darxus> I'm playing with merging hugin 2009.2.0 (current upstream).
[18:59] <sharms> fabrice_sp: Can you give me a hand with 423755
[19:00] <hyperair> ScottK: could you look at bug #442328 please?
[19:00] <ScottK> Right.  I think I meant to ack that one yesterday.
[19:00]  * ScottK looks
[19:01] <fabrice_sp> hey sharms
[19:01] <hyperair> thanks
[19:01] <fabrice_sp> bug #423755
[19:01] <fabrice_sp> oh this one
[19:01] <sharms> fabrice_sp: yesterday you said you wanted a different approach, I cant see a cleaner way of just copying the file outside of a patch
[19:02] <sharms> what would you suggest?
[19:02] <fabrice_sp> I have to check both files, to see what is the real difference
[19:02] <sharms> someone else said I should splice up the xml file and ignore spaces, but since upstream supplied it I dont think its proper to modify the xml directly
[19:03] <fabrice_sp> the other approach is to have this file in debian, and copy it. But I also saw a comment saying that they could have regressions...
[19:03] <fabrice_sp> Do you think it would be possible to have upstream indicate the line(s) that fix this specific issue?
[19:03] <fabrice_sp> that would definitively be better
[19:04] <sharms> fabrice_sp: the debian maintainer quit maintaining it, but the xml file itself we got from the author
[19:04] <sharms> in the forum post: http://opbyte.freeforums.org/grsync-gtk-2-0-2-16-6-t112-15.html
[19:05] <sharms> he advices we use this xml file as he regenerated it using gtkbuilder, and it is included in future versions
[19:05] <fabrice_sp> I'll see later, if I can see something... Otherwise, it would be good to publish the resulting  package in a ppa, and assk for testing
[19:05] <sharms> fabrice_sp: ok and just so we are on the same page, today if we dont change it it wont work at all
[19:05] <fabrice_sp> have to go now. bbl
[19:05] <sharms> so regressions cant be more than not working completely
[19:06] <fabrice_sp> I know, but uplaoding something that won't work is not a good solution either :-)
[19:06] <sharms> haha, I am not shooting for 'not work less' either
[19:06] <fabrice_sp> could you just upload the resulting package in a ppa?
[19:06] <Darxus> Heh.
[19:06] <sharms> yup will do
[19:07] <fabrice_sp> Hey Darxus. I saw your email. Have to lunch now. Will look after :-)
[19:07] <Darxus> fabrice_sp: Thanks.
[19:07] <fabrice_sp> thanks sharms :-)
[19:07] <sharms> thank you for the time
[19:20] <sharms> I am pretty sure with the current ppa build queues my test package wont be ready by release :)
[19:25] <irvingpop> Hi, can someone explain the purpose of the Standards-Version field in the debian/control file?
[19:26] <irvingpop> I'm wondering if it can be safely updated
[19:29] <mok0> irvingpop: for lucid it should be 3.8.3
[19:30] <Laney> mok0: see Debian policy, and /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
[19:30] <Laney> er
[19:30] <Laney> irvingpop even
[19:30] <mok0> irvingpop: but you need to check that new policy rules are fulfilled in the package
[19:30] <ScottK> irvingpop: Generally we prefer not to update standards version ahead of what Debian had sone
[19:30] <ScottK> sone/done
[19:30] <Laney> it refers to the version of Debian policy that the package conforms to
[19:32] <irvingpop> Thanks ScottK and mok0.   I'm trying to eliminate lintian errors for the package I uploaded to REVU
[19:32] <ScottK> dtchen: Since you TIL wvstreams: http://code.google.com/p/pathfinder-pki/issues/detail?id=26 (I'm working on the NBS from the transition)
[19:33] <irvingpop> Mine is at 3.8.0, because that is what dh_make put in place
[19:33] <ScottK> irvingpop: Is the package in Debian at all?
[19:33] <irvingpop> nope
[19:33] <irvingpop> I'm closing a needs-packaging bug I filed
[19:33] <ScottK> OK, then make it 3.8.3 and make sure you follow the current standards.
[19:33] <ScottK> irvingpop: You know this won't get into Karmic, right?
[19:33] <irvingpop> OK, thank you :)
[19:34] <ScottK> Now isn't a bad time to be getting packages ready for the next release though
[19:34] <irvingpop> I'm just doing what I can to get my code contributed to the community
[19:34] <mok0> irvingpop: do you have a PPA?
[19:34] <irvingpop> yes
[19:34] <mok0> irvingpop: k :-)
[19:35] <irvingpop> I've published the package in my PPA already.   I'm under the impression that I need to put it in REVU to get the attention of the MOTU team and get mentorship/sponsorship
[19:35] <ScottK> irvingpop: You might also consider trying to get your package into Debian then.  Once it's in Debian, it will automatically get sync'ed into Ubuntu
[19:35] <ScottK> irvingpop: That's correct
[19:36] <mok0> irvingpop: yeah REVU is the nexus of new package for Ubuntu
[19:37] <irvingpop> the port to Debian would be easy,  I'm just not running Debian
[19:40] <irvingpop> One more quick question.    Is there a way to get postinst  NOT to automatically start the init script?   I had to remove the #DEBHELPER# bit to stop it, but that makes lintian complain
[19:40] <mok0> irvingpop: you can easily have a Debian chroot
[19:41]  * mok0 seems to remember something about init scripts...
[19:41] <ebroder> irvingpop: Go look at the arguments to dh_installinit
[19:43] <irvingpop> ah, thats helpful
[19:43] <irvingpop> so I could just change the rules file to  dh_installinit --no-start
[19:44] <fabrice_sp> Hi. If I upload a package which will have a missing dependency, will it automatically build when the dependency will be uploaded?
[19:46] <Laney> yes
[19:47] <mok0> I think it depends in what way the dependecy is missing
[19:47] <mok0> If it's a not-yet existing package, it will fail
[19:48] <ScottK> It will either dep-wait and start automatically or fail and you can retry it at the right time.  No new upload would be needed either way
[19:49] <surfzoid> Hi, i m a developer and i m building ubuntu deb of my software, what must i do to see them in ubuntu repository's ?
[19:52] <randomaction> surfzoid: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[19:52] <surfzoid> thanks :-)
[19:53] <fabrice_sp> cool. Thanks laney, mok0 and ScottK :-)
[19:54] <surfzoid> hum, to be quick, is there here some people who know the OpenSuse Build Service ?
[19:54] <ScottK> Not anymore than I can help.
[19:58] <randomaction> If a *.h file from evolution-dev includes a *.h file from libgtkhtml3.14-dev, then evolution-dev should depend on libgtkhtml3.14-dev, right?
[19:58] <geser> randomaction: yes
[19:58] <randomaction> ok, I'll double-check and file a bug
[20:02] <geser> you might also want to check if the pkg-config file mentions any other apps (pkg-config files) not listed as pkg dependencies for the -dev package
[20:06] <randomaction> is it that thing that adds include paths?
[20:08] <geser> yes, it lists the needed libs (-lfoo) and also the include dirs (-Ibar)
[20:08] <surfzoid> Is there a build server in ubuntu world, like the OpenSuse Build Service one ?
[20:09] <geser> surfzoid: if you want to get packages build for Ubuntu, look at PPA
[20:09] <geser> !PPA
[20:10] <surfzoid> geser: i think it will be incompatible with the client i add writed :-)
[20:11] <surfzoid> http://monoosc.sourceforge.net/
[20:11] <geser> what are you trying to do?
[20:12] <surfzoid> I have write a client to the opensuse build server API, i try to see if i can extend my client to other build server
[20:13] <surfzoid> geser: yu see ?
[20:14] <geser> yes
[20:14] <surfzoid> geser: so PPA is a build server ? and it have an public API ?
[20:15] <geser> you can also access Launchpad (PPA is part of it) through an API too
[20:15] <geser> PPA is your own repository where you can upload source packages (deb format) and get it build for some arches
[20:16] <geser> you can access it also through the LP API
[20:16] <surfzoid> at this time i guess there is existing client, web, cmd line ?
[20:16] <sebner> hihu geser =)
[20:17] <geser> hi sebner
[20:18] <geser> surfzoid: for uploading the usual tools like for the main Ubuntu or Debian archive too (dput), for download you can include it in your apt configuration, and other things are currently done through a webbrowser (I don't know of any app yet using the LP API for it)
[20:19] <fabrice_sp> ari-tczew, there?
[20:19] <surfzoid> hum, oki, and you know if the API, use the REST technology ?
[20:20] <geser> surfzoid: see https://help.launchpad.net/API for a description of the API
[20:20] <surfzoid> oki
[20:21] <geser> you first task would probably be to write mono bindings for it as currently only python bindings exist
[20:21] <surfzoid> nop, it is write it use REST :-) so my actual framework is okay :-)
[20:21] <surfzoid> just need to get the list of all url function
[20:22] <geser> https://edge.launchpad.net/+apidoc/
[20:23] <surfzoid> after it will be like that : http://monoosc.svn.sourceforge.net/viewvc/monoosc/MonoOSC/MonoOBSFramework/Class/Functions/About/GetAbout.cs?revision=200&view=markup
[20:25] <surfzoid> in fact there isn't lot of unction to write, only this few one https://edge.launchpad.net/+apidoc/#packageset
[20:25] <surfzoid> :-)
[20:26] <surfzoid> but they seem to many different to be include in my actual gui, i could use my engine framework and add this new urls, but need a complete new GUI
[20:28] <surfzoid> **too many
[20:28] <geser> surfzoid: I guess packageset is not the correct one, I think you need "archive" (a PPA is an archive) and "build" if you are interested in the state of the builds (and any logs of it)
[20:28] <surfzoid> ho oki
[20:29] <surfzoid> and packageset is for what so
[20:30] <surfzoid> hey, suddenly there is more :-)
[20:30] <geser> packagesets are/will be used in the main archive to control who can upload which packages (package sets) to the main archive
[20:31] <surfzoid> oki
[20:31] <irvingpop> OK, my fixed packages are uploaded to REVU.   http://revu.ubuntuwire.com/p/flashcam  and  http://revu.ubuntuwire.com/p/vloopback-dkms -- not that they'll go anywhere for a while
[20:31] <surfzoid> some ubuntu developer speak C#
[20:31] <ScottK> I think you want directhex
[20:31] <ScottK> He apparently bleeds C#.
[20:31] <irvingpop> Thanks for your help.   Feel free to hit me up when you start accepting packages :)
[20:31] <surfzoid> héhé yes :-)
[20:32] <surfzoid> i spoke with him at #mono
[20:32] <geser> yes, directhex is our local C#/Mono guru
[20:32] <ScottK> irvingpop: It'll be The first or second week of November likely.
[20:33] <irvingpop> is there an equivalent of -backports,  or can they only go into 10.04 ?
[20:35] <shakaran1> hi, how to package a program for several distributions, i.e. jaunty and karmic?
[20:36] <av`> shakaran1, if a package is on karmic already you can request a backport
[20:36] <av`> for jaunty
[20:36] <geser> or are you asking about how to do it in a PPA?
[20:36] <irvingpop> For my bug https://bugs.launchpad.net/ubuntu/+bug/434883 ,  what's the best way to modify it to show that the work has been completed, just needs review?
[20:38] <shakaran1> av`: No, the package isn't in karmic. I'm debianized a program and I like to make .deb for jaunty and one for karmic.
[20:38] <ScottK> irvingpop: There is backports for after it gets into Lucid (10.04)
[20:38] <shakaran1> geser: yes, for example on my ppa
[20:38] <av`> shakaran1, if you wanna see it into the main archive, that's impossible then :)
[20:38] <av`> shakaran1, you can have it on your PPA
[20:39] <ScottK> irvingpop: The main thing is to upload the package to REVU.  That's where people mostly look for new packages.
[20:39] <irvingpop> Thanks, ScottK
[20:40] <shakaran1> how to do for my ppa? I have a debian/control different for jaunty and for karmic
[20:40] <directhex> i'm about to go to the supermarket. Laney, hyperair, i choose you!
[20:40] <geser> shakaran1: for your PPA upload it once targeting jaunty and once targeting karmic (with a slight different version, e.g. by appending the releasename to your version string)
[20:40] <av`> shakaran1, different B-D / Depends?
[20:41] <av`> shakaran1, anyway you can easily make two packages with different versioning, one for jaunty and one for karmic then you push it to your PPA paying attention to the target (to be set into the changelog)
[20:41] <shakaran1> av`: yes, for jaunty I have depends pygtk(>=2.14) and for karmic  pygtk(>=2.16)
[20:42] <av`> shakaran1, like 1.2-1ubuntu1~jaunty1 or 1.2-1ubuntu1~karmic1
[20:42] <hyperair> directhex: uh what?
[20:42] <av`> shakaran1, so you gonna upload two different packages with the changes on the control
[20:43] <av`> shakaran1, is that clear enough?
[20:43] <shakaran1> exactly
[20:43] <shakaran1> av`: ok, now my problem is how to create a easy way for create .deb with the same directory of source
[20:44] <av`> shakaran1, two different trees?
[20:44] <av`> shakaran1, you don't need to have two binary files built, that's not what you want
[20:44] <av`> shakaran1, you make a package1/ dir and a package2/ dir
[20:45] <av`> shakaran1, you add debian dirs on them with the changes on the control file or whatever
[20:45] <av`> shakaran1, you hack the changelog (e.g target, versioning)
[20:45] <irvingpop> thanks for your help, guys.  talk to you in November!
[20:45] <av`> shakaran1, you upload to your PPA
[20:45] <shakaran1> my tree looks like:
[20:45] <shakaran1> sandbox/
[20:45] <shakaran1>   myapp-0.0.1/
[20:45] <shakaran1>   myapp-0.02/
[20:45] <shakaran1>   ...
[20:45] <shakaran1> Inside I have the debian/...
[20:45] <shakaran1> If I run dpkg-buildpackage where? On myapp-0.01 I cannot have two different control file
[20:46] <shakaran1> (sorry for flood, on my message was only a line)
[20:46] <av`> shakaran1, use pastebin
[20:46] <av`> !paste
[20:47] <av`> shakaran1, usually we like to work on clean trees
[20:47] <av`> shakaran1, so giving a dpkg-buildpackage at top level is not the way to go
[20:47] <av`> shakaran1, give a try to pbuilder
[20:47] <av`> shakaran1, anyway you should have sandbox/ then my-app-0.0.1/debian and myapp-0.0.2/debian
[20:48] <shakaran1> http://paste.ubuntu.com/286470/
[20:48] <av`> shakaran1, we have *two* different debian dirs into two source trees
[20:48] <shakaran1> two? but how to choose for karmic or jaunty?
[20:48] <shakaran1> some option like destination-debian-src-dir?
[20:49] <av`> shakaran1, no, looks like you didnt read basic guides :) but anyway the target ( jaunty / karmic ) is set on the changelog
[20:49] <av`> debian/changelog
[20:49] <shakaran1> http://paste.ubuntu.com/286471/ this is wrong?
[20:50] <geser> shakaran1: you can upload e.g. my-app 0.0.1-1jaunty with the control file for jaunty, and my-app 0.0.1-1karmic with the control file for karmic
[20:50] <av`> shakaran1, how can you have two debian dirs into one source? :)
[20:51] <av`> shakaran1, your tree should be:
[20:51] <av`> app-0.1/debian/control --> jaunty
[20:51] <shakaran1> ok, then, this is my actual changelog (only for karmic) http://paste.ubuntu.com/286474/ if I change karmic on some lines for jaunty it works?
[20:51] <av`> app-0.1-karmic/debian/control --> karmic
[20:52] <av`> shakaran1, if you change target to jaunty it will be built against jaunty
[20:52] <shakaran1> humn...I understand...then several foldes, but for each version of myapp
[20:52] <shakaran1> *folders
[20:52] <av`> shakaran1, but you need to be sure you made the needed changes on control file as well
[20:52] <av`> shakaran1, not several, two folders, one for each target
[20:52] <shakaran1> yeap, exactly
[20:53] <shakaran1> umn, I gonna try now
[20:53] <shakaran1> the name for folder is app-0.1-karmic or better app-0.1~karmic?
[20:56] <av`> shakaran1, you can use whatever name you want for the folder
[20:56] <shakaran1> ok
[21:16] <kklimonda> is it early enough to change application settings for universe apps? I'd like to remove a reduntant option from transmission-daemon starting script that just makes problems. should I open a bug about it for the later reference?
[21:29] <Darxus> kklimonda: Open a bug.
[21:45] <Darxus> I merged hugin 2009.2.0 from debian experimental:  https://bugs.launchpad.net/ubuntu/+source/hugin/+bug/443328
[21:45] <Darxus> Is there enough chance of this getting in karmic that I should post to the hugin list asking for testing?
[21:55] <arand> What is it that keeps changelogs lagging so much in publication?
[21:55] <arand> Why would they be anything but simultaneous to package publication?
[21:57] <shakaran1> I made a script for dpkg-buildpackage -rfakeroot -kMYKEY, but I have to put the GPG secret password many times. How to avoid this?
[21:59] <geser> use gpg-agent to cache your passphrase and/or only sign the version which you really want to upload
[21:59] <shakaran1> Do you have some guide or tutorial?
[22:05] <fabrice_sp> Darxus, as it's only in experimental, I'm not really confident... I would wait to have more feedback in Debian
[22:06] <shakaran1> geser: I did this: http://paste.ubuntu.com/286527/ but it dont work. It ask me four times for the key
[22:08] <fabrice_sp> hyperair, you will manage Bug #442328, right?
[22:08] <Darxus> fabrice_sp: Okay, thanks.
[22:09] <Darxus> fabrice_sp: The Debian maintainer said I intend to upload to unstable as soon as the other hugin maintainers
[22:09] <Darxus> have had their say."
[22:09] <Darxus> Should have been a quote before "I".
[22:09] <fabrice_sp> Darxus, when did he said that?
[22:09] <shakaran1> geser: I use wrong gpg-agent? some mistake?
[22:10] <Darxus> fabrice_sp: Date: Sat, 3 Oct 2009 19:22:14 +0200
[22:13] <geser> shakaran1: you should also tell gpg to use the agent (use-agent in .gnupg/gpg.conf)
[22:14] <shakaran1> where I modify the script?
[22:14] <Darxus> fabrice_sp: What if there's nothing specifically holding hugin 2009.2.0 back from sid other than lack of response of debian maintainers?  And what if I get a bunch of people to test it?
[22:15] <ScottK> Darxus: First question is why is it in Experimental and not Unstable?
[22:15] <ScottK> Until you know the answer to that question, don't even think about it.
[22:16] <geser> shakaran1: good question, I don't see an easy way to get it done in your script
[22:17] <shakaran1> Here says: http://www.debian-administration.org/articles/452 To configure gpg to make use of gpg-agent when available, edit ~/.gnupg/gpg.conf, and add a line use-agent.  Then, restart your session, and you should have gpg-agent running and the environment variable $GPG_AGENT_INFO set.
[22:17] <shakaran1> Do I have to do this for work?
[22:17] <shakaran1> or more things?
[22:19] <geser> adding the option to your gpg.conf should be enough as you start the gpg-agent in your script (the gnupg-agent package also install a script to start it as part of your xsession if you have use-agent in your gpg.conf)
[22:19] <Darxus> ScottK: I believe the maintainer just wanted to do some extra testing.  I'll ask.
[22:19] <shakaran1> yeap! IT WORKS!
[22:20] <shakaran1> THANKS!
[22:21] <shakaran1> I love Ubuntu more and more each day
[22:22] <slacker_nl> shakaran1: don't we all ;)
[22:23] <Darxus> Heh.
[22:24] <shakaran1> :)
[22:26] <PMantis> Hi, #ubuntu doesn't seem to know, so maybe here... What's the "correct" way to update the symlinks in /etc/rcS.d while keeping dependencies in mind? There's a command that looks at all the init scripts and dependencies and creates numbered symlinks to be sure dependent items start at appropriate times... forget what it is.
[22:27] <PMantis> That's supposed to be /etc/rcX.d. :-)
[22:30] <ScottK> PMantis: Your inability to get a good answer in #ubuntu doesn't make this a support channel.
[22:31] <ScottK> PMantis: Have a look at man update-rc.d
[22:32] <PMantis> ScottK: Sorry, I'm not here to offend or interrupt. I have been *told* to go here in the past, and have been well-received and helped.
[22:32] <ScottK> OK, well I gave you your answer in any case.
[22:33] <PMantis> Also, as far as I can recall update-rc.d  allows me to specify what S and K number I want. I received that answer in #ubuntu.
[22:33] <PMantis> However, what I'm looking for re-reads all the scripts at once, removed all the symlinks in rc?.d, and recreates them in order of dependencies.
[22:34] <PMantis> I believe it is tightly bound to upstart.
[22:35] <PMantis> If you don't know, thanks anyway. I did this for a customer machine with custom init scripts a few months ago, now I need to do it again. I should have kept notes!!
[22:36] <Darxus> https://help.ubuntu.com/community/BootFromCD and https://help.ubuntu.com/community/BurningIsoHowto should be much easier to find.
[22:36] <ScottK> There are two dependency based boot systems.  One, done in Debian is strictly sysv init.  The other is upstarts, but it didn't do much until Karmic.
[22:36] <ScottK> Not sure which you want.
[22:38] <PMantis> Darxus, ScottK: Thanks, I'll look closer.. I'm actually making a custom live cd with my own services embeded, so your link is unintentionally relevant.
[22:39] <PMantis> Darxus: Nevermind, either that wasn't meant for me, or you misunderstood. :)
[22:48] <Darxus> PMantis: Wasn't meant for you.
[22:59]  * PMantis found it: insserv
[23:09] <jbernard_> I've attached a patch to bug #443241 that fixes the FTBFS, if anyone has time to take a look
[23:18] <fabrice_sp> jbernard_, please subscribe ubuntu universe sponsors. I'll ahve a look tomorrow
[23:19] <jbernard_> fabrice_sp: will do
[23:19] <jbernard_> fabrice_sp: thanks
[23:19] <fabrice_sp> my first impression is that it may not be necessary to add a README.source and a patch system, but will have a better look tomorrow (within 7 hours :-) )
[23:19] <fabrice_sp> bye