[05:10] (slangasek/#ubuntu-motu) hmm, scratch that, it is installed
[05:12] <persia> Do the language catalogs translate "Password:" as "Password:" for PAM, perhaps?
[05:12] <slangasek> no
[05:13] <slangasek> $ su
[05:13] <slangasek> Contrasea:
[05:13] <slangasek> gksudo still works, so maybe it's setting the locale somewhere first, dunno
[05:16] <imbrandon> hrm you would think there would be an api or message passing specificly for something like this, scrapping dosent seem "proper"
[05:16] <slangasek> there is an API.
[05:16] <pwnguin> psh
[05:16] <pwnguin> its called pam
[05:16] <Konam> hi
[05:16] <pwnguin> but nobody wanted to work with that when just frontending sudo might work
[05:17] <Konam> the deluge gutsy package is bad, it works but not properly, take a look at it
[05:17] <imbrandon> seems like a expect script hehe
[05:17] <RAOF> Konam: Anything specific?
[05:17] <ScottK> Konam: If you want someone to actually care, you are going to have to provide specifics.
[05:17] <RAOF> Konam: Bonus marks for LP bugs.
[05:18] <Hobbsee> mega-bonus-points for actually doing the work.
[05:18] <bddebian> +1
[05:19] <RAOF> -
[05:20] <StevenK> RAOF: Like off the keyboard entirely? :-P
[05:20] <pwnguin> StevenK: can't do that, that's where capslock is slatd to go!
[05:23] <RAOF> Konam: Of course, the very best way to ensure that no-one does anything about a problem is to pop up, make vague statements about brokenness, then disappear.
[05:26] <Konam> RAOF i'm in the deluge channel to see if it is bug or something
[05:26] <Konam> but thanks for your interest
[05:27] <macd> Am I correct in thinking my pbuild env. needs all dependencies satisfied prior to building, or will pbuild try and satisfy those from repos?
[05:30] <imbrandon> it will try to satisfy those
[05:30] <imbrandon> as it bulds
[05:30] <Hobbsee> more spam!
[05:30] <pwnguin> spam?
[05:30] <macd> if it cant, to clarify, do I just install them to my system, or is there some way I need to isntall them into the pbuild chroot env?
[05:31] <pwnguin> no
[05:31] <pwnguin> the whole point is to make sure it builds anywhere
[05:32] <pwnguin> so if you've gone and created the base, with universe enabled
[05:32] <pwnguin> you'll need to figure out where the bug is =/
[05:32] <RAOF> Konam: That's OK, thanks.
[05:33] <ScottK> macd: You'll want to remove the depens on libmocha before you try to build it.  It's not in Ubuntu and not really needed.
[05:33] <macd> ScottK, yeah the 1.2.4 orig.dsc doesnt have libmocha as a dep
[05:33] <macd> soren, Im a bit confused as to why the debian package has it
[05:33] <macd> eww so*
[05:34] <greeneggsnospam> heh
[05:35] <ScottK> macd: It's needed for some test stuff, but doesn't actually hurt anything if not present.
[05:36] <ajmitch> macd: it does have it, in debian/control
[05:36] <ajmitch> as ScottK says, testing only
[05:39] <bddebian> heh
[05:40] <ajmitch> then you've had more experience with it than I have
[05:41] <ScottK> It wasn't actually hard as he's using Feisty for development and will upgrade to Gutsy shortly, so it was in his self interest for us not to mess it up.
[05:41] <macd> if a package is in universe and meets the version requirements and pbuilder cant find it, uhh what then?
[05:42] <ScottK> macd: Can it find any Universe packages?
[05:44] <macd> I'm not exactly sure how to check that, It found debhelper and dpatch but those are in main
[05:44] <ScottK> macd: What instructions did you use to set up your pbuilder?
[05:44] <macd> https://wiki.ubuntu.com/PbuilderHowto and Im on feisty.
[05:45] <ScottK> IIRC that doesn't include enabling Universe.
[05:46] <macd> that explains alot then ;)
[05:46] <ScottK> imbrandon or ajmitch: I really need to concentrate on not messing up the code I'm writing as I'm about to do a release.  Would one of you please help macd enable universe on his pbuilder...
[05:46] <ScottK> Anyone else for that matter...
[05:46] <tonyyarusso> Could someone with experience understanding crash reports take a look at https://bugs.edge.launchpad.net/ubuntu/+source/kompozer/+bug/148576 please?
[05:46] <ubotu> Launchpad bug 148576 in kompozer "kompozer-bin crashed with SIGSEGV" [Medium,New] 
[05:46] <macd> ty
[05:47] <ajmitch> macd: the part about enabling universe is actually on that wiki page
[05:47] <macd> the .pbuildrc I just saw that
[05:47] <imbrandon> sure one sec lemme grab a drink, the short of it , do `sudo pbuilder login --save-after-login`
[05:47] <imbrandon> err yea what ajmitch said
[05:48] <ScottK> tonyyarusso: I'd add to that request and knows something about why stuff dies on 64bit archs.
[05:48] <tonyyarusso> ScottK: good point
[05:52] <tonyyarusso> RAOF: If you're around, would you be willing to try reproducing that bug?
[05:53] <RAOF> tonyyarusso: Ok, but it'd need to wait for the evening.
[05:53] <tonyyarusso> RAOF: That's still infinitly sooner than I'll have a clue what to do about it.
[05:53] <imbrandon> bbiab
[05:53] <RAOF> I'm looking at the backtrace, and it's... urgh.
[05:59] <Jaearess> Hello all. I'd like to get involved in packaging for Hardy, but I'm not sure when people can start working on packaging for a new release. Is it when the tool chain is released (Oct. 25 according to the Hardy schedule) or is it some time later?
[05:59] <persia> tonyyarusso: Do you have the hardware & can you reproduce?
[06:00] <ajmitch> Jaearess: as soon as you feel like it, especially for new packages
[06:00] <ajmitch> nothing can be uploaded to the archive until the toolchain is inplace & settled
[06:01] <tonyyarusso> persia: I only have 32-bit running feisty, so probably not the best environment to test.
[06:01] <ajmitch> but that doesn't stop people from preparing things to be uploaded
[06:01] <Jaearess> ajmitch: Ah, I see. Thank you :)
[06:01] <pwnguin> Jaearess: what did you have in mind that you would be doing?
[06:01] <persia> tonyyarusso: Ah.  OK.  Briefly it looks like there's an issue discovering the current context for the spellchecker, but without a test environment it's hard to be sure.
[06:03] <tonyyarusso> persia: as in figuring out whether aspell is present and if so where?
[06:03] <pwnguin> Jaearess: if you haven't any experience with packaging, there's an intro to packaging that walks you through a hello world. that's probably the best place to start. you can probably have that down by the time hardy's open
[06:03] <Jaearess> pwnguin: I'm not really sure at the moment. I was thinking of packaging somethings that people had reported on Launchpad as needing packaging and just whatever else I could do to help. I just know I want to give something back to Ubuntu :)
[06:03] <persia> tonyyarusso: Take a look at the StatketraceSource.txt.  I think the problem is either related to the call in #3 or the call in #7.
[06:04] <persia> tonyyarusso: Specifically, I think that mozRealTimeSpell, when enabled, is unable to do it's thing because it's not been told where to paint.
[06:04] <persia> s/it's/its/
[06:04] <ScottK> tonyyarusso: Just based on the topic, I wonder if Kompozer is doing something like Gramps was: https://bugs.edge.launchpad.net/ubuntu/+source/gramps/+bug/120569
[06:04] <ubotu> Launchpad bug 120569 in gramps "[gutsy]  gtkspell segfaults when trying to set the language on gtk.TextView" [Medium,Fix released] 
[06:04] <Jaearess> pwnguin: Yeah, I've been looking through some of the stuff on the wiki; I just need to actually go through and work on getting packaging figured out.
[06:04] <pwnguin> Jaearess: in that case, how about taking notes while you walk through packaging-guide?
[06:05] <ScottK> Or reading what persia just said, nevermind I think.
[06:05] <pwnguin> !info packaging-guide
[06:05] <ubotu> packaging-guide: The Ubuntu Packaging Guide. In component main, is optional. Version 7.04.4 (feisty), package size 100 kB, installed size 612 kB
[06:05] <persia> ScottK: No, that's the annoying API change in GTK memory management :)
[06:05] <pwnguin> I know it's out of date, and it would greatly help if someone pointed out the changed needed
[06:05] <ScottK> persia: OK.
[06:05] <Jaearess> pwnguin: Okay, I think I'll give that a try.
[06:05] <LaserJock> pwnguin: what's out of date?
[06:06] <ScottK> persia: Anything that starts with G, I hardly know about.
[06:06] <pwnguin> last i looked, i think hello world isn't up to date
[06:06] <pwnguin> and i know upstream has a new version
[06:06] <pwnguin> of hello-world
[06:06] <persia> ScottK: heh.  Most of them are similar to thinks beginning with K or Q, except targeting a different API.
[06:06] <LaserJock> pwnguin: it shouldn't be that bad
[06:06] <pwnguin> LaserJock: well, the less barriers the better :)
[06:07] <ScottK> Right.  I like server stuff.  Little/no annoying user interface stuff to deal with.
[06:07] <LaserJock> ScottK: amen to that
[06:07] <LaserJock> pwnguin: so you're volunteering to fix it then? :-)
[06:07] <pwnguin> 'sides, if we get new people to file bugs against the packaging documentation and submit diffs, the better!
[06:08] <persia> Personally, I like GUI and Audio bugs: they tend to be easier to fix, as the code hasn't been reviewed by as many people.  Mind you, deep GTK or QT bugs are frustrating.
[06:09] <pwnguin> LaserJock: hey, no fair defending your work and then asking someone else to fix it :P
[06:10] <ajmitch> pwnguin: that's how free software works :)
[06:10] <LaserJock> pwnguin: it's not my work, it's the communities work ;-)
[06:10] <LaserJock> is anybody here in the Desktop Team?
[06:11] <LaserJock> I need to find a project to work on that actual has bugs
[06:12] <Hobbsee> kde exists.
[06:12] <LaserJock> the one I'm working on now doesn't have much for bugs so it's not as interesting from a "let's learn how to use the tools" perspective
[06:12] <macd> yay, it built, installed and my rails app didnt break with it.
[06:12] <pwnguin> fixing bugs isnt exactly "learning to use the tools"
[06:12] <bddebian> LaserJock: "project" meaning what?
[06:12] <pwnguin> at some point it becomes "applying judgement and wisdom"
[06:12] <LaserJock> Hobbsee: does Kubuntu have a "Desktop Team"?
[06:13] <persia> LaserJock: Aren't there still a fair number of outstanding MOTU Science bugs?
[06:13] <StevenK> LaserJock: "Riddell"
[06:13] <Hobbsee> LaserJock: kubuntu-members
[06:13] <Hobbsee> so, somewhat
[06:13] <imbrandon> LaserJock: kubuntu-members
[06:13] <pwnguin> does kubuntu need a NOT desktop team?
[06:14] <pwnguin> kubuntu-kernel ;)
[06:14] <imbrandon> heh
[06:14] <persia> pwnguin: Kubuntu differs from Ubuntu primarily due to the desktop, so in a sense, the Kubuntu team is a desktop team.
[06:14] <pwnguin> persia: that is the essence of my point, i think
[06:14] <persia> pwnguin: Right.  Sorry.  My slow typing combined with your separated statement.  Apologies.
[06:15] <LaserJock> hmm, it's just always bugged me that the Ubuntu Desktop Team is really the Ubuntu Gnome Desktop Team
[06:16] <LaserJock> persia: I'm looking for upstream projects
[06:16] <Hobbsee> LaserJock: the names get more screwy, and now that actually refers to a subset of canonical developers
[06:16] <Hobbsee> or something.
[06:16] <Hobbsee> i have a list of all the teams now, somewhere
[06:16] <pwnguin> LaserJock: get me phred and phrap from upstream into ubuntu :P
[06:18] <bddebian> Hmm, we don't have autopackage stuff ?
[06:18] <Hobbsee> huh?
[06:18] <persia> autopackage?
[06:18] <pwnguin> why would ubuntu have it?
[06:19] <bddebian> Sorry, trying to build a new game and he is using it :-(
[06:19] <bddebian> apg++
[06:20] <LaserJock> we have 0install, why not autopackage? :-)
[06:20] <Hobbsee> LaserJock: limiting crack.
[06:20] <LaserJock> too late ;-)
[06:20] <StevenK> That reminds me. I need to make checkinstall SEGV
[06:20] <persia> autopackage appears to automatically download random libraries from the internet.  That can't be ideal.
[06:21] <bddebian> Aye though apparently this apg++ think somehow makes linking easier
[06:22] <StevenK> Easier than what?
[06:22] <bddebian> Dunno I didn't even know WTF it was until I just googled it :-)
[06:22] <persia> bddebian: It does make it easier, for a developer, or someone with a dedicated need.  It reminds me of why I prefer to avoid python packages (EZinstall)
[06:23] <persia> StevenK: Easier than having the user hunt down the right libraries and install them, or waiting for the distro maintainers to package the software in the first place.
[06:23] <ScottK> persia: Just patch the ezinstall stuff out.
[06:23] <StevenK> persia: Ah yes, along with the fun "autopackage appears to automatically download random libraries from the internet."
[06:24] <persia> ScottK: Right.  For C, I don't have to worry about that: if upstream is whiny about package dependencies, they provide the source of the libraries, so I can check if there are useful patches to extract.
[06:24] <persia> StevenK: Indeed.  Context is suprisingly useful :)
[06:24] <ScottK> Right.  Well right thinking Python developers don't use ez_install.
[06:25] <ScottK> Sounds reasonable to me.
[06:25] <pwnguin> autopackage kinda sounds like a distro without a home
[06:26] <StevenK> Or one that just piggybacks
[06:26] <bddebian> Gnight ScottK
[06:26] <persia> pwnguin: Sortof.  It's based on the concept of there being one true linux, with various distributions just means to get a base install, on top of which one uses autopackage.
[06:27] <pwnguin> the whole thing reeks of "i hate finding rpms for fedora when I use mandrake!"
[06:27] <persia> pwnguin: Exactly, except replace with linspire & MEPIS
[06:27] <LaserJock> well, I'm seeing some interest in autopackage for science apps on the forums
[06:27] <pwnguin> from who?
[06:27] <LaserJock> users
[06:27] <pwnguin> users or developers?
[06:28] <LaserJock> for stuff that's not in Ubuntu
[06:28] <persia> 0install seems safer than autopackage: it doesn't install as root.
[06:28] <LaserJock> I'm not sure what a good response is
[06:28] <pwnguin> my favorite line from the FAQ
[06:28] <pwnguin> # What about security?
[06:28] <pwnguin> What about it?
[06:28] <LaserJock> at some point it's unrealistic to assume we can provide *all* software
[06:28] <pwnguin> well, i'd say debian's pretty good at it
[06:29] <persia> pwnguin: We've more than Debian (at least at the beginning of dev cycles), but that's still not everything.
[06:31] <persia> Perhaps we should determine a "Ubuntu best practice" method for 3rd party preparations, and recommend it?  Checkinstall is out, but having something that lets upstreams make instant (if bad) .debs for distribution might help, and may even be better for users, as the software could then be uninstalled cleanly (unlike building from source).
[06:31] <pwnguin> isn't it called dpkg?
[06:31] <LaserJock> persia: I think I agree
[06:32] <persia> pwnguin: That takes a fair bit or work to learn, and is a high bar for people who primarily develop for Mac & Fedora (for example)
[06:32] <LaserJock> perhaps a dh_make2
[06:32] <ScottK> One more thing... doko: Please consider adding libsigc++-2.0 to your ia32-libs upload so Skype will work on AMD64.
[06:32] <imbrandon> well basicly that means make pbuilder ( and debootstrap ) distro independant, easy to install and give it a front end
[06:32] <pwnguin> persia: easy and "best practices" might not go together
[06:33] <coolbhavi> hello...... Can you please resync my keyrings to the revu uploader keyring so that I can upload packages..Please.. Everything is done according to revu wiki page
[06:33] <LaserJock> well, if we had something that was at least PPA-ready
[06:33] <macd> when I use dget to grab source, where does pbuilder store that?
[06:33] <persia> imbrandon: That does the backend, but there's still the preparation of debian/rules, debian/copyright, and debian/control.  copyright is easy to do sufficiently (if poorly) from a form.  control is similar, although perhaps it needs something to check dependencies somehow.  rules is not always obvious.
[06:33] <macd> I poked around in /var/cache/pbuilder but didnt see it
[06:34] <LaserJock> macd: dget doesn't build the source package automatically
[06:34] <persia> macd: pbuilder doesn't store it anywhere.  dget puts it in .
[06:34] <Hobbsee> coolbhavi: it'll take around an hour
[06:34] <imbrandon> persia: true the gui could mix dh_make and pbuilder, kinda like installshield builder does
[06:35] <Hobbsee> checkinstall makes you specify your own vesrion # though, so may actually be safer
[06:35] <Hobbsee> as in, easier ot reject teh bugs.
[06:35] <persia> imbrandon: That sounds reasonable.  I'm still not sure about rules: there are so many exception cases.
[06:35] <macd> persia, so If I need to make a change to debian/control I'll need to untar it, change it and retar it up? Im just a bit confused on a few things
[06:36] <imbrandon> persia: yea nothing is gonna subsitute good old packing , but to make a "something for upstream to get by with" thing
[06:36] <pwnguin> macd: just grab the source, unpack it, and debuild it back up
[06:36] <coolbhavi> My launchpad id is https://launchpad.net/~bhavi.. please.......
[06:36] <persia> Hobbsee: Yes, although checkinstall has other failings.  Perhaps just fixing checkinstall to be acceptable is a solution.
[06:36] <persia> macd: Use `dpkg-source -x fo.dsc` to unpack, and `debuild -S` to pack.
[06:37] <imbrandon> if checkinstall has some dependancy checking would be nice
[06:37] <persia> imbrandon: Exactly.  Even better, something that was pluggable, so that with sufficient chroots it could produce .deb, .rpm, .tgz, etc.
[06:38] <imbrandon> definately
[06:38] <imbrandon> sonds like a good project
[06:38] <persia> (for extra points, produce .dsc/diff.gz, .srpm, etc.)
[06:38] <pwnguin> this would of course require defining equivilent packages across dkg and rp
[06:38] <pwnguin> m
[06:39] <persia> pwnguin: No: it just means having a pluggable dependency analysis checker: check what gets dlopen'd, check the parent package, and assign a dependency.
[06:39] <imbrandon> hrm lots of reflection
[06:39] <imbrandon> yup
[06:39] <imbrandon> all done in the chroot
[06:39] <persia> The problem I see is getting the initial set of build-deps to contruct.  Iterative, or source-inspection?
[06:40] <pwnguin> thats what i meant
[06:40] <imbrandon> well if it builds and runs on the host ...... hrm
[06:40] <pwnguin> how do you define build-deps across debian / redhat?
[06:41] <persia> imbrandon: That does it: build it locally, determine deps from the local build, and then pass to chroots.  Clean, and only requires +1 builds.
[06:41] <persia> pwnguin: Watch the local build, and determine which files are used.  In the chroots, determine which package provides that file.  Add those packages as build-dependecies.
[06:42] <imbrandon> yea, would require lots of work but i think its a great idea
[06:43] <imbrandon> and would be WELL worth the effort, even if a package needed some manual tweaking to go into a repo its still does the major stuff in a point-n-clicky way accross distros, hell gentoo has debootstrap and iirc so does suse 10.x
[06:44] <imbrandon> i'm sure there are ways to get base suse / fedora / mandrake chroots
[06:44] <LaserJock> well, just getting a .deb solution would be great, IMO
[06:44] <pwnguin> what exactly does this solve?
[06:44] <persia> That would go a great way towards reducing checkinstall / 0install / autopackage / ezinstall / etc., as developers could easily produce distro-tailored binary packages, and source packages in all desired formats to ease distro adoption.
[06:44] <imbrandon> i dont think it would apply to meta distros like freebsd ports or gentoo though
[06:45] <persia> LaserJock: The problem with a .deb only solution is that it's not much better than checkinstall, but building the .deb / .dsc target seems a good first goal: with other distros perhaps adding their components if desired.
[06:45] <pwnguin> if i'm a developer for say suse, and i want an easy way to deb
[06:45] <LaserJock> no, I didn't mean .deb only
[06:46] <pwnguin> how does the chroot work?
[06:46] <LaserJock> I meant not worrying about .rpms, etc.
[06:46] <imbrandon> pwnguin: you know how bsd jails work ?
[06:46] <persia> pwnguin: Unpack the tarball, chroot into the minimal ubuntu, pbuild.
[06:46] <pwnguin> ah.
[06:46] <persia> LaserJock: I think it's worth worrying about sufficient abstraction to easily allow RPMs later, but I'd agree for a first pass.
[06:47] <pwnguin> so we're talking everyone carries an debian / ubuntu minimal build env
[06:47] <persia> pwnguin: The tool would presumably have minimal tarballs for all desired target environments.
[06:47] <imbrandon> no only upstream packagers that wish to use this tool
[06:47] <bddebian> I thought everything was going to be in some VCS so we are all saved anyway? :-)
[06:47] <persia> bddebian: How does that help for things we haven't packaged?
[06:47] <pwnguin> but how does the unpacker know which extra packages i need to install?
[06:48] <bddebian> Dunno but it's some kind of cure-all I hear ;-P
[06:48] <imbrandon> pwnguin: from the local build that the upstream developer surely already has going
[06:48] <persia> pwnguin: It doesn't.  The sbuild or pbuilder process downloads the build-deps as required for the minimal chroot build.
[06:49] <pwnguin> so step one build locally and watch to see which files / headers are accessed
[06:49] <imbrandon> pwnguin: think of this as more of a MOTU-in-a-box for upstreams to use *instead* of them only providing a tar.gz for users to resort to checkinstall
[06:49] <pwnguin> step two build a .dsc etc and pbuild a deb
[06:49] <persia> pwnguin: I'd say 1) local build, 2) analysis of local build, 3) build .dsc, 4) build n .debs, but otherwise yes.
[06:50] <pwnguin> i guess the other problem is
[06:50] <pwnguin> build deps missing / version problems?
[06:51] <RAOF> pwnguin: You mean "missing in $DISTRO", yes?
[06:51] <imbrandon> somethings will always have to be checked and most auto* stuff will check the versioning when building
[06:51] <imbrandon> if $dist is missing it
[06:51] <persia> pwnguin: For missing build-deps (the dependency also isn't packaged), the build would fail (with a log).  For version conflicts, the build fails, and upstream version X isn't supported for distro Y.
[06:52] <persia> If upstream wants to be fancy with super-portability (e.g. parallel code paths for QT3 vs. QT4), then there is wider support.
[06:53] <imbrandon> rember too this doesnt have to be a 100000% end all, we're looking for something inbetween checkingstall and MOTUship
[06:53] <imbrandon> ( with a GUI )
[06:53] <imbrandon> heh
[06:53] <pwnguin> why the gui?
[06:53] <persia> imbrandon: Even between checkinstall and MOTU Contribution
[06:54] <imbrandon> people love point-and-clicky
[06:54] <pwnguin> they still need to grab the build deps locally anyways
[06:54] <persia> pwnguin: Easier to present multi-entry dialogs (e.g. template for debian/copyright).
[06:54] <persia> pwnguin: If they are a developer, they probably already have the build-deps locally installed, no?
[06:55] <pwnguin> there's also the question of automatic builds and GUIs
[06:55] <pwnguin> persia: if they're the developer, then they outta be comfortable with the command line, i'd say. but if you think it'll be easier, hats off
[06:56] <imbrandon> it would only need to be done for the initial packageing pwnguin , subsuquint builds could be done the "normal" automated way
[06:56] <persia> pwnguin: Not easier.  Flashier.  More candy.  Easier to blog with screenshots.  These build mindshare, which is useful.  No reason it can't have a CLI backend.
[06:56] <pwnguin> you just said it'd be easier to present multi-entry dialog
[06:56] <imbrandon> automatix for MOTU's /me ducks
[06:57] <LaserJock> well, I think helping upstreams get to us is a good thing
[06:57] <LaserJock> and helping users help upstream get to us is a good thing
[06:58] <persia> imbrandon: I'd disagree.  It's doesn't try to do all the stuff you'd do if you had the secret info, but rather it provides a scripted bridge for the uninterested.  Wait, nevermind.  You're right.
[06:58] <imbrandon> persia: hehehe
[06:59] <imbrandon> persia: you down for making any of this happen, i'm totaly psyced about it and actualy thinking about getting some design goals etc going
[06:59] <persia> LaserJock: Do you think it would be easier to market a new tool, or overhaul/replace checkinstall?  Also, should we point at getdeb as a central location to advertise new unofficial packages?
[07:00] <imbrandon> persia: +1 on the getdeb
[07:00] <Hobbsee> but then, who knows of the quality of the getdeb stuff
[07:00] <Hobbsee> im' assuming we're still rejecting all their bugs
[07:00] <persia> Hobbsee: getdeb still (softly) recommends checkinstall.  It'd be nice to have something a little cleaner.
[07:00] <LaserJock> persia: problem with checkinstall would be that we don't have any control over it
[07:00] <persia> Hobbsee: Ubuntu rejects the bugs, but LP upstreams may accept them, depending...
[07:01] <Hobbsee> persia: yeah, well.  but we dont care about them either :)
[07:01] <imbrandon> lol
[07:01] <persia> Hobbsee: As long as you have narrow enough vision when rejecting, I shan't complain :)
[07:01] <imbrandon> heh Hobbsee you are so pesimistic sometimes , i care about ( some ) upstreams , watch the word "we" :)
[07:01] <imbrandon> hehe
[07:02] <Hobbsee> imbrandon: i was thinking in terms of bugs, and stuff that we personally would be fixing.
[07:02] <imbrandon> tru tru , just spoutin
[07:02] <Hobbsee> but i agree - as a wider issue, it's worth thinking about :)
[07:03] <imbrandon> ok anyhow anything s better than checkinstall as is
[07:03] <persia> LaserJock: Makes sense.  I'm not so concerned about control, as long as the results are useful.  Checkinstall already seems to generate .deb, .rpm, and .tgz.  Perhaps we can send patches to make the .debs better.
[07:03] <LaserJock> persia: well, I'm just saying, can we just go "heh, we're gonna take over checkinstall, do you mind?"
[07:04] <imbrandon> persia: yea i was thinking the same thing, or a fork just adding a step inbetween building and packing
[07:04] <imbrandon> in checkinstall
[07:04] <imbrandon> that does the dep resolution
[07:04] <persia> I'd like to avoid a fork, but I think we'd get on better with checkinstall upstream if we prepared some patches for them, rather than just repeating "checkinstall makes crack".
[07:05] <imbrandon> we would still need to make use of "clean rooms" though ( chroots )
[07:05] <persia> imbrandon: Something simple like adding something for dependency generation would be awfully nice.
[07:06] <imbrandon> heh depends on the job but yea i agree
[07:06] <pwnguin> heh
[07:06] <macd> I think I'm missing something seriously fundamental, Ive got the dsc, the source, the diff.gz which mentions changes to debian/* but nothing has a debian/* dir in it?
[07:06] <superm1> perhaps something that runs ldd on the binaries, and then uses apt-file to find where they are coming from
[07:07] <imbrandon> macd: `dpkg-source -x *.dsc`
[07:07] <pwnguin> imbrandon: no wonder i cant access it; we cant both browse mexico's only http server :P
[07:07] <superm1> it would grab a majority of the dependencies at least then
[07:07] <imbrandon> LOL
[07:07] <imbrandon> superm1: i was thinking exactly that
[07:07] <persia> superm1: We can't guarantee the presence of apt-file: a network solution might be cleaner, but that sort of thing.
[07:07] <superm1> persia, well make checkinstall depend on apt-file then
[07:07] <imbrandon> heh
[07:08] <persia> macd: That's normal.  The .diff.gz gets applied to the .tar.gz, and generates the debian/ directory.
[07:08] <pwnguin> there can't be that many header files
[07:08] <superm1> or at least recommend it
[07:08] <pwnguin> just build a DB
[07:08] <macd> a light upstairs just went off, thanks
[07:08] <superm1> and then if it doesn't detect its presence, then a network solution to query packages.ubuntu.com could go too
[07:08] <persia> superm1: Think cross-distro.  It'd be nice to get something better for checkinstall in Ubuntu, but if we can patch it so upstream can send it to everyone, we get better random crack out there.
[07:09] <superm1> indeed.  your right it is always better to think on a more distro global scale with things like this
[07:09] <persia> pwnguin: There's a potentially infinite number of header files: consider all the libraries that could ever be written, in all the programming languages that have been invented.
[07:09] <pwnguin> good news
[07:09] <pwnguin> nobody uses random infinite libraries
[07:10] <imbrandon> the one thing this is gonna be tricky with is pythn packages
[07:10] <macd> Should I leave the maintainer name alone? or change it to mine so I can sign it when done?
[07:10] <imbrandon> you sign it based on the changelog
[07:10] <pwnguin> macd: theres a script out there to fix it up motu style
[07:10] <persia> imbrandon: Why python?  Can't we extract a fair amount of info from either setup.py or the ezinstall wrapper?
[07:10] <superm1> imbrandon, well you can always parse all python source files for import lines too
[07:10] <superm1> and do test imports if it came down to it
[07:10] <imbrandon> hr,
[07:10] <pwnguin> imbrandon: perl'd likely also be a pita
[07:10] <imbrandon> hrm
[07:11] <persia> Any scripting language is annoying : import, use, source, etc.  It just needs parsers.
[07:12] <superm1> someone should get this down into a spec to work on for hardy
[07:12] <bddebian> Gnight folks
[07:12] <superm1> or at least discuss at uds
[07:13] <imbrandon> superm1: yea i'm doing just that right now
[07:13] <persia> imbrandon: Thanks.  Please subscribe me to the spec when you get it up.
[07:13] <imbrandon> k
[07:13] <superm1> me too, i'll join in on this if its put up for a sprint at uds
[07:13] <imbrandon> kk
[07:14] <LaserJock> we should discuss something on ubuntu-motu/ubuntu-devel
[07:14] <imbrandon> wow checkinstall is just a big bash script
[07:15] <pwnguin> heh
[07:15] <imbrandon> i'm just putting some things in a text file for now, i'll write a coherant spec after soem sleep tonight
[07:16] <persia> imbrandon: Yep.  It's not very robust either: it assumes a fair amount about the running system, which is not always true.
[07:17] <imbrandon> but just from an initial inspection i'm thinking after mabe some "basic" dep checking in checkinstall we might be better making our own tool based in part on checkinstall code/ideas and distro indep
[07:17] <imbrandon> with an optional gui
[07:18] <persia> imbrandon: That sounds good.  I'm in favor of a parallel path: basic fixes to checkinstall (with efforts to get upstream), and a better local tool to assist Ubuntu users who are upstream developers in producing preview debs.
[07:19] <imbrandon> persia: exactly
[07:19] <Hobbsee> ajmitch: cover your ears.
[07:19] <persia> ajmitch: It's silent.  Otherwise, adjust your bell :)
[07:19] <lifeless> uhm
[07:19] <lifeless> checkinstall as a way to produce 'you should do X' - maybe
[07:19] <ajmitch> hi lifeless :)
[07:19] <lifeless> as a way to make packages.... where do you live prey tell ?
[07:19] <imbrandon> heya lifeless
[07:20] <lifeless> hi guys, and gal
[07:20] <RAOF> Hey lifeless
[07:20] <Hobbsee> hiya lifeless!
[07:20] <persia> lifeless: For context: we're thinking that patching checkinstall will result in something more useful than enabling autopackage.
[07:20] <imbrandon> lifeless: hehe we're trygin to make a MOTU-in-a-box , lots of backlog to read, its not what you think :)
[07:21] <persia> Further, replacing checkinstall with some guided .dsc/.deb builder that is relatively sane will further improve the random crack found on the internet.
[07:21] <imbrandon> by dependancy checking, gracefully pulling off dh_make type things etc
[07:21] <imbrandon> and clean room building with chroots/pbuilders
[07:22] <imbrandon> to put it in 2 sentances
[07:23] <pwnguin> seriously, we cant all visit the checkinstall website at once =/
[07:24] <imbrandon> LOL
[07:24] <lifeless> no browser == no random distraction
[07:24] <lifeless> you should try it sometime
[07:24] <persia> All the docs, etc. are available in the package.  `apt-get source checkinstall` (and don't `aptitude install checkinstall`: that's not the right command yet :))
[07:25] <imbrandon> telnet www.asic-linux.com.mx 80
[07:25] <pwnguin> well, im trying to find a cvs for ohloh
[07:26] <persia> imbrandon: If for nothing else, you might like `aptitude download hello` and similar.
[07:26] <pwnguin> it appears there's none
[07:28] <pwnguin> unrelated: "Back around 1999, I was really interested in getting all of Debian imported into CVS (ugh!) so we could have all the benefits of pervasive version control. I've always been sad it didn't happen, especially since ubuntu did it. Although they seem to get less benefits from it than I would have thought at the time, go figure." (from joey hess's blog)
[07:28] <pwnguin> all of ubuntu is in cvs/bzr?
[07:29] <imbrandon> i read that a few days ago
[07:29] <imbrandon> and no not afaik
[07:29] <persia> Perhaps every Soyuz upload actually triggers a checkin somewhere :)
[07:30] <LaserJock> well, the are planning on it
[07:30] <LaserJock> *they
[07:30] <imbrandon> no-source-packages spec from way back in dapper
[07:30] <persia> LaserJock: Is it not implemented at all?  I thought there was at least some stubbing done.
[07:30] <imbrandon> or something liek that
[07:30] <LaserJock> well, they've got some code for it
[07:30] <LaserJock> but it's gonna take awhile
[07:31] <LaserJock> last I heard they were gonna just do it over some time
[07:31] <persia> LaserJock: Do you know if there were plans to integrate with dget / dput, or will it all be bzr co, bzr ci?
[07:31] <LaserJock> no, they are gonna to vcs imports of the packages
[07:32] <LaserJock> the first thing is to just get everything into bzr
[07:33] <persia> Too bad.  It'd be nice to have it automatically scrape the last changelog entry for a commit comment when using dput, but I guess that's harder to implement cleanly.  I do hope there will be something for dget.
[07:34] <LaserJock> well, I did get them to make dget'able URLs for source packages
[07:34] <LaserJock> anyway, I don't know much
[07:34] <LaserJock> just I heard they're gonna try to import Debian into LP
[07:35] <persia> I thought that was discussed at last UDS.  It'll be interesting, although I'm really not sure how useful it will be, nor how one might manage the synchronisation.
[07:36] <imbrandon> brb
[07:37] <macd> can someone have a look @ http://pastie.caboo.se/105611  Im getting a cant find sec key error (but its there)
[07:38] <persia> macd: Make sure the name & email address in the changelog exactly matches the name & email address on the key.  In this case, you have "(deb sign only)" getting in the way.
[07:39] <macd> I figured as much
[07:39] <macd> I should just add that to the changelog then correct?
[07:39] <persia> macd: You can override by using debuild -k, and sponsoring yourself, but it'll appear as a sponsored upload to the system, so  both names / emails will appear, depending on where in the interface you check it.
[07:40] <imbrandon>                          macd debuild -S -sa -k940DEA9B
[07:40] <macd> what is considered to be the best practice?
[07:40] <persia> macd: I'd recommend removing the comment from the key, personally.  I think that's easier (although you have to remember which is the debsign key).
[07:40] <persia> imbrandon: Hobbsee: with the new default package interface, it'll grab the email from the signing key for display in the non-changelog.
[07:41] <macd> also by default it looks like dch -e grabs my local username@domain rather than my gpg info, is that expected behavior
[07:42] <persia> macd: `export DEBEMAIL="David Portwood <dzp@bellsouth.net>"
[07:42] <macd> yeah I have that in my .bashrc
[07:42] <macd> maybe I didnt spawn a new session
[07:42] <persia> dch -e should grab that.
[07:42] <macd> hey btw thanks all of you for your help with this!
[07:44] <macd> when Im done, should I just upload everything to the affected LP bug, and find someone to sponsor it?
[07:46] <persia> macd: Follow the SRU process, and request sponsorship with https://wiki.ubuntu.com/SponsorshipProcess
[07:47] <macd> ok, I read the SRU process, youve been very helpful again, thanks.
[07:51] <persia> macd: Don't forget to nominate for feisty (if it's not already done).  This doesn't affect the gutsy bug.
[07:51] <macd> sure thing
[08:06] <macd> persia, used dpkg-source -x foo.dsc, then went into source dir, made dependency changes to debian/control, used dch -e to edit the changelog, did debuild -S -sa, then pbuilder build file.dsc  but in pbuilder/results/file.deb still has a dependency I removed
[08:09] <persia> macd: Interesting.  I suspect you've either a static depends in a binary stanza in your control file, or a build-depends that generates the dependency with ${misc:depends}.  As long as you build in a feisty chroot, you should be safe to install to a feisty target.
[08:12] <macd> I notice after doing debuild -S -sa, the file.orig.gz doesnt have an updated timestamp, I thought debuild from within the source dir rebuilt the orig.gz file? doesnt pbuilder extract and use that to build?
[08:12] <macd> ohh, nvm
[08:12] <macd> answered myself
[08:14] <macd> I do have %{misc-depends} in the control file, what exactly does that entail?
[08:14] <macd> pending the rest of the dependencies are met, is it safe to remove that?
[08:16] <persia> macd: That pulls in all the dependencies that you want based on the build.  You don't want to remove it, or at least you really want to understand why something was brought in that way, and that you really don't need it prior to removal.
[08:17] <macd> gotcha
[08:20] <macd> is ${misc:depends} defined anywhere?
[08:20] <macd> Im just wondering b/c it keeps throwin this non ubuntu package in there *libmocha) and it will never install short of forcing it that way
[08:21] <ajmitch> from what I saw, libmocha is only dragged in from the Depends: line, make sure that your package did rebuild properly
[08:21] <ajmitch> eg that it has a recent timestamp corresponding to when you built it
[08:21] <ajmitch> & that you ran pbuilder with the updated .dsc
[08:21] <persia> macd: Just to confirm: libmocha doesn't appear in the control file (for either source or binary stanzas), nor libmocha-dev, and you are building it in a feisty pbuilder chroot, in which libmocha is not installed, right?
[08:22] <macd> correct@ persia
[08:22] <ajmitch> the original Depends: line is Depends: ${misc:Depends}, ruby, ruby1.8 (>=1.8.2-3), rake (>>0.7.0), rdoc (>>1.8.2), libsqlite3-ruby1.8 | libpgsql-ruby1.8 | libmysql-ruby1.8 | libdbi-ruby1.8, libredcloth-ruby1.8, liberb-ruby, libmocha-ruby1.8
[08:22] <macd> ajmitch, I did remove it from the control file, then ran debuild
[08:22] <ajmitch> being fun ruby stuff
[08:23] <ajmitch> and then you went up to the parent directory & ran pbuilder from there on the new .dsc file?
[08:23] <persia> macd: `debuild` or `debuild -S -sa -k...`?
[08:23] <macd> http://pastie.caboo.se/105623
[08:23] <macd> should help
[08:23] <macd> debuild -S -sa
[08:23] <macd> I ran pbuilder from the directory that contains the dsc file, yes
[08:24] <ajmitch> & the timestamp of the resulting .deb?
[08:24] <persia> macd: You probably want to use `dch -i`, and generate rails_1.2.4-1ubuntu1.dsc, just so you can debdiff the .dsc files and verify your changes, but that doesn't explain the problem.
[08:25] <macd> ajmitch, I ran debuild from within rails-1.2.4/ at 1:00
[08:25] <macd> and I didnt get a deb out of it :/
[08:25] <ajmitch> that's expected if you used -S
[08:25] <imbrandon> gnight all
[08:25] <ajmitch> night imbrandon
[08:25] <macd>  yeah but should it have changed the orig.src.gz package?
[08:25] <ajmitch> nope
[08:25] <macd> see ya imbrandon
[08:26] <macd> ohh, then everything is right timestamp wise
[08:26] <persia> macd: No.  That needs to preserve the md5sum: it should never change as part of the packaging or build process.
[08:26] <macd> I dont know why its pulling in that libmocha then
[08:26] <ajmitch> filterdiff -z -i'*/debian/control' rails_1.2.4-1.diff.gz
[08:26] <persia> macd: is there a debian/control.in ?
[08:26] <ajmitch> paste the Depends: line somewhere
[08:27] <ajmitch> there isn't
[08:27] <ajmitch> I am not
[08:27] <macd> one sec, installing filterdiff ;P
[08:27] <ajmitch> heh, sorry :)
[08:27] <ajmitch> too used to having it
[08:27] <macd> ohh is it not in repos?
[08:27] <macd> or part of something else
[08:27] <ajmitch> patchutils
[08:29] <macd> http://pastie.caboo.se/105625
[08:30] <macd> libmocha is def not in there
[08:30] <macd> is it possible its some whack pbuilder error and I should rebuild it?
[08:31] <ajmitch> yes
[08:31] <ajmitch> and always best to put in a changelog entry
[08:32] <macd> I did
[08:32] <ajmitch> with what version?
[08:32] <macd> dch -e added reference to the bug, and mentioned removing libmocha dep
[08:32] <macd> its in rails-1.2.4/debian/changelog
[08:33] <macd> should I clear the results dir on pbuilder too?
[08:33] <ajmitch> you must never change an existing changelog entry, but add a new version
[08:33] <pwnguin> joeyh's blog is a great historic reference
[08:33] <macd> ajmitch, ohhh
[08:33] <ajmitch> so it would be 1.2.4-1ubuntu1 (for gutsy at least)
[08:33] <pwnguin> like this gem: ""
[08:33] <pwnguin> "<Kamion> pitti used to put patches in debian/patches/ that patched files in the debian/ directory, until we re-educated him with a stick"
[08:34] <macd> ajmitch, so dont edit the existing changelog, make a new one ?
[08:34] <ajmitch> pwnguin: almost as fun as patching debian/rules & reexecing it :)
[08:34] <StevenK> ajmitch: Eeeek
[08:34] <ajmitch> macd: add a new version into debian/changelog, dch -i will do it
[08:34] <macd> gotcha, thanks
[08:35] <ajmitch> StevenK: fun, no?
[08:35] <macd> is there any way to completely rebuilt my pbuilder just to rule out that possibility
[08:35] <Hobbsee> pwnguin: hahaha, nice
[08:35] <ajmitch> macd: you shouldn't need to
[08:37] <macd> ajmitch, for feisty would be 1.2.4-0ubuntu0 ?
[08:39] <ajmitch> preferably something like 1.2.4-1ubuntu0.1
[08:39] <macd> ok
[08:39] <ajmitch> though I can't recall the current agreed upon syntax for SRUs
[08:39] <ajmitch> especially ones that are a new upstream version
[08:40] <macd> ehh doesnt really say
[08:41] <macd> ahh
[08:41] <persia> macd: Take a look in the feisty proposed repository to see recent names.
[08:41] <macd> I wonder what happened
[08:42] <macd> well, I'll still build it and upload my debdiff and nominate it, at least the next time I do a package it wont be nearly this bad
[08:43] <ajmitch> it's always a learning experience :)
[08:44] <macd> http://pastie.caboo.se/105632
[08:44] <macd> is that something I need to worry about?
[08:46] <RAOF> macd: Yes, probably.
[08:46] <RAOF> macd: https://wiki.ubuntu.com/DebianMaintainerField gives some details, and there's an update-maintainer script in ubuntu-dev-tools.
[08:47] <RAOF> Or somewhere.
[08:47] <RAOF> I *presume* you still need to follow that for SRUs, I can't think of a particular reason not.
[08:48] <macd> yeah the SRU wiki page mentions that
[08:48] <StevenK> Were we doing DebianMaintainerField for Feisty?
[08:48] <RAOF> StevenK: My memory is hazy, but I think so.
[08:48] <RAOF> That's a looooong way back.  Nearly 6 months!
[08:48] <persia> StevenK: Near the end, yes.  It was adopted in January, and we figured out how to use it in February.
[08:50] <StevenK> Ah. Then you need to do for Feisty SRUs, but not Edgy or Dapper.
[08:53] <macd> http://pastie.caboo.se/105636  should suffice yes?
[08:55] <dholbach> good morning
[08:56] <jussi01> dholbach: morning Daniel
[08:56] <dholbach> hey jussi01
[09:00] <Hobbsee> hi dholbach!
[09:01] <dholbach> hiya Hobbsee
[09:01] <macd> should the debdiff on what Im working on be from the original feisty rails to the newly built feisty rails,  or from the upstream package to the newly built feisty rails?
[09:02] <persia> macd: If there is a debian package, you want it to be against the debian package.
[09:03] <macd> I have to wonder why not against the current feisty package?
[09:04] <persia> macd: Volume of diff output.  One typically selects the smallest debdiff for submission to a bug.
[09:05] <macd> k
[09:06] <persia> macd: I don't typically due SRUs, but if you need a diffstat, take the diffstat from the debdiff between the existing feisty package and the candidate package, even though that's not the debdiff you're attaching.
[09:09] <macd> persia, Im not sure I follow you there?  I should get the debdiff, then attach it to the bug, nominate it for feisty, the request a sponsorship to upload right?
[09:10] <macd> it says for SRU you should attach a complete source debdiff
[09:11] <macd> I would assume that means b/t the 2 feisty packages
[09:11] <persia> Bleh: this is written to imply MOTUs never file SRU requests
[09:12] <Hobbsee> there would be some truth to that....
[09:12] <Hobbsee> or at least, some of us bad MOTU's :P
[09:13] <persia> Hobbsee: Right.  See, if someone were to rewrite all the documentation to indicate that people of certain ages in certain sourthern districts were responsible for SRUs, you might act differently :)
[09:13] <Hobbsee> haha
[09:13] <Hobbsee> but if it's truthful....
[09:14] <Hobbsee> i wouldnt object to "the australians suck at doing SRU's, therefore dont ask for sponsorship from them, for SRUs"
[09:14] <persia> macd: The general rule of thumb is to use the smallest debdiff that contains sufficient information to properly encapsulate all the changes for the new candidate.  This test isn't very clear.  I'd say you're pretty safe either way: as long as the sponsor can easily regenerate your candidate.  On the other hand, I don't do much with SRUs, so you may see other opinions.
[09:15] <persia> Hobbsee: Well, I'm not sure we can go that far, but I think language that encouraged MOTUs to also make SRU requests would be good (unless we're following a "if you propose, you can't approve" rule.)
[09:16] <Hobbsee> hm
[09:18] <macd> would it be a safe bet to upload a debdiff for source and for the package, along with everything built?
[09:18] <macd> or is that just extreme overkill
[09:18] <persia> macd: Only the source debdiff is interesting.  That's the set of changes that is sponsored.  Any binary packages are just side effects useful for testing.
[09:22] <macd> does pbuilder build a new source package?
[09:22] <Hobbsee> uh?
[09:22] <Hobbsee> pbuilder builds whatever you tell it to
[09:22] <persia> macd: No.  It weakly simulates sbuild on the buildds to prepare binary packages.
[09:22] <persia> Hobbsee: It can build source packages?
[09:22] <Hobbsee> persia: well, it rebuilds sources at the end, yes.
[09:23] <Hobbsee> well, i think it does, anyway
[09:23] <Hobbsee> see the last few lines of build logs
[09:23] <Hobbsee> althoguh you invariably have to build it again anyway, as it builds with -sd
[09:23] <macd> Im confused as to how to make a full source debdiff, do I diff to the current feisty source package against the debian source I built the new feisty package with?
[09:25] <macd> and/or how do I rebuild the source package with pbuilder
[09:25] <persia> macd: There are some instructions on different ways to construct a diff for sponsor review from https://wiki.ubuntu.com/MOTU/Contributing.  Look near the bottom of "Preparing New Revisions"
[09:26] <macd> ok, I see
[09:39] <macd> well, 7 houtrs later thats done
[09:40] <macd> persia, the wiki page for sponsoring an upload seems to revolve around a script that wont run on my machine, how can I manually do this?
[09:45] <persia> macd: manually attach the debdiff to the bug, and manually subscribe the sponsorship team.
[09:47] <macd> ok, done, thanks again for all your help, hopefully next time this will go much smoother
[09:48] <macd> hopefully if all goes well, maybe I'll just start picking all the sru related bugs out and do them ;P
[09:49] <persia> macd: This is a good time for SRUs.  The dev archive is frozen, but there's bunches of bugs in the previous release.
[09:50] <macd> Yeah, now that I know howto do this, and Im sure I
[09:50] <macd> I'll have to do more to finish this out, I can move alot faster
[09:50] <macd> but yeah, a good way to contribute
[09:51] <BugMaN> hi all
[09:52] <BugMaN> dholbach: good morning, now i'm ubuntu member ;)
[09:56] <dholbach> congratulations BugMaN! :-)
[09:57] <BugMaN> dholbach: thanks :)
[09:59] <persia> dholbach: Do you have an opinion on maintaining the migration to dpatch for libvisual-plugins?  The patch looks sane, but it's perhaps annoying to maintain a different patch system.
[10:00] <dholbach> persia: oh, I didn't realize that - what patch system is it using right now?
[10:00] <persia> dholbach: It's just raw diff.gz, and has a big autotools change.  The candidate reverts the debian autotools patch, migrates to dpatch, and applies 5 useful bugfixes.
[10:01] <dholbach> hrm
[10:02] <dholbach> I'd rather he applied the 5 patches and put them into debian/applied-patches for reference or something - there's no need to unpatch the autoconf changes
[10:02] <persia> dholbach: Yep.  The submitter doesn't want to only present the bugfixes, and the maintainer hasn't responded to requests for comment.
[10:02] <RAOF> !packagingguide | contrast83: Read this one? ->
[10:03] <persia> dholbach: The argument is that we don't want to use 1.7 anymore (true), and that it massively reduces the size of the diff.gz.  Note that the autotools update is completely sane, just hasn't attracted Debian interest.
[10:03] <persia> (or rather, restoration of upstream autoconf)
[10:03] <dholbach> persia: ok, that's fine with me
[10:04] <contrast83> RAOF: ? Didn't get anything. I did start to glance over the guide in the repos, but stopped when it prerequisited make know-how.
[10:04] <RAOF> contrast83: Ah, it seems that ubotu has gone walkabout again, sorry.
[10:04] <contrast83> np
[10:04] <persia> dholbach: OK.  I'm generally opposed to imposing patch systems, but if Chris hasn't done something with it by the next time I have some time at an Ubuntu system, I'll chase it.
[10:04] <RAOF> contrast83: I'll hunt you down a bitesize kubuntu bug if you like :)
[10:05] <contrast83> Sounds good
[10:05] <dholbach> persia: thanks for taking care of that
[10:05] <philn> hi!
[10:08] <RAOF> contrast83: So, https://wiki.ubuntu.com/MOTU/TODO#head-bf1f056ba36d8ea73f10c84156fdd84b543d2754 is a list of some bitesize bugs.  Any catch your fancy?
[10:10] <RAOF> persia: Which "Chris" were you talking about there?  I thought I'd touched that bug at one point.
[10:10] <persia> RAOF: Whichever Chris Daniel listed by my name in the request for action.  Could be you :)
[10:10] <contrast83> RAOF: looking....
[10:14] <RAOF> persia: :).  I was hoping to avoid the 3mb debdiff + autofoo, but...
[10:15] <persia> RAOF: Me too :)  It's a 3MB debdiff, but the majority is a reduction of the 3MB diff.gz.  I'd recommend getting rid of 90_autoconf_fixes.patch (or whatever), and applying that raw, just to make it cleaner.
[10:17] <\sh> moins ogra
[10:17] <contrast83> RAOF: The only ones I'm seeing which I'd feel comfortable taking on (those related to .desktop files, mostly), are already spoken for...
[10:18] <RAOF> contrast83: Hm, OK.  Got a pet kubuntu package, or kubuntu peeve (it's KDE, I'm sure there are lots :P)?
[10:19] <contrast83> RAOF: That does bring me to another question though... As a KDE user that uses several GNOME apps, I've made alternate .desktop files for them so they fit better with the general language of KDE's .desktop files. Any idea whether those could be put to broad use somehow?
[10:19] <pwnguin> hmm
[10:19] <contrast83> Oh, and they also solve the problem of said apps showing up in multiple categories under the K Menu.
[10:19] <pwnguin> i should probably pick up that slow suspend bitesize patch
[10:20] <RAOF> persia: You mean apply all the autotools patches + the autoreconf patch just raw to the source?
[10:20] <persia> contrast83: Ideally, we should have a single .desktop file that works for both GNOME & KDE.  It's possible to maintain parallel trees, but it's a big overhead, and harder to push to Debian, and even harder to push upstream.
[10:21] <pwnguin> i always assumed my hardware couldn't suspend
[10:21] <persia> RAOF: If I understand correctly, it's actually a reversion of a patch in the diff.gz, and a restoration to upstream.
[10:21] <\sh> hey jono
[10:22] <RAOF> persia: Plus an autoreconf to pick up the various Makefile.am & configure.ac changes, surely?
[10:22] <pwnguin> apparently dpatch and friends are hated all around in debian
[10:22] <contrast83> RAOF: I've got a lot of little tweaks I do on every installation of Kubuntu. I'll see about readying up a list of ones that might be suited for general use.
[10:22] <persia> RAOF: Maybe.  I think DarkMageZ tested with 1.9, and upstreams worked fine for gutsy.
[10:23] <persia> pwnguin: I wouldn't say that.  I've seen some very agressive quilt promoters.  It's hard to get consensus with 2000 people, of whom only about 150 ever do NMUs.
[10:23] <contrast83> RAOF: One of them is just a .desktop file that's a link to ~/.kde/Autostart, placed in the System submenu. Think that could fit into the kubuntu-default-settings package?
[10:25] <RAOF> contrast83: Quite possibly.  That sounds useful.
[10:25] <contrast83> One of the most common questions I see in #kubuntu is "How do I add autostart applications?" :-P
[10:26] <RAOF> contrast83: You might be wanting to talk to LongPointyStick, or ScottK or another kubuntuite about that, though :)
[10:27] <contrast83> RAOF: Cool, will do
[10:27] <contrast83> RAOF: Big thanks for pointing me in here.
[10:27] <pwnguin> new slaves are always welcome ^_^
[10:27] <contrast83> lol
[10:27] <RAOF> contrast83: Heh.  Everyone's friendly in here :)
[10:28] <jono> hey \sh
[10:28] <RAOF> persia: It's entirely possible that some of 90_autoreconf could be dropped if I tried hard enough :)
[10:28] <pwnguin> god, autoreconf is horrible
[10:28] <pwnguin> you'd think there'd be a dh_autoreconf
[10:29] <pwnguin> ive already got plenty of fun on my plate
[10:29] <RAOF> But what would it actually do?
[10:29] <persia> RAOF: It's possible, but do take a look at the bug log before you do that.  Personally, I think you'd do better not to drop it (or at least I received some vitrol when offering to sponsor a reduced version previously)
[10:29] <pwnguin> just call autoreconf i guess, so you don't have to have a gigantic patch for silly crap
[10:30] <RAOF> pwnguin: Yeah, but then you have random versions of automake doing crazy things problems and such.
[10:30] <persia> pwnguin: That's incredibly dangerous.  Given the level of magic, it makes build completely uncertain.
[10:30] <pwnguin> heh
[10:30] <pwnguin> autoreconf is already magic to me
[10:31] <RAOF> Don't give the buildd's an opportunity to surrepticiously break your package, or they will :)
[10:31] <pwnguin> psh
[10:31] <pwnguin> they dont need excuses
[10:31] <pwnguin> see amd64 and clocks
[10:31] <contrast83> So, last I read, the "official" stance on Automatix is it serves an important purpose, but doesn't do so in a standards-compliant way. I've been working on something that would solve that problem (still very much in its infancy). Once I get it to a point where it's presentable, who should I show it to for critique, and maybe eventually, inclusion in main?
[10:32] <pwnguin> contrast83: release early release often
[10:32] <persia> pwnguin: Right.  The idea is that magic should be confined to packaging-time and runtime.  build-time should be predictable.
[10:33] <contrast83> pwnguin: Ok. So release to...? Just Sourceforge or some site like that, or is there something more *Ubuntu-specific?
[10:33] <pwnguin> contrast83: this sort of thing should likely be done in the open from the beginning, and seek commentary throughout, given the history of novices and this stuff
[10:33] <persia> contrast83: Um.  First, state the issue in a way upon which everyone can agree.  Second, prepare a candidate for universe/multiverse, for input and testing.  If it's deemed critical enough, it may make it to main/restricted, but this shouldn't be a direct goal initially.
[10:33] <RAOF> contrast83: Launchpad does code hosting :)
[10:33] <pwnguin> contrast83: well, im sure launchpad would love it
[10:34] <contrast83> Ok
[10:34] <persia> contrast83: Any code host will do. LP, Google, SF, your private host, etc.
[10:34] <pwnguin> if you're shooting for main / universe you have to release code anyways
[10:34] <pwnguin> but give smart people a chance to review your work before your mistakes compound
[10:34] <RAOF> And do work for you!
[10:34] <persia> Rather, code must be released for inclusion: Soyuz only accepts source uploads.
[10:35] <pwnguin> and multiverse?
[10:35] <asisak> Hey MOTUs
[10:35] <pwnguin> persia: how's multiverse possibly work then?
[10:36] <persia> pwnguin: All the source is available, but it's not all licensed in a way that's free.
[10:36] <contrast83> Is there already work being done on such a project that I'd be better off directing my efforts to?
[10:36] <contrast83> RAOF: Peace, thanks again.
[10:37] <pwnguin> contrast83: have you seen Add/Remove programs in Gnome?
[10:37] <persia> contrast83: Depends on which problem you seek to solve.  Automatix was trying to hit a few.  Some have active efforts underway already.  You'd do best to state the problem you mean to solve clearly, and ask for input on where efforts could be best contributed.
[10:37] <contrast83> persia: So CC licenses and the like?
[10:37] <contrast83> pwnguin: I use it. :-)
[10:37] <persia> contrast83: Perhaps.  Or "This cannot be modified", or "requires payment if used in a business context", or "cannot be used in a military context", etc.
[10:38] <contrast83> Purging Adept is one of thefirst things I do on every Kubuntu installation since mid-Edgy. :-\
[10:38] <contrast83> heh
[10:38] <persia> contrast83: Sometimes there are also binary blobs (PDF, images, firmware, drivers, etc.) for which there's no source, and some source framework around it, or just a system to download closed binaries from an external source (although this is strongly discouraged).
[10:39] <persia> contrast83: It wouldn't be DFSG-free (field of endeavour)
[10:39] <contrast83> Got cha
[10:39] <pwnguin> there's a few that are "no israelis"
[10:39] <contrast83> lol
[10:40] <pwnguin> i cant remember what off the top of my head, but it was after it was announced that isreali forces accidentally attacked a UN watchpost
[10:42] <contrast83> I think I may already know the answer to this - some users' hard drives are too small to permit it - but why doesn't Ubuntu partition / and /home seperately by default? I've noticed several other distros do that and I was awe-struck by the brilliance once I understood the reasons behind it.
[10:43] <awalton__> I've asked that question in my head for ages, I'd love to hear real discussion on that.
[10:45] <contrast83> The aforementioned project I'm working on (Kubuntu-Aide's the working name) insists to the user before doing anything that if they haven't already done so, they repartition their hard drives like that. One of the extra things it does is set up a very primitive backup/restore system, which is dependent on the partitions being set up like that.
[10:47] <persia> contrast83: One hopes you're backing up /usr by storing the output of dpkg --get-selections somewhere, rather than keeping the actual files.
[10:47] <contrast83> persia: of course. :-)
[10:47] <pwnguin> because local couldn't possibly exist
[10:48] <persia> pwnguin: If it does, it deserves a local backup solution, no?
[10:48] <contrast83> actually...
[10:49] <contrast83> the way i've been going about it, is i have /home/mike/.BASHback, which contains all binary installers, output of dpkg --get-selections, the restore script itself, and so on...
[10:49] <contrast83> and then /home/mike/.BASHback/root-directory/, which contains all changes manually made under / which have been confirmed to not break anything
[10:50] <pwnguin> there's a set of programs called simple backup i think
[10:51] <pwnguin> probabl
[10:52] <pwnguin> is there much value on backing up stuff to the same disk it came from?
[10:52] <contrast83> what i'd like to have is something that silently monitors / for changes made by anything other than dpkg (obviously excluding general logs, tmp files, etc.). whenever a change is made, upon the next successful boot/login, it asks the user if they'd like to commit their change to the fake root directory (e.g., /home/mike/.BASHback/root-directory)
[10:53] <contrast83> pwnguin: if it's to a different partition, i think so.
[10:53] <persia> pwnguin: In the case of accidental deletion or file corruption, yes.  In the case of filesystem corruption, maybe.  In the case of hardware issues, no.
[10:53] <contrast83> ^ better answer.
[10:54] <persia> contrast83: Careful about /var : that could quickly become unmanageable if e.g. mysql were installed.
[10:55] <contrast83> persia: excluding */var*, general logs, tmp files, etc... :-)
[10:55] <pwnguin> /mnt and /media probably as well
[10:56] <asisak> ScottK: do you know what happened to the checkgmail update?
[10:56] <contrast83> right, anything in that general realm. i'm just speaking generally, hence the etc. :-P
[10:56] <pwnguin> at this point, you're nearly as well off just listing the things you DO want ;)
[10:57] <contrast83> actually, better idea, i think...
[10:57] <pwnguin> im guessing you dont want to back up /root
[10:58] <persia> pwnguin: Could drop a snapshot into /home/root, if the daemon was suid.
[10:58] <contrast83> i actually am at the moment, just because i had to jump through some hoops to get GTK apps to use the desired style/color scheme when run as root
[10:58] <pwnguin> ruh?
[10:58] <contrast83> but i'm not backing up the entire directories
[10:59] <contrast83> all i'm placing in the fake root directory are files i've changed or put in / manually, obviously in the proper hierarchy
[10:59] <pwnguin> please do name a few gtk apps you run as root
[10:59] <contrast83> synaptic
[11:00] <contrast83> that's mainly it.
[11:00] <pwnguin> gksudo?
[11:00] <pwnguin> gksudo doens't cut it there?
[11:00] <pwnguin> or whatever kde uses
[11:01] <contrast83> nope. had to manually go in and copy some gtk2-rc file or some such from /home/mike
[11:01] <contrast83> but to better clarify on the original point...
[11:02] <contrast83> i have a fresh install. i download an icon theme, for example, that i want to be available to all users and extract it to /usr/share/icons.....
[11:03] <contrast83> then i would run mkdir -p /home/mike/.BASHback/root-directory/usr/share/icons and then cp /usr/share/icons/newicontheme /home/mike/.BASHback/usr/share/icons
[11:03] <pwnguin> it seems like that sort of thing should be a real quick deb
[11:04] <pwnguin> in fact, local debs are gonna be a challenge =/
[11:04] <contrast83> a quick deb for each and every change, or one that covers all of them, which would be updated everytime a new change is made?
[11:05] <pwnguin> i just mean, if i want to install a new theme, there _ought_ to be a way to quickly make a .deb from such a thing. donno if alien actually does it or not
[11:05] <contrast83> pwnguin: that's why i said for example. ;-)
[11:05] <pwnguin> but you could just as easily use a new etc file or something
[11:05] <contrast83> ?
[11:06] <pwnguin> joebob makes a new etf file, maybe a runlevel thing
[11:06] <pwnguin> etc
[11:06] <pwnguin> anyways
[11:06] <contrast83> so you're saying not even worry about backing up these small changes manually made under /?
[11:07] <pwnguin> no, im saying you're right in the general sense
[11:07] <contrast83> ok...?
[11:07] <contrast83> lol
[11:08] <pwnguin> actually
[11:08] <pwnguin> i think there's a dpkg list of all files managed by dpkg
[11:08] <RAOF> You can certainly get it on a per-package basis, yes.
[11:09] <contrast83> some of the files to be backed up may be managed by dpkg though
[11:09] <pwnguin> what?
[11:09] <pwnguin> surely ive seen apt complain that a file was owned by another package
[11:09] <RAOF> pwnguin: Yeah, that's right.
[11:09] <contrast83> i've changed dozens upon dozens of default .desktop files under /usr/share/applications
[11:10] <RAOF> contrast83: You'd only need to backup anything found in the conffiles of packages.  And store diffs if you wanted to backup such manual changes like /u/s/a
[11:12] <contrast83> RAOF: Right. I know there are cleaner and more proper ways to do some of this stuff, like the way you just said, but how comprehensible is something like that to the average end-user. or how practical is it to implement that method in a way that's transparent to the average end-user?
[11:12] <persia> contrast83: I don't think supporting changes to package-installed files in /usr is a common use case.  For all of them, one should be able to achieve the same result with changes in /etc or $HOME (or else the package is non-ideal, and should be patched).
[11:13] <RAOF> contrast83: Pretty practical.
[11:13] <RAOF> contrast83: You may be interested in... um, this project on ubuntuforums, which seems to be a simple-backup app.
[11:13] <pwnguin> !info simplebackup
[11:13] <ubotu> simplebackup: Simple backup tool. In component universe, is optional. Version 0.0.9-1 (feisty), package size 8 kB, installed size 84 kB
[11:14] <pwnguin> that one?
[11:15] <contrast83> And as for things like /etc/X11/xorg.conf and /etc/apt/sources.list?
[11:15] <RAOF> They're conf-files.  dpkg will leave them alone.  If not you get to scream very loudly at the maintainer
[11:15] <persia> contrast83: dpkg keeps track of the md5sums of everything auto-installed in /etc.  If you have cycles to spare (you may not), only backing up the files that differ would save space.
[11:16] <contrast83> RAOF: We're on different pages here, I think...
[11:16] <contrast83> persia: That's *exactly* what I'm suggesting.
[11:16] <persia> RAOF: Not every configuration file is a conffile, and not everything in /etc is a configuration file :)
[11:16] <RAOF> True.
[11:16] <contrast83> RAOF: What I'm suggesting is for when the user needs to format the / partition, or that partition becomes otherwise unusable.
[11:17] <RAOF> Or... shouldn't anything under /etc be considered as a conffile?
[11:17] <contrast83> RAOF: Then they restore the changes they've made to it from the fake root directory (which contains only those changes) that's under /home/user
[11:17] <contrast83> after reinstalling*
[11:18] <RAOF> contrast83: Sounds reasonable.
[11:18] <persia> RAOF: No.  conffiles must be declared by the packages.  The basic difference is that a conffile will likely be edited by a user, and so dpkg should take special efforts to preserve the contents, whereas other configuration files (not conffiles) may be mangled during an upgrade (e.g. the script that gathers everything in foo.d/ to replace the now obsolete foo.conf)
[11:19] <contrast83> I'm thinking the desktop search daemons could be put to use for this, if they could be taught what changes to disregard.
[11:19] <persia> contrast83: That's a lot of overhead.  inotify is probably a lighter interface.
[11:20] <RAOF> persia: Yes, yes.  That's right.
[11:20] <RAOF> contrast83: Also, the desktop search daemons generally only touch $HOME
[11:21] <contrast83> Ok, note taken... What I'm thinking though is, when a change is made in one of the monitored directories, a notification comes up asking the user if they want to commit this change to their fake root directory. They'd have the option to be asked again later if they're not sure of whether they just broke something.
[11:21] <contrast83> Ahh... Point taken. You can tell I've never really used desktop search. :-)
[11:22] <persia> contrast83: Right.  Your daemon is an inotify client, and manages the user interaction through a dbus? call to your session app, which puts a new icon in the notification-area?
[11:22] <contrast83> persia: Sounds right.
[11:23] <persia> The notification-area? icon launches your GUI app, passing the message, and allows user configuration, which gets passed back to your daemon.
[11:23] <contrast83> Remember, I'm still a borderline noob, so this is all purely brainstorming at this point. Not sure how im/practical any of it might be.
[11:24] <contrast83> ok... i just installed simple-backup. gonna tinker with it a bit.
[11:25] <RAOF> contrast83: You may also be interested in revision
[11:25] <RAOF> -control systems, form what it looks like.
[11:26] <contrast83> like SVN, GIT, etc?
[11:29] <RAOF> Yes.
[11:29] <RAOF> Well, more git or bzr, because they don't require a central server.
[11:29] <contrast83> Got cha
[11:29] <RAOF> In fact, you could probably do something tricky with mounting /etc on a gitfs or something.
[11:31] <contrast83> I'm not that bold yet. :-P
[11:35] <contrast83> BRB, gotta get outta this Openbox/xcompmgr session. :-P
[11:39] <persia> RAOF: lsdiff is your friend.  Also, take a look at the resulting diff.gz.  diffstat against the original diff.gz and 90-silly-magic.patch might help too.
[11:39] <geser> dholbach: bug #151078 is not a sync, rails 1.2.4 has a new dependency which isn't in gutsy
[11:39] <ubotu> Launchpad bug 151078 in rails "Please sync rails 1.2.4-1 from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/151078
[11:41] <geser> I will upload rails 1.2.4 without that dependency right now
[11:41] <dholbach> geser: ok, gotcha
[11:41] <dholbach> thanks geser
[11:42] <persia> geser: macd was playing with a similar debdiff earlier, if you haven't already done it.
[11:43] <contrast83> !packaging-guide
[11:43] <ubotu> Sorry, I don't know anything about packaging-guide - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[11:43] <dholbach> !packagingguide ?
[11:43] <contrast83> !packagingguide
[11:43] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports
[11:44] <contrast83> thanks
[11:44] <dholbach> de rien :)
[11:44] <contrast83> Do you know offhand if one of those is the same as the one in the package "packaging-guide"?
[11:44] <dholbach> lucas: is it OK to drop  http://wiki.ubuntu.com/MOTU/MorgueForMOTU  or move somewhere else?
[11:44] <dholbach> contrast83: yes it is
[11:45] <geser> persia: I had a package ready yesterday but went to bed before the UVFe got approved
[11:45] <persia> geser: Perfect then :)
[11:46] <geser> I just uploaded it
[11:46] <contrast83> dholbach: I started to read that one and stopped when it said a good understanding of the makefile is a prerequisite. Was I wrong to do so, and if not, do you know of a good resource for the information on make that I need?
[11:46] <persia> contrast83: http://www.gnu.org/software/make/manual/make.html
[11:46] <contrast83> thanks
[11:47] <contrast83> So read *all* of that, or just skim it as I go through the packaging documentation?
[11:47] <persia> contrast83: Sections 1-3 are the most important, and 4-6 very useful.  7+ get into more advanced topics, which can be helpful, but aren't as essential.
[11:47] <contrast83> Ok, much appreciated.
[11:49] <dholbach> great to have you here contrast83 :)
[11:50] <contrast83> thanks, good to be here
[11:50] <contrast83> dholbach: i think you're one of the ones RAOF suggested I speak with about getting "recruited." not sure what he meant by that.
[11:51] <dholbach> hehe :-)
[11:51] <persia> contrast83: You're in #ubuntu-motu, reading docs, and planning things: you've already been recruited :)
[11:51] <dholbach> if you need any help or have problems with anything, let me know, I'm happy to help out and try to fix things to make it easier to join the team :)
[11:52] <contrast83> cool, thanks a lot. :-)
[11:52] <bluekuja> heya all
[11:52] <bluekuja> dholbach: is possible to be added inside mentors list?
[11:52] <asisak> Hey bluekuja
[11:52] <asisak> And everyone around :)
[11:52] <bluekuja> heya asisak!
[11:52] <bluekuja> :)
[11:53] <dholbach> bluekuja: sure
[11:53] <bluekuja> dholbach: thanks mate :)
[12:00] <jussi01> OK, I officially hate flash... is there not some other way we can distribute it?
[12:01] <awalton__> 'fraid not. :-/
[12:01] <awalton__> adobe_hate++
[12:01] <jussi01> why the **** does it take me ~5-10 HOURS to download it every time...
[12:01] <awalton__> hah, why indeed, do they not have mirrors?
[12:02] <soren> jussi01: Because your internet connection is rusty barb wire?
[12:02] <jussi01> soren: I have 10/10
[12:02] <soren> bps?
[12:02] <awalton__> *rimshot*
[12:02] <jussi01> grrr
[12:03] <soren> Hard to say.. Look at the url in the script and see if it's faster to fetch it in firefox or something.
[12:04] <jussi01> soren: true... I would rather use the package though....although it was a similar story in firefox.. I guess its something to do with the TA connection
[12:04] <soren> jussi01: If you've got a more suitable URL, we can just change it?
[12:05] <soren> jussi01: I wasn't suggesting you should use firefox instead of the script. I just suggested you try it in firefox to see it was the script that was acting strangely or if it's like to be the remote end or the connection between you and them.
[12:05] <jussi01> ahh... its not the scripts fault by the look of it...
[12:06] <soren> Clearly.
[12:10] <lucas>  dholbach feel free to remove it
[12:11] <dholbach> lucas: ok, thank you
[12:27] <Q-FUNK> Howdy! I'm having troubles packaging a Python module that doesn't use distutils. Can anyone help?
[12:31] <POX__> Q-FUNK: write your own setup.py file or install files by hand (dh_install) to /usr/share/python-support/$package or /usr/share/pycentral/$package/site-packages
[12:32] <RAOF> jussi01: You could always try gnash :P
[12:33] <Q-FUNK> POX__: they are already installed by hand to  /usr/share/python-support/$package but then it leaves me with a Lintian warning about having one script installed as non-executable
[12:33] <jussi01> grrr
[12:33] <POX__> Q-FUNK: remove ahshbang or chmod +x it
[12:33] <POX__> hashbang, sorry
[12:34] <Q-FUNK> POX__: files in /usr/share are correctly suposed to not be executable.
[12:36] <RAOF> jussi01: Eh, gnash works for me ;)
[12:37] <POX__> Q-FUNK: just remove hashbang
[12:37] <POX__> you can do it in debian/rules (hint: sed) or simply patch the sources
[12:38] <jussi01> RAOF: for everything?
[12:39] <RAOF> jussi01: Pretty much.  Youtube works, but I really don't use that much flash
[12:40] <jussi01> RAOF: I may give it a try. I use a fair bit of flash though... :(
[12:40] <jussi01> !gnash
[12:40] <ubotu> An open source flash replacement.  It is still beta software. For current status or for more info http://www.gnu.org/software/gnash/
[12:45] <jussi01> hmmm, where did that nice tutorial that used to be in the factoid go?
[12:51] <RAOF> For gnash?
[01:01] <gnomefreak> there wasnt a tut in gnash factoid
[01:02] <gnomefreak> there was one in !restricted but i dont know if its still there
[01:04] <ScottK> asisak: I do not.
[01:04] <ScottK> Morning all.
[01:04] <ScottK> asisak: Any chance you could just pull the .desktop from their source and do the change (we're kind of out of time to wait)?
[01:05] <contrast83> I seem to remember seeing a page listing all the packages on their way into universe, but I'm having some trouble finding it. Any ideas?
[01:19] <albert23> I was asked to do a patch using cdbs. debian/patches didn't exist yet, so clearly this is the first patch. Is it ok to start numbering at 01 or should I leave some number space for possible debian patches?
[01:21] <RAOF> persia: I'd prefer to redo the 90_autotools patch entirely.  It'll be easy to make it ~1K.
[01:21] <persia> albert23: You can use any numbering scheme you like (including the absence of a numbering scheme).  Personally, I like to start with 01, just to indicate that this applies before other patches.
[01:21] <RAOF> persia: Any thoughts here?
[01:22] <persia> RAOF: That seems sensible.  If I understand the original intention properly, the point was to revert the diff.gz patch, and make minimal changes to ensure it compiled with 1.9
[01:22] <albert23> persia: thanks, I will use 01 then
[01:23] <RAOF> persia: Actually, I think the intention was to make the changes to .ac & .am files to actually apply.  I'll see after I do some editing :)
[01:23] <persia> RAOF: heh
[01:23] <contrast83> w00t w00t
[01:24] <contrast83> just made my first makefile. can't believe how much i overestimated the difficulty of that. :-P
[01:24] <Whoopie> bluekuja: hi, what about uswsusp? Now, it's really too late :(
[01:24] <persia> contrast83: The only tricky bit is thinking in terms of rules & dependencies, rather than procedural progress.  Glad to hear you find it easy.
[01:26] <contrast83> well, i did start with a *very* easy target (an icon set). given how much i've dealt with broken dependencies though, that "tricky bit" you mentioned comes natural. :-)
[01:27] <contrast83> in theory, at least. :-\
[01:27] <ScottK> doko: Did you see my overnight ping to please consider adding libsigc++-2.0 to your ia32-libs upload so Skype will work on AMD64.
[01:27] <persia> contrast83: One thing to watch out for is that make assumes every rule will generate a file matching the rule name, so if there is already a file there, it won't run (unless it depends on a rule for which the corresponding file has a newer timestamp).
[01:28] <doko> ScottK: yes
[01:28] <contrast83> got cha. thanks for the tip.
[01:29] <ScottK> doko: Thanks.
[01:29] <bluekuja> Whoopie: heya, did your debdiff get uploaded?
[01:30] <Whoopie> bluekuja: nope
[01:31] <bluekuja> Whoopie: you told me you had to talk with mjg59 about it
[01:32] <bluekuja> Whoopie: what's his response on it?
[01:38] <Whoopie> bluekuja: I asked him twice if he had time to look at it. But he hadn't, so no progress.
[01:38] <bluekuja> Whoopie: you should try to ping him again, and anyway it's not too late yet
[01:40] <Whoopie> bluekuja: could you? ;) I fear, he'll hate me if I ping him too often.
[01:40] <bluekuja> Whoopie: ok, when I catch him online,
[01:40] <bluekuja> gonna ping him on -devel
[01:40] <bluekuja> would be nice to have you there too...
[01:41] <bluekuja> for any explanation debdiff-related
[01:44] <RAOF> Can there be anything more fun than manually editing Makefile.ins?
[01:46] <persia> RAOF: Makefile.am ?
[01:47] <RAOF> persia: Only if you want ~3mb worth of autoretooling
[01:48] <persia> RAOF: Not really: just thinking of things more fun than manually editing Makefile.in  Good luck with the timestamps :)
[01:48] <RAOF> The active ingredient of the Makefile.am patches is a 2 line change to Makefile.in.
[01:48] <persia> RAOF: Ah.
[01:48] <RAOF> Sadly, this comes burdened with autofoo changing every single other line, just because it can.
[01:49] <RAOF> Oh, yes.  The joy of timestamps.
[01:49] <RAOF> I've beaten them back before, I'll do it again!
[01:50] <RAOF> Excessive use of bold may be a side-effect of autofoo.
[01:50] <Whoopie> bluekuja: I'm there. we also should discuss about bug 134238. there're some "angry" people who want s2ram back.
[01:50] <ubotu> Launchpad bug 134238 in uswsusp "Please re-enable build of s2ram binary" [Undecided,Confirmed]  https://launchpad.net/bugs/134238
[01:51] <bluekuja> Whoopie: who disabled it?
[01:51] <Whoopie> bluekuja: mjg59
[01:51] <bluekuja> oh^^
[01:51] <bluekuja> Whoopie: link me to your debdiff
[01:52] <Whoopie> bluekuja: it's in bug 109151
[01:52] <ubotu> Launchpad bug 109151 in uswsusp "no hibernate with uswsusp installed" [Undecided,Confirmed]  https://launchpad.net/bugs/109151
[01:53] <ScottK> bluekuja: Dunno if you are contemplating it or not, but I'd not revert his s2ram change without understanding why he thinks it makes no sense.
[01:54] <bluekuja> ScottK: I wont revert any change he made
[01:54] <bluekuja> ScottK: I even dont use this package
[01:54] <persia> Whoopie: Did you ever have a chance to test?  The bug log doesn't make clear the results of any testing.
[01:54] <ScottK> bluekuja: Good plan.
[01:55] <bluekuja> ScottK: I did a merge of it on June
[01:55] <bluekuja> ScottK: that's all I've done for it
[01:55] <Whoopie> ScottK: you're absolutely right. if I understood correctly, he thinks there's no need for s2ram as it's not intregrated in acpi-support.
[01:55] <ScottK> OK.
[01:55] <Whoopie> I understand his point, but I also understand the complaints.
[01:55] <ScottK> Whoopie: I'd suggest mark the bug invalid and explain why then.
[01:56] <bluekuja> ScottK: you should talk with Whoopie about it ;)
[01:56] <RAOF> Heh.  There's a bug filed that overwriting your harddrive with random data for lvm/crypt is slow.  Cool.
[01:56] <Whoopie> I tried to, but the arguments are that it should be available even if it's not used by default.
[01:57] <ScottK> Whoopie: Then Won't Fix.  Yes, it kind of makes sense, but we aren't going to do it.
[01:57] <ScottK> persia: Ask mjg59 why (but probably not the day before the RC is scheduled).
[01:58] <Whoopie> persia: I tested it half successfully. but it seems to me that it's an issue with my laptop, not the debdiff itself.
[01:58] <persia> ScottK: Something should be done.  From the bug log, it appears s2ram is mentioned in README.Debian (and no, I'm not chasing this before release, just having opinions as a means to procrastinate tracking down hydrogen crashes)
[01:59] <ScottK> Sure.  Makes sense.
[01:59] <persia> Whoopie: OK.  One of the basic requirements to get a debdiff committed is to have a successful test.  With the current state of the bug log, it's very unlikely anyone will upload your candidate.
[02:00] <Whoopie> ScottK: I'm no MOTU, so if you guys decide "Won't fix", then could you close the ticket?
[02:04] <RAOF> Right.  Debdiff is now 44K rather than 3.3 Mb.  That makes it much easier to see what's happening :)
[02:04] <persia> Whoopie: BTW, nice work in making a patch for both 109151 and 114688
[02:04] <Whoopie> persia: good plan, I asked on #ubuntu+1 if someone wants to test, but no answers.
[02:04] <persia> RAOF: debdiff against what?
[02:04] <ScottK> Whoopie: Forgot not everyone could do that.
[02:05] <RAOF> persia: The current package version (ubuntu2)
[02:05] <Whoopie> ScottK: why?
[02:05] <persia> Whoopie: You could try #ubuntu.  I've had success in the past trading advice for testing.
[02:05] <Whoopie> ScottK: because I just provided a debdiff.
[02:05] <ScottK> Won't Fix is restricted.
[02:05] <Whoopie> ?
[02:05] <Whoopie> ah
[02:06] <persia> RAOF: Did you decide not to modify autotools?  What about backing out the Debian autotools patch to make it build with 1.9 instead of 1.7?
[02:06] <ScottK> Whoopie: I was suggesting you do it because you (unlike me) appear to have some understanding of the issue.
[02:07] <Whoopie> ScottK: ok, sorry, misunderstanding.
[02:07] <ScottK> No problem.
[02:07] <RAOF> persia: I decided to do the minimal changes, although this includes some autotools modifications.
[02:08] <persia> RAOF: Ah.  I actually liked the reversion of the autotools hack: I don't think 1.7 is a good target :)  On the other hand, it makes it hard to concentrate on the actual bugfixes ;)
[02:08] <RAOF> persia: However, I didn't touch the existing debian direct-to-the-source patches.
[02:09] <persia> RAOF: Do you still have a 90-autofoo patch then?
[02:09] <RAOF> persia: Yes, it's just much, much smaller.
[02:09] <RAOF> And only touches the files it needs to.
[02:10] <RAOF> Of course, it's still building, so "it needs to" may need to be expanded in the future (but I, obviously, don't think so).
[02:10] <RAOF> You know what would be awesome?  If autotools didn't rebuild every single file it touched from the ground up with every change ;)
[02:10] <persia> RAOF: Personally, I think a package that patches the autotools one way from diff.gz, and then another way from dpatch is just broken (and will be very painful to maintain).  When you've got the rest sorted, would you mind either dismantling the diff.gz patch, or adding your 90-autofoo patch to diff.gz raw?
[02:11] <persia> RAOF: It doesn't.  Only those that would be affected by the change (based on timestamps).  The fact that so much is touched in the diff.gz unpack (for the 1.9 -> 1.7 backport) horribly confuses the tools.
[02:13] <RAOF> persia: No, I mean that when it touches a file it re-writes it totally, even if the active ingredient is a 2 line patch.
[02:13] <persia> RAOF: That's a safety feature.  Imagine downloading binary debdiffs and applying them to a running system instead of the current dpkg behaviour.
[02:14] <asisak> ScottK: okay. I'll do that after lunch
[02:15] <ScottK> asisak: Thanks.
[02:15] <RAOF> persia: Again, I think we're talking past each other - I don't mean it shouldn't rewrite the file from scratch rather than trying to modify the existing file, but it should re-write it in roughly the same way so that the 2 line diff that counts isn't swamped by thousands of lines of cosmetic changes.
[02:16] <persia> RAOF: It's supposed to produce roughly the same output, as long as the input is the same.  I suspect you see the result of improved config.sub and config.guess :)
[02:17] <persia> OK.  This is frustrating.  Jack appears to require realtime scheduling with the default configuration, but the default kernel doesn't provide realtime scheduling.
[02:22] <persia> Any audio people around?
[02:23] <zul_> persia: there is the -rt kernel
[02:24] <persia> zul_: Yes, but that doesn't solve the common case.  It's not hard to run jack -R, but I don't think it should be default.  Anyway, I don't seem to be able to launch jack at all right now, which is even more annoying.
[02:26] <RAOF> Yay!  sbuild appears to have decided to mail me buildlogs again!
[02:28] <sivang> hi all
[02:28] <sivang> is universe frozen as well ?
[02:29] <sivang> ah, the subject says it all :)
[02:37] <persia> Found it.  Apparently it takes special magic to get jack & speech-dispatcher to play nice together.
[02:38] <RAOF> I wonder if anyone has complained that we don't seem to be building the gstreamer libvisual input plugin
[02:40] <RAOF> Ok; it wasn't built before & no-one's complained.  I don't think I'll try to get it built, then.
[02:41] <RAOF> Now, to wrestle with timestamps!
[02:51] <persia> Would someone mind confirming that "riuso il path del nuovo sample (perche' e' gia relativo al path del drumkit" means something akin to "reset the path for the new sample (in a manner relative to the path of the drumkit)"?
[02:52] <ScottK> asac: I see there is a new nspluginwrapper in Debian Unstable.  Would it be worth a merge to get the latest version in before release?
[02:52] <ScottK> Good evening Hobbsee.
[02:53] <pkern> asac: Could you have a look at https://bugs.edge.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/96260/ please?
[02:53] <ubotu> Launchpad bug 96260 in network-manager-openvpn "n-m-openvpn: resolv.conf is erased if endpoint does not push DNS servers" [Low,Triaged] 
[02:53] <Hobbsee> hiya ScottK
[02:53] <RAOF> Evening Hobbsee
[02:53] <pkern> persia: Because it'a already relative
[02:53] <Hobbsee> hi RAOF
[02:54] <RAOF> Got you a new kubuntu recruit :)
[02:54] <Hobbsee> woot!
[02:54] <Hobbsee> fresh blood!
[02:54] <persia> pkern: Thanks.  That makes that stanza much more likely to contain the bug.
[02:55] <RAOF> Bah! It's too late to be hunting down timestamping problems :(
[02:56] <persia> RAOF: Just manually swap the order of things in the diff :)
[02:56] <RAOF> Hm, would that work?
[02:57] <asac> ScottK: i don't think we need an nspluginwrapper update for gutsy. what is new?
[02:57] <persia> RAOF: If I remember correctly, the diff.gz unpack touches just about eveerything.  The patches get applied sequentially, so the things touched last will have the latest timestamps.  That's one of the reasons mixing diff.gz and debian/patches is likely to cause heartbreak.
[02:58] <ScottK> asac: I've been told (but haven't actually checked) that it works better with a new flash beta (I think it was).
[02:58] <RAOF> persia: I've checked the previous build logs, and they managed to have timestamp problems even without the debian/patches stuff ;)
[02:58] <RAOF> But you're right.
[02:59] <ScottK> asac: Dunno if you noticed on devel-discuss, but the Automatix devs have kind of reached out to cooperate.  Currently their Gutsy version will provide it, so I'd rather have there be one less 'reason' for people to install Automatix.
[02:59] <ScottK> That's enough for me right there.
[02:59] <pkern> Yeah let's track Automatix.
[02:59] <RAOF> diff.gz touches everything, then patches touch stuff.
[02:59] <persia> Or rather, one less thing were delegate to automatix
[02:59] <persia> s/were/we/
[03:00] <ScottK> pkern: I'd rather give them fewer rather than more reasons to exist.  That's how I think of it.  It's a merge from Sid, so it's not entirely random crack.
[03:00] <asac> ScottK: hmm. its really late in the cycle and we don't have any testing for it
[03:00] <persia> RAOF: Right.  I suggest stripping all the autofoo stuff from diff.gz, and putting anything you really, really need in debian/patches (as long as you're porting to dpatch).
[03:00] <proppy> hi
[03:00] <RAOF> persia: Fair crack o' the whip :)
[03:01] <ScottK> asac: Would it take more than basic local testing I could do before uploading?
[03:01] <ScottK> asac: If you say no, I won't do it, but as I say, one less reason for them to exist.
[03:02] <persia> RAOF: It should reinflate the debdiff to ~3.5MB, but reduce diff.gz to almost nothing, and make the package sane for the next person.
[03:02] <asac> ScottK: at least I would want to get ppa testing with forum feedback i would say
[03:02] <ScottK> asac: I don't have a PPA to upload it to.  If I give you a merge debdiff, could you handle that?
[03:03] <asac> ScottK: yes give it
[03:03] <ScottK> asac: OK.  I'll work on it and ping you when I have it.
[03:04] <ScottK> My Gutsy laptop just overheated and died thanks to kernel regression, so it wont' be immediate.
[03:04] <asac> thanks
[03:04] <RAOF> persia: So you reackon we should keep the autofoo 1.7 -> 1.9 targeting from the diff.gz+
[03:05] <persia> RAOF: Hrm?  Now I'm confused.  I thought the diff.gz went from 1.9 -> 1.7 (although I haven't actually looked at the patch in a few months).
[03:05] <RAOF> persia: No.  diff.gz went 1.7 -> 1.9.
[03:06] <persia> RAOF: Um..  That's actually useful.  Now I don't know what to say.  The quick & dirty way would be to just apply the 5 little fixes in diff.gz, but the author of the bugfixes seemed pretty set against that, so I'm not sure we have permission.
[03:09] <RAOF> persia: I think that was actually his first go - the initial debdiff just played with files in the diff.gz
[03:09] <persia> RAOF: What was the bugnumber again?
[03:10] <RAOF> bug 123934
[03:10] <ubotu> Launchpad bug 123934 in libvisual-plugins "[debdiff]  bunch of fixes for libvisual-plugins" [Medium,Confirmed]  https://launchpad.net/bugs/123934
[03:11] <norsetto> howdy folks
[03:11] <Hobbsee> hiya norsetto
[03:11] <RAOF> Good evening, norsetto
[03:12] <norsetto> Hi RAOF
[03:12] <persia> RAOF: Hrm.  It looks like you and I failed to communicate whilst getting someone else to do the dirty work 3 months ago.  What seems easiest to you at this point?
[03:12] <asisak> Hey Hobbsee, norsetto et al.
[03:12] <norsetto> asisak: hello young hooligan .....
[03:13] <ScottK> Good afternoon norsetto.
[03:13] <asisak> Hiya ancient friend, norsetto
[03:13] <norsetto> scottK: hello old hooligan :-)
[03:13] <ScottK> Hey. You are the one person here who doesn't get to call me that ;-)
[03:14] <RAOF> persia: Out of the options (1) rolling the autofoo changes in the diff.gz into 90_autofoomax.patch or (2) Applying everything to the diff.gz, I like (1) better, but I'm a sucker for patch systems and tired.
[03:14] <norsetto> scottK: he, the date is approaching though, wehen we will be equal!
[03:14] <asisak> Hmm... only 1G mem is shown :(
[03:14] <persia> RAOF: Go for it.  I like staying close to debian, but this close to RC, it's better just to get the bugs closed, and clean up in a few weeks.
[03:14] <ScottK> norsetto: Only in the years, not in the months...
[03:15] <norsetto> scottk: thats what it counts ....
[03:15] <ScottK> persia: +1 close to Debian is good.  Working is even better.
[03:16] <Hobbsee> RAOF: does that mean that it still applies each release?
[03:16] <Hobbsee> where autohell may change?
[03:16] <persia> Hobbsee: It targets a specific autohell, rather than selecting the most tortuous at build-time.
[03:16] <Hobbsee> ah right
[03:17] <Hobbsee> cprov!
[03:17] <RAOF> Hobbsee: Hopefully the next upstream release won't require us to fix their buildsystem for them, and the whole patch can DIAF
[03:17] <Hobbsee> RAOF: hehe :)
[03:18] <Hobbsee> RAOF: that's the first time i've heard DIAF in a non-customer service context.  sad, isnt it?
[03:18] <ScottK> First time I've heard it period.
[03:19] <cprov> Hobbsee: hi there.
[03:19] <ScottK> Ah.  Acroynmfinder.com to the rescue
[03:19] <Hobbsee> ScottK: DIAF and FOAD are similar, adn both very useful.
[03:21] <persia> In C++, if "setFilename" is used on a class where m_sFilename is defined, and there's no template in the .cpp or .h files, should it work automagically?
[03:21] <ScottK> FOAD I'm definitely familiar with.
[03:21] <Hobbsee> ScottK: hint:  never say them to your customers.
[03:21] <ScottK> I can see DIAF beeing useful too.
[03:27] <ScottK> RAOF: Would you be up for testing a new nspluginwrapper merge?
[03:27] <RAOF> persia is correct
[03:27] <imbrandon> moins all
[03:27] <Hobbsee> ScottK: there's a thing on REVU for that, btw
[03:27] <Hobbsee> i should upload it
[03:27] <RAOF> ScottK: Not this evening, I really want to hit the bed.
[03:27] <RAOF> With sticks.
[03:27] <RAOF> And fire, it'll be awesome.
[03:27] <ScottK> Hobbsee: For what?
[03:27] <persia> RAOF: That C++ isn't magical?  Cool: that makes this an easy bug :)
[03:28] <Hobbsee> ScottK: nspluginwrapper
[03:28] <ScottK> Hobbsee: Not usually for a merge from Debian.
[03:32] <pkern> ScottK: What does testing involve?
[03:33] <pkern> persia: Of course C++ isn't that magical.
[03:33] <ScottK> pkern: It needs AMD64.  Build it test it and see if it works.
[03:33] <pkern> persia: But that should raise a compiler failure.
[03:33] <pkern> ScottK: I'm on amd64.
[03:33] <ScottK> perfect.
[03:33] <pkern> But I guess I would need a link.
[03:34] <ScottK> I'll have a debdiff for you in just a moment.  In the meantime you may as well get Debian's from Sid.
[03:34] <persia> pkern: I've been primarily programming in Ruby the past few months, so missing methods don't scream "BUG!" at me as much as they did in the past, and despite most of my Ubuntu patches being C++, I don't consider myself to know the language.
[03:34] <pkern> persia: Duck typing friend? :-P
[03:35] <RAOF> Duck typing *rocks*, although it does mean that language designers are less likely to have a turing complete type system.
[03:35] <ScottK> geser: Did you get the rails update done (speaking of Ruby)?
[03:35] <pkern> persia: Consider this for this particular problem: setLanguage should work magically? Then set_language would have to work magically too. And that would be nonsense. ;)
[03:35] <pkern> RAOF: Problem is that it's harder to find problems as you need to actually invoke all lines of code.
[03:36] <pkern> Now duck typing is also possible with C++ and you get type safety.
[03:36] <persia> pkern: In Ruby, it works, despite being nonsense (as long as you have a sufficiently overloaded missing_method)
[03:36] <RAOF> pkern: Kinda.
[03:36] <RAOF> pkern: But yes, you do want unittests, and having apport give a nice backtrace on all the bugs is nice.
[03:37] <pkern> persia: I know.
[03:37] <persia> I could ask for more with backtraces.  "0x00002baa04c47b91 in std::string::assign () from /usr/lib/libstdc++.so.6" isn't really a good pointer to a missing method.
[03:38] <pkern> A missing method would imply an ABI break?
[03:38] <persia> pkern: It's an internal API for the app.  Specifically, Hydrogen crashes when loading different drumkits under certain circumstances.
[03:41] <ScottK> pkern: see bug #151288
[03:41] <ubotu> Launchpad bug 151288 in nspluginwrapper "Please merge nspluginwrapper 0.9.91.5 from Debian Unstable (Contrib)" [Undecided,New]  https://launchpad.net/bugs/151288
[03:41] <RAOF> Ok.  I'm too tired to upload, but that seems to have worked.
[03:41] <ScottK> asac: nspluginwrapper debdiff is in the above bug ^^^
[03:41] <RAOF> I'll see if I still think so in the morning :)
[03:42] <RAOF> Good night all!
[03:42] <norsetto> night RAOF
[03:42] <ScottK> Good night RAOF
[03:42] <persia> RAOF: Nice work.  Thanks.
[03:44] <pkern> ScottK: Got it.
[03:44] <ScottK> pkern: Great.
[03:45] <ScottK> Evey time we can say "Neener - Ubuntu does that already" to Automatix, a dead kitten comes back to life.
[03:45] <ScottK> Evey/Every
[03:46] <persia> ScottK: No gloating.  Everyone helps the user experience :)
[03:46] <ScottK> persia: Automatix helps users gain experience with from scratch reinstalls in many cases.
[03:47] <persia> ScottK: Yep.  See.  Experience.
[03:47] <ScottK> persia: I was agreeing with you.
[03:47] <asac> ScottK: did debian apply 002_install_to_NSPLUGINDIR.patch ?
[03:47] <asac> its not in remaining changes
[03:47] <ScottK> Just providing added detail.
[03:47] <Hobbsee> !uvfe
[03:47] <ubotu> Sorry, I don't know anything about uvfe - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[03:47] <Hobbsee> !uvf
[03:47] <ubotu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
[03:47] <Hobbsee> we dont want a new wxpython, do we?
[03:47] <ScottK> asac: They have 002_install_to_NSPLUGINDIR.diff
[03:47] <Hobbsee> or wxwidgets?
[03:48] <ScottK> Just renamed it.
[03:48] <pkern> ScottK: Works for me.
[03:48] <pkern> ScottK: Regenerated the plugin in /var/lib/flashplugin-nonfree by hand, though.
[03:48] <asac> ScottK: ok ... can you test to remove everything, ensure that there is no flashplugin deployed in ffox and then install flashplugin-nonfree and see that it works?
[03:48] <ScottK> asac: ^^^ is the nspluginwrapper debdiff
[03:48] <ScottK> pkern: ^^^
[03:48] <pkern> On it.
[03:49] <persia> New wxwidgets?  2.10?
[03:50] <asac> ScottK: so for pkern it was not automatically regenerated
[03:50] <ScottK> OK.  I'll have another look then.
[03:50] <pkern> Simply installing flashplayer-nonfree worked.
[03:51] <pkern> Let me retry the regeneration.
[03:51] <asac> pkern: did you remove everything before and checked that ffox didn't know anything about flash anymore?
[03:51] <pkern> asac: Yep.
[03:52] <Hobbsee> persia: https://launchpad.net/bugs/151286
[03:52] <ubotu> Launchpad bug 151286 in wxwidgets2.5 "Request: wxPython 2.8.4 for Gutsy Gibon" [Undecided,New] 
[03:52] <ScottK> asac: Debian's patch and yours are identical.
[03:52] <asac> ScottK: yes good
[03:52] <persia> Hobbsee: We already have 2.8.4.  Interesting bug.
[03:53] <Hobbsee> even better.
[03:53] <pkern> The /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so is not regenerated.
[03:54] <pkern> http://rafb.net/p/ZUudO222.html
[03:54] <persia> I don't really understand how Frank got wxpython2.5.3 installed.  I thought we only have wxwindows2.4, wxwidgets2.6 and wxwidgets2.8.
[03:55] <Hobbsee> crack, most likely
[03:55] <bddebian> Heya gang
[03:55] <Hobbsee> persia: done by automatix, perhaps
[03:55] <persia> Hobbsee: Perhaps.  Still, I like closing wx bugs.  If only I had managed to get the last few wxwindows packages ported...
[03:56] <Hobbsee> hehe :D
[03:56] <asisak> Heya bddebian
[03:56] <bddebian> Hi asisak
[04:04] <ScottK> pkern: Any idea why?
[04:05] <jpatrick> Hobbsee: are there any new kubuntu devs I could support?
[04:05] <pkern> ScottK: There is no postinst?
[04:05] <ScottK> Hmm
[04:05] <pkern> I don't *think* it's a *regression*.
[04:05] <Hobbsee> jpatrick: havent been keeping track, but quite likely.  RAOF found one
[04:05] <ScottK> jpatrick: Riddell was looking for help for Bug #146216 the other day.
[04:05] <ubotu> Launchpad bug 146216 in knetworkconf "kde network administration doesn't disable interfaces in /etc/network/interfaces" [High,Confirmed]  https://launchpad.net/bugs/146216
[04:06] <jpatrick> hi Tonio_ !
[04:06] <pkern> ScottK: There aren't any postinst scripts in the current version neither.
[04:07] <jpatrick> ScottK: I was thinking more motu sponsership
[04:07] <ScottK> pkern: Am currently running overloaded.  Any chance you could look into it.
[04:08] <ScottK> jpatrick: The ubuntu-universe-sponsor's queue was pretty empty last Iooked.
[04:08] <Hobbsee> gasp.  that's a first.
[04:08] <bddebian> 9 bugs last night
[04:09] <bddebian> The libvisualstudio plugins or whatever it's called has been there for a while
[04:09] <bddebian> I am scared to touch that one :-)
[04:09] <persia> bddebian: That goes away in the morning: RAOF is sleeping on a solution.
[04:10] <bddebian> Heh, OK
[04:10] <persia> Currently, there appear to be 7 candidates really awaiting upload for gutsy.
[04:11] <jpatrick> can we still upload to universe?
[04:11] <ScottK> Yes
[04:11] <persia> jpatrick: Yes, but be sane about it, and we're under UVF and FF
[04:11] <pkern> Bah, flashplayer-nonfree does not even recommend nspluginwrapper.
[04:12] <jpatrick> oh, great, I have a bugfix package done and was waiting for heron
[04:12] <persia> jpatrick: No point: upload today!
[04:13] <pkern> Hm sorry it does.
[04:13] <pkern> ScottK: Quick fix: Bump flashplugin-nonfree and depend on the new nspluginwrapper?
[04:14] <pkern> That would regenerate the wrapper.
[04:15] <ScottK> pkern: No idea.  asac ^^^
[04:16] <pkern> asac: And could you please take a look at that n-m patch?
[04:17] <asac> ScottK: hard to say ... nspluginwrapper would need some kind of registry to properly recreate wrappers on upgrade
[04:18] <asac> pkern: i can take a look. how critical is the bug anyways?
[04:18] <asac> i mean, why doesn't vpn provide nameservers?
[04:18] <ScottK> asac: So it sounds like this is at least not a regression.
[04:19] <persia> Does anyone have any recommendations as to getting a better stacktrace for bug #149557?
[04:19] <ubotu> Launchpad bug 149557 in hydrogen "hydrogen crashed while playing" [Medium,New]  https://launchpad.net/bugs/149557
[04:20] <asac> ScottK: ok ... i upload to PPA
[04:20] <asac> aeh ... once i return from iso testing to my main desktop
[04:22] <pkern> asac: Well it's a server setting and the openvpn documentation says "pushing DHCP settings is mainly for Windows".
[04:22] <asac> pkern: so what is the way for linux?
[04:22] <pkern> asac: It's weird to erase all nameserver settings if the new connection does not provide one. It's critical for those who don't control the VPN server.
[04:22] <asac> we need DNS as well
[04:23] <pkern> asac: I had to change my VPN endpoint too.
[04:23] <pkern> asac: I don't feel that an empty resolv.conf is helpful at all.
[04:23] <asac> pkern: i don't see how keeping the old resolv.conf is a cleaner way ... most of the times it should be equally wrong
[04:23] <pkern> Thus it should drop changes to resolv.conf if no new nameservers are set.
[04:24] <pkern> asac: Not if you use the possibility of using partial routing.
[04:24] <asac> does that work with network-manager?
[04:24] <pkern> asac: I could set "only route 0.0.0.0/24 through this VPN" in n-m-openvpn.
[04:25] <pkern> Which then erased my nameserver settings because they weren't pushed.
[04:25] <pkern> I don't know why the hell admins refuse to change that.
[04:25] <asac> what happens if you enter a valid subnet there?
[04:25] <pkern> Now we could just say to beg their admins to do it. But leaving them with an empty resolv.conf is IMHO worse than leaving them with nameservers not reachable.
[04:26] <pkern> n-m-vpnc supports that setting too.
[04:26] <pkern> Well I have a valid subnet entered there and it works.
[04:28] <asac> pkern: how does nm vpnc handle nameservers if all works right?
[04:28] <asac> e.g. for the subnet use-case
[04:31] <pkern> 1) My Cisco endpoint (at university) pushes DNS settings and 2) it would not be sensible to connect to the university VPN without setting those servers because of split DNS.
[04:31] <pkern> So even if I set subnets I need those DNS servers.
[04:32] <ScottK> Any idea why *-security uploads got copied to *-updates yesterday?
[04:32] <lamont> ScottK: I bet they were just lucky.
[04:32] <lamont> UIW =m dybbi
[04:32] <persia> ScottK: Did it happen for everything?  I thought it was only special cases.
[04:33] <ScottK> persia: Dunno.  All the packages I've looked at so far.
[04:33] <ScottK> leonel: I thought you were going to file a feisty-backports request for clamav 0.91.2?
[04:33] <persia> ScottK: Given your interest in security patches, that probably means everything.  It's probably a good thing: the security updates will get mirrored for people who've been lazy about installing them.
[04:34] <ScottK> persia: SUre, but semi-random mass copying of releases from one pocket to another is concerning.
[04:34] <albert23> Whoopie: Looks like uswsusp killed my swap device
[04:35] <albert23> Whoopie: I had swap recognized before I installed uswsusp, now it is not recognized anymore
[04:36] <persia> ScottK: It at least would benefit from advertisement.
[04:36] <ScottK> keescook: Was yesterday's copying of lots of stuff from *-security to *-updates intentional?
[04:36] <ScottK> persia: At this point I'm just hoping it was on purpose.
[04:37] <persia> ScottK: hadn't thought of that.  Hmmm...
[04:43] <leonel> ScottK: done    bug  151308    sorry it's been  a LOOOOONG  month
[04:43] <ubotu> Launchpad bug 151308 in feisty-backports "please backport Clamav from Gutsy to Feisty " [Undecided,New]  https://launchpad.net/bugs/151308
[04:44] <ScottK> leonel: No problem.  You tested it, right?
[04:45] <leonel> wow  hold on ..
[04:45] <leonel> wait ...
[04:45] <asac> ScottK: that patch is a bit cumbersome for me to apply ... we have a bzr tree.
[04:45] <ScottK> asac: Please let me know if there's anything else I can do for nspluginwrapper.
[04:45] <ScottK> Heh.  Such timing.
[04:45] <leonel> when I file the   backport   means  the backport  works  fine  because I've tested ?
[04:45] <asac> ;)
[04:45] <asac> yeah
[04:45] <asac> i can premerge the new upstream sources
[04:46] <ScottK> asac: I don't do bzr, so I'm not sure how much help I'll be on that.
[04:46] <leonel> ScottK:  if so  let me do the work  today ..
[04:46] <ScottK> leonel: Thanks.
[04:46] <asac> if you could then provide the diff for the debian dir it would be helpful
[04:46] <ScottK> OK.  I can do that.
[04:47] <ScottK> asac: Debian dir diff from current Gutsy to propsed new version or current Unstable to proposed new version?
[04:47] <ScottK> blueyed: Did you see my comment on your apt-listchanges patch?
[04:48] <blueyed> ScottK: not yet I think. I'll take a look.
[04:48] <ScottK> K
[04:48] <asac> ScottK: debian dir diff against what is now in bzr (well, in a minute) :)
[04:49] <ScottK> asac: I don't have what's in bzr, just in the actual repositories.
[04:50] <asac> bzr branch http://bazaar.launchpad.net/~ubuntu-core-dev/nspluginwrapper/ubuntu
[04:50] <blueyed> ScottK: the point is that dholbach has already uploaded a (not fully working) patch, which deletes the db.
[04:50] <ScottK> blueyed: OK.  Missed that.
[04:51] <blueyed> So if you do not want this, this should get reverted, too. However, I've asked the apt-listchanges maintainer from Debian (Pierre) and he thinks the patch in queue is ok for Ubuntu.
[04:51] <dholbach> blueyed: which package, which patch?
[04:51] <dholbach> ah, apt-listchanges
[04:51] <persia> ScottK: Yes.  Packages should be source, or by VCS.  Mixing is bad.
[04:51] <blueyed> bug 139143
[04:51] <geser> ScottK: yes, rails 1.2.4 is in the archive
[04:51] <ubotu> Launchpad bug 139143 in apt-listchanges "apt-listchanges crashes after python upgrade" [Undecided,Confirmed]  https://launchpad.net/bugs/139143
[04:51] <persia> s/by/be/
[04:51] <ScottK> geser: Cool.  Thanks.
[04:52] <bddebian> Heya geser :-)
[04:52] <ScottK> dholbach: Would you please sort that out.  I've got about 1742 things going on right now.
[04:52] <geser> Hi bddebian
[04:53] <dholbach> ScottK: sure
[04:53] <dholbach> blueyed: got the page bookmarked, but have to tend to a call right now, will get back to you
[04:54] <blueyed> sure, thanks.
[05:00] <ScottK> asac: Diff added to bug #151288
[05:01] <asac> thanks
[05:01] <asac> bug 151288
[05:01] <ubotu> Launchpad bug 151288 in nspluginwrapper "Please merge nspluginwrapper 0.9.91.5 from Debian Unstable (Contrib)" [Undecided,New]  https://launchpad.net/bugs/151288
[05:01] <asisak> ScottK: sorry, I have to run now. If jtbl prepares a debdiff I am glad to review&upload it. If not, I'll do this tomorrow.
[05:02] <ScottK> asisak: OK.  Or I'll find someone else.  Thanks for looking into it.
[05:02] <ScottK> Anyone who knows about .desktop files looking for something useful to do ...
[05:02] <bddebian> ScottK: What's up?
[05:03] <persia> ScottK: What do you need?
[05:03] <ScottK> Automatix has shipped a .desktop for checkgmail since Dapper.
[05:03] <ScottK> We discussed here with one of their devs yesterday adding it to our package just default turned off from the menu (since it's normally auto started).
[05:04] <ScottK> The .desktop can be gotten out of their proposed Gutsy source here http://ubuntuforums.org/attachment.php?attachmentid=45694&d=1191877399
[05:04] <persia> ScottK: Is there a bug?
[05:05] <ScottK> So I'm looking for someone to add it to our package and upload it.
[05:05] <ScottK> persia: Dunno if there is one.
[05:05] <ScottK> persia: Can you hit kitterman.com
[05:05] <persia> In Ellicott City?
[05:06] <ScottK> Yeah.
[05:06] <persia> My arms aren't that long.
[05:06] <bddebian> hah
[05:06] <ScottK> I'll post it and give you a url if you can ge it from there.
[05:06] <ScottK> Just as well.
[05:06] <persia> ScottK; That background is really bad on the eyes.
[05:06] <ScottK> Yes.  I agree.
[05:07] <ScottK> Is on my list.
[05:07] <bddebian> haha
[05:08] <ScottK> persia: http://www.kitterman.com/ubuntu/automatixgutsy.tar.bz2
[05:08] <ScottK> persia: No.  It's really just a placeholder.  If you need to find me for $WORK, the web site won't be how you do it.
[05:09] <ScottK> persia: Just now I think if I could work 3000 hours in the next year I could bill it, so attract new customers is actually pretty low on my list.
[05:10] <persia> ScottK: Ah.  I avoid a web presence specifically for that reason.  Anyway, that .desktop file isn't even close to valid.  I also can't find any license for the associated artwork.
[05:10] <persia> ScottK: You need employees :)
[05:10] <ScottK> persia: No.  The LAST thing I need is employees.
[05:11] <bddebian> :)
[05:11] <ScottK> Gah.  Licensing is not their strong suite.
[05:12] <persia> ScottK: If you can get someone to get legal-to-ship attachments in a bug, I'd be happy to upload (takes about 15 minutes to process).
[05:12] <ScottK> persia: OK.  I just ponged the guy on the forums.  Hopefully he'll show up.
[05:19] <asac> ScottK: without recreating nswrappers firefox hangs
[05:19] <asac> bad thing
[05:20] <asac> after recreating it works
[05:20] <asac> pkern: ^^^
[05:20] <ScottK> asac: OK.  What does one do about that then?
[05:20] <ScottK> Is that an upstream issue?
[05:21] <keescook> ScottK: yeah, pocket copying was intentional to help bandwidth load for OOo updates
[05:22] <ScottK> keescook: OK.  As long as it was on purpose.  Thanks.  They way LP has been lately, I had my doubts.
[05:22] <keescook> hehe
[05:22] <ScottK> They/The
[05:22] <keescook> it shouldn't have been "everything", just OOo
[05:22] <ScottK> Well it was definitely more.
[05:22] <asac> well ... might be fixable upstream ... otherwise we need to recreate the wrappers, but that would need infrastructure work
[05:23] <ScottK> keescook: As an example... https://launchpad.net/ubuntu/+source/ia32-libs/+publishinghistory
[05:23] <asac> let me try again
[05:23] <leonel> scottK   downloaded clamav sources from gutsy to feisty   theres a dependency  for libcurl4  ...  should I change the  debian/control file  with   dpatch-edit-patch ??
[05:23] <ScottK> Urgh.
[05:24] <ScottK> leonel: No, patches are only needed for outside the debian dir.
[05:24] <ScottK> leonel: In the debian dir you can just edit it directly.
[05:24] <keescook> ScottK: hunh.
[05:24] <keescook> I'll ask.
[05:24] <ScottK> keescook: Clamav too.
[05:24] <ScottK> keescook: Dunno if it's all, but it's all I've looked at.
[05:25] <leonel> scottK ok   then  a dpkg-source then   dpkg-buildpackage    test   and  send the diff ??
[05:26] <ScottK> leonel: Yes.
[05:26] <keescook> ScottK: ah, nm, everything was copied.  :)
[05:26] <leonel> scottK  ok working ...
[05:26] <ScottK> keescook: On purpose?
[05:30] <pkern> asac: As said bumping flashplugin should solve this?
[05:42] <asac> yes
[05:43] <ScottK> Hobbsee: Speaking of customer service (we were earlier - i.e. DIAF) here's another take.. http://www.ubersoft.net/comic/hd/2007/10/i-had-similar-conversation-last-night
[05:43] <ScottK> asac: You OK if we upload it then as long as we do that too?
[05:44] <Hobbsee> ScottK: hahaha nice
[05:44] <ScottK> Hobbsee: He's reliably pretty funny, especially if you do tech support at all.
[05:44] <keescook> ScottK: seems so, I wasn't expecting it, though.  :)
[05:45] <ScottK> keescook: OK.  Thanks.
[05:45] <Hobbsee> ScottK: my previous boss warned me very verbosely about the fact that the computer might blow up if i touched it the wrong way.  especially if i was to pull the back off.
[05:46] <ScottK> Hobbsee: Cool.  I want one of those.
[05:46] <Hobbsee> (you think i'm going to be foolish enough to pull a computer apart while it's turned on?)
[05:46] <Hobbsee> and plugging in a speaker cable != pulling hte back off - on any scale!
[05:46] <ScottK> Umm.  Well I've done that.
[05:47] <Hobbsee> as in, and then touch bits of it that obviously shouldnt be touched
[05:47] <ScottK> Only got electrocuted once (and that one wasn't turned on).
[05:47] <broonie> Helps if you know how the case is designed.
[05:48] <ScottK> In my case it would have helped if the tech that built the prototype (me) had properly shrink wrapped the internal connections from the power line to the power supply.
[05:49] <Hobbsee> yet, i love how we get safety sheets to sign, for the entire staff, effectively saying "be careful when there are trucks in hte back dock, they may run over you if you get in their way"
[05:50] <persia> Exciting.  On the other hand, the covers for those tend to be well separated, with no flybacks randomly glued to the case.
[05:50] <Hobbsee> so maybe i should be unsurprised about the computer stuff.
[05:50] <persia> Hobbsee: The idea is to make sure you don't sue them because you were stupid.
[05:50] <broonie> The planes Easyjet use for the Edinburgh->Luton run have safety instructions that include gems like "don't jump into fire".
[05:50] <Hobbsee> persia: they cant have enough warnings for that.
[05:50] <Hobbsee> broonie: *snort*
[05:51] <Hobbsee> good thing i wasnt drinking!
[05:51] <persia> Hobbsee: They can try (that's what legal departments are for).
[05:51] <Hobbsee> this is australia, not america.
[05:51] <asac> ScottK: personally i wouldn't do it. i have not seen any real benefit to justify two new uploads during RC freeze. There isn't any critical bug open for both et al. ... but then my bar might be too high for |universe|.
[05:51] <ScottK> asac: Thanks.
[05:52] <asac> ScottK: if you really want to go ahead, let me know so i can upload them to ppa
[05:53] <pkern> So they point would be to get better compatibility to a package not in Gutsy? (i.e. flashplugin beta)
[05:53] <ScottK> Right.
[05:53] <persia> Hobbsee: I've actually had more delays related to legal arrangements in Australia than in America, but perhaps it's just me.
[05:53] <asac> pkern: where is that bug?
[05:54] <Hobbsee> persia: ah.  all i meant by that comment was that, as australians, we dont tend to sue anyone and everyone for any reason.
[05:54] <Hobbsee> whereas it seems that americans do that far mroe
[05:54] <ScottK> asac: I'd appreciate it if you go ahead and upload to PPA.  If you're running 32bit FF plugins on 64bit archs, I expect your the sort that wants the latest crack.
[05:54] <persia> Hobbsee: Right, but the legal departments wouldn't make as much money if they didn't protect their clients from people who didn't act like proper Australians :)
[05:55] <pkern> ScottK: Do the automatix guys now offer REPOS instead of hacking the disk?
[05:56] <ScottK> They say yes.
[05:56] <Hobbsee> persia: haha :)
[05:57] <dholbach> blueyed: added a note to the page
[05:57] <asac> ScottK: ok i can uploaded nspluginwrapper to my ppa ... bzr is updated for that release as well
[05:57] <asac> ScottK: should be build in an hour or so ... if you call for testing, please tell them to --reinstall flashplugin-nonfree after the install
[05:58] <ScottK> OK.  And then if testing is good maybe we go for it.
[05:58] <asac> ScottK: revision uploade is nspluginwrapper_0.9.91.5-1ubuntu1~ppa1_source.changes:
[05:58] <ScottK> asac: Where should I call for testing?
[05:58] <asac> yes ... but still some hard facts about the bugs resolved in the revision would be nice to have in the bug
[05:58] <asac> ScottK: i think in forums
[05:58] <asac> devlink
[05:59] <asac> ScottK: maybe as heno if he has some preferred way to coordinate application testing
[05:59] <asac> s/as/ask/
[05:59] <bddebian> Damnit, bug on colorgcc filed already :-(
[06:00] <ScottK> asac: Added the upstream NEWS items for the release.
[06:00] <persia> bddebian: Why is that bad?  Isn't that an indication of active and helpful users, who live only to give you feedback?
[06:02] <bddebian> persia: Well it's bad because I'm clueless and to be honest I'm not sure how it was working the way he has it configured in the previous version :-(
[06:02] <persia> bddebian: Ah.  One of those.  Good luck.
[06:04] <asac> ScottK: ok commented in bug
[06:06] <persia> ScottK: I'm suspecting a flood of issues similar to bug #151329, with the fluxbox UVFe so close to release.  Do you think we should try to chase them, or process as backports?
[06:06] <ubotu> Launchpad bug 151329 in fbdesk "Package is outdated" [Undecided,New]  https://launchpad.net/bugs/151329
[06:06] <bluekuja> norsetto: heya, asked today to get added as mentor to daniel
[06:07] <bluekuja> norsetto: if you have any student ready, just mail me
[07:33] <leonel> scottK the debdiff is  with  the  clamav_0.91.2-3ubuntu1.dsc  gutsy   and  clamav_0.91.2-3ubuntu2~feisty1.dsc now with the changes  or is with the    feisty original ?
[07:41] <imbrandon> macd: thanks
[07:47] <leonel> scottK done ..
[08:22] <bddebian> A freshly filed wammu dependency problem?  I thought that just got resovled?
[08:35] <macd> keescook, ping
[08:35] <keescook> macd: hello
[08:36] <geser> asac: do you need more information for bug #41134?
[08:36] <macd> I did a sru for a bug yesterday and was told to inform you bug 151078
[08:36] <ubotu> Launchpad bug 41134 in network-manager "Does not store WPA-Enterprise password in keyring" [Medium,Incomplete]  https://launchpad.net/bugs/41134
[08:36] <ubotu> Launchpad bug 151078 in rails "Please sync rails 1.2.4-1 from Debian unstable (main)" [Undecided,Fix released]  https://launchpad.net/bugs/151078
[08:36] <macd> Im just looking for some clarification if it was done properly
[08:37] <keescook> macd: okay, thanks, let me go read it quickly
[08:40] <keescook> macd: yeah, if we can get the upstream fixes extracted and put into a debdiff, I'd be happy to get them published.
[08:41] <macd> okay, do you have a minute to give me some insight on that
[08:42] <macd> am I just diffing the current feisty source package v. the upstream debian source?
[08:43] <keescook> macd: unfortunately not; it's a bit more involved.
[08:44] <keescook> macd: since they are stable releases, we want to only change the vulnerable code
[08:44] <keescook> macd: so the debdiff should only include patches for the specific changesets mentioned that fix the CVEs.
[08:44] <macd> ok, is there a reference on the wiki for this?
[08:44] <keescook> yeah, see: https://wiki.ubuntu.com/SecurityUpdateProcedures
[08:45] <keescook> in step 2, it links to the patching tutorial too.
[08:45] <imbrandon> keescook: macd is very new to MOTU and just getting started, this is his first "fix"
[08:45] <imbrandon> just FYI
[08:45] <keescook> imbrandon: cool; I'm glad to have the help.  :)
[08:45] <macd> great, I didnt know that was the process I just built a feisty package based on the debian upstream sources and figured that was it
[08:46] <keescook> macd: that would work for -backports, but I'm less familiar with that area.
[08:46] <macd> so diff the CVE related changes,  create a patch and add that to the LP bug
[08:47] <keescook> macd: right.  I haven't looked at the rails package, but it may use a patch system (dpatch, cdbs, etc)
[08:47] <keescook> that's where the patching tutorial in step 2 might be helpful
[08:47] <macd> dpatch, yeah.  again thanks
[08:47] <keescook> sure thing, let me know if you have any other questions.
[08:49] <jtbl> i have found a dependency issue in the new nspluginwrapper package
[08:49] <jtbl> https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/151288
[08:49] <ubotu> Launchpad bug 151288 in nspluginwrapper "Please merge nspluginwrapper 0.9.91.5 from Debian Unstable (Contrib)" [Undecided,Confirmed] 
[08:56] <ajmitch> hello
[08:58] <zul> hey ajmitch
[08:58] <imbrandon> heya ajmitch
[08:59] <norsetto> morning ajmitch
[09:04] <bddebian> Heya ajmitch
[09:05] <pkern> ScottK: Will do
[09:05] <pkern> Testers will need to --reinstall flashplugin-nonfree after the install too. <-- That sounds wrong.
[09:06] <pkern> ScottK: That's probably the same I tested earlier? Or has s.th. been fixed?
[09:09] <geser> Hi ajmitch
[09:27] <ScottK> pkern: Not sure it's exactly the same.
[09:28] <pkern> So if the flashplugin-nonfree needs to be reinstalled I'm not ok with that.
[09:29] <ScottK> leonel: from the Gutsy one
[09:31] <ScottK> pkern: I think that's just because we haven't bumped it yet.
[09:33] <ScottK> asac: Looks like the nspluginwrapper update needs one dependency change https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/151288/comments/7
[09:33] <ubotu> Launchpad bug 151288 in nspluginwrapper "Please merge nspluginwrapper 0.9.91.5 from Debian Unstable (Contrib)" [Undecided,Confirmed] 
[09:37] <norsetto> scottK: works for me (AMD64/Konqueror). I have util-linux installed of course
[09:38] <norsetto> scottK: and it didn't remove anything
[09:39] <ScottK> norsetto: Thanks.
[09:40] <ScottK> slangasek: If you have a moment, would you please accept doko's ia32-libs package.  It needs to go in before my pending WINE upload.
[09:41] <ScottK> StevenK: I'm curious your opinion on Bug 151289
[09:43] <slangasek> ScottK: sorry, not accepting any universe stuff right now to keep the buildds clear for any last-minute main builds we need to finalize images for RC
[09:52] <ScottK> slangasek: OK.  Is there a timeline for when it'll open up again?
[10:01] <slangasek> ScottK: once the upcoming CD rebuild is finished, I expect
[10:02] <ScottK> OK.  Thanks.
[10:10] <ScottK> pkern: You said bumping flashplugin would make the nspluginwrapper problem go away, right?
[10:12] <pkern> Well bumping the nspluginwrapper dep in flashplugin.
[10:13] <pkern> It somehow regenerates the wrapper then.
[10:13] <ScottK> Ah.
[10:13] <pkern> It's a weird fix I agree.
[10:14] <ScottK> pkern: Would you be up for taking the source in asac's PPA and updating it for that the the util-linux thing?
[10:14] <ScottK> pkern: If you do that and test it, I think it's tested enough for upload.
[10:16] <ScottK> bigon: I asked for the debdiff just for a double check because we are so close to release.
[10:16] <pkern> There is no linux32 in my util-linux? o_O
[10:16] <bigon> ScottK: ok :)
[10:17] <ScottK> Weird.
[10:17] <ScottK> pkern: It's listed as an ADM64 binary on LP?
[10:17] <pkern> Oh wait.
[10:17] <pkern> Yeah sorry, I screwed up and checked on the wrong host due to the prompts looking similar.
[10:17] <pkern> )':
[10:18] <pkern> ~15 shells open.
[10:19] <ScottK> jtbl: Any word on the licensing for the artwork?
[10:19] <pkern> util-linux is essential so linux32 could be removed safely.
[10:22] <ScottK> Cool.
[10:24] <ScottK> asac: With the linux32 depends and flashplugin depends adjusted we're going to do ahead with nspluginwrapper, UNODIR.
[10:26] <pkern> Firefox doesn't crash here, the flash just doesn't load and messages are printed to stderr with the wrong version installed.
[10:27] <pkern> ScottK: So flashplugin-nonfree would need to be adjusted. The window would be small, but should we consider a conflicts against the current flashplugin version?
[10:27] <ScottK> pkern: Or just upload a rebuild revision after this goes in...
[10:28] <pkern> ScottK: I don't get that one. A binnmu would not be sufficient as the depends field should be adjusted.
[10:29] <ScottK> pkern: OK.  I wasn't thinking binnmu (we don't do those) but a updated source package with a higher number to depend on.  Would it actually have to conflict?
[10:29] <soren> bigon: Why does the upstream changelog not even come close to suggest to fix the issues you outline in the bug description?
[10:29] <soren> bigon: bug 151289
[10:29] <ubotu> Launchpad bug 151289 in esvn "Please merge eSVN 0.6.12 from debian lenny/sid to Gutsy - fixes svn incompatibility." [Undecided,New]  https://launchpad.net/bugs/151289
[10:30] <bigon> soren: I think it's the [*]  Implement parser for .svn/enties with format > 6 (Damien Caliste). entry
[10:31] <soren> bigon: Ah, yes, could be.
[10:32] <pkern> ScottK: There are those XbuildY versions.
[10:34] <pkern> ScottK: Well if you upgrade flashplugin first and then upgrade nspluginwrapper it's broken.
[10:34] <pkern> ScottK: Uh ignore me.
[10:34] <ScottK> OK
[10:35] <pkern> Ah point was that if nspluginwrapper is upgraded flash will be broken until flash gets reinstalled.
[10:35] <pkern> Circular deps are bad.
[10:36] <bddebian> !#$^#$^
[10:36] <norsetto> bddebian: couldn't agree with you more
[10:39] <pkern> bddebian: What's up?
[10:39] <bddebian> Just whining
[10:40] <pkern> bddebian: Haha. /me evil.
[10:48] <bddebian> pkern: Why?
[10:48] <pkern> bddebian: Just because I can. Just like you can just be whining. :-P
[10:49] <bddebian> Fair enough :-)
[10:50] <pkern> ScottK: So I fill upload nspluginwrapper now?
[10:52] <ScottK> pkern: No universe uploads are being accepted until after the CD images are done, but I just realized I forgot to get the UVFe for that.
[10:52] <pkern> ScottK: But I could get them into unaccepted?
[10:53] <pkern> flashplugin-nonfree is prepared, too
[10:53] <ScottK> soren: Would you please ack bug 151288.  It's yummy.  pkern promises.
[10:53] <ubotu> Launchpad bug 151288 in nspluginwrapper "Please merge nspluginwrapper 0.9.91.5 from Debian Unstable (Contrib)" [Undecided,Confirmed]  https://launchpad.net/bugs/151288
[10:53] <ScottK> pkern: Yes.  Once soren gives us permission.
[10:53] <pkern> Aye.
[10:54] <ScottK> I'll be back in ~45 minutes.
[10:54] <bddebian> Hmm, cdbs and a -data package.  That'll be a new one for me
[10:54] <pkern> cdbs o_O
[10:54] <pkern> It shouldn't exist! :-P
[10:54] <bddebian> It was already kinda packaged :-(
[10:55] <DktrKranz> pkern, mind to sponsor a debian package?
[10:55] <pkern> DktrKranz: Maybe :-P
[10:55] <DktrKranz> no cdbs :D
[10:56] <pkern> Hah :D
[10:56] <DktrKranz> it solves an outstanding bug...and my previous sponsor did not ping back
[10:57] <pkern> You just probably link me to a dsc *hint hint*
[10:57] <DktrKranz> pkern, http://mentors.debian.net/debian/pool/main/b/boa-constructor/boa-constructor_0.6.1-2.dsc
[10:58] <pkern> ScottK: I won't commit to nspluginwrapper's bzr too. core-dev ;)
[10:58] <pkern> What a pun.
[10:58] <_16aR_> Hello
[10:58] <_16aR_> In about how much time a package is reviewed under revu.tauware.de ?
[10:59] <pkern> _16aR_: After Gutsy?
[10:59] <pkern> Or rather: When Hardy reopened.
[10:59] <pkern> s/reopened/opens/ \:
[10:59] <_16aR_> Ok
[10:59] <_16aR_> So everyone is in rush for Gutsy release right now, that's it ?
[11:00] <pkern> I would disagree about the rush bit :-P
[11:00] <norsetto> _16aR_: after Gutsy is over the answer anyhow is "depends"
[11:00] <pkern> People contribute to Debian instead. :-P
[11:00] <DktrKranz> o/
[11:00] <_16aR_> lol
[11:00] <norsetto> _16aR_: what package is that?
[11:00] <_16aR_> that a lib package
[11:00] <_16aR_> i've put about 3 lib packages ^^
[11:01] <pkern> -XS-Vcs-Bzr: https://code.launchpad.net/~dktrkranz/boa-constructor/debian
[11:01] <pkern> DktrKranz: Fun :-P
[11:01] <DktrKranz> yep :)
[11:01] <norsetto> _16aR_: the best, once Gutsy is over and you think you have a good work ready, is to come here and askk for a review
[11:01] <_16aR_> hawknl, gnelib and replicantbody
[11:01] <pkern> DktrKranz: Out of curiosity: Is that Python-Version: all stuff really necessary?
[11:01] <_16aR_> ok
[11:01] <norsetto> _16aR_: links will be very helpful
[11:01] <_16aR_> I haven't internet since 2 month ^^
[11:01] <DktrKranz> pkern, moving to python-central seems to require it
[11:01] <pkern> DktrKranz: Because it somehow sounds silly.
[11:01] <pkern> Hm k
[11:02] <_16aR_> i've uploaded from a VirtualBox at my work ^^
[11:02] <_16aR_> http://revu.tauware.de/details.py?upid=319 : hawknl
[11:02] <DktrKranz> pkern, if you omit it, pycentral will blow you during install
[11:03] <pkern> Sounds funny (:
[11:03] <_16aR_> http://revu.tauware.de/details.py?upid=320 : gnelib
[11:03] <_16aR_> (replicant body)
[11:03] <_16aR_> gnelib has been a mistake since it depends from hawknl ... ^^
[11:03] <DktrKranz> sounds scary...I had to face it :)
[11:04] <norsetto> _16aR_: a quick one, use hardy as distribution, and ubuntu version numbers
[11:04] <_16aR_> 1.6.8-1ubuntu1 for example ?
[11:07] <norsetto> _16aR_: actually, since this is not in debian (right?), it should be 1.6.8-0ubuntu1
[11:07] <_16aR_> ok
[11:07] <_16aR_> I thought ubuntu version number was only to use on an already debianized package
[11:08] <norsetto> _16aR_: try also to keep the changelog to the bare minimum to start with; like "first issue only", and only change the time tag at the end
[11:08] <siretart> _16aR_: well, that way we can sync an potential 1.6.8-1 upload to unstable.
[11:10] <norsetto> _16aR_: can you add a watch file?
[11:11] <_16aR_> norsetto: sure ... But I may check what's that ^^
 _16aR_: try also to keep the changelog to the bare minimum to start with; like "first issue only", and only change the time tag at the end : didn't understand you on that one :/ sorry
[11:12] <norsetto> _16aR_: sorry, I've got a very lousy connection tonight. Here is a link: https://wiki.ubuntu.com/MOTU/Recipes/DebianWatch
[11:13] <norsetto> _16aR_: what I mean is, that we don't need to have recorded in the changelog the changes you made in the packaging before it is released
[11:13] <norsetto> _16aR_: of course it is appreciated if you add it in the comment box in REVU
[11:15] <pkern> DktrKranz: Sorry for the delay, got distracted by someone else. ;)
[11:15] <pkern> DktrKranz: Looks good, will rebuild and upload/.
[11:15] <DktrKranz> pkern, no hurry...
[11:15] <DktrKranz> thanks :)
[11:17] <_16aR_> norsetto: ok, understood ^^ But since I was testing PPA too, i had to increase package revision to have the possibility to upload it again
[11:17] <norsetto> _16aR_: I don't think we need this one in DOCS: readme.macintosh
[11:17] <_16aR_> (to PPA)
[11:17] <_16aR_> norsetto: ups ^^
[11:17] <norsetto> _16aR_: for ppa you can add a ~ppaXXX at the end
[11:17] <norsetto> _16aR_: just remove it when the package is ready for upload
[11:18] <pkern> DktrKranz: Done, thank you for your contribution to Debian.
[11:18] <DktrKranz> pkern, thanks for time and sponsorship
[11:18] <norsetto> _16aR_: didn't check the tarball, is there no README, changelog, or anything else from upstream?
[11:19] <_16aR_> norsetto: it is VERY light
[11:19] <_16aR_> and the makefile was quite ugly
[11:19] <contrast83> RAOF: Hey, you around?
[11:19] <norsetto> _16aR_: I hope there is a COPYING or equivalent?
[11:20] <_16aR_> norsetto: not sure ^^
[11:21] <norsetto> _16aR_: better make sure then or it won't be uploadable
[11:21] <_16aR_> norsetto: yes
[11:22] <norsetto> _16aR_: just checking some sources, I see some more copyrighters that you need to add to copyright
[11:22] <_16aR_> Ok
[11:22] <norsetto> _16aR_: for instance Copyright (C) 2000-2002 Phil Frisbie, Jr. (phil@hawksoft.com)
[11:23] <norsetto> _16aR_: and there is no mention of a license, so, no COPYING and no license headers......
[11:24] <_16aR_> norsetto: damn. I wasn't sure about copyrighting at the time packaging it. I didn't check every source file, in fact
[11:24] <_16aR_> ok, then I must contact upstream to change that
[11:24] <_16aR_> I will update the package with the tips you indicate me
[11:25] <_16aR_> while waiting for license modification
[11:25] <norsetto> _16aR_: some sources are LGPL, so you need to mention that in copyright too
[11:25] <_16aR_> norsetto: the watch file permit the auto download of new tarballs ?
[11:26] <norsetto> _16aR_: yes
[11:26] <_16aR_> norsetto: and how it is managed if the patchs doesn't apply again ?
[11:26] <norsetto> _16aR_: you get an error :-)
[11:27] <_16aR_> norsetto: and the package doesn't compile, or it compile with the original source ?
[11:27] <norsetto> _16aR_: what are those patches btw?
[11:27] <_16aR_> norsetto: makefile patch to add $(DESTDIR)
[11:28] <_16aR_> and modif in some makefile because of character misplacement
[11:28] <_16aR_> (used multiple space instead of tab if I remember right)
[11:28] <ajmitch> hello jono
[11:29] <jono> hey
[11:29] <norsetto> _16aR_: the best of course is to ask upstream to correct those
[11:30] <imbrandon> heya jono
[11:30] <_16aR_> norsetto: sure. But this project wasn't the real one to interest me, it was only a dependency from another one
[11:31] <_16aR_> norsetto: so at the moment, I've only contacts with the other project upstream
[11:31] <norsetto> _16aR_: yeah, but for us they are all alike
[11:32] <_16aR_> norsetto: you're right ^^ I was just explaining why I didn't contact this upstream at all
[11:32] <_16aR_> (at the moment)
[11:32] <norsetto> _16aR_: what do you mean that gnelib was a mistake?
[11:33] <_16aR_> norsetto: it depends on HawkNL ^^
[11:33] <_16aR_> I've missed that when I uploaded it ^^
[11:33] <norsetto> _16aR_: ok
[11:33] <_16aR_> So it cannot be uploadable until hawknl is ok
[11:34] <_16aR_> norsetto: replicantbody should be ok though
[11:35] <jono> hey im
[11:35] <jono> imbrandon:
[11:35] <norsetto> This is not correct in install: debian/tmp/usr/local/lib/lib*.so.* usr/lib/
[11:36] <pkern> bddebian: So if Ari assumes that you are `just talking', just I put weight into that? I mean Ari is known to talk... strange things. :-P
[11:36] <ScottK> pkern: Since it's in Universe now I'm going to suggest (after we get done with this release) that nsplugingwrapper get pulled from their SVN.
[11:37] <pkern> ScottK: s/SVN/Bzr/?
[11:38] <pkern> Or I didn't get it ;)
[11:38] <ScottK> Yesh.  svn/bzr.
[11:39] <ScottK> That or I'll decline to listen to whining about not using the repo.
[11:39] <_16aR_> norsetto: in gnelib ?
[11:40] <ScottK> StevenK, zul, or soren: I'd really like to let pkern push Bug #151288 uphill.  One of you please ack....
[11:41] <ScottK> The bot doesn't like me today.
[11:41] <norsetto> _16aR_: no, I'm still looking through hawknl. Do you need that because you could not specify the right prefix?
[11:41] <ajmitch> pkern: ari? strange?
[11:42] <ScottK> soren: As an added bonus: Debian released a fix for openssl0.9.7 arbitrary code execution issue today.  Since the only thing we have that needs openssl0.9.7 is vmware-player and it's broken, I'm thinking remove the lot from the archive before release.  Opinions?
[11:42] <pkern> ajmitch: Well Clint in conjunction with Ari.
[11:43] <pkern> ScottK: Let's remove vmware-* 1.x :-P
[11:43] <siretart> ScottK: which multiverse package is in a core-dev VCS?
[11:44] <ScottK> nspluginwrapper.
[11:45] <ScottK> pkern: vmware-server is in the Canonical commercial repo, so I can't touch that one.
[11:45] <pkern> ScottK: Don't be bothered with that.
[11:45] <pkern> ScottK: But the multiverse ones.
[11:45] <ScottK> Right.
[11:46] <ajmitch> pkern: a truly disturbing combination
[11:46] <_16aR_> norsetto: no, it must be a bug. I should only have 1 .so and links to that, but not multiple copy of libs
[11:46] <pkern> Well Clint may be changing. His blog entries look... sensible currently.
[11:47] <pkern> I fear that. :-P
[11:47] <ScottK> pkern: You want to do the vmware-player/openssl0.9.7 removal bugs? https://wiki.ubuntu.com/UbuntuDevelopment#Removals
[11:48] <norsetto> _16aR_: apparently hawknl doesn't depend on anything, is it ok?
[11:48] <_16aR_> yes
[11:48] <_16aR_> only libc :')
[11:48] <ScottK> Gotta run and play Daddy for several hours, so see you all later.  pkern fire away on nspluginwrapper and company if you get another motu-uvf ack.
[11:49] <_16aR_> it was the most little lib of the dependencies of delta3d, but since it was the first for me... It was hard ^^
[11:49] <pkern> ScottK: Aye.
[11:50] <norsetto> _16aR_: you should delete README.Debian
[11:53] <norsetto> _16aR_: contentwise looks ok
[11:54] <_16aR_> norsetto: oh, it was still here ?
[11:54] <_16aR_> norsetto: I'll move it then
[11:55] <_16aR_> norsetto: I think this page isn't enough for copyright : http://www.hawksoft.com/free.shtml
[11:58] <norsetto> _16aR_: no, but this is more relevant: http://www.hawksoft.com/hawknl/
[11:59] <_16aR_> yes, but COPYING and all header to source code should still be included into archive, no ?
[12:00] <norsetto> _16aR_: I'm not a lawyer, but I don' t think a web page replaces the fact that there must be a verbatim copy of the LGPL with the source code
[12:01] <geser> without a copy of the license text in the orig.tar.gz it won't get accepted by the archive admins
[12:02] <pkern> ScottK: rdeps on libssl0.9.7: aolserver4-{nsopenssl,nsimap}
[12:03] <_16aR_> yep
[12:03] <norsetto> _16aR_: can you add the homepage to the long description?
[12:04] <norsetto> _16aR_: I'm getting a strange error when I compile twice, I would have to look into that
[12:05] <_16aR_> norsetto: never tried it twice without pbuilder
[12:06] <norsetto> _16aR_: instead of "Developpement library" you could say "This package contains the development libaries and headers"
[12:06] <norsetto> _16aR_: well, I do it with a pbuilder hook
[12:06] <norsetto> _16aR_:  s/libaries/libraries
[12:08] <norsetto> _16aR_: he, you really got some stuff into gnelib
[12:09] <mneptok> try "development liberries" to make users *extra* confident
[12:10] <mneptok> mmm .... berries
[12:10] <ScottK> pkern: Odd.  I missed that one when I looked.  Maybe it should die too?
[12:10] <norsetto> _16aR_: do you really need to rerun the autoconf stuff?
 _16aR_: he, you really got some stuff into gnelib : that means it is bad ? :'(
[12:13] <_16aR_> norsetto: don't remember, but I do it once, no ?
[12:13] <norsetto> _16aR_: for the one that has to review it, yes :-)
[12:15] <pkern> ScottK: Removal requests done. #151424 and #151423
[12:15] <_16aR_> norsetto: sorry, these are my first package
[12:15] <_16aR_> norsetto: I hoped they'd be nearly cool, but it seems they're not :/
[12:15] <norsetto> _16aR_: why not? seems you've been doing a nice job
[12:17] <pkern> ScottK: aolserver4-nsopenssl is currently bug free.
[12:17] <pkern> And it's installable.
[12:18] <pkern> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408221
[12:18] <ubotu> Debian bug 408221 in aolserver4-nsopenssl "aolserver4-nsopenssl: recompile against latest libssl0.9.8" [Normal,Open] 
[12:18] <pkern> No response from the Debian maintainer since >250d
[12:19] <pkern> openssl097 was already removed from unstable
[12:19] <pkern> Which means that this package is probably uninstallable in unstable.
[12:20] <RAOF> contrast83: Not really :)
[12:20] <_16aR_> norsetto: thanks, but there is still work to do
[12:20] <contrast83> RAOF: Yo yo...
[12:20] <_16aR_> norsetto: I'm just finishing my own repo with reprepro/autobuilding and then I'll correct hawknl
[12:21] <norsetto> _16aR_: sure, there always is, but its pretty minor stuff (only stopper is the license so far)
[12:21] <contrast83> RAOF: Remember when we were talking about how to better implement GNOME apps into the K Menu earlier?
[12:21] <RAOF> Yeah, kinda?
[12:21] <pkern> ScottK: It was binnmued to 0.9.8, so that sounds like an action to take for Ubuntu, too.
[12:21] <_16aR_> norsetto: I had a SDK which is proprietary and I'm sure it cannot be uploaded :( So I must have my own repo to share it
[12:21] <pkern> Reprepro with autobuilding? o_O
[12:21] <pkern> Now if you have a solution for that, let me know.
[12:22] <_16aR_> pkern: bash scripts ^^
[12:22] <_16aR_> pkern: but it sucks ass
[12:22] <pkern> I set up wanna-build yesterday night, but the buildd solution is still missing.
[12:22] <contrast83> RAOF: I was blabbing about the altered .desktop files I use for Firefox, GIMP, Synaptic, etc. so their name - description syntax matches that of the KDE apps. I think I figured out a practical way to implement this
[12:22] <RAOF> contrast83: Cool!
[12:22] <norsetto> _16aR_: what was licensed under?
[12:23] <RAOF> pkern: Poke seveas - falcon is growing buildd claws.
[12:23] <RAOF> :)
[12:23] <_16aR_> pkern: hmmm, not so bad after all, it has compiled a package i've just dput ^^
[12:23] <_16aR_> pkern: but the script only works for 1 account
[12:24] <contrast83> RAOF: the user can install a package containing a script that checks for commonly installed GNOME apps, and when they run that script, it'll replace the relevant lines in whatever GNOME .desktop files it finds via SED
[12:24] <pkern> RAOF: (:
[12:24] <pkern> RAOF: I grabbed the Debian wanna-build, so there was this ancient version of sbuild. I would rather use cowbuilder but well.
[12:25] <pkern> mrvn will get me his ocaml version of buildd but *shrug* ocaml...
[12:25] <norsetto> _16aR_: you should change this: Maintainer: Dolanor Tharivae <dolanor@evereska.org>
[12:25] <_16aR_> pkern: it needs lots of tweaking. There one script called with dput (it do the reprepro command) and there a "daemon" which looks the buildTmp dir to pbuilder the content
[12:25] <_16aR_> norsetto: in gnelib ?
[12:26] <norsetto> _16aR_: well, its your gnelib link, but it is really replicantbody
[12:26] <pkern> _16aR_: I need two arch autobuilding (the one which is missing).
[12:26] <_16aR_> norsetto: I think I've done it on PPA, but not on revu since it was too hasty to put it (since the dependency with hawknl couldn't be verified
[12:27] <_16aR_> norsetto: ah yes. I thought i'd updated replicantbody on that though
[12:27] <norsetto> _16aR_: I noticed that you have no versioning in your deps. You sure its ok like this?
[12:28] <_16aR_> pkern: I don't know if my script can help... There are really bad call to pbuilder and reprepro, some mv/rm, and that's all
[12:29] <_16aR_> norsetto: I've tried to add versionning like in the libpkg-guide, but the script for versionning wasn't found. I didn't look for it afterwards
[12:29] <_16aR_> norsetto: So I let without versionning
[12:29] <norsetto> _16aR_: you don't need this: +debian/tmp/usr/lib/librvrutils.so.0.0.0  usr/lib/ in librvrutils0.install
[12:29] <_16aR_> norsetto: oh ? Why ?
[12:30] <norsetto> _16aR_:  because you are just coipying the same file in the same location
[12:31] <_16aR_> norsetto: hu ? Everything in debian/tmp/ will be copied as is ?
[12:31] <norsetto> _16aR_:  in .install the first element is relative to the current directory, ythe second to the build directory
[12:31] <_16aR_> norsetto: I mean, the deb archive will be done from debian/tmp ?
[12:31] <norsetto> _16aR_: yes
[12:32] <_16aR_> norsetto: some would say : OMGWTFBBQ !
[12:32] <_16aR_> norsetto: this IS an enlightenment !
[12:32] <_16aR_> lol
[12:33] <_16aR_> So my every package stinks foot ...
[12:33] <_16aR_> I copy every time from debian/tmp/usr/lib/ to usr/lib
[12:33] <_16aR_> nearly every time
[12:34] <norsetto> _16aR_: well, they had some convoluted logic in them .....
[12:34] <_16aR_> I like harrassing CPU for nothing !
[12:34] <_16aR_> I thought the .install things copy from build dir to a chroot env. But it seems the build dir IS the chroot env ^^
[12:35] <norsetto> _16aR_: yes again :-)
[12:37] <_16aR_> norsetto: I must be retard... Hmmm there's quite few packages to modify then ... :p