[00:18] <SilverBullet> Getdeb Founder interviewed Topic => http://ubuntuforums.org/showthread.php?t=1038224
[00:33] <anakron> hi
[00:33] <anakron> someone know why if i type this
[00:34] <anakron> sudo debdiff slingshot_0.8.1p-1.dsc slingshot_0.8.1p-1ubuntu1.dsc > slingshot_0.8.1p-1ubuntu1.debdiff
[00:34] <anakron> it doesn't work
[00:36] <Hobbsee> well, you don't need to sudo it, for a start
[00:37] <anakron> yes
[00:37] <anakron> but says
[00:37] <anakron> bash: slingshot_0.8.1-ubuntu1.debdiff: Permiso denegado
[00:37] <anakron> and i can't understand
[00:37] <anakron> must be my error, but i can't see i
[00:37] <anakron> it
[00:37] <Hobbsee> then chown it to your user?
[00:38] <anakron> ops
[00:38] <anakron> hehe
[00:38] <anakron> dont worry :)
[00:39] <anakron> i do it like root
[00:39] <anakron> but it was chown error
[00:50] <RAOF> So!  Who wants to review nouveau-kernel-source!  Simple, fun, and makes a very nice open-source nvidia driver installable in Jaunty! http://revu.ubuntuwire.com/details.py?package=nouveau-kernel-source
[00:51] <directhex> RAOF, is it dkms based?
[00:51] <RAOF> Yes.
[00:51] <RAOF> Which is mich easier than the wiki page suggests, it turns out.
[00:52] <RAOF> directhex: If you haven't seen a dkms-using package before, I'd suggest checking it out.  It's a good example, I think.
[00:53]  * Hobbsee clubs RAOF with a dead ferret
[00:53] <RAOF> Hobbsee: Sadness.
[00:53] <RAOF> Ferrets are awesome.  They shouldn't be dead.
[00:54]  * RAOF tickles his ferret.
[00:54] <Hobbsee> RAOF: gnome-do keeps flipping back to open for the ssh.  Fix it, and I won't kill the ferrets and club you with them ;)
[00:54] <Hobbsee> i didn't know you had a ferret.  I'd like to see this!
[00:54]  * directhex feeds RAOF's ferret some cat food
[00:54] <StevenK> Hobbsee: You mean my bug?
[00:55]  * RAOF doesn't _actually_ have a ferret.
[00:55] <Hobbsee> StevenK: yeah.  But now i'm actually being able to reproduce it
[00:56] <StevenK> Woot
[00:58]  * RAOF files "SSH Hosts shouldn't be openable" against do-plugins, and does some bug gardening there, too.
[00:59] <StevenK> Yay RAOF!
[00:59] <Hobbsee> well, they should be openable.  just, they should never be the default ;)
[00:59] <RAOF> But nothing _happens_ on open, right?
[00:59]  * Hobbsee finds it useful to have a GUI for browsing remote machines, sometimes.
[00:59] <Hobbsee> no, it opens / on the destination machine.
[01:00] <Hobbsee> in nautilus.  Works a charm when you actually want it to do that.
[01:00] <RAOF> Oh, sweet.  That's broken here, sadly.
[01:00] <Hobbsee> or at least, did last time i tried it
[01:00] <RAOF> Yeah, that's what it's _trying_ to do.
[01:01] <RAOF> We may need to give it some gvfs love to make it work better, but that's what it's trying.
[01:02] <RAOF> The relevance engine is next up on getting an overhaul.  That should make this better.
[01:16]  * RAOF hopes he missed someone volunteer to review nouveau ;)
[01:17] <ScriptRipper> the qemu pkg dependencies is now ok with universe
[01:17] <ScriptRipper> now i run into a new issue: dpkg-source: error: unrecognized file for a v1.0 source package: qemu_0.9.2svn6277.orig.tar.bz2
[01:18] <ScriptRipper> are .tar.bz2 not allowed anymore?
[01:18] <ScriptRipper> debian etch eats it!
[01:20] <RAOF> Really?  I thought that was reasonably recently introduced in dpkg.
[01:23] <ScriptRipper> debian etch works, but lenny not.
[01:24] <ScriptRipper> that is the strange thing
[01:24] <directhex> hmm, no.
[01:24] <directhex> bz2 is supported in dpkg, but not by the archive stuff
[01:24] <directhex> so you can create a local bz2 package, but not upload it
[01:25] <ScriptRipper> so i run into a new consistency check not present in etch?
[01:28] <directhex> quite possible
[01:28] <ScriptRipper> not upload it to the debian build system or the ubuntu build system?
[01:29] <ScriptRipper> so i should go back to .tar.gz then?
[01:30] <ScriptRipper> source files...?
[01:32] <RAOF> Yeah; repack it to a tar.gz
[03:15]  * ScottK does a cruft cleaning victory dance.  5 removal bugs done of his today.
[03:15] <ScottK> Thanks slangasek
[03:15] <nhandler> Congrats ScottK
[04:13] <pwnguin> RAOF: how much time / skill would I need to review nouveau stuff?
[04:14] <RAOF> pwnguin: Time?  Dunno; depends on how fast you are at copyright sweeps.  Probably a couple of hours.  It's not very complicated packaging.
[04:14] <pwnguin> i guess the other thing is, im not motu
[04:17] <RAOF> That is, of course, awkward.  You're welcome to give it a once over; if you find anything I can fix it before someone who could advocate it needs to look at it.
[04:17] <Hobbsee> RAOF: how much crack is it on?  is it a new package, or waht?
[04:18] <lifeless> persia: do you know where a schedule of the asia board meetings is?
[04:18] <lifeless> persia: I keep misssing them cause announcements are sent after I finish work, and I don't read email in the evenings generally
[04:18] <persia> lifeless, I only know of the one in my head, which goes 15:00 today, 9:00 on the 20th, 15:00 on the 27th, etc.
[04:18] <RAOF> Hobbsee: It's a new package.  It's not really on any crack at all.
[04:19] <lifeless> UTC?
[04:19] <persia> lifeless, I don't know how far in advance amachu has posted to the fridge.
[04:19] <persia> Yes, UTC.
[04:19] <RAOF> Hobbsee: Packaging-wise, at least.  It's quite simple.
[04:19] <lifeless> ok, well I won't be at todays
[04:19] <lifeless> thats 2am
[04:19] <persia> No, don't imagine anyone from the east will be there.
[04:19] <RAOF> Hobbsee: It's also fairly safe; it shouldn't break anything for anyone.
[04:19] <lifeless> I'd like a ical feed for these
[04:19] <Hobbsee> hrm...
[04:19] <lifeless> could you bring that up please
[04:20] <lifeless> persia: ^
[04:20] <persia> An iCal feed?
[04:20]  * persia knows almost nothing about iCal
[04:20]  * nhandler still wishes the fridge would make their ical feed work with gcal
[04:21] <persia> nhandler, It's an issue with the drupal plugin.  Feel free to chase the bug :)
[04:21] <nhandler> persia: I know it is. I don't have enough experience with drupal or ical to tackle this one.
[04:23] <Hobbsee> RAOF: will there be gnome-do fixes if it gets reviewed?  :P
[04:23] <lifeless> nhandler: yeah, gcal is what I need
[04:23] <RAOF> Hobbsee: There'll likely be a new gnome-do release if it gets reviewed, with plenty of shiny?
[04:23] <Hobbsee> will it fix the ssh connect issues?
[04:24] <Hobbsee> and how likely?  :P
[04:24] <RAOF> Probably not; that's related to something deep in the core.
[04:24] <Hobbsee> awww
[04:24] <RAOF> We can't really pin something to the top of the priority for a specific item at the moment.
[04:25] <Hobbsee> ah
[04:25] <RAOF> Improvements to the relevance, including per-element relevance (so the fact that you use "open" a lot on files doesn't affect your ssh hosts), are coming after the next release.
[04:26] <Hobbsee> woot!
[04:26] <Hobbsee> hand me a URL then, and i'll attack you with a rubber chicken if the copyrighting is wrong ;)
[04:26] <RAOF> http://revu.ubuntuwire.com/details.py?package=nouveau-kernel-source
[04:29]  * Hobbsee blinks
[04:30] <RAOF> That bad?
[04:30] <Hobbsee> i just looked at the legal page
[04:31] <RAOF> I think I've got them all covered, but yeah.
[04:33] <RAOF> Damn.  I should have just stolen the copyright from the kernel!  That's where all those files normally end up!
[04:34]  * Hobbsee wonders why debian/install is needed
[04:35] <Hobbsee> oh, you don't dump them all in the same place.
[04:37] <Hobbsee> RAOF: presuambly one needs to update the debian/snapshot_hash when updating the package?
[04:38] <RAOF> Hobbsee: I thought I set up a target to refresh that.
[04:38] <RAOF> Let me check.  It's been sitting there a while :)
[04:38] <RAOF> Hobbsee: The get-new-snapshot target generates snapshot_hash
[04:38] <Hobbsee> oh, so you do
[04:39] <RAOF> Wow.  That's quite a lot less trivial than I remember ;)
[04:39] <Hobbsee> RAOF: I didn't check copyright, and I didn't try building it, but I can't find anything wrong with it.
[04:40] <RAOF> I'm reasonably certain copyright is OK.  Older versions of many of the files in there are in the kernel tree already, and the rest have clearcut copyright.
[04:44] <RAOF> Want to upload or ack it, then? :)
[04:44] <Hobbsee> RAOF: i'm assuming the answer is "no", but this doesn't require internet access while building the binaries, does it?
[04:44] <lifeless> anyone know if dh_zope adds python to the dependencies itself?
[04:44] <RAOF> No, it doesn't.
[04:44] <RAOF> Hobbsee: ^
[04:45] <Hobbsee> oh good
[04:45] <lifeless> does it need to ? as python is implied by zope..
[04:46] <RAOF> lifeless: Do packages which call dh_zope also call dh_python?
[04:46] <lifeless> no
[04:47] <RAOF> Should they?
[04:48] <lifeless> I think it may 'depend' :P
[04:49] <RAOF> Another query: where is dh_zope, exactly?
[04:50] <RAOF> apt-file search dh_zope comes up empty.
[04:50] <RAOF> Or are you writing a dh_zope yourself?
[04:51] <RAOF> Hobbsee: BTW, it should be safe for you to build and install the package.
[04:52] <Hobbsee> RAOF: that's what i'm tryingnow
[04:53] <RAOF> Worst case: it kills your 3d :)
[04:57] <Hobbsee> RAOF: found some interesting bits in the build log
[04:57] <RAOF> Oh?  Pastebin?
[04:57] <Hobbsee> dpkg-source: info: building nouveau-kernel-source in nouveau-kernel-source_0.0.11+git20081220-0ubuntu1.dsc
[04:57] <Hobbsee>  debian/rules build
[04:57] <Hobbsee> tail: cannot open `/usr/bin//changelog' for reading: No such file or directory
[04:58] <Hobbsee> dpkg-parsechangelog: failure: tail of /usr/bin//changelog gave error exit status 1
[04:58] <Hobbsee> the last 2 lines repeated another 6 times
[04:58] <RAOF> Ah, right.
[04:59] <RAOF> It's trying to evaluate CURVER.  I don't know why.
[04:59] <Hobbsee> warning, `debian/nouveau-kernel-source/DEBIAN/control' contains user-defined field `Original-Maintainer' is a little odd too, as i can't see why
[04:59] <RAOF> Hobbsee: Because it's got me as the original-maintainer?
[05:00] <RAOF> I probably shouldn't be there.
[05:00] <Hobbsee> RAOF: well, i'm not sure why it's cut off the XSBC- part
[05:00] <RAOF> Because it's in the binary already?
[05:00] <Hobbsee> ah, fair enough
[05:01] <Hobbsee> W: nouveau-kernel-source: script-not-executable ./usr/src/nouveau-0.0.11+git20081220/scripts/create_bsd_pci_lists.sh
[05:01] <Hobbsee> W: nouveau-kernel-source: script-not-executable ./usr/src/nouveau-0.0.11+git20081220/scripts/create_linux_pci_lists.sh
[05:01] <Hobbsee> W: nouveau-kernel-source: old-fsf-address-in-copyright-file
[05:01] <Hobbsee> fwiw
[05:04] <RAOF> Hm.  I wonder why those scripts don't come executable from git.
[05:14] <Hobbsee> RAOF: it seems the other two in that directory did - just not those.
[05:15] <RAOF> Yeah. I can fix that in get-orig-source if you think its worth it.
[05:15] <Hobbsee> meh
[05:16] <Hobbsee> RAOF: advocated.
[05:18] <RAOF> Hobbsee: Sweet!  I'll upload now.  Nouveau can be installable for Alpha 3!
[05:19] <Hobbsee> :)
[05:19] <Hobbsee> that's if it gets thru the new queue
[05:19] <RAOF> Well, yeah.  I guess so.
[05:29] <RAOF> Hobbsee: And uploaded.  Thanks muchly!
[05:29] <Hobbsee> RAOF: you're welcome
[05:30] <fabrice_sp> Hi. I'm upgrading a package to a new upstream version, and of the 2 patches that the package had is not used anymore. Should I remove the patch from the debian/patch or just delete from the series file?
[05:31] <fabrice_sp> "and ONE of the 2 patches"
[05:35] <RAOF> To push the bzr tree for that packaging I first need to create the launchpad project, don't I?  Has that changed with packagebranches yet?
[05:48] <persia> RAOF, You might want to ask james_w that, in several hours :)
[07:00] <stochastic> Hi room, I've just made my first debdiff to patch this bug: https://bugs.launchpad.net/ubuntu/+source/jack-rack/+bug/211798 How do I go about getting it off my computer and into the stream?
[07:01] <stochastic> should I first post it to the bug as an attachment? or is there a review process?
[07:02] <jmarsden> stochastic: If you have tested it and it works well for you, post it to the bug as an attachment.
[07:10] <stochastic> jmarsden, okay it's uploaded, is that all I need to do?
[07:10] <persia> stochastic, Once the patch is uploaded, subscribe ubuntu-universe-sponsors to the bug.
[07:11] <stochastic> okay, will do
[07:45] <didrocks> morning o/
[07:54] <RAOF> james_w: ping, re: where to push bzr packaging to in these sourcepackage-branch laden days.
[08:10] <POX> james_w: well, adding it in Debian will need NEW again, so I guess it will be easier to add small diff in Ubuntu
[08:36] <porthose> james_w: added the additional info you needed to bug #316092, thx
[09:17] <_ruben> is there a way to override the installation of packages listed in Recommends: ?
[09:18] <liw> _ruben, yes, apt-get has an option to either disable it by default (if you put it in a config file) or per use (if you use the -o option); I forget what the option is called, though
[09:19] <RAOF> _ruben: In aptitude? Certainly.  List the package with a minus next to it (sudo aptitude full-upgrade idontwantyou-)
[09:19]  * _ruben reads the manual one more time
[09:19] <_ruben> using apt-get
[09:20] <_ruben> --no-install-recommends .. doh .. wonder how i could miss that :p
[09:21] <directhex> --without-recommends ?
[09:25] <dholbach> good morning
[09:28] <slytherin> asac: I have a question regarding tuxguitar merge. tuxguitar launcher script looks for libxpcom.so (needed for documentation browser) in /usr/lib/xulrunner-1.9. But the installation of xulrunner on ubuntu is done in /usr/lib/xulrunner-1.9.0.x. How do I solve the problem of libxpcom.so lookup?
[09:28] <slytherin> dholbach: good morning.
[09:28] <dholbach> hiya slytherin
[09:29] <stochastic> hi room, I'm in the process of stepping through packaging tutorials in an attempt to build a .deb for the calf plugin pack here: http://calf.sourceforge.net/ and I'm wondering if someone can walk me through the depends and build-depends sections of the control file
[09:31] <liw> stochastic, what you want to know about them?
[09:32] <stochastic> I'm not sure on what the difference between build-depends and depends fileds
[09:32] <directhex> stochastic, erm... do you need gcc to run nano?
[09:34] <stochastic> okay, should I just guess at the libraries required to run these plugins?
[09:34] <stochastic> or are there systematic means of figuring it out?
[09:34] <liw> stochastic, depends is for what the package needs when a user uses it; build-depends is what you need when you build it
[09:34] <directhex> stochastic, generally, you should use substitution variables and a sufficiently smart packaging helper tool for them to be calculated
[09:35] <liw> stochastic, shared libraries are usually determined automatically (rare exceptions exist); other stuff you mostly have to figure out by reading the source code
[09:35] <stochastic> directhex, sorry I'm BRAND new to this packaging thing
[09:35] <liw> stochastic, or by experimenting
[09:35] <directhex> ${shlibs:Depends} is a good thing to depend on
[09:36] <directhex> it's populated by something, probably dh_makeshlibs in debian.rules
[09:36] <StevenK> dh_shlibdeps
[09:36] <StevenK> dh_makeshlibs is for libraries to *make* them
[09:37] <stochastic> okay, so I only need to take the dependencies listed here: http://calf.sourceforge.net/?id=2 and find suitable packages in Ubuntu's repos and put those into build-deps
[09:37] <directhex> yeah, close enough
[09:37] <directhex> if your packaging helper is smart enough, you shouldn't even need to care about which dh_foo to run
[09:37] <StevenK> stochastic: Just make sure you put the development libraries in the build-deps.
[09:37] <StevenK> debhelper 7 for the win
[09:38] <directhex> StevenK, yes!
[09:38] <stochastic> now when it says it requires Expat XML parser, should I include the dev libraries, or the expat executable?
[09:38] <directhex> it's even mono-friendly, and does ${cli:Depends}
[09:39] <StevenK> stochastic: The development libraries, since things usually link against it
[09:40] <stochastic> I'm learning off the youtube videos by dholbach, but they kinda gloss over this section
[09:48] <slytherin> stochastic: when you are need a library for building your program, you usually need -dev package of that library since that is where all the header files lie.
[10:15] <stochastic> hi again, I'm having further difficulties with build-depends in that same package when it comes to pbuilder
[10:15] <stochastic> I get a whole bunch of <package name> is a virtual package errors and it fails to build
[10:16] <stochastic> like ladspa-sdk and dssi-dev and libjack-dev
[10:17] <stochastic> am I missing something obvious, or am I using the wrong packages?
[10:18] <james_w> stochastic: I believe you don't have universe enabled in your pbuilder
[10:19] <stochastic> ok, that makes sense
[10:19] <stochastic> how do I fix that?
[10:20] <james_w> RAOF: there's not a special place on launchpad yet, so either under the project, or under your +junk
[10:20] <RAOF> james_w: OK. Which means creating the project, I guess.
[10:21] <james_w> stochastic: I believe the fix is to edit your ~/.pbuilderrc and then run "pbuilder update --override-config"
[10:21] <james_w> stochastic: I've never had to do it though, so that might be nonsense
[10:21] <james_w> RAOF: yeah, you could use your +junk, but creating the project can be useful for other things, such as bug watches
[10:22] <RAOF> Yeah.
[10:22] <stochastic> james_w, I don't have a ~/.pbuilderrc
[10:25] <james_w> stochastic: https://wiki.ubuntu.com/PbuilderHowto#Universe%20support
[10:38] <dholbach> james_w: we shouldn't be doing sponsoring at the same time :)
[10:38] <dholbach> mid-air collision on bug 316536
[10:38] <james_w> :-)
[10:38] <dholbach> although you were quicker :)
[10:38] <james_w> at least we agreed :-)
[10:38] <dholbach> yeah
[10:39] <james_w> I'm on gpsd and ampache-themes now
[10:39] <dholbach> netkit-telnet
[10:40] <james_w> pff, main :-)
[10:40] <dholbach> hehe, right
[10:41]  * dholbach does metacity next
[10:45] <Laney> you should set them to in progress when reviewing!
[10:48] <james_w> on goocanvasmm now
[10:48] <james_w> Laney: you can still have issues even then, but yeah it would help a bit
[10:55] <james_w> on azureus
[10:59] <stochastic> hmm, still on with this package I'm trying to build, it didn't seem to generate any dependencies; my debian/control file had: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}, ${misc:Depends}
[11:01] <liw> stochastic, you're probably missing something earlier in your debian/rules file; can you post it to paste.ubuntu.com?
[11:03] <stochastic> here it is: http://paste.ubuntu.com/104333/
[11:03] <stochastic> just what was automatically generated
[11:06] <liw> stochastic, I think you want to uncomment the line that calls dh_makeshlibs
[11:07] <stochastic> I'll try that, anything else?
[11:07] <liw> not immediately
[11:13] <stochastic> liw, I still get the same issue
[11:13] <liw> stochastic, hmm
[11:14] <liw> stochastic, can you put the entire source package up somewhere so that I can play with it to see what the problem is?
[11:14] <james_w> stochastic: turning on DH_VERBOSE may give some clues
[11:15] <stochastic> what would you like, any of my packaging work, or just the source of the application?
[11:15] <james_w> stochastic: dh_shlibdeps is the call that should add ${shlibs:Depends}
[11:17] <stochastic> james_w, should I just put the dh_verbose on line 75?
[11:18] <james_w> stochastic: nope, at the top of the file is a commented-out call to "export DH_VERBOSE=1" if you uncomment that the dh will tell you more about what it is doing
[11:18] <james_w> the trace may be informative about why that variable isn't getting set
[11:26] <stochastic> here's the entire output of pbuilder with verbose on: http://paste.ubuntu.com/104339/
[11:26] <stochastic> I don't see anything obviously tracing that error
[11:26] <stochastic> the error is way down at the bottom
[11:27] <james_w> stochastic: the issue is that the install rule doesn't actually install the program
[11:28] <james_w> it install the header files, and a few other things, but doesn't appear to install calfmakerdf etc.
[11:28] <stochastic> oh
[11:29] <james_w> at least I assume that is what is supposed to happen
[11:36] <stochastic> liw, I've tarred the whole kit and kaboodle up and it's here to download if anyone wants to fiddle: http://rapidshare.com/files/182751716/calf-packageAttempt.tar.gz.html
[11:38] <stochastic> it does look like the calfmakerdf is moved at lines 1128, 1132, etc.. and besides these are audio plugins so they're not really designed as an executable standalone
[11:40] <liw> stochastic, I'll have a look
[11:42] <stochastic> well thank you all for the insights that have gotten it this far, unfortunately I do need sleep
[11:43] <stochastic> liw, if you find something I'm missing, or any explanation please e-mail me (e-mail is in the packaging) as I'd love to know where I took a misstep
[11:43] <liw> stochastic, sure
[11:48] <slytherin> stochastic: dh_makeshlibs is not the command you should use, rather dh_shlibdeps
[11:55] <directhex> the usefulness of quilt suddenly becomes apparent, when looking at an rpm spec file with 54 patches in it
[12:00] <liw> hmm, stochastic's package doesnt end up with a substvars file
[12:09] <liw> which seems to be because he installs into debian/calf rather than debian/calf-plugins
[12:10] <liw> fixing that, there's still a complaing about misc:Depends
[12:12] <liw> but that seesm to be fixed in newer debhelpers so that's ok
[12:34] <thekorn> jpds: hi, FYI, I just added a tool to create credentials for the launchpad API to lp:~thekorn/ubuntu-dev-tools/use_launchpadlib
[14:16] <directhex> hm, looks like my new ikvm packaging did the trick - i can't imagine the old package would have been able to gobble a gig of ram on the armel buildd during compile
[14:21] <Laney> you da bomb
[15:11] <mok0> doko: ping
[15:17] <quadrispro> dholbach: ping
[15:18] <dholbach> quadrispro: pong
[15:20] <doko> mok0: contentless pong
[15:20] <mok0> doko: oh, just going through my bug list, and bumped into bug 308194
[15:22] <mok0> doko: I will make a patch for intrepid, ok?
[15:23] <doko> mok0: sure
[15:33] <mok0> doko, did you remove cython building from lxml?
[15:34] <apw> if universe sponsors hang about over here, where to main sponsors hang out?
[15:34] <mok0> apw: in -devel
[15:35] <doko> mok0: yes
[15:35] <apw> mok0, thanks :)
[15:35] <mok0> doko: OK. It was my impression that you didn't like that
[15:35] <ScottK-desktop> apw: It depends a bit.  You can also find people in #ubuntu-server, #ubuntu-desktop, and #kubuntu-devel depending on the package.
[15:36] <apw> pm-utils and apport
[15:36] <apw> so i'll try -devel
[15:38] <doko> mok0: did I say that? hmm
[15:38] <ScottK> apw: I doubt anyone other than pitti is going to touch apport unless it's an emergency.
[15:39] <mok0> doko: you said something like "if lxml can't be built from source it should leave Debian"
[15:39] <apw> yeah, think he is away from keyboard this week
[15:43] <ScottK-desktop> Someone who knows a bit of Python and is looking for a bug to fix, might want to look at Bug #316674
[15:45] <POX> ^^ I can check/sponsor this one thru PAPT
[15:46] <POX> i.e. upload it as PAPT member
[15:58] <mok0> ScottK, why not subscribe the pythonistas team to the bug?
[15:58] <ScottK> mok0: They are.
[15:58] <ScottK> That's why I saw it.
[15:58] <mok0> ScottK, it's not on their bug page
[15:59] <ScottK> mok0: If a team is subscribed to a package, that doesn't mean all package bugs show up on the team bug list.
[15:59] <mok0> ScottKnot they are
[15:59] <ScottK> All members of the team got bugmail on it.
[15:59] <mok0> ScottK, sorry: now they are
[15:59] <ScottK> Oh.
[15:59] <mok0> ScottK, the team was in the "Notified" column
[16:00] <mok0> ScottK, when I subscribed them, they moved to the "Subscribed" column
[16:00] <ScottK> Ah.
[16:01]  * mok0 contemplates to join Ubuntu Pythonistas
[16:02] <mok0> ScottK, hey you are in it :-)
[16:03] <ScottK> mok0: I can even approve your request to join.
[16:03] <mok0> ScottK, heh
[16:09] <pochu> mok0: no need to subscribe the team if they are notified, fwiw
[16:10] <mok0> pochu: notifcation is via mail, yes?
[16:10] <pochu> right
[16:10] <pochu> as subscribed is
[16:10] <savvas> I've sent a mail to contact at twotoasts punkt de about the catfish bug :)
[16:10] <mok0> pochu: I tend to forget about mails
[16:10] <mok0> pochu: but I often check the buglist
[16:11] <pochu> you can check the packages one team/person is subscribed to
[16:11] <mok0> pochu, go on...
[16:12] <pochu> e.g. https://bugs.edge.launchpad.net/~pythonistas/+packagebugs
[16:12] <pochu> if you go to the bugs tab in launchpad, then click on "Show package report", you will get that
[16:12] <savvas> hm.. there's a new upstream version, 0.3.2 for catfish
[16:12] <pochu> which are all the packages the team/person is in "also notified"
[16:13] <savvas>  + fix search from folders with spaces breaking find
[16:13] <savvas> ScottK: http://www.twotoasts.de/media/catfish/ChangeLog - this is probably fixed in 0.3.1
[16:13] <mok0> pochu: LP is a never-ending source of amazement...
[16:13] <pochu> hehe
[16:14] <mok0> pochu: ok, I wont subscribe anymore bugs to pythonistas
[16:14] <ScottK> mok0: amazement/pain, but yes.
[16:14] <RainCT> heh
[16:14] <ScottK> savvas: Any interest in packaging the new version?
[16:15] <ScottK> savvas: POX said he would sponsor it for Debian and we can sync it from there.
[16:15] <RainCT> ScottK: I've joined the team, can you approve me?
[16:15] <savvas> ScottK: I'll try to package the new version :)
[16:16] <RainCT> (well, or just do that once you check your mail and see the new member notification.. I've no hurry :))
[16:16] <ScottK> savvas: Great.  You might also want to join #debian-python on IFTC.
[16:16] <ScottK> RainCT: Sure thing.  Will do.
[16:17] <savvas> I'm still learning, but I think it's easy for this package
[16:18] <ScottK> savvas: OK.  If you have questions, you can ask me here or on #debian-python
[16:18] <ScottK> Any motu-sru around?
[16:18] <cody-somerville> I am
[16:19] <ScottK> cody-somerville: Would you please ack the ebox SRU?
[16:19] <cody-somerville> bug #?
[16:20] <ScottK> Bug 273486
[16:20] <ScottK> bug 314606
[16:20] <ScottK> Bug 255368
[16:23] <RainCT> nixternal: yes, Brainstorm is finally being updated today (actually, it looks like it already has been), but it doesn't look like that thing in Jono's post :P
[16:32] <sll> hello! could anybody help me to package a set of objects please?
[16:34] <jpds> thekorn: re: lplib - that's brilliant, I'll start merging it as soon as I can.
[16:38] <sll> It's my firs time packaging, the objects are like plugins written in C, I need some help with rules file
[16:39] <hyperair> nhandler: codelite's ready for reviewing again
[16:41] <shankhs> hi
[16:41] <cody-somerville> ScottK, sommer: https://bugs.edge.launchpad.net/ubuntu/+source/ebox/+bug/273486
[16:42] <shankhs> hi guys I know c/c++ and want to start developing some small softwares , but I dont know how to???Can anybody give me a starting point...please
[16:44] <sommer> cody-somerville: yep
[16:44] <cody-somerville> sommer, I made some comments on your SRU application.
[16:48] <sommer> cody-somerville: thanks, I'll address those items
[16:54] <nixternal> RainCT: argh, I was hoping I was correct ;)
[16:55] <RainCT> nixternal: if you have some other theory, I'll listen ;P
[16:58] <mok0> vorian: I looked at the patches; only one is still relevant. I might as well make the last change and upload
[16:58] <mok0> vorian: (in stellarium)
[16:59] <cody-somerville> sommer, Also commented on bug #255368
[17:00] <vorian> mok0: are you going to upload it then?
[17:00] <mok0> vorian: yeah why not. It is already in the archive
[17:00] <vorian> if so, the stellarium.desktop could use a patch as well
[17:01] <mok0> vorian: OK will take a look
[17:01] <vorian> awesomeness
[17:01] <mok0> vorian: It runs great on my intrepid amd 64!!!
[17:01] <cody-somerville> sommer, I just commented on #314606 now too
[17:01] <vorian> coolio
[17:01] <mok0> vorian: Very nice work they did to the interface!
[17:02] <vorian> i'll have to play with it when the dust from kde updates settles down
[17:02] <mok0> vorian: uh-uh, I haven't dared take those on
[17:03] <vorian> :)
[17:03] <mok0> vorian: still at 4.1
[17:03] <vorian> its a spiritual experience
[17:03] <vorian> mok0: 4.1.4 should be hitting any time now if you use -proposed
[17:03] <sommer> cody-somerville: thanks, should have updates to those sometime this afternoon or evening
[17:03] <mok0> vorian: tell me about it. I just had a spiritual experience when my sys disk crashed yesterday
[17:03] <vorian> ouch!
[17:03] <cody-somerville> sommer, thanks
[17:04] <mok0> vorian: fortunately my home is on a separate disk ;-)
[17:04] <mok0> vorian: ... with backup
[17:04] <vorian> nice, not too big a deal then. other than hardware loss
[17:04] <vorian> :)
[17:05] <mok0> vorian: yes. This time, I bought a Server Edition disk
[17:05] <Turl> hello
[17:05] <Turl> any possibility of you fixing Bug #285417? or is this package on main?
[17:06] <vorian> hehe
[17:07] <mok0> Turl, if you click on the "ubuntulooks (Ubuntu)" link on the taskbar, and then select the "Overview" tab, you'll see that it's in main
[17:08] <Turl> oh, sorry then
[17:08] <Turl> is there any channel I can go to bug the main packagers? :p
[17:09] <mok0> Turl: is this a matter of changing a directory name?
[17:09] <mok0> Turl: core developers generally hang out in #ubuntu-devel
[17:10] <mok0> Turl, why didn't that elli222 fellow upload a patch?
[17:10] <Turl> mok0: it's changing the dependencies not to delete ubuntu-theme if I'm right, the bug has an explanation on how to repackage it to work correctly
[17:11] <Turl> mok0: no idea :p maybe he doesn't know how?
[17:11] <mok0> Turl: it's faster to make a patch than writing that long explanation :-)
[17:12] <Turl> I believe so :p
[17:13] <mok0> Turl, If you wanna fix it, we can guide you along here
[17:13] <Turl> really it's for a friend, I don't want to install that theme :p
[17:14] <mok0> Turl: you wanna fix it? :-)
[17:14] <Turl> will I need to install tons of packages? :p
[17:15] <mok0> Turl: I don't think so
[17:15] <mok0> Turl: perhaps some devel tools
[17:15] <mok0> Turl: but you'll need those the NEXT time you fix a bug lol
[17:16] <Turl> ok, guide me then :=
[17:16] <Turl> :)*
[17:16] <mok0> Turl: first you need to go into a working dir and download the source package
[17:16] <Turl> any empty dir is ok, am I right?
[17:16] <mok0> Turl: yes
[17:17] <mok0> turl, what version do you want to make the fix. Intrepid?
[17:18] <Turl> yep
[17:18] <mok0> Turl: do you know how to get the source package?
[17:18] <Turl> apt-get source I guess?
[17:19] <mok0> Turl: yes, if you're on the same version of Ubuntu
[17:19] <Turl> yeah
[17:19] <Turl> I got a diff.gz, a .dsc, a tar.gz and a dir
[17:20] <mok0> Turl: now unpack using dpkg-source -x <.dsc file>
[17:21] <Turl> ok, done
[17:23] <Turl> now what mok0?
[17:23] <mok0> Turl: go down into the topdir
[17:23] <Turl> ok
[17:23] <mok0> Turl: what's that called, btw
[17:23] <Turl> ubuntulooks-0.9.12
[17:24] <mok0> Turl: ok. Now go into debian/
[17:24] <Turl> ok
[17:24] <mok0> Turl: as I understand the bug, you need to edit the dependencies?
[17:25] <mok0> Turl: then you need to edit "control"
[17:25] <Turl> with nano is ok?
[17:25] <Turl> or do I need to use some dpkg tool?
[17:25] <mok0> Turl: yes
[17:25] <mok0> Turl:  not yet
[17:27] <mok0> Turl, remove the line containing "Replaces: ... "
[17:29] <Turl> ready
[17:29] <Turl> now what?
[17:29] <mok0> Turl: do you know anything about ubuntu artwork? Because I don't
[17:30] <Turl> I now there are pretty ones and ugly ones :p
[17:30] <mok0> Turl: now you need to edit "changelog" and write a new entry at the top
[17:30] <Turl> I copy one and edit it?
[17:31] <mok0> Turl: yes, you can make a copy of the first entry and change it
[17:32] <mok0> Turl, you need to use a new revision string
[17:32] <Turl> ubuntulooks (0.9.12-13) intrepid-proposed; urgency=low
[17:33] <mok0> yes
[17:33] <Turl> would that be ok? it said hardy-proposed on the other one
[17:33] <mok0> Turl: that will propose it as a fix for intrepid
[17:34] <savvas> ScottK: I think I've finished with catfish: http://revu.ubuntuwire.com/details.py?package=catfish https://launchpad.net/~medigeek/+archive/+build/836369
[17:34] <mok0> Turl: if you want to fix for hardy, you need to do the same for the hardy version of the package
[17:34] <mok0> Turl: when you're done, cd ..
[17:35] <savvas> ScottK: I'm going to see if it actually works now with folders with spaces :)
[17:35] <mok0> Turl: then do "debuild -S -uc -us"
[17:37] <Turl> where can I get debuild?
[17:37] <savvas> Turl: sudo apt-get install devscripts
[17:37] <mok0> heh
[17:38] <ScottK> savvas: Since we are going to get POX to upload this to Debian, you want the revision to be -1 and the distro to be unstable
[17:39] <POX> ScottK, savvas: acually, new upstream release of catfish is already in PAPT svn, Kmos: why didn't I upload it yet? (/me is too lazy to dig in his mails)
[17:39] <ScottK> Ah.
[17:39] <savvas> meh
[17:39] <ScottK> savvas: Might be good of you to review what's in the svn and see if you have anything of significance that's different.
[17:42] <Turl> mok0: installing, might take some timeç
[17:42] <mok0> Turl: ok
[17:42] <Turl> it installed exim :/
[17:43] <Turl> mok0: it threw a lot of errors :S
[17:43] <savvas> POX: the changelog in svn shows 0.3.1 - http://svn.debian.org/wsvn/python-apps/packages/catfish/trunk/debian/changelog?op=file&rev=1943&sc=1
[17:43] <mok0> Turl: the debuild command?
[17:44] <Turl> a lot of "file or directory does not exist"
[17:44] <Turl> yeah
[17:44] <mok0> Turl: can you pastebin the output?
[17:44] <ScottK> Something needs to be changed to depend/recommend postfix|mail-transport-agent instead of exim|mail-transport-agent
[17:44] <Turl> like /usr/share/cdbs/1/class/autotools.mk does not exist, /usr/share/cdbs/1/rules/debhelper.mk does not exist, ..
[17:44] <Turl> mok0: it's in spanish, idk if you want it all the same
[17:44] <POX> cody-somerville: you're catfish maintainer, why it's not uploaded yet?
[17:44] <savvas> ScottK: it's been good for training hehe :) They've pretty much changed the same things I have, so that's good!
[17:45] <ScottK> yes.
[17:45] <mok0> Turl: yikes. Try anyways
[17:45] <POX> cody-somerville: http://people.debian.org/~piotr/sponsor Q9 (if that's the reason)
[17:45] <ScottK> savvas: You can also request a sync after it's uploaded to Debian.
[17:45] <cody-somerville> POX, I'm simply too busy atm
[17:46] <POX> oh, ok
[17:46] <POX> I'll upload it as PAPT member then
[17:46] <Turl> mok0: http://paste.pocoo.org/show/99473/
[17:46] <POX> (after some basic tests)
[17:46]  * mok0 looks
[17:46] <mok0> turl, sudo apt-get install cdbs
[17:47] <savvas> POX: I made one for 0.3.2, the one in Debian svn is for 0.3.1
[17:47] <mok0> turl, sudo apt-get install debhelper
[17:47] <POX> savvas: did you have to change something besides version?
[17:47] <savvas> POX: I think it's the fix_makefile patch
[17:47]  * Turl installs what mok0 said
[17:48] <mok0> turl, after that try debuild again
[17:48] <cody-somerville> POX, thanks
[17:49] <Turl> mok0: it seems to have worked
[17:49] <Turl> there's a little warning though, W: ubuntulooks source: ancient-standards-version 3.6.2 (current is 3.8.0)
[17:49] <mok0> Turl: yay
[17:49] <mok0> Turl: you should have a new source package in ..
[17:50] <POX> savvas: send me `svn diff` output (or I'll prepare it myself)
[17:50] <Turl> mok0: I have some new files now, a .build and a .changes
[17:50] <Turl> is it OK?
[17:51] <mok0> Turl: sounds right. You should also have a new .dsc fie
[17:51] <mok0> file
[17:51] <Turl> mok0: I only have the old one :/
[17:52] <Turl> I guess it's been replaced?
[17:53] <Turl> well, it seems to be the old one mok0. I cat'ted it and it has the old version number
[17:53] <mok0> Turl: what's in the changes file? (pastebin)
[17:54] <Turl> http://paste.pocoo.org/show/99474/
[17:54] <mok0> Turl, hmm, I think something went wrong with your changelog entry
[17:55] <mok0> Turl: you didn't update the release to -13
[17:56] <Turl> stupid me, I didn't :p
[17:56] <mok0> Turl: change it, and run the debuild command again
[17:57] <Turl> ready
[17:57] <Turl> I have now -12 and -13 files
[17:57] <savvas> POX: I'm still learning, can you grab it and compare it yourself? :) Here: http://savvas.radevic.com/packaging/catfish/10Fix_makefile.dpatch
[17:57] <mok0> turl, great. But you overwrote the original -12 files so you need to apt-get source again
[17:57] <POX> ok
[17:58] <savvas> POX: It's mostly the same patch, but I've included the change to point to share/icons/hicolor/scalable/apps
[17:58] <Turl> mok0: do I need to do everything from scratch?
[17:58] <mok0> Turl: no, just don't delete the -13 files
[17:58] <Turl> ok
[17:59] <savvas> POX: do I have to open a new upstream package request in Debian for this?
[17:59] <mok0> Turl: we just need to re-establish the -12 files that were accidentally overwritten
[17:59] <Turl> now dpkg-source -x ? or what?
[17:59] <mok0> Turl: yes
[18:00] <Turl> ready mok0
[18:00] <POX> savvas: no, I will just upload it and let you know to file a sync request bug in Ubuntu (I'll close the LP bug in changelog)
[18:00] <mok0> Turl: now run debdiff old.dsc new.dsc
[18:00] <savvas> POX: ok, cheers! :)
[18:01] <mok0> Turl: replace "old" and "new" with the appropriate names
[18:01] <Turl> ok mok0
[18:01] <Turl> ready
[18:01] <mok0> Turl: the output came to stdout, right?
[18:01] <Turl> I got a ubuntulooks_0.9.12-13.diff.gz if I'm right
[18:02] <Turl> yeah, some output came to stdout
[18:02] <mok0> Turl: ok, you need to pipe it to a file; I routinely would call it "ubuntulooks_0.9.12-13.debdiff"
[18:03] <Turl> ready
[18:03] <mok0> Turl: let's check the debdiff file. You need to:
[18:04] <mok0> Turl: apt-get install patchutils
[18:04] <savvas> btw, I noticed something in the dpatch file: "--- catfish-0.3~/Makefile.in2007-04-04 04:20:26.000000000 +0200" <- Does that ~ character stand for anything?
[18:04] <mok0> savvas: yes
[18:04] <mok0> savvas: patch needs it
[18:05] <Turl> mok0: it seems to be there already
[18:05] <mok0> turl, great. So do lsdiff ubuntulooks_....debdiff
[18:06] <mok0> Turl: it should tell you what files are modified by the diff
[18:06] <mok0> Turl: hopefully only 2
[18:07] <savvas> mok0: I used catfish-0.3.2/Makefile.in instead of catfish-0.3~/Makefile.in and it built the package. Does that ~ mean something like .* in regex? :)
[18:08] <mok0> savvas: eerrr no
[18:08] <savvas> ok now I'm officially confused :p
[18:08] <mok0> savvas: it's actually only important what's in the +++ line
[18:09] <savvas> +++ catfish-0.3/Makefile.in2008-05-22 02:45:33.000000000 +0200
[18:09] <Turl> mok0: there are more than 2 files, but it's because I moved a dir in purpouse for it not to conflict
[18:09] <savvas> ah I see, ok
[18:09] <mok0> savas, thats the one
[18:09] <savvas> thanks mok0!
[18:09] <mok0> Turl: ah, ok
[18:09] <Turl> now what mok0?
[18:10] <mok0> Turl: how did you move that dir?
[18:10] <Turl> mok0: with mv, why?
[18:10] <mok0> Turl: because that way it won't be reflected in the package
[18:10] <mok0> Turl: it's not the right way to do it
[18:11] <Turl> :/
[18:11] <Turl> tell me how to move it and I'll do it from scratch then :p
[18:11] <mok0> Turl: but forgetting about that, you are in principle done. You could attach the debdiff to the bug and write a note that this fixes the ubuntulooks package
[18:12] <mok0> Turl: but the bug mentions making a fix in another package, too
[18:12] <Turl> yeah
[18:12] <Turl> and how can I upload it to a ppa? so it's available for my friend
[18:12] <mok0> Turl: so you should go through the same thing with that, build a new package with a new release number, make a debdiff to the old package and upload the debdiff to LP
[18:13] <Turl> ok mok0
[18:13] <mok0> Turl: then the developers will look at your patches, and you will get a lot of karma ;-)
[18:13] <mok0> Turl: but we should look at that dir that you want to move
[18:14] <mok0> Turl: can you tell me what it is
[18:15] <mok0> Turl: yes you can upload to your ppa,
[18:16] <Turl> mok0: the dir is ubuntulooks-0.9.12/themes/Human/
[18:16] <Turl> and I moved it to ubuntulooks-0.9.12/themes/Human-UbuntuLooks/
[18:16] <Turl> and fixed the makefiles
[18:16] <mok0> Turl: ah
[18:17] <mok0> Turl: but when the package is built, it uses the orig.tar.gz which still has that dir in the same place
[18:17] <mok0> Turl: so the trick is not to move it locally, but install it somewhere else
[18:19] <Turl> hm, so what should I edit then?
[18:20] <mok0> Turl: err I need to figure out how it works first
[18:21] <mok0> Turl: during building, the package is constructed in a subdir to debian/
[18:22] <mok0> Turl: so, it creates a directory: debian/gtk2-engines-ubuntulooks/usr/share/themes/Human
[18:23] <mok0> Turl: the trick is to move it after compilation but before package building
[18:23] <mok0> Turl: and you do that in debian/rules
[18:24] <mok0> Turl, are you there?
[18:24] <Turl> yeah mok0
[18:24] <mok0> Turl: are you following?
[18:24] <Turl> the rules file has includes only
[18:24] <mok0> Turl: yes, but CDBS has some hooks you can use
[18:25] <Turl> I really don't know CDBS :p nor packaging, that's why you're explaining me
[18:25] <mok0> Turl: after the includes, make a new target called "install/gtk2-engines-ubuntulooks::"
[18:25] <mok0> turl, next line:
[18:26] <hyperair> could someone review my package? http://revu.ubuntuwire.com/details.py?package=codelite
[18:26] <Turl> mok0: for the target I just type "install/gtk2-engines-ubuntulooks::" ?
mv -f ddebian/gtk2-engines-ubuntulooks/usr/share/themes/Human/ debian/gtk2-engines-ubuntulooks/usr/share/themes/Human_somethingelse
[18:27] <mok0> Turl: yers
[18:27] <Turl> is it ok the ddebian or is it a typo?
[18:28] <mok0> Turl: debian
[18:28] <mok0> Turl: it's just the mv command from topdir to move the Human directory to something else
[18:28] <Turl> ok :)
[18:29] <mok0> Turl: but the <tab> first character on that line is importatnt
[18:30] <mok0> turl, see here how it's done, about 1/5 down the document: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
[18:31] <mok0> Turl: my wife just called me the 2nd time to tell me to come home for dinner... I gotta go
[18:32] <mok0> Turl: don't forget to document moving the directory in changelog
[18:35] <iulian> RainCT: ping
[18:54] <cody-somerville> w00t
[18:54] <cody-somerville> :)
[18:55] <RainCT> iulian: pong
[19:08] <iulian> RainCT: What do you think about the removal of the revu-uploaders team?
[19:11] <iulian> RainCT: I mean, do we still need it there?
[19:15] <RainCT> iulian: nope
[19:24] <iulian> RainCT: OK then.  Do you have the power to deactivate it or should we open a question in launchpad and ask for it to be removed?
[19:24] <RainCT> iulian: I set it to restricted, that's all I can do
[19:30]  * iulian wonders who can deactivate it.
[19:31] <Turl> how can I sign a .changes file?
[19:31] <Turl> I already have my key
[19:33] <iulian> Turl: debsign -k<keyid> ...
[19:35] <Turl> thanks iulian
[19:42] <Turl> my packages were rejected :/  PPA uploads must be for the RELEASE pocket.
[19:42] <Turl> what does that mean?
[19:49] <iulian> Turl: You should ask PPA questions in #launchpad.
[19:49] <Turl> ok
[19:55] <fabrice_sp> Turl, you used other version that normal release (hardy, jaunty, intrepid, ...) in your changelog
[19:56] <Turl> I used intrepid-proposed
[19:56] <fabrice_sp> you have to put intrepid
[19:57] <Turl> ok
[20:09] <fabrice_sp> Hi. Where can I ask something about sbuild (it seems to leave sometime a temporary build partition that I cannot delete)
[20:20] <ScottK> fabrice_sp: Here's not bad.  A number of people who hang out here use it (not me, however).
[20:21] <fabrice_sp> ok. I just wanted how to delete them, as I haven't found for the moment why it's happening
[20:21] <fabrice_sp> (and I have 6 of them)
[20:27] <fabrice_sp> I can't even umount them: Device is busy (and I rebooted several time my computer)
[20:30] <maxb> This is sbuild in lvm mode, I assume?
[20:33] <fabrice_sp> maxb, yes
[20:33] <fabrice_sp> I setup a lvm for that purpose
[20:33] <maxb> Try 'schroot --list --all-sessions'
[20:34] <fabrice_sp> here they are my 6 sessions
[20:34] <maxb> schroot --end-session --all-sessions (or do it individually)
[20:35] <fabrice_sp> It worked! You're the man, maxb ! Thanks :-)
[20:36] <maxb> And I've never even used LVM :-)
[20:36] <maxb> need to find some spare hd space to play at some point
[20:37] <fabrice_sp> I did that to have some software 'raid' for my home (already lost 2 times my home before)
[20:37] <fabrice_sp> and I decided to use it also for building thing, and separating the chroot in  another 'partition'. Work great! :-)
[20:39] <fabrice_sp> but never access your lvm at the same time with gparted and system-config-lvm. You will lost everything
[20:39] <fabrice_sp> anyway, thanks for your help! :-)
[20:47] <AnAnt> can someone direct me to an example package to help me in writing get-orig-source: target ?
[20:48] <ScottK> AnAnt: How about plasmoid-kbstate
[20:49] <AnAnt> what's the source package name ?
[20:52] <POX> AnAnt: /me wrote recently this: http://svn.debian.org/viewsvn/*checkout*/python-modules/packages/sqlalchemy/trunk/debian/rules
[20:53] <ScottK> AnAnt: plasmoid-kbstate.  It's only in Jaunty though.
[21:07] <mok0> hrmph. Damn mysql build clogging up the build queue
[21:11] <directhex> jms@destiny:~$ firefox
[21:11] <directhex> Aborted
[21:11] <directhex> jms@destiny:~$ firefox
[21:11] <directhex> Aborted
[21:11] <directhex> go go free software
[21:13] <joaopinto> directhex, exactly how does "free software" relates to your problem ?
[21:14] <directhex> joaopinto, firefox crashes 30+ times a day. it gets annoying
[21:15] <joaopinto> I have no crashes with firefox, it most likely related to a plugin, or something specific to your configuration
[21:15] <directhex> nspluginwrapper/flash is certainly to blame for many of the crashes, but it seems not as many of them as i thought
[21:16] <joaopinto> relating a firefox crash with "free software" could be offending for free software developers
[21:17] <ScottK> directhex: Firefox isn't particularly free, IMO.
[21:18] <directhex> ScottK, mmm, perhaps. i have a EULA here for you..... ;)
[21:18] <laga> joaopinto: win
[21:18] <Chris`> Firefox crashes sometimes for me yet Windows XP crashed more, how does it relate to the freeness of it?
[21:18] <ScottK> directhex: Exactly.
[21:19] <directhex> firefox is one of the media's poster children for a successful free software app. it's high profile. when it cocks up, it's noticed more than if the chicken scheme compiler isn't up to scratch, fr'example
[21:19] <directhex> and as an app people use constantly, infuriating when it dies
[21:20] <mok0> Firefox is stable as a rock for me
[21:20] <directhex> mok0, i386?
[21:20] <mok0> directhex: perhaps you should direct your curses at the wireless producers that wont release  their specs
[21:21] <mok0> directhex: amd64
[21:22] <Chris`> When a package gets removed for the reason "NBS" what does that mean?
[21:25] <mok0> Chris`: it's a binary package with no corresponding source package
[21:26]  * directhex gives webkit another spin
[21:26] <Chris`> mok0: Thanks ;)
[21:26] <mok0> Chris`: for example if the source package has been renamed, the old binary packages will be "orphans"
[21:27] <mok0> directhex: are you looking at Chrome?
[21:27] <directhex> mok0, midori. does chrome's linux shell have advanced features like "pressing enter" yet?
[21:28] <mok0> directhex: I don't know
[21:31] <stochastic> Hi everyone, I just finished my first package and uploaded it to my PPA: http://ppa.launchpad.net/stochastic/ubuntu  it's of the Calf audio plugins.  Please review and let me know how horrible my packaging skills are.
[21:32] <directhex> stochastic, cracked the variable substitution?
[21:33] <laga> stochastic: you should probably put it on REVU (?)
[21:33] <stochastic> directhex, yes, thanks to liw's advice it was a problem with it trying to make to debian/calf rather than debian/calf-plugins
[21:34] <stochastic> laga, how do I do that - I'm new to all this
[21:35] <laga> stochastic: i bet it's documented on the MOTU wiki page
[21:35] <stochastic> ok, I'll do a search
[21:36] <laga> !revu
[21:36] <laga> wee.
[21:39] <stochastic> ok, it's in REVU now
[21:45] <stochastic> hmm, it looks like dput uploaded to REVU fine, but I don't see it there and my profile shows no uploads, am I just too quick for the system?
[21:54] <jpds> RainCT, james_w: We have lplib support in u-d-t \o/
[21:54] <james_w> thanks jpds
[21:54] <james_w> and thekorn
[21:54] <jpds> Especially thekorn.
[21:55] <james_w> jpds: would you write a mail to the list about what that means please?
[21:56] <RainCT> jpds: rock on!
[21:56]  * RainCT hugs jpds and thekorn 
[21:56] <jpds> james_w: Sure, first shower and let brain cool down.
[21:56] <james_w> :-)
[22:19] <khashayar> stochastic: from my experience, it can take a while before the package shows up on the web interface ;-)
[22:22] <stochastic> khashayar, I know you're good at backporting, and I'd like to upload a version of that package for intrepid to my PPA, is there anything special I need to do other than force the upload of the different version?
[22:24] <khashayar> stochastic: The only thing you need to do, is to make sure it has a different version number (limitation of ppa). That is, if your jaunty package is calf-0.0.17-0ubuntu1~jaunty~ppa1, your intrepid pacakge should be something like calf-0.0.17-0ubuntu1~intrepid~ppa1.
[22:26] <maxb> But usually you wouldn't use ~jaunty at all since its the development release
[22:26] <khashayar> oh, and you in your .dput.cf, you could have a section for intrepid with "incoming = ~stochastic/ubuntu/intrepid". This will upload to intrepid.
[22:26] <maxb> and the logical nesting is more ~ppa1~intrepid
[22:26] <khashayar> maxb: That's right, no ~jaunty
[22:26] <maxb> Convention seems to be to do ~intrepid1, also
[22:27] <stochastic> ok, so do I just rename the .changes file after I've debuild the package?  or does that need to happen before debuild somewhere?
[22:27] <khashayar> maxb: really? I thought convention was ~release~ppa1, and releaseX for backports.
[22:27] <maxb> nope
[22:27] <ScottK> stochastic: In debian/changelog
[22:27] <ScottK> Then debuild.
[22:27] <stochastic> ok, perfect
[22:28] <ScottK> maxb: I'd suggest the other way around.
[22:28] <maxb> because if you update the package in your ppa, you go to ~ppa2, and then you backport that
[22:28] <ScottK> maxb: In Ubuntu Backports we use ~$RELEASEX
[22:28] <maxb> Quite
[22:28] <ScottK> So ~ppaX will be a problem.
[22:29] <ScottK> Should be ~releaseX~ppaY
[22:29] <maxb> Well, I'm basing my suggestion off https://help.launchpad.net/Packaging/PPA#Versioning
[22:29] <maxb> ScottK: What's the X for, in that model?
[22:29] <ScottK> maxb: This is an Ubuntu channel.  Nothing to do with us there.
[22:29] <ScottK> Number starting with 1
[22:30] <maxb> ScottK: I don't understand what you're saying. Given that Ubuntu is the only distribution with PPAs, how can documentation about PPA versioning not apply?
[22:30] <maxb> ScottK: Yes, but what does that number mean? Attempts at backporting?
[22:31] <ScottK> Yes.  Revisions.
[22:31] <ScottK> maxb: It's written by Launchpad developers who are not Ubuntu developers.
[22:32] <maxb> If ~ppaX indicates releases of a package in a ppa, and ~intrepidX indicates attempts at backporting, then the order of versioning significance dictates ~ppaX before ~intrepidX
[22:32] <maxb> Because the first attempt at backporting the second release needs to be newer than the second attempt at backporting the first release
[22:32] <ScottK> maxb: What happens if you upgrade from Hardy to Intrepid.  You need to move to the intrepid version of the package.
[22:33] <ScottK> How do you ensure that with that broken model
[22:33] <ScottK> maxb: It's really OT here anyway.  Go find someone on #launchpad that knows more about distro development than we do here.
[22:33]  * ScottK heads off.
[22:34] <maxb> Erm
[22:36] <maxb> I am unconvinced the model I'm suggesting is broken. Is there a better channel to discuss the interaction between Ubuntu PPAs and Ubuntu primary archive?
[22:37] <khashayar> maxb: I pm:ed you.
[22:39] <maxb> indeed, I just wanted the conversation to unambiguously show that I don't accept the assertion that that model is broken
[22:52] <RainCT> uhm.. how can I install the nvidia 180 driver? I tooke the .deb's from packages.ubuntu.com but the version doesn't show up in jockey
[22:52] <RainCT> (as always I want to know something, no answers in #ubuntu :P)
[22:52] <maxb> RainCT: Install the -modaliases package, then jockey should know about it
[22:52] <RainCT> funny, that's what I was doing right now :P
[22:52] <RainCT> maxb: thanks :)
[22:53] <maxb> But, what do you mean you took the .deb's from packages.ubuntu.com? Why not let apt get them for you?
[22:53] <RainCT> maxb: because (and I've no idea why) I can't get APT to see it..
[22:53] <RainCT> updates, backports, etc. are enabled and cache up2date
[22:53] <RainCT> but I only see 180 packages in jaunty
[22:53] <maxb> That's because they're in intrepid-proposed
[22:54] <RainCT> oh. packages.ubuntu.com shows them in intrepid-updates
[22:54] <RainCT> great, jockey sees it now.. let's see if it works
[22:56] <RainCT> maxb: failed to initialzie kernel module"
[22:56] <RainCT> maxb: do I need to reboot'
[22:56]  * RainCT should learn to type :P
[22:58] <RAOF> What's a major update binary nvidia driver doing in -proposed?
[22:58] <cody-somerville> lmao
[23:00] <maxb> Oh, it's actually in -updates now, I hadn't noticed.
[23:00] <maxb> However, it's a new-to-intrepid package, so it's strictly opt-in
[23:00] <maxb> probably why it was considered SRU-able
[23:00] <directhex> does 180.22 support gtx295?
[23:01] <maxb> 180 does ameliorate some severe compiz rendering issues, so that's probably also a reason for the SRU
[23:02] <directhex> hm, no, 295 unsupported
[23:02] <RainCT> (works now)
[23:02] <bluesmoke> maxb: Does it fix nvidia leaking texture memory into the compiz process?
[23:03] <directhex> "Fixed a regression that could result in window decoration corruption when running Compiz using Geforce 6 and 7 series GPUs."
[23:03] <maxb> Don't know about that one. I know it stops my window decorations from corrupting themselves often, which they did with 177
[23:05] <RAOF> bluesmoke: That's a good question.  I haven't tried that :)
[23:35] <Chris`> Which section would a flight simulation program best fit?
[23:41] <ScottK> maxb: I'll file a bug on help.launchpad.net when I get a moment.
[23:41] <maxb> Where would such a bug belong? It's not exactly part of launchpad-the-project per-se?
[23:42] <ScottK> BTW, I don't accept that people managing to develop a really slow web tool gives them any particular expertise about Linux distro development.
[23:42] <ScottK> maxb: Dunno.  In Ubuntu we have a project for web site bugs, I'd assumed that Launchpad would have something similar.
[23:43] <ScottK> Generally I file against the launchpad meta project and someone triages it into the right place.
[23:44] <maxb> ok. By the way, are there any concrete examples of the number in ~releaseX being other than 1?
[23:44] <ScottK> Sure.  It takes me more than one try on a not infrequent basis.
[23:45] <maxb> for sourceful backports, then?
[23:45] <ScottK> maxb: https://edge.launchpad.net/~ubuntu-clamav/+archive for a PPA.
[23:46] <ScottK> That also shows you the multi-release model I suggest is appropriate.
[23:48] <maxb> In a quick read through I don't see anything other than ~release or ~release1, but I do see foo~dapper1~ppa4 but foo~hardy1~ppa1 which is enlightenting
[23:49] <maxb> My advocacy of ~ppaX~releaseX is founded on the assumption that any bump to the ppaX number is a crosscutting packaging change which *will* be backported to all release series
[23:49] <maxb> I agree that without that assumption, upgrading across releases is broken
[23:50] <ScottK> maxb: https://launchpad.net/ubuntu/+source/clamav/+publishinghistory
[23:50] <ScottK> Also ~ppa is a higher revision than anything you'll find in *-backports and that should be avoided too.
[23:52] <maxb> Ah, thanks, didn't know about that view, so I tried to skim though all of the superseded package info, and evidently missed bits
[23:54] <ScottK> Clamav is about as tortured a package history as you are likely to find as it's a highly used package with lots of security uploads and stuff.
[23:55] <maxb> Is ~dapper1ubuntu0.1 just someone driving dch in a non-optimal way?
[23:56] <maxb> ohh... I think I'm seeing the tortuous sense in it now
[23:58] <maxb> I agree ~ppaX is a bit of a nonsense all round, really. If you are doing further development of foo 1.0-1ubuntu1, then it makes more sense to go to 1.0-1ubuntu1ppa1 rather than 1.0-1ubuntu2~ppa1, I think
[23:58] <maxb> Whilst if you are doing a backport, it needs to be less than an official backport.
[23:58] <maxb> So ~ppa loses either way
[23:59] <savvas> Yay, catfish 0.3.2-1 published in debian: http://packages.debian.org/sid/catfish