[02:34] <Seeker`> If I want to get started with packaging stuff, is it ok to do it on a VirtualBox guest system running 8.10?
[02:37] <persia> Seeker`: Well, excepting that 8.10 doesn't exist yet, yes.
[02:40] <Seeker`> persia: ok, ubuntu in virtualbox using the intrepid repos
[02:41] <persia> Seeker`: That would be a reasonable way to test things.  Note that you may find it frustrating when handling your keys, but this oughtn't matter while you get started.
[02:42] <persia> Eventually, I expect you'll find working with local chroots easier, although it took me months of experimentation after I was packaging regularly to determine the setup that worked for me.
[02:43] <nxvl> Seeker`: or a chroot environment (i.e pbuilder)
[02:44] <Seeker`> I was going to have a go at this: https://bugs.launchpad.net/ubuntu/+bug/115288
[02:45] <nxvl> Seeker`: you can also work on hardy, but at the end test it using a chroot environment
[02:50] <emgent> morning
[02:59] <persia> Seeker`: For new packaging, you really want to be in the development environment, to get the right toolchain, etc.  In general, I recommend bugfixing prior to packaging, as it's a lot easier to learn packaging bit-by-bit while fixing bugs, rather than all at once.
[03:10] <Seeker`> persia: anything in particular where you recommend starting?
[03:11] <persia> Seeker`: Depends on what you like.  Searching for the bitesize or packaging tags on LP might be a good place.
[03:11] <persia> If you are familiar with debugging, looking at the apport crashes to dig out small fixes from stacktraces could work.
[03:11] <persia> If you're good with build systems, looking at the FTBFS list on qa.ubuntuwire.com might be a good place.
[03:12] <persia> There's heaps of packages with lintian errors of varying importance.  Some (like missing intepreter, missing manpage, etc.) are fairly easy, and interesting to fix.
[03:13] <Seeker`> hmm
[03:18]  * Seeker` may wait for the next "packaging 101"
[03:19] <persia> Seeker`: What interests you.  I'll help you find your first bug.
[03:19] <persia> Also, feel free to ask questions here anytime.  People may be slow to answer, but they ought eventually.
[03:20] <Seeker`> I've not really done any packaging stuff before, so I'm not really sure
[03:22] <persia> Seeker`: OK.  Have you done coding or debugging before?
[03:24] <Seeker`> I've just finished a CS degree, so I have done quite a bit of coding before, but only really on assignments (not any publicly released software or anything)
[03:26] <nxvl> persia: btw, did you think i'm ready or near to be ready for applying for MOTU?
[03:27] <persia> nxvl: I'd have to review and check.  Best to wait until several people sponsoring your changes tell you to apply: this gets better testimonials and helps you identify sponsors for your MOTU application (as opposed to sponsors for your fixes).
[03:28] <nxvl> persia: yep, that's what i'm waiting for, just asking :D
[03:28] <persia> nxvl: I recommend just keeping on with what you're doing, and the day will come.  At that point, it won't really matter to you very much.
[03:29] <nxvl> yep
[03:29] <nxvl> that's what i also think
[03:31] <Seeker`> persia: did you see my reply?
[03:31] <persia> Seeker`: Yep.  Just hunting a bug for you.
[03:33] <persia> Seeker`: Why don't you take a look at https://bugs.launchpad.net/ubuntu/+source/kerberos-configs/+bug/179142
[03:33] <persia> Solving this requires a bit of research into the right format for the configuration file, some thoughts about how it might work, a small text change, and some testing.  It ought be a good way to get familiar with the process, and start working with a package.
[03:34] <persia> Don't forget to assign yourself and set "In Progress" if you're going to work on it.
[03:38] <Seeker`> persia: ok
[03:48] <Seeker`> persia: from the looks of it, that field is required in the configuration file, and the example here: https://help.ubuntu.com/community/Samba/Kerberos uses "Example.com"
[03:49] <persia> Seeker`: Yep.  It's pretty clearly a bug.  It just needs someone to figure out how to get the right solution, and set it up.
[03:51] <Seeker`> persia: looking here: https://launchpad.net/ubuntu/+source/kerberos-configs it looks like it has already been fixed possibly
[03:54] <persia> Seeker`: I'd recommend verifying that.  If it is indeed fixed, then just mark it Fix Released with a comment reporting your research and the results.
[03:54] <persia> Seeker`: I chose if from the list at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize : You can try finding another one there that nobody ha started yet.
[04:09] <Seeker`> persia: as its 4am, I reckon i'll have a look for something else tomorrow. Thanks for the hlep.
[04:10] <persia> Seeker`: Thanks for closing a bug :)
[04:10] <Seeker`> :)
[04:21] <Seeker`> hmm, think I found another non-bug
[04:22] <persia> Seeker`: The more of those that can be closed, the better.  We've lots of bugs, and not enough people closing them.  Thanks a lot for helping.
[04:24] <Seeker`> persia: can you have a quick look at https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/230865
[04:25] <Seeker`> In the code for the program, it says:   parser.add_option ("--dist-upgrade","--dist-ugprade", action="store_true", which makes me think that the 2nd option was deliberately added
[04:28] <persia> Seeker`: Quite possibly there used to be a -u or something, which is now gone.  I'm not sure.
[04:32] <Seeker`> persia: if that were the case, the "-u" would just be removed, not replaced with "--dist-ugprade". I think that it may be deliberate to catch a typo
[04:35] <persia> Seeker`: Ah.  Right.  --distugprade.  I suspect you are correct.
[04:35] <Seeker`> shall I close the bug? or just comment that I  dont think it is a bug?
[04:37] <persia> Seeker`: Hard to say.  Depends on how strongly you feel about it.
[04:37] <persia> If you think catching the typo is good, set "Won't Fix", and explain why.  If you think the extra option should be removed, submit a patch.
[04:38] <persia> Note that in the case of update-manager, where there is source locally managed in Ubuntu in BZR, patches as branches are appreciated over patches as debdiffs (although this is a rare exception for packages in general: there are maybe 30 packages of this style)
[04:38] <Seeker`> ok
[04:38] <Seeker`> i've just left a comment for now - see if it gets any response
[04:43] <persia> Seeker`: Remember to subscribe to the bug if you want to see the responses.
[05:50] <Flannel> Gaaaah.  What would be wrong with apt-cache policy shows something, but you can't apt-get it due to no install candidate?
[05:56] <Hobbsee_> Flannel: something that you installed whe nit did exist, but doesn't still exist.
[05:57] <Flannel> Hobbsee_: No, theres no current install.  Here, I'll show.
[05:57] <Flannel> http://dpaste.com/54272/
[05:58] <persia> Flannel: Candidate: (none) tells you there's nothing available to install (although it may be referenced).
[05:58] <Hobbsee_> even though it's on the version table.  strange.
[05:59] <Flannel> Yeah, and thats a fresh update
[06:00]  * Hobbsee_ does an upgrade
[06:01] <persia> Flannel: Try a purge for it, as 5.0.24a-9 likely oughtn't be there.
[06:01] <Flannel> persia: Its an upgrade, and... let me bring in the person who's actually having the issues.
[06:02] <persia> Looks to me like it got pinned too high, and then removed, and now it can't upgrade, and can't install.
[06:05] <Flannel> jb0t, meet persia, he's got an idea.
[06:05] <jb0t> hi.. i'm all ears :)
[06:05] <persia> jb0t: Did you even pin or hold mysql-common?
[06:06] <jb0t> persia: no
[06:07] <persia> jb0t: Hm.  My idea is incorrect then.  Do you have a .deb in /var/cache/apt/archives ?
[06:07] <jb0t> ha. so frazzled, i started typing commands in this window.  one sec
[06:08] <jb0t> persia: http://dpaste.com/54276/
[06:10] <persia> jb0t: Delete /var/cache/apt/archives/mysql-common_5.0.24a-9_all.deb and try again.
[06:11] <jb0t> same error
[06:12] <persia> jb0t: Got me then.
[06:12] <wgrant> Has purging been tried?
[06:13] <jb0t> no.  but its not installed.
[06:13] <jb0t> afaict
[06:13] <wgrant> Does it have a config left over, though?
[06:13] <wgrant> dpkg -l mysql-common
[06:14] <jb0t> http://dpaste.com/54277/
[06:14] <jb0t> seems to
[06:14] <wgrant> Aha.
[06:14] <wgrant> So it knows of an old version.
[06:14] <wgrant> sudo apt-get remove --purge mysql-common, and hope it forgets about it.
[06:15] <jb0t> http://dpaste.com/54277/
[06:16] <wgrant> sudo apt-get purge mysql-common
[06:17] <jb0t> same error
[06:17] <wgrant> Bah.
[06:17] <jb0t> ahh
[06:17] <jb0t> !!
[06:17] <jb0t> install -f actually removed it this time
[06:19]  * wgrant hates intermittent ACPI faults.
[06:20] <jb0t> ugh.  still no luck.  won't install.  can't remove or purge, and still shows the conf on dpkg -l mysql-common
[06:20] <jb0t> wth is going on here
[06:22] <jb0t> oh. was removing my failed attempt on the .deb install i guess
[06:37] <dholbach> good morning
[06:38] <ajmitch> hi dholbach
[06:38] <dholbach> hi ajmitch
[06:46] <Hobbsee_> oh noes, it's ajmitch
[06:47] <ajmitch> where?!?
[06:48] <StevenK> ajmitch: In a mirror!
[06:48] <ajmitch> now that's a scary though
[06:49]  * Hobbsee_ points.  there!
[06:56] <jb0t> wgrant: i backed up /var/lib/dpkg/status and proceeded to remove mysql-common.  it (seems to) no longer thing its installed, but same errors on install attempts both with apt-get install and dpkg .deb
[06:56] <jb0t> *think
[07:34] <Hewus> Hi, quick question. Does anyone know why myspell-en-au is in universe, while the other three myspell-en-* are in main?
[07:42] <bimberi> Struth mate, is it?  Stone the crows!
[07:45] <Hewus> Stone the crows? Haven't heard that one..
[07:45] <wgrant> Neither have I, fortunately.
[07:45] <bimberi> Ah, you younguns :)
[09:25] <norsetto> howdy dowdy
[09:26] <RAOF> Man, that's what I call a backtrace.  #94 0x0000000000430030 in main ()
[09:26] <pwnguin> hah
[09:26] <RAOF> Nearly breaks the magical 100 functions on the stack.
[09:27] <norsetto> huats !!!
[09:27] <huats> norsetto !!!
[09:27] <huats> already awake ?
[09:27] <huats> ;)
[09:27] <norsetto> norsetto !!!!
[09:27] <RAOF> (When you die with 100 functions on the stack you get a plaque)
[09:28] <norsetto> huats: heck, its holiday here today :-)
[09:28] <huats> ;)
[09:28] <huats> hum
[09:28] <persia> RAOF: Which bug?
[09:28] <huats> I understand now :)
[09:28] <RAOF> persia: epiphany-webkit is not particularly stable on gmail.com :)
[09:29] <persia> RAOF: Ah.  No, I suppose not :)
[09:29] <RAOF> Let us combine unfinished code with serious browser-side javascript.  What could _possibly_ go wrong? ):
[09:29] <RAOF> :)
[09:30] <RAOF> OOoh, it's deterministic!  Awesem.
[09:30] <persia> At least the combination explains the depth of the stacktrace.  Running Javascript within the Javascript container within Webkit within GNOME...
[09:31] <RAOF> About >50 of those functions were within libwebkit, too.
[09:37] <persia> norsetto: Quick explanation: components are supposed to be self-including, so universe can depend/build-depend on main, and multiverse can depend/build-depend on universe.  For an example of a split package, see lshw with part in main and part in universe (and source in main).
[09:37] <persia> (also, mythbuntu is a multiverse derivative, rather than a universe derivative)
[09:38] <norsetto> persia: so, the answer is no, a multiverse source cannot have a binary in universe
[09:39] <persia> norsetto: Right.  Well, it could technically, but it would violate the current semantics.
[09:39] <norsetto> persia: yes, I understand its not a technical problem
[09:43] <huats> persia: hello
[09:47] <slytherin> Can someone please give back libvte-java?
[09:48] <dholbach> slytherin: best to ask in #ubuntu-devel - more archive/buildd admins are hanging out there
[09:48] <persia> dholbach: We can all do it now :p
[09:48] <persia> slytherin: Do you have a build failure URL?
[09:48] <norsetto> dholbach: also motu can now :-)
[09:48] <dholbach> oh... OH!
[09:48] <RAOF> Awesome.
[09:48] <dholbach> :)
[09:49] <RAOF> (for those playing along at home, the dbg symbols for webkit are 50mb)
[09:50] <slytherin> persia: http://launchpadlibrarian.net/14854649/buildlog_ubuntu-intrepid-powerpc.libvte-java_0.12.3-5_FAILEDTOBUILD.txt.gz It is failing on powerpc, sparc, ia64 while it has built on i386 and amd64. Looks like wrong timing.
[09:52] <persia> slytherin: Giving it back where it failed.  For future reference, the URL that is useful when requesting a give-back is https://launchpad.net/ubuntu/intrepid/+source/libvte-java/0.12.3-5 (or https://launchpad.net/ubuntu/+source/libvte-java/0.12.3-5/+build/620720 if you only need one)
[09:52] <slytherin> persia: Ok.
[10:11] <sistpoty|work> hi folks
[10:12] <sebner> hoi sistpoty|work
[10:12] <sistpoty|work> hi sebner
[10:13] <sebner> sistpoty|work: when is the next MOTU meeting so I can mail the fridge folks ^^
[10:13] <sistpoty|work> sebner: should be regular schedule, I guess?
[10:14] <sistpoty|work> sebner: so 13th, 20 UTC
[10:14] <sebner> sistpoty|work: thanks =)
[10:14] <sistpoty|work> np
[10:24] <norsetto> all heil sistpoty|work
[10:24] <sistpoty|work> hi norsetto
[10:25] <sebner> sistpoty|work: hmm, heil? xD
[10:25] <sebner> morning norsetto
[10:25] <norsetto> sebner: your excellency
[10:25] <sistpoty|work> oh, heh... well yes. I guess I shouldn't react to "heil" *g*
[10:25] <sebner> haha
[10:26] <sebner> cody-somerville: thanks =)
[10:29] <sebner> norsetto: first thing is to add a new stanza in debian/control? http://paste.ubuntu.com/16371/
[10:30] <norsetto> sebner: ok, make this "
[10:30] <norsetto> This package offers
[10:30] <norsetto>  SSL-Support for eggdrop.
[10:30] <norsetto> oh s*e
[10:30] <sebner> ^^
[10:30] <sebner> ha!
[10:30] <sebner> I'm not *that* dumb =)
[10:30] <norsetto> sebner: make the final line of description a different line
[10:31] <norsetto> sebner: and chage the short description
[10:32] <sebner> norsetto: how different should the final line be?
[10:32] <norsetto> sebner: no, its me the dumb who doesn't paste text correctly
[10:32] <norsetto> sebner: a separate line
[10:34] <sebner> norsetto: http://paste.ubuntu.com/16372/ ?
[10:34] <norsetto> sebner: note that the two packages should conflict with each other, it shall not be possible to install both at the same time
[10:34] <sebner> norsetto: a versioned conflict or just on the package?
[10:34] <norsetto> sebner: nope, it really has to be a self-standing line
[10:35] <sebner> norsetto: ah k. I'll show when I added the conflicts field
[10:36] <RAOF> Am I right in remembering that there was a bug in a pkgconfig file which made most of gnome uselessly depend on libffi4, with the added bonus of making a whole lot of stuff uninstallable?
[10:36] <sebner> norsetto: also a "Replaces" ?
[10:37] <norsetto> sebner: why a replaces? I suggest you look at how other packages handle binaries with files in same locations ...
[10:37] <norsetto> sebner: and think as well what will happen when you upgrade from previous versions ...
[10:38] <sebner> norsetto: ok ok
[10:47] <rzr> asac: hi
[10:47] <rzr> asac: do you know http://en.wikipedia.org/wiki/NetFront ?
[10:47] <asac> rzr: not yet. does it ship its own engine?
[10:48] <rzr> i guess yes, since it seems to be closedsource
[10:53] <rzr> asac: http://www.accessdevnet.com/index.php/ACCESS-Linux-Platform-Native-Development/Inside_ALP.html
[10:53] <rzr> see the 1st image
[10:55] <ruiboon> hi. how do i know if a package is using dpatch or cdbs? (trying to pack in a bug fix)
[10:57] <persia> ruiboon: It could be using both.  You can tell if it is using CDBS because it will Build-Depend: on CDBS in debian/control and #include some CDBS rules in debian/rules.
[10:58] <persia> ruiboon: You can tell if it uses dpatch because it will likely mention dpatch in debian/rules, and all the patches in debian/patches will be in dpatch format.
[10:59] <ruiboon> persia: i was told that it is using dpatch by u-u-s but then there is no dpatch include nor debian/patches
[11:00] <persia> ruiboon: Which bug?
[11:00] <ruiboon> persia: bug 234365
[11:04] <norsetto> ruiboon: what-patch tells me it is using dpatch
[11:05] <norsetto> ruiboon: and indeed it is a bd and is in the rules file too
[11:05] <ruiboon> norsetto: i guess i have to create my own debian/patches directory and files then
[11:06] <ruiboon> norsetto: the rule file didnt mention dpatch though
[11:06] <norsetto> ruiboon: no need, dpatch-edit-patch will do that for you
[11:06] <norsetto> ruiboon: include /usr/share/cdbs/1/rules/dpatch.mk
[11:06] <ruiboon> norsetto: oops. i missed that one
[11:07] <ruiboon> norsetto: thanks (:
[11:07] <norsetto> ruiboon: thank Luca ;-)
[11:08] <norsetto> ruiboon: in the future you may want to use what-patch, a utility which is in ubuntu-dev-tools
[11:09] <ruiboon> norsetto: that will certainly be useful. (actually it is already installed but i just didnt discover it)
[11:09] <ruiboon> norsetto, persia: Thanks again (:
[12:34] <emgent> morning \sh
[12:34] <emgent> :)
[12:35] <\sh> is it morning or is it the hell after linuxtag 2008
[12:35] <persia> \sh: Can it be both?
[12:37] <\sh> persia, dunno..but what I know is, we hacked the bordcomputer of a mercedes C class without using computer technique last night...we had luck to not be killed from a stupid driver on the highway
[12:38] <\sh> 160 km/h on the left lane..this stupid guy was pulling over from right to left and good that sput was reacting fast enough to brake...ABS + ESP were working great...
[12:38] <emgent> gh
[12:38] <\sh> after that, bordcomputer said: "Dear Driver, you don't have ABS, you don't have ESP and I really don't know what's your driving speed anymore...better to park this broken expensive car somewhere and wait for help"
[12:39] <emgent> hahahaha
[12:39] <\sh> without driving speed and some sensors ... our board navi refused to work, too...so we were waiting for almost 4 hours for a new car to get home
[12:40] <\sh> planned ETA at home: 18 UTC....real time at home: 1am UTC...
[12:44] <Iulian> Hey
[12:54] <mpt> What's the procedure for asking for a program to be packaged? I've read <https://wiki.ubuntu.com/MOTU> but it doesn't seem to cover that.
[12:54] <slytherin> mpt: file a bug
[12:55] <dholbach> http://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[12:55] <\sh> mpt,  wishlist bug, tag it as "needs-packaging"
[12:55] <mpt> ok, thanks :-)
[12:56] <mpt> ah, already reported, bug 94494
[12:57] <slytherin> persia: You forgot to give back libvte-java on ia64
[12:58] <persia> slytherin: OOps!
[12:59] <yannick> Hi, does someone knows how apt-ftparchive can handle 2 flavors of ubuntu (e.g. hardy and gutsy) ?
[12:59] <persia> slytherin: given-back
[13:00] <slytherin> persia: thanks, powerpc and sparc builds have completed already.
[13:03] <slytherin> persia: It will be great if you give back libglade-java also - https://launchpad.net/ubuntu/+source/libglade-java/2.12.8-5
[13:05] <persia> slytherin: Given back.
[13:09] <Hobbsee> heh.  other people getting bugged for givebacks.  yay!
[13:12] <persia> Hobbsee: Main is still all yours :)
[13:12] <Hobbsee> hehe
[13:12] <Hobbsee> yes, but there's less of that
[13:12] <Hobbsee> persia: it goes without saying that you're using buildd.py?
[13:12] <\sh> uh we have new semi-archive-professionells ;)
[13:13] <persia> \sh: Yep, like you.  Go visit a failed-build page.
[13:13] <Hobbsee> \sh: they should be able to do new packages reviews at some point, too
[13:13]  * persia thinks that's exceedingly dangerous
[13:14] <Hobbsee> persia: yes, well.
[13:14] <\sh> oh...that's why I was in a somewhat unstable state of mind...to not deal with LP...I really had forget about LP...
[13:18] <\sh> wow...but I think LP ants could improve the UI ;)
[13:50] <yannick> Hi, can apt-ftparchive (or dpkg-scanpackage) knows to which distro a .deb belong?
[13:53] <persia> yannick: Not directly.  There's the Origin: header, but it's often ignored.
[13:55] <yannick> persia, i've .deb, some belong to hardy and some to gutsy, using apt-ftparchive result in mixing them either into hardy, either into gutsy. Do you know how I can solve this?
[13:56] <persia> yannick: Create two separate archives, one for gutsy and one for hardy.  Alternately, look at a more powerful tool that supports pool.
[13:56] <yannick> persia, do you know such tool (supporting pool)?
[13:57] <persia> yannick: Sorry.  Not off the top of my head.  I don't tend to keep more than two or three packages in a private repo, and then only for an hour or so while testing something.
[13:57] <yannick> persia, ok, thank you very much
[13:59] <nxvl> morning :D
[14:00] <persia> yannick: Actually, I do have a word of advice: dak is larger and more complicated than you need.
[14:03] <yannick> persia, I thinnk I'll wrote a bash script to discard gutsy packs while I run apt-ftparchive for hardy, and then discard those for hardy when i'll run apt-ftparchive for gutsy. Hopefully I've a naming convention for my packs including the distro name in it.
[14:17] <persia> pochu: The size of freepats is precisely the issue.
[14:17] <persia> I'd prefer libwildmidi to depend on freepats, but it makes gstreamer-bad really heavy.
[14:18] <persia> This is especially annoying to the vast majority of people who don't actually every use .mid files.
[14:38] <fredreichbier> hello. i found a bug in the git ubuntu package, where do i report that?
[14:38] <slytherin> fredreichbier: launchpad.net
[14:39] <fredreichbier> slytherin: there is no git entry in launchpad. should i report it on launchpad.net/ubuntu?
[14:40] <slytherin> fredreichbier: yes that is what I meant, under ubuntu project search for package git
[14:40] <fredreichbier> ah, sorry. thank you!
[14:42] <persia> In the special case of git, I believe the package is named git-core (unless this is an issue with GNU Interactive Tools)
[14:43] <fredreichbier> however, the bug has already been reported by someone else ;-)
[14:44] <mterry> Question re: LP #207437 -- the patch is upstream, so it will be included in intrepid, so I figure no need to provide intrepid debdiff, and the change doesn't seem important enough for hardy.  Do I just do nothing more there?  (in terms of being a good MOTU-in-training)
[14:44] <persia> mterry: Not directly, as it won't crash in the default installation.
[14:45] <white> Marco Rodrigues here?
[14:47] <persia> white: he's not allowed to talk here.
[14:47] <persia> white: He goes by Kmos: try /query
[14:48] <white> not allowed to talk here? -v?
[14:48] <white> he just reassigned a few bugs to my packages without checking/looking over them
[14:48] <white> wasn't really the nicest thing to do :)
[14:49] <persia> white: That's why he's not allowed to talk here.
[14:54] <Hobbsee> white: if he's acting on ubuntu stuff again, after being asked to stop doing all development, tehn you'll probably need to whine to the MC.
[14:55] <persia> Well, it depends on what is done.
[14:55] <persia> We'll listen, but we may not be the appropriate parties to do much
[14:56] <white> Hobbsee: wow, that is quite a statement, he must have been quite ...
[14:57] <Hobbsee> white: it took many months to get rid of him.  the motu ML and motu-council mailing lists have the juicy details, including a stamp from mark.
[14:58] <Zelut> Is there a way to have pbuilder use my local mirror during & after pbuilder creation?
[14:58] <persia> Zelut: pbuilder --login is the easiest way to explain (but doesn't handle creation)
[14:59] <Zelut> persia: I can get it to use it via --othermirror (for post installation), but can't figure out creation..
[14:59] <Hobbsee> !pbuilder
[15:01] <Hobbsee> Zelut: follow ^, and modify /etc/pbuilder/apt.config/sources.list before creating the pbuilder.
[15:04] <mok0> sebner, yo!
[15:11] <jpds> dholbach: cool packaging video
[15:15] <schmiedc> jdps which video?
[15:15] <schmiedc> jpds*
[15:15] <jpds> schmiedc: http://www.jonobacon.org/?p=1190
[15:16] <schmiedc> thx
[15:17] <jpds> you're welcome.
[15:25] <bddebian> Heya gang
[15:26] <sistpoty|work> hi bddebian
[15:26] <Iulian> Hey bddebian
[15:26] <bddebian> Hi sistpoty|work, Iulian
[15:26] <schmiedc> hi
[15:29] <dholbach> jpds: I'm glad you like it
[15:30]  * jpds hugs dholbach
[15:30] <schmiedc> :)
[15:30] <schmiedc> de vid is super
[15:31] <effie_jayx> dholbach,  ping
[15:31] <dholbach> effie_jayx: pong
[15:32] <effie_jayx> dholbach,  I started working on a merge on saturday and since you were one of the initial maintainers of it I was wondering If I could ask you a couple ofsimple q's about it
[15:32] <effie_jayx> if you have the time of course
[15:32] <dholbach> effie_jayx: which package is it? sure
[15:33] <effie_jayx> bakery2.4
[15:33] <dholbach> alright
[15:37] <dholbach> effie_jayx: shoot :)
[15:37] <effie_jayx> dholbach,  it seems there is a new version in debian. and there are several differences in packaging. with regards to dependecies I am a bit lost. what could help me determine if the deps are ok for ubuntu as well?
[15:37] <effie_jayx> name changes...
[15:37] <mok0> eeek I can't get sound on that video...
[15:37] <dholbach> effie_jayx: the debian package generally looks good but the biggest problem I see right now is that there's libbakery-2.4-common vs libbakery-common
[15:38] <effie_jayx> dholbach,  aslo I am unsure about the changes that originated the merge in the first place.
[15:38] <effie_jayx> right
[15:39] <dholbach> effie_jayx: we packaged it before Debian did and started off from bakery2.3
[15:40] <effie_jayx> dholbach, mmkey. that clears that.
[15:40] <dholbach> effie_jayx: libbakery-common is the better name (would need a conflicts/replaces)
[15:40] <effie_jayx> dholbach,  ok, any other comments ... I think I can do this...
[15:41] <dholbach> effie_jayx: the depends look good to me on first glance
[15:42] <effie_jayx> dholbach,  version numbers is what got me jittery
[15:42] <dholbach> effie_jayx: it might be worth trying to build a package that build-depends on libbakery-2.4-dev (prefixsuffix or glom maybe)
[15:42] <dholbach> effie_jayx: thanks for stepping up to do the work :)
[15:43] <dholbach> effie_jayx: I haven't checked to closely but for now the package naming change is one thing we definitely need to keep ( probably until the next LTS :-( )
[15:43] <effie_jayx> dholbach, trying hard to keep up ;)
[15:43] <dholbach> effie_jayx: if you need any more help with it, let me know
[15:43] <effie_jayx> dholbach,  keep the name then
[15:44] <dholbach> that'd be even a bigger diff :)
[15:44] <\sh> dholbach, cool video btw
[15:44] <effie_jayx> dholbach,  ok.. I'll start with it and shall email if anything comes up... thanks for the input
[15:44] <effie_jayx> dholbach,  is that ok?
[15:45] <dholbach> effie_jayx: absolutely
[15:45] <dholbach> effie_jayx: and thanks for that
[15:45] <dholbach> \sh: thanks for the flowers :)
[15:45] <effie_jayx> dholbach,  thanks for?
[15:45] <dholbach> effie_jayx: taking care of the merge :)
[15:45] <effie_jayx> dholbach,  thank me when it's done... hehehe
[15:45] <dholbach> hehe
[15:46] <schmiedc> are there any other vids for people who decider about getting involved?
[15:46] <sebner> dholbach: *n *i* *c* *e*
[15:48] <\sh> dholbach, jono mentioned it on friday...and I'm wondering if we are able to do those videos "live"...(with chats during the live feed and as well interacting with other people (when they have a cam attached)) too :))
[15:48] <dholbach> \sh: it would be nice to get more videos on there - also localised ones
[15:49] <dholbach> schmiedc: expect more to come up soon
[15:49] <sebner> \sh: uhhh /me has a build-in webcam =)
[15:49] <Hobbsee> ack, videos.
[15:49] <Hobbsee> pictures are bad enough!  :P
[15:49] <schmiedc> dholbach:cool
[15:49] <\sh> dholbach, I promised jono to present a software for doing those liveshows via browser ... it's what I'm working on in my company...
[15:50] <dholbach> sebner: MOTU Videos in "Austrian" FTW! Yoohoo! ;-)
[15:50] <dholbach> \sh: oh great
[15:50] <sebner> dholbach: lol. "carinthian" :P
[15:51] <schmiedc> sebner: Styrian :P
[15:51]  * sebner hides xD
[15:51]  * schmiedc follows
[15:53] <Zelut> can anyone give me some feedback on my package in REVU? http://revu.ubuntuwire.com/details.py?package=origami
[16:01] <mok0> I propose that Contributing Developers be allowed to request syncs directly to ubuntu-archive
[16:02] <siretart> mok0: I object to that proposal. strongly.
[16:03] <mok0> siretart: why is that?
[16:03] <siretart> mok0: you didn't provide a rational either - please do first ;)
[16:04] <Hobbsee> mok0: i also object strongly to that proposal.
[16:04] <mok0> I think it's a small privilege, and ucd's have gone through an approval process
[16:05]  * Hobbsee thought revu was a priveledge.
[16:05]  * mok0 is not talking about revu
[16:05] <siretart> mok0: the priviledge is equal to the uploading priviledge. I don't see how it would be less than (full) upload access
[16:05] <mok0> siretart: how so? It is processed by an archive admin
[16:06] <Hobbsee> mok0: who should not have to figure out if all changes should be dropped.
[16:06] <mok0> I don't want to argue strongly for the point, I'd just like to understand your position
[16:06] <sebner> mok0: huhu. mok0. \o/ thanks =)
[16:07] <Hobbsee> siretart: it's slightly less - everything there's gone thru debian.  mind you, that's no guarentee on quality, at times.
[16:07] <mok0> Well, this is what should be examined when somebody applies for ucd
[16:07] <mok0> siretart: it is definitely much less than upload privs
[16:07] <siretart> mok0: the archive admins do not review the ubuntu changes and evalute if it was safe for the delta to be dropped. If they did that in the past, that would be a saftey bonus, but nothing to rely on
[16:08] <sebner> mok0: I asked for the right to change the wishlist and it would be a long process to allow that ... ^^
[16:08] <siretart> moreover, lp will offer an UI so that every upload can request syncs without archive admin intervention
[16:08] <Hobbsee> sebner: be a part of -bugcontrol?
[16:08] <sebner> Hobbsee: that's not the same ;)
[16:09] <mok0> Hobbsee: and it practice it's not possible
[16:09] <siretart> mok0: I fear that debian maintainers will use that feature to undo divergence in the ubuntu branch of their package. I've seen enough pointless and wrong request for syncs in the past
[16:09] <Hobbsee> sebner: why?
[16:09] <mok0> Hobbsee: they don't process the list of applicants
[16:09] <Hobbsee> mok0: around UDS, or at all?
[16:09] <Hobbsee> mok0: if they don't, you should poke bdmurray about it.
[16:09] <Hobbsee> and/or heno
[16:10] <sebner> Hobbsee: because a lot people see the universe group a step near MOTUship and this right isn't that big compared to mok0s sync right.
[16:10] <siretart> mok0: why should syncing be 'less' priviledge than regular upload priviledges? - considering dropping previous work is a hard decision from time to time!
[16:10] <ScottK> Sync right is exactly the same as upload rights.
[16:10] <siretart> and I really don't expect random contributors to be able to do that assessment
[16:10] <mok0> siretart: I don't have your experience, but the syncs I have seen have been very straightforward
[16:10] <Hobbsee> ScottK: excluding the fact that it's been thru debian QA.  which doesn't necessarily mean that any QA was actually done on it (see -games, etc)
[16:10]  * ScottK is seriously considering advocating we push new contributors away from merges and leave them to the more experiences.
[16:11] <ScottK> Hobbsee: Right, but it give the ability to land code in the archive.
[16:11] <Hobbsee> ScottK: oh, sure.
[16:11] <ScottK> mok0: Many of them aren't.
[16:12] <Hobbsee> mok0: specifically for you, i've seen various questions which have been rather elementary, which you either got wrong, or didn't know the answer to, so i'm not sure that something so 'elementary' as sync requests would be a good thing for you to touch, without a sponsor checking, anyway.
[16:12] <sebner> ScottK: I'm against it pushing me away from syncs and merges ;) (courier ?)
[16:12] <Hobbsee> but that's learning for you - i'm sure you'll slowly learn, and be given more privs as a result.
[16:13] <siretart> mok0: boy, this merge and sync buisness is hard work and definitly not an beginners task. I agree with ScottK that we should take newcomers away from that work. it is way too error prone and very hard to undo.
[16:13] <mok0> I everyone is opposed there is no point for me to push it any further. I thought it would be good to offer ucd's additional privelges to ordinary contributors...
[16:13] <Hobbsee> mok0: such as?
[16:13] <mok0> Hobbsee: such as what?
[16:13] <Hobbsee> (apart from the sync requests)
[16:13] <Hobbsee>  I thought it would be good to offer ucd's additional privelges to ordinary contributors...
[16:14] <Hobbsee> hence, such as?
[16:14] <mok0> Hobbsee: the right to process a sync
[16:14] <mok0> Hobbsee: but not to upload
[16:14] <mok0> After all, they are approved by MC.
[16:15] <Hobbsee> mok0: the MC doesn't touch them.
[16:15] <ScottK> sebner: You haven't just started.
[16:15] <mok0> ... and the handfull we have now are quite capable
[16:15] <sebner> ScottK: hmm?
[16:15] <mok0> Hobbsee: surely, MC approves UCDs?
[16:16] <ScottK> sebner: I don't think you're the beginner I was suggesting should be pushed away from merges.
[16:16] <siretart> mok0: can you please point me to the criteria under which the MC approves new members?
[16:16] <soren> mok0: I'm not sure why we'd want to grant syncing privileges to more people than we grant upload priv's to?
[16:16] <mok0> sebner: weren't you evaluated by MC?
[16:16] <sebner> mok0: yes
[16:16] <ScottK> mok0: Yes, MC approves, but not based on technical criteria.
[16:16] <Hobbsee> mok0: oh, that they do.  but they don't get approved based on the criterias of whether something is good to upload, changes can be dropped, it's suitable to do it at this time, etc.
[16:16] <siretart> ScottK: I wasn't sure, but I expected that
[16:16] <Hobbsee> OTOH, mok0 is not exactly a beginner, either
[16:17] <sebner> ScottK: Ahhh, I thought that you mean that only the beginners should do merges and syncs ^^
[16:18] <ScottK> sebner: No.  I think the shouldn't.
[16:18] <mok0> My suggestion is that UCDs continue to do merges but can push a sync to ubunut-archive
[16:18] <sebner> ScottK: understood
[16:18] <Hobbsee> mok0: suggestion examined, and denied :)
[16:18] <mok0> heh
[16:18] <sebner> Hobbsee has the power \o/
[16:18]  * Hobbsee has the stick...
[16:19]  * sebner hides
[16:19] <siretart> mok0: my suggestion is that UCDs should not consider working on merges at all
[16:19] <jpds> long live the pointy stick \o/
[16:19] <mok0> My suggestion has the merit of gradually increasing responsibility towards MOTU status
[16:19] <Hobbsee> siretart: why, if they're eventually going to go for MOTU?
[16:19] <Hobbsee> mok0: if you can upload one section of code directly to one component, why shouldn't you be able to upload any other sections of code to that component?
[16:19] <siretart> Hobbsee: there is tons of less error prone work in ubuntu to work on.
[16:20] <sebner> ScottK: no time for courier? I'm curious what you are saying in the end also because you told me somthing about the "example" courier
[16:20] <soren> mok0: I'm not sure why syncing should have a lower barrier of entry? It's just as intrusive as a regular upload?
[16:20] <Hobbsee> siretart: oh, sure, but i thought these guys were going for universe unlimited upload rights
[16:20] <ScottK> sebner: I ended up being out of town unexpectedly almost steadliy since UDS.
[16:20] <siretart> Hobbsee: sure. but I think working on existing packages gives you way faster the experience in packaging than working on merges in the first place.
[16:21] <mok0> soren: not really. A sync has already been processed by the DD. In a merge, you can introduce terrible things
[16:21] <siretart> I may be wrong, of course
[16:21] <\sh> a sync can also break things...terribly
[16:21] <soren> mok0: syncs can do quite terrible things, too.
[16:21] <sebner> ScottK: ah ok then, sry for annoying =) (Just curious about for final opinion on me ^^)
[16:21] <ScottK> mok0: But a sync has been processed by a DD for Debian.
[16:21] <ScottK> sebner: No problem.  The reminders are good.
[16:22] <sebner> ScottK: I'm waiting if you have finished with courier ;)
[16:22] <emgent> hello
[16:22] <Hobbsee> siretart: true.  althouhg of course, when they get up to possible MOTUship, they'll be wanted to have exposure to all of it.
[16:22] <sebner> hi emgent
[16:22] <emgent> ScottK: have you saw about wordpress backport?
[16:22]  * white gets the popcorn out
[16:22] <Hobbsee> siretart: but i see your point
[16:22] <ScottK> emgent: No.
[16:22] <ScottK> emgent: Bug?
[16:22] <emgent> just a moment
[16:23] <Hobbsee> mok0: in a sync, the DD hasn't checked for ubuntu changes that might be important.
[16:23] <Hobbsee> it's just checked that the proposed changes work for *debian*.  not for ubuntu.
[16:24] <ScottK> mok0: One case for Ubuntu/Debian diff is we've fixed something that applies to Debian.  In many other cases it's because Ubuntu is different.  Before you can understand in some cases if a sync is appropriate, you need to understand that.
[16:24] <emgent> ScottK: Bug #172440
[16:24] <sistpoty|work> imho there are both easy and difficult merges, so I don't think it's a good idea to keep new people from doing merges, nor to encourage them.
[16:24] <mok0> Hobbsee: that's true, but we do encourage people sending patches to Debian, and it's pretty trivial to see if that has been done since last release. Otherwise, ScottK's rule still applies for UCDs as well as everyone else
[16:25]  * Hobbsee has seen enough people manage to screw that up, who might fit in that 'contributor' category, too.
[16:25] <ScottK> mok0: I agree that there are merges that it's trivial to see if they should be syncs.  I just don't think that's the most common case.
[16:25] <mok0> If the UCDs are known to follow ScottK's rule I think it could be a great time saver for the MOTU crew
[16:26] <ScottK> emgent: Backports aren't for bug fixes (particularly not for security fixes).  Get it fixed in -security first and then if there is new capability worth a backport, ask for it then.
[16:26] <ScottK> mok0: Which rule is that (the ask first one)?
[16:26] <mok0> "Don't touch what you don't understand"
[16:27] <ScottK> Ah.
[16:27] <mok0> :)
[16:27] <ScottK> That's a good one.
[16:27] <emgent> ScottK: i can fix it, but it`s very long and big work. I think to backport for include the newest features too.
[16:27]  * ScottK wishes some MOTU would follow that rule.
[16:27] <mok0> ... none mentioned...
[16:27] <Hobbsee> ScottK: don't.  it'll send you down a path of disollusionment if you think like that.
[16:27]  * \sh don't touch main anymore...
[16:28] <ScottK> emgent: Backports is not for security fixes.  If it's not feasible to patch it to fix it, talk to kees_ or jdstrand about putting the new version in -secuirty.
[16:28] <emgent> \sh: lol :)
[16:28] <ScottK> Hobbsee: Just because I with for it, doesn't mean I have any expctation I'll get it.
[16:29] <Hobbsee> ScottK: true, but that still leads to disollusionment.
[16:29] <ScottK> Urgh.
[16:29] <ScottK> with/wish
[16:29] <ScottK> Hobbsee: You assume it's possible for me to be more disillusioned than I already am.
[16:30] <Hobbsee> ScottK: this is true.  you're still alive, so tha'ts a fair assumption.
[16:30] <Hobbsee> :)
[16:30] <mok0> Hobbsee, ScottK, cheer up you 2 grumpypots :-)
[16:30] <ScottK> Well.  Maybe.
[16:30] <Hobbsee> mok0: grumpy?  nah.
[16:30] <siretart> sistpoty|work: is that dexconf quirk easy to port to general qemu/faumachine?
[16:31] <sistpoty|work> siretart: haven't looked at it yet in detail, and I fear it's not (at least not to FAUmachine)
[16:31] <\sh> man...opensuse build service can now work with other installed buildservices somewhere around the world...I wonder when it happens, that we have more then one LP...
[16:31] <mok0> Hobbsee: Ah, ok, only disillusioned and bitter ;.)
[16:32]  * \sh 's catching up with the important news of the last month
[16:32] <Hobbsee> mok0: i'm not sure that bitter really fits.  i'm aware that i don't really have the time to put into it, so have stepped back a lot, and so don't have the same degree of caring about it anymore.
[16:33] <sistpoty|work> siretart: well, it could be ported, I guess: that's the corresponding line in dexconf: QEMU_KVM=$(grep "QEMU Virtual CPU" /proc/cpuinfo || true)
[16:33] <mok0> Hobbsee: don't worry about it, I am just teasing
[16:33] <sistpoty|work> siretart: but of course that'd be quite wrong for FAUmachine (it's meant to behave exactly like real hw)
[16:33] <Hobbsee> mok0: as in, i still care that my stuff is right, and i still care somewhat that everyone else's is right, so is not compromising the archive, but i don't tend to smash people with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ for getting it wrong repeatedly anymore.
[16:34] <siretart> sistpoty|work: what does qemu report in /proc/cpuinfo?
[16:34] <sistpoty|work> siretart: no idea, haven't checked actually
[16:35] <sistpoty|work> siretart: and I have the strong believe that the current hardy x won't start with a real cirrus gd5446 as well.. I'll add some more details to the bug
[16:35]  * mok0 has thankfully not tasted the LPS yet... :-/
[16:35] <siretart> sistpoty|work: aah, plain qemu reports "Pentium II (Klamath)"
[16:38] <mok0> Gotta go, see you later!
[16:38] <sistpoty|work> cya mok0
[16:51] <siretart> sistpoty|work: perhaps it is possible to set the DefaultDepth on a per driver level?
[16:52] <sistpoty|work> siretart: maybe... I'm just about to dig through where it comes from (must be somewhere in xorg-server-1.4.1~git20080131/hw/xfree86/common)
[16:53] <wasabi> Hey anybody work with IKVM?
[16:53] <wasabi> Ahh. Only minor Ubuntu forks. Never mind. Shall consult Debian maintainer.
[16:55] <jpds> wasabi: how are you cloaked, and not identified?
[16:57] <wasabi> I don't follow?
[16:57] <Hobbsee> jpds: freenode playing with the new services.
[16:57] <Pici> jpds: You dont have to be on a registered user to identify now.
[16:57] <Hobbsee> jpds: it kept the cloaks, but forced everyone to reidentify
[16:57] <Pici> Well, that too, but my answer doesnt answer your question
[16:58] <jpds> Hobbsee: hmmm
[16:58] <sistpoty|work> siretart: I guess I'm a little bit stupid. this appears to be a bug in the cirrus driver after all
[16:59] <siretart> sistpoty|work: sorry?
[17:01] <sistpoty|work> siretart: imho the cirrus driver determines it's max pixel clock value by the wrong bpp entry (the one from the framebuffer), but need to dig a little bit further into the code still
[17:39]  * sistpoty|work heads home now... cya
[18:14] <green_mandarin> hi guys
[18:18] <green_mandarin> is a Ubunteros here?
[18:47] <amikrop> How can I declare wxPython as a dependency?
[18:48] <amikrop> python-wxgtk does not have an installation candidate, so I am not sure how to handle this
[19:00] <amikrop> So, any help, please?
[19:00] <geser> amikrop: which python-wxgtk? 2.4, 2.6 or 2.8?
[19:01] <Balachmar> Hi, I want to check if someone else already is packaging blender 2.46 for hardy (backports)
[19:01] <geser> amikrop: see "apt-cache search python-wxgtk"
[19:01] <amikrop> geser: Any.
[19:01] <amikrop> I have done so.
[19:01] <amikrop> I want any python-wxgtkx.y
[19:02] <geser> amikrop: depend on python-wxgtk2.4 | python-wxgtk2.6 | python-wxgtk2.8 if it works with any of the three
[19:02] <geser> the version you prefer list at first
[19:02] <amikrop> geser: I haven't thought of that. Thanks.
[19:03] <jb0t> Flannel: i figured it out.  mysql-common was pinned in /etc/apt/prefs
[19:03] <jb0t> i must have downgraded going from dapper to edgy because the package was broken at the time.
[19:05] <sebner> Balachmar: 2.46 is not even in intrepid so wait until then before you request a backport
[19:05] <jb0t> anyway.. persia, Flannel, wgrant...thanks for your help last night
[19:05] <Balachmar> @sebner: Well, I wasn't really requesting a backport, but offering to do it :) (or at least try it...)
[19:06] <sebner> Balachmar: no need to package it at your own. we merge it from debian
[19:07] <Balachmar> Any idea, on how long that will take (not really impatient, but curious) And how long will it take to be backported afterwards?
[19:08] <sebner> Balachmar: depending on when Debian it has ;) When intrepid has it I usually takes just a few days if you annoy the right people ^^
[19:08] <Balachmar> Because I want to learn how to help out, and I just wanted to try blender 2.46 as well. And I saw that more people wanted it. And thought, well maybe I could try it myself.
[19:09] <sebner> Balachmar: well, blender seems no to be the right thing to start with
[19:09] <sebner> \sh: any hints?
[19:10] <\sh> any software is good to start with packaging, after reading all the documentations about packaging...
[19:11] <\sh> s/reading/reading+watching/ ;)
[19:11] <sebner> \sh: Tell something about merging :P
[19:12] <Balachmar> I was reading: https://wiki.ubuntu.com/MeetingLogs/openweekhardy/PackagingA and thought I could follow that...
[19:12] <geser> \sh: don't forget "understanding"
[19:12] <Balachmar> :) ofcourse, you shouldn't be doing things like a headless chicken...
[19:12] <\sh> geser, oh I thought that implies "reading" ;) ok "after reading+watching and understanding"
[19:12] <sebner> \sh: uhhhh that's not that clear :P
[19:13]  * Balachmar agrees with sebner
[19:13] <Balachmar> So, basically I just thought that I should check here in order to prevent that different people are doing the same thing
[19:14] <sebner> Balachmar: good ;)
[19:15] <\sh> Balachmar, it's open source ... many people are doing the same thing...
[19:15] <jpds> ScottK: are you there?
[19:15] <amikrop> Is it legal to package/distribute freeware firmware?
[19:15] <sebner> \sh: bah. It's good to check and ask -.-
[19:15] <ScottK> Yes
[19:15] <jpds> ScottK: pm?
[19:15] <ScottK> Sure
[19:16] <Balachmar> @\sh I think it would be more efficient if the work is divided. So not too much is done twice (or trice or....)
[19:16] <\sh> sebner, if miguel would have asked matthias if someone is working on a desktop software...gnome would have never been invented...
[19:17] <sebner> \sh: but that's a total different thing
[19:17] <\sh> Balachmar, regarding one distro yes...regarding the whole universe ... people do whatever they want...
[19:17] <Balachmar> @\sh: This is about packaging, it would be foolish to package the same thing twice
[19:17] <amikrop> I mean, is it legal to include some freeware, hardware firmware into my package, and distribute it?
[19:17] <Balachmar> @\sh I understand what you mean
[19:18] <Balachmar> @amikrop: Free as in speech, or free as in beer? :P
[19:18] <\sh> Balachmar, check gnome-look or kde-look.org...people package software for debian, redhat, ubuntu, suse, mandriva, whathaveyou...they don't care about double the work already done...they do something because they want to ...
[19:18] <\sh> and this is good..
[19:18] <amikrop> Balachmar: Beer (I said "freeware", not "open source").
[19:19] <Balachmar> @amikrop, then you have too read the license, but I think most of the time, they don't want you to distribute the software
[19:19] <Balachmar> @\sh: With the risk of being stupid: And why is this good?
[19:21] <\sh> Balachmar, people are interested to learn something? they are curious how things are working and trying to understand the system? I mean we are living in a consuming community..people who are ready to learn and curious are sometimes hard to find :)
[19:21] <Balachmar> @\sh: OK then it is mostly good for themselves :) But I get your point
[19:22] <\sh> Balachmar, what's good for you could be good for others..
[19:22] <Balachmar> @\sh: Don't get too philosophical now! :P
[19:24] <\sh> hmm...I was telling this people at linuxtag when they were asking "why the hell are you investing your free time into opensource"...they were quite excited and fascinated that geeks are thinking about those things...
[19:25] <\sh> one guy already started to work on software + packaging...
[19:26] <Balachmar> :) always nice to amaze people
[19:30] <Balachmar> But if I would somehow still want to package blender 2.46 couldn't I also send it in to debian, so that they wouldn't have to do it?
[19:30] <\sh> Balachmar, you can send a bug report with the package attached (when you use thedebian package as base)
[19:31] <sebner> Balachmar: btw, blender is already in experimental ... ;9
[19:33] <Balachmar> @sebner aah I see, so no need to do that. But shouldn't it then be fairly easy using pbuilder?
[19:34] <sebner> Balachmar: what should be easy?
[19:34] <Balachmar> I am just reading the howto. And just build bc from source.
[19:35] <geser> while I see you talking about blender, /me remembers to continue the download of the "bunny" movie via torrent
[19:35] <Balachmar> @sebner: to create a ubuntu hardy package for blender
[19:35] <sebner> Balachmar: hmm yes but that's not the way we are doing that normally
[19:36] <Balachmar> @sebner: but it could be a transitional solution for the impatient few among the hardy users wouldn't it?
[19:36] <Balachmar> And if it isn't that hard I am willing to give it a try
[19:36] <sebner> Balachmar: you can always giving it a try and offer it through your PPA if you want
[19:37] <Balachmar> @sebner, I will just do that: for learning sake ;) \sh
[19:37] <sebner> ^^
[19:39]  * \sh goes off and learn who to reactivate his whole human system from being in rescue mode....bathtub  bow
[19:39] <sebner> hf \sh
[19:39] <amikrop> I have made a package which once installed, enables a ueagle modem user to connect to the internet (installs the firmware, asks ADSL params and fills configuration files, provides some simple, related scripts, etc). I really think it makes new users' lifes easier, and generally, makes the process of using the modem, fully-automated. I have tested it from many aspects, and it seems functional. I believe it will help. So, are there any st
[19:39] <amikrop> eps I should take, to provide the package to a larger community than myself, family and friends?
[19:40] <sebner> \sh: bathtube? bad Harald is showing dumb things :P
[19:41] <geser> Balachmar: you could even fetch the blender source package from Debian experimental and if it builds in hardy without modifications, make it available via your PPA
[19:41] <sebner> geser: shouldn't he do a proper merge?
[19:42] <leonel> ScottK: http://lurker.clamav.net/message/20080602.130841.9c64bafa.en.html  <-- it's coming
[19:42] <Balachmar> @geser: I have downloaded the .dsc from debian experimental and am currently trying to build it using Pbuilder.
[19:42] <Balachmar> @sebenr, how would I do a proper merge?
[19:43] <geser> sebner: ah, we have Ubuntu changes, then a merge would be the better solution
[19:43] <sebner> Balachmar: look at the outstanding ubuntu changes.
[19:43] <sebner> geser: yep =)
[19:43] <Balachmar> I have found this page: https://wiki.ubuntu.com/UbuntuDevelopment/Merging?action=show&redirect=MOTU%2FHowToMerge
[19:43] <ScottK> leonel: Thanks.
[19:43] <ScottK> leonel: You saw that the 0.92.1 packages are in feisty/gutsy updates now, right?
[19:46] <Balachmar> When using Pbuilder: I get an error that it cannot satisfy the build dependencies
[19:47] <sebner> Balachmar: pastebin
[19:52] <leonel> ScottK: yes I did that's why I stopped searching  cves
[19:53] <amikrop> geser: In other words, how can I contact a responsible for reviewing my package?
[19:54] <geser> amikrop: where is your package? on REVU?
[19:55] <amikrop> geser: What do you mean by saying "REVU"?
[19:55] <sebner> amikrop: where is your package?
[19:55] <geser> !revu
[19:55] <amikrop> sebner: On a LAN repository.
[19:56] <amikrop> geser: I will have a look and answer you.
[19:56] <sebner> amikrop: upload it to revu ;)
[19:58] <amikrop> sebner, geser: OK, thanks. I will.
[20:01] <amikrop> OK. Joined revu-uploaders in Launchpad. But I can't find a way to upload. Any hints?
[20:01] <sebner> amikrop: https://wiki.ubuntu.com/MOTU/Packages/REVU
[20:02] <devfil> amikorp: if you want to upload a package type on terminal: dput revu _souce_changes_of_package_to_upload
[20:02] <sebner> amikrop: first you may want ask a revu admin to sync the keyrings
[20:04] <amikrop> I see.
[20:08] <Zelut> can universe contain software under a non-free license?
[20:08] <sebner> Zelut: nope
[20:08] <geser> no, only multiverse and there only if it's redistributable
[20:09] <Zelut> sebner: I didn't think so but a user just pasted me the commented lines from the sources.list which mention it may be non-free..
[20:09] <sebner> Zelut: non-free ist debian
[20:10] <sebner> Zeddie: debian != ubuntu
[20:11] <Zelut> sebner: this guy is a GNU-head so he considers it tainted if it even mentions it 'might' contain.
[20:11] <sebner> Zelut: well, see what geser wrote
[20:12] <Zelut> sebner: / geser: well I guess the question is then why does the commented sources.list mention it might be?
[20:12] <geser> Zelut: how exactly is the software licensed?
[20:12] <geser> Zelut: can you show the line you got?
[20:13] <Zelut> geser: http://pastebin.ca/1037110 - a paste from the default sources.list file..
[20:17] <Balachmar> Hi, If I use grab-merge.sh for blender it comes up with the 2.45 version not the 2.46. So, what should I do then?
[20:17] <sebner> Balachmar: as I said. blender 2.46 is in experimental and grab-merge only fetched from unstable. you have grab the source manually
[20:19] <Balachmar> @sebner: ooh sorry, I guess I missed that.
[20:19] <sebner> np
[20:20] <Balachmar> @sebner: Is there some documentation on how to do that?
[20:21] <sebner> Balachmar: http://packages.debian.org/source/experimental/blender
[20:27] <Balachmar> @sebner and then use those files instead of the ones you get from grab-merge?
[20:28] <sebner> Balachmar: yes though you have to apply the remaining ubuntu changes manually
[20:29] <Balachmar> @sebner thanks for the info. Will check that some other day. Have to check the finances now. But I guess I will be back :)
[20:29] <sebner> ^^
[20:29] <sebner> hf
[20:30] <amikrop> The url you gave me, says about a `dpkg-buildpackage -S -sa -rfakeroot` command. Where to execute it? Inside the my-package directory (which contains the DEBIAN directory and the filesystem tree of the package's data)?
[20:31] <amikrop> I did so and got that output: http://dpaste.com/54389/
[20:31] <sebner> amikrop: inside the package directory
[20:32] <amikrop> sebner: But I got this error message, above.
[20:33] <sebner> amikrop: strange but doesn't seem that you are in it
[20:33] <amikrop> (Am I missing any files? I just have "DEBIAN/", "usr/" and "etc/" in the package directory.
[20:33] <sebner> amikrop: does debian/changelog exists?
[20:34] <amikrop> No. Not even "debian/" exist.
[20:34] <sebner> amikrop: but DEBIAN/ ??
[20:34] <amikrop> I always package using "DEBIAN/", not "debian/".
[20:34] <sebner> use debian/ ^^
[20:34] <amikrop> ok
[20:35] <geser> looks like the temporary dir from where the deb is made
[20:35] <amikrop> geser: Yes, that is it.
[20:35] <Jazzva> norsetto: Are you ok with me updating gnome-mplayer and gecko-mediaplayer?
[20:36] <norsetto> Jazzva: totally ok
[20:36] <amikrop> sebner: So, I need "debian/changelog"? I never used that before. Where can I find some documentation about the contents of "debian/changelog"?
[20:36] <geser> amikrop: call dpkg-buildpackage from the contain the source and the debian/ dir
[20:36] <Jazzva> norsetto: Cool. I'll start working on it tonight and change bug report's status to In Progress (and assign myself). Thanks :)
[20:36] <geser> amikrop: how did you build your packages till now?
[20:37] <sebner> !packaging
[20:37] <norsetto> Jazzva: no, thank you :-)
[20:37] <sebner> geser: hmm. O_o
[20:37] <Jazzva> :)
[20:38] <geser> sebner: I also suspect seeing someone doing it the wrong way
[20:39] <sebner> geser: true. Now I'm keen to here the answer of your question
[20:39] <amikrop> geser: with `dpkg -b`
[20:40] <amikrop> geser: I find it pretty simple and straightforward.
[20:40] <sebner> amikrop: no valid packages then ....
[20:40] <amikrop> sebner: Why not?
[20:41] <sebner> amikrop: because a valid package needs all the things mentioned in the packaging guide. manpages, .desktop, changelog .....
[20:41] <geser> amikrop: and how do you automate applying patches, calling configure with the right flags, building the package?
[20:41] <amikrop> geser: I guess I don't.
[20:43] <amikrop> So, I should follow the packaging guide step-by-step? I didn't know it was mandatory. OK, then, I will.
[20:44] <sebner> geser: *thumbs up*
[22:10] <emgent> heya
[22:12] <effie_jayx> hey emgent
[22:13] <devfil> emgent: hi
[22:41] <RoAkSoAx> chan #ubuntu-irc
[22:41] <RoAkSoAx> oops
[22:41]  * ajmitch goes & trolls in there
[23:38] <Neurostu> so I'm having a problem building a package is there anybody here that has a few minutes to answer some questions
[23:38] <Laney> Neurostu: It's best to just ask, then anyone who knows can answer if and when they see it
[23:41] <Neurostu> ok so I'm trying to build 2 packages, the first one builds fine, but the second one depends on the first....  I get the following error:
[23:41] <Neurostu> dpkg-shlibdeps: failure: no dependency information found for /usr/lib/libsomanetwork-1.0-0.3.so.1 (used by debian/tspikes/usr/bin/ratetimelinevis).
[23:41] <Neurostu> When I inspect the first package using dpkg --contents <package name> I get
[23:41] <Neurostu> lrwxrwxrwx root/root         0 2008-05-30 20:24 ./usr/lib/libsomanetwork-1.0.so -> libsomanetwork-1.0-0.3.so.1.0.2
[23:41] <Neurostu> lrwxrwxrwx root/root         0 2008-05-30 20:24 ./usr/lib/libsomanetwork-1.0-0.3.so.1 -> libsomanetwork-1.0-0.3.so.1.0.2
[23:41] <Neurostu> I have the first package installed,  so i'm not sure exactly what the error means
[23:41] <Neurostu> sorry for the flood
[23:43] <ajmitch> in the library package, you used dh_makeshlibs?
[23:43] <Neurostu> no just dh_make
[23:44] <ajmitch> dh_make template may not be enough
[23:44] <ajmitch> did you tell dh_make that the first package was a library?
[23:47] <Neurostu> no, how exactly do I do that (sorry this is my first time building debs)
[23:48] <ajmitch> library packaging is a complex beast, full of pitfalls
[23:49] <ajmitch> in debian/rules in the library package, you'll want to have dh_makeshlibs there
[23:49] <ajmitch> the debian library packaging guide may be of some help, though it'll probably seem overly complex
[23:57] <Neurostu> ok... I'll check it out...
[23:57] <Neurostu> what are the main differences between using pbuilder and dh_make
[23:58] <mok0> Neurostu: they're 2 very different beasts
[23:59] <Neurostu> but they are used to accomplish the same task right?
[23:59] <mok0> Neurostu: no
[23:59] <Neurostu> oh..
[23:59] <mok0> dh_make creates template files in the debian/ directory
[23:59] <Neurostu> k
[23:59] <mok0> pbuilder compiles and builds packages