[00:07] <norsetto> blairzajac: I'll give it a better look tomorrow but looks pretty good, just two things:
[00:08] <norsetto> blairzajac: the standards version is now 3.8.0 (not your fault, time passed away unfortunately)
[00:08] <norsetto> blairzajac: since your icense is the same as perl, you need to have pointers in copyright to /usr/share/common-licenses/Artistic and /usr/share/common-licenses/GPL
[00:09] <norsetto> blairzajac: not sure if Perl-5 is GPL-2 or GPL-3, just use the right one
[00:11] <norsetto> blairzajac: also, your watch file doesn't seem to work
[00:14] <norsetto> blairzajac: also, please file a needs-packaging bug in LP and close it in your changelog with (LP: #xxxxx). You don't need all that stuff in changelog, just initial release will do
[01:12] <mitsarionas> hi all...could someone help me with automake/autoconf?
[01:25] <blairzajac> norsetto: thanks!
[01:33] <zachtib> hey, i have a packaging problem... i'm making a package that is split into multiple binary packages, all of which have some python in them.  the files are getting moved to /usr/share/python-support, but then each binary package's files go into a separate subdir after that... how can i get them all in the same directory the way it was before I spilt the package?
[01:33] <zachtib> i've been googling for a couple hours now :-/
[01:39] <persia> zachtib: The presumption is that you are splitting the package in a way that makes the separate pieces logically distinct.  While there are ways to force things to again be in the same directory, why would you want to split the package if the contents are collocated?
[01:41] <zachtib> well, there's a daemon and multiple UI's, i want the daemon in one package, then each UI in another, but then there's also some shared module that I have in a common package
[01:41] <persia> That makes sense.  Now, why ought they share the same directory?
[01:42] <zachtib> well, i know when they are in different directories, it crashes, which i'm assuming is because they can't find some of the common modules
[01:43] <persia> That sounds like insufficient namespace separation to me, which would be a bug.  Is the code perhaps not written to be sufficiently modular to do what you expect?
[01:45] <zachtib> that might be the case, and if so i'll work with the devs to fix the issue
[01:46] <persia> zachtib: Good luck.  Note that without seeing the error, I'm just guessing: it could be that there's some file that needs to be in a different place, and it's just an artifact of the way the package was split.
[01:46] <zachtib> one sec, lemme reproduce and pastebin
[01:47] <zachtib> http://paste.ubuntu.com/23223/
[01:48] <zachtib> that may or may not be the error that's causing trouble, i'm rebuilding now
[01:51] <zachtib> yeah, it's pretty much the same error
[01:53] <persia> That fragment clearly indicates that the code sought is not stored in the expected place.  That said, it's not likely you can differentiate between the code to be loaded being stored in an unexpected or misnamed directory from loading code that makes incorrect assumptions about the relative relationship to code to be loaded without investigation of the code concerned.
[01:53] <zachtib> ok, i think i may have left something out when i split the package, i'm gonna go check over my scripts again
[01:53] <persia> It's worth checking documentation on the modularity of the affected package, and ensuring that your package split and the expected modular breakdown match: this may require patching some module names.
[01:55] <persia> On the other hand, this approach may not be successful, as it may be that the code is constructed in such a way that you cannot split the package in the way you desire. (it's neither simple or desireable to have two binary packages provide separate components of a single module)
[01:55] <emgent> ls
[01:56] <emgent> ups, wrong terminale session
[01:56] <zachtib> oh wow, yeah, i missed a lot of .py files >.<
[01:56] <persia> zachtib: Excellent news: you're now no longer communication blocked, and can proceed with your plan :)
[01:57] <zachtib> yep, till my next error at least
[01:58] <zachtib> the project was meant to be modular from the ground up, but i think i'm the first one to actually try and build multiple binaries out of it
[02:38] <emgent> night
[02:41] <zachtib> persia, got my package working, thanks for the help :)
[02:43] <persia> zachtib: Great news!
[05:04] <persia> There's a completely unadvertised MOTU Meeting on in #ubuntu-meeting, if anyone is available to attend.
[05:08]  * ScottK jumps in.
[06:28] <foxbuntu> Hi all, I was wondering if someone would mind a quick review of my package to provide a +2 for it
[06:28] <foxbuntu> mythbuntu-apple-trailers
[06:29] <StevenK> foxbuntu: Can you post a URL to it?
[06:29] <foxbuntu> StevenK, http://revu.ubuntuwire.com/details.py?package=mythbuntu-apple-trailers
[06:42] <swegner> Is there a standard way to package icons to be installed using cdbs?
[06:45] <StevenK> foxbuntu: Personally, I'm not so sure about having the source in <unpacked dir>/usr/share/mythtv. It should be installed there by debian/rules, but probably not in the upstream tarball, surely?
[06:47] <foxbuntu> StevenK, I am the upstream now, but i am not really sure what you are asking?
[06:47] <StevenK> foxbuntu: When you unpack the .orig tarball, the source isn't in ., it's in ./usr/share/mythtv
[06:48] <superm1> a variety of the mythbuntu-* packages store it that way already
[06:48] <StevenK> In the source? Why?
[06:48] <superm1> no need to complicate things and make a rule for moving it around
[06:48] <superm1> you know exactly where it will end up
[06:49] <StevenK> It's three files, you add a debian/install file, and stop caring. :-)
[06:50] <superm1> well when the packages start to grow at least
[06:50] <superm1> some of them are shipping a ton of settings files say for example
[06:50] <superm1> but either way its a matter of opinion
[06:50] <StevenK> I've just never seen it done that way before
[06:52] <StevenK> Does mythtv-frontend being installed ensure the mythtv user and group exist?
[06:53] <superm1> mythtv-common does
[06:53] <superm1> which is a dependency for mythtv-frontend
[06:53] <StevenK> Right. In any case, the packaging for mythbuntu-apple-trailers looks good.
[06:54] <StevenK> foxbuntu: ^
[06:55] <foxbuntu> StevenK, thanks
[06:55] <foxbuntu> StevenK, did you add a comment +1?
[06:56] <StevenK> Just fighting with REVU to do so now
[06:57] <foxbuntu> thanks
[07:36] <dholbach> good morning
[07:37] <nxvl> hi!
[07:39] <geser> Guten Morgen dholbach
[07:39] <dholbach> hi geser, hi nxvl
[07:39] <nxvl> i have been thinking today about we talk last night
[07:39] <nxvl> and i think that maybe a process like debian's NM would be good
[07:40] <nxvl> (not so bottle necked as debian, but that's the idea)
[07:40] <dholbach> nxvl: what would you like to change?
[07:40] <siretart> Guten Morgen, MOTU!
[07:41] <nxvl> dholbach: the mentors program
[07:41] <nxvl> in my experience with it, is too short
[07:41] <dholbach> nxvl: and what in particular would you like to change?
[07:42] <nxvl> well
[07:42] <nxvl> first to have some standars for mentors
[07:42] <nxvl> so the people mentoring a new contributor to have some "steps" to follow
[07:42] <nxvl> and make it more extensive
[07:42] <nxvl> i was drop by my own really early as i feel it
[07:43] <dholbach> we never announced the mentors programme really publically and even then we did not have enough mentors
[07:43] <geser> Guten Morgen siretart
[07:43] <dholbach> I'm not sure that introducing standards for mentors is going to help with that particular problem
[07:44] <nxvl> well i was more thinking in having steps for new contributor
[07:44] <siretart> 'steps'?
[07:45] <nxvl> and not to hardly say mentors: this are the standars
[07:45] <dholbach> like?
[07:45] <nxvl> just: here you have some suggestions that you can follow
[07:45] <jscinoz> Hey guys, im working on a number of packages, and i've run into a problem with cowbuilder, basically i cannot run multiple instances of it simultaneously as it gets dpkg admin directory locked errors, any ideas what i'm doing wrong?
[07:47] <nxvl> jscinoz: have you tried pbuilder?
[07:48] <jscinoz> nxvl, yes but its far slower than cowbuilder due to the extracting of the base tarball each build
[07:48]  * nxvl loves pbuilder
[07:48] <RAOF> sbuild-on-lvm FTW!
[07:48] <jscinoz> cowbuilder is still prettymuch pbuilder just cow directory rather than tarball
[07:49] <jscinoz> but any ideas why they seem to ebe sharing a common /var/lock?
[07:50] <nxvl> dholbach: actually i don't think the process isn't good, just that can be better, and i'm thinking on ways to improve it
[08:05] <jscinoz> hmm
[08:05] <jscinoz> anyone else notice that /var/lock is mounted on tmpfs while in a chroot (cowbuilder), causing breakage when using multiple cowbuilders at once?
[08:06] <StevenK> /var/lock and /var/run have been tmpfses since Feisty.
[08:09] <jscinoz> does that behaviour break pbuilder/cowbuilder for anyone other than me then?
[08:09] <StevenK> I don't recall it breaking pbuilder.
[08:11] <jscinoz> basically because it seems /var/lock is common amoungst all chroots, multiple simultaneous builds fail with DPKG administrator directory locked
[08:11] <jscinoz> when trying to satsify build depends
[08:18] <TheMuso> ?c
[09:32] <huats> morning everyone
[09:41] <gnomefreak> doko: did you merge fontconfig?
[10:18] <sistpoty|work> hi folks
[10:18] <Iulian> Heya sistpoty
[10:19] <sistpoty|work> hi Iulian
[13:23] <norsetto> cheerio
[13:23] <geser> Hi norsetto
[13:24] <norsetto> hi geser
[13:29] <huats> hey norsetto and geser
[13:30] <huats> norsetto: dont you should have sent me an email about the mentoring :) ?
[13:30] <norsetto> huats \!*
[13:31] <huats> norsetto: !!
[13:31] <norsetto> huats: its ready to go, will send it around 1700
[13:31] <huats> norsetto: take your time for the mail, but don't forget it !
[13:31] <huats> ;)
[13:31] <huats> no pb
[13:31] <geser> Hi huats
[13:32] <norsetto> huats: would you be available to have a chat tonight? Anytime between 2200 and 0100 ?
[13:33] <huats> norsetto: not realy sure
[13:33] <huats> norsetto: can I confirm that later ?
[13:33] <norsetto> huats: ok, let me know when you see my email
[13:33] <huats> sure
[14:05] <PMantis> ﻿Does anyone have a URL they can give me stating that deb packages are typically built to install to (for example) /usr/sbin instead of /usr/local/sbin ?
[14:08] <directhex> http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1
[14:57] <superm1> could someone take a look at this debian/control and tell me why it's even getting attempted to be built on anything that is not i386,lpia,or amd64? http://paste.ubuntu.com/23307/
[14:58] <superm1> i get mail about it FTBFS on these other platforms, but both binary packages shouldn't be touched on them
[15:00] <directhex> superm1, can i see a failed build log?
[15:01] <superm1> http://launchpadlibrarian.net/15644065/buildlog_ubuntu-intrepid-sparc.coreavc_0.1~svn65-0ubuntu2_FAILEDTOBUILD.txt.gz
[15:02] <sistpoty|work> superm1: afaict that's normal... architecture in debian/control will just cause a FTBFS on architectures not in there
[15:02] <superm1> sistpoty|work, well how can i keep it from building on those other arch's then?
[15:02] <sistpoty|work> superm1: iirc the only way that the package won't get attempted to build is via p-a-s
[15:02] <superm1> what's p-a-s?
[15:02] <superm1> soyuz thing?
[15:02] <superm1> like a soyuz override
[15:03] <sistpoty|work> superm1: not really, it's package-arch-specific shared by debian and ubuntu, ask lamont or elmo for details ;)
[15:03] <sistpoty|work> (and yes, it's a override database)
[15:03] <sebner> hiuhu sistpoty|work
[15:03] <sistpoty|work> hi sebner
[15:03] <directhex> superm1, your standards-version needs updating while you're at it
[15:04] <superm1> directhex, not if its based on an old standards and will be backported
[15:04] <superm1> :)
[15:04] <directhex> yay, backports are a world of fun
[15:04] <superm1> sistpoty|work, well i'll ask elmo about details when he's around.  for getting this solved though, should i just file a bug and subscribe ubuntu-archive then?
[15:05] <superm1> to tell them to override it
[15:05] <sistpoty|work> superm1: iirc the right thing is to mail elmo and lamont (and there's a third person in p-a-s, I just forgot who)
[15:06] <sistpoty|work> \sh: didn't you recently ask for an updated entry in p-a-s and hence know the procedure?
[15:07] <directhex> i see nothing wrong with the control file, so it must be something silly, such as sistpoty|work's suggestion
[15:08] <\sh> sistpoty|work: yes..ask lamont,elmo or infinity
[15:09] <sistpoty|work> \sh: a, thx... superm1 ^^
[15:09] <directhex> so why does LP ignore the Architecture line?
[15:10] <directhex> i mean, isn't the entire effing point of it so you don't need some kind of magic override database with the same goddamn info in it?
[15:10] <superm1> thanks \sh
[15:10] <sistpoty|work> directhex: it doesn't ignore it, it does the right thing, which is to fail the build
[15:11] <directhex> sistpoty|work, it's intentional! if it was meant to attempt to build on that arch, then it'd be listed in Architecture!
[15:11] <sistpoty|work> directhex: the p-a-s layer exists mainly to ease porting, and because maintainers are often wrong in regards to architecture
[15:12] <Hobbsee> superm1: u-a can't do anything about overrides, last i knew.
[15:12] <Hobbsee> it's only lamont / infinity / elmo iirc.
[15:12] <superm1> okay :)
[15:14] <directhex> sistpoty|work, if it's to ease porting, then it's implemented wrong - it should either assume the packager isn't thick (and allow the porters to override on a per-package basis) or assume the packager isn't thick, and only bother the porters with FTBFS issues (because nobody wants to see mess caused by trying to build obviously i386-only junk on hppa)
[15:15] <geser> superm1: http://cvs.debian.org/srcdep/Packages-arch-specific?root=dak&view=markup is the current P-a-s list used both by Debian and Ubuntu
[15:15]  * directhex grumbles
[15:16] <superm1> surely its not identical in both.  we have packages not present in debian
[15:16] <sistpoty|work> directhex: well, p-a-s is just an override on a per-package basis (everything that's not in there imo takes the values from the architecture field)... that the uploader gets the ftbfs mails is a different question though, and nothing debian specific ;)
[15:17] <geser> sistpoty|work: isn't the default that it's given to every buildd and will fail later because of the Architecture line?
[15:17] <sistpoty|work> geser: not too sure actually, that at least happens *if* there's s.th. in p-a-s
[15:17] <sistpoty|work> geser: however that may be true as well
[15:19] <sistpoty|work> geser: oh, indeed, since coreavc is not in p-a-s
[15:19] <persia> superm1: It is identical for both distributions.  Perhaps eventually Soyuz will move away from P-a-s, and use the extracted information from the architecture field, but it isn't so implemented yet.
[15:21] <superm1> persia, so that means if elmo/infinity/lamont fix it, they will be adding this override in debian for a package that (currently and possibly never) isn't present there?
[15:22] <persia> superm1: Precisely.  The reason it is those three people is because of the role they have in Debian.  The fact that it matters for Ubuntu is only accidental.
[15:22] <superm1> geez.  that makes more sense why ~ubuntu-archive cant touch it then
[15:24] <persia> Yep.  I heard once that the long-term goal was not to use P-a-s, but that it was leftovers from dak, which is why it is that way.  If such a plan isn't in place, it likely makes more sense to branch P-a-s for administration by buildd-admins.
[15:41] <vhaarr> Hey, the latest audacious (1.5.1-1ubuntu1) segfaults on launch -- should I file a bug or is it enough to mention it here?
[15:42] <vhaarr> if I start it from a terminal I just get a message saying "Segmentation fault" and no stacktrace or anything.
[15:42] <james_w> vhaarr: please file a bug
[15:42] <vhaarr> james_w: any other details I can provoke somehow, or logs that I should include?
[15:42] <james_w> https://wiki.ubuntu.com/DebuggingProgramCrash
[15:42] <vhaarr> right
[15:42] <james_w> https://wiki.ubuntu.com/Backtrace
[15:43] <james_w> those pages should help you provide information about the segfault.
[15:43] <james_w> also, you should look in /var/crash to see if you have any audacious crash files
[15:43] <james_w> if you do then running "apport-cli -c <file>" on one will file a bug using apport which may be easier than getting the backtrace yourself.
[15:45] <vhaarr> james_w: actually I dont have apport installed, would that make it easier to generate a backtrace in the first place? If I install apport and try to run audacious again, I mean.
[15:45] <vhaarr> there are no logs in /var/crash
[15:45] <james_w> there won't be if apport isn't installed
[15:46] <james_w> it may be easier to install it and use that, I don't know.
[15:46] <vhaarr> I am not sure how apport works, does it use some sort of kernel hooks? Perhaps I would have to restart for it to work after installing.
[15:46] <vhaarr> I'll try
[15:53] <vhaarr> ah, heh, someone reported the same bug 3 minutes ago :p
[15:53] <vhaarr> https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/243539
[15:53] <vhaarr> I was just about to file it
[15:54] <persia> I'd really like to see a full apport trace for that: the supplied trace has missing symbols.
[15:55] <vhaarr> the trace I generated with gdb is exactly the same as in the report already
[15:55] <vhaarr> I installed apport, but it does not provide any dialog when I reproduce the segfault
[15:56] <vhaarr> (or any log in /var/crash)
[15:56] <persia> Frame #2 in threads 1 & 3 has no symbol?
[15:56] <persia> (and we should probably take this to #ubuntu-bugs)
[16:34] <k0p> !help
[16:35] <k0p> someone can help me to re-sync my key to upload on revu?
[16:37] <sistpoty|work> k0p: sure, give me a minute
[16:38] <k0p> ok. :) thanks
[16:40] <sistpoty|work> k0p: hm... are you a member of the group revu-uploaders on launchpad?
[16:41] <sistpoty|work> k0p: nevermind, found you already
[16:42] <k0p> sistpoty|work, yeap. I make a upload to revu. But I don't have sucessful. I forget ask to re-sync.
[16:43] <sistpoty|work> k0p: good. resync will be completed in a few minutes. I'll then put back your upload, so it should show up with in the next 10 minutes
[16:44] <k0p> sistpoty|work, so.. I need re-upload files?
[16:44] <sistpoty|work> k0p: no, you don't... the files are all still there, just in the rejected queue, but I'll free them ;)
[16:45] <k0p> oh thanks for spot files. sorry mistakes :)
[16:46] <sistpoty|work> k0p: no problem
[16:54] <Laibsch> Hi
[16:54] <Laibsch> I am trying to build a package from bzr. I have put debian/ into a separate bazaar branch, too.  debuild now complains about the debian/.bzr/ directory and binary, unrepresentable changes in there.  How can I get debuild to ignore that directory?
[16:55] <ember> Laibsch try debuild -i.bzr
[16:59] <Laibsch> looking good
[17:00] <Laibsch> Thanks, just what I needed.  I wonder why that is not mentioned in the man-page
[17:01] <sistpoty|work> Laibsch: debuild passes the parameters to dpkg-buildpackage, which in turn passes them to dpkg-source (when a source package should get built)
[17:01] <sistpoty|work> Laibsch: hence you can find it in the one of those man pages
[17:02] <Laibsch> Ah, yes right
[17:02] <Laibsch> I got bitten by that before (looking for stuff in the debuild man-page when it was an option for one of the scripts it called)
[17:11] <norsetto> hmmmm, how de we reserve channels for meetings? The fridge!?
[17:14] <sistpoty|work> norsetto: ubuntu-news-team list (cf. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-June/000428.html)
[17:16] <norsetto> thanks super-master sistpoty|work (even though I still have to find how to actually do the bloody thing)
[17:18] <sistpoty|work> norsetto: you mean how to register a meeting?
[17:18] <norsetto> sistpoty|work: yes, how to check if the room is available and book it
[17:18] <sistpoty|work> norsetto: that's a good question... it used to be on http://fridge.ubuntu.com/event (but that doesn't display anything for me atm.)
[17:19] <norsetto> sistpoty|work: neither for me, so, at least I'm not blinder than usual
[17:19] <sistpoty|work> heh
[17:20] <persia> norsetto: If your meeting is soon, the #ubuntu-meeting topic can be a good guide for room availability.  If you want #ubuntu-classroom, talk to james_w or pleia
[17:23] <norsetto> persia: OK, I set it through the topic, thx
[17:27] <persia> norsetto: You really want to set it by sending a note to the ubuntu-news-team, as the bot will overwrite your /topic update at the time of the next meeting.
[17:27] <persia> I only meant to suggest that reading the /topic was an alternate mechanism to get the list of events whilst that fridge page was blank.
[17:28] <norsetto> persia: well, never mind, as long as the room is free I'm happy
[17:32] <persia> norsetto: It's usually free around that time, but I still encourage you to send a quick email, just in case :)
[17:44] <porthose> norsetto: 20:00 UTC in #ubuntu-meeting for the mentoring reception meeting sounds good, will be there :)
[17:44] <norsetto> porthose: cool
[17:44]  * DktrKranz kicks at himself for bogus twisted-calendarserver upload :/
[17:45]  * norsetto didn't know that totem could use mplayer as the backend
[18:07] <porthose> norsetto:  I have emailed everyone on the "status" list, requesting an update. :)
[18:10] <pochu> hi all!
[18:10] <sistpoty|work> hi pochu
[18:12] <pochu> hey sistpoty|work
[18:19]  * sistpoty|work needs to head home, cya
[18:39] <Technoviking> how do I create a .dsc file for a new pakage
[18:39] <azeem> dpkg-source does tat
[18:39] <azeem> that*
[18:43] <directhex> debuild -S -sa?
[18:43] <Technoviking> azeem: is there a guide to dpkg-source somewhere
[18:43] <azeem> there's the manpage
[18:43] <azeem> but probably using debuild or dpkg-buildpackage -S is better
[18:44] <Technoviking> how do I get past gpg: [stdin]: clearsign failed: secret key not available
[18:44] <RainCT> Technoviking: what are you using, debuild?
[18:44] <Technoviking> RainCT: yes
[18:45] <RainCT> Technoviking: debuild -S -sa -k<your email address>
[18:45] <RainCT> or use  dch  to sign the last changelog entry with your name and email
[18:46] <RainCT> (supposing that you have a GPG address and the variables DEBFULLNAME and DEBEMAIL are exported)
[18:47] <norsetto> porthose: thanks
[18:47] <porthose> norsetto: np
[18:48] <Technoviking> doing  debuild -S -sa -kmike.basiner@ubuntu.com
[18:49] <Technoviking> still get error, gpg is setup on this machine
[18:49] <RainCT> Technoviking: and you have a GPG key for e-mail address mike.basiner@ubuntu.com?
[18:49] <RainCT> (on your machine)
[18:49] <Technoviking> RainCT: yup
[18:51] <RainCT> Technoviking: isn't there a 'g' missing?
[18:51] <Technoviking> needed key and not e-mail
[18:51] <RainCT> Technoviking: ie, basinger and not basiner
[18:51] <Technoviking> mistyped in irc, was ok in terminal
[18:52] <RainCT> ah
[18:52] <RainCT> it should work with the e-mail then... :S
[18:53] <Technoviking> e-mail work not after using gpg key
[18:53] <Technoviking> must have a gpg problem somewhere
[18:54] <Technoviking> lets see if pbuilder will work now
[18:59] <Laibsch> Oops, sorry
[19:00] <Laibsch> Wrong window
[19:00] <Laibsch> Can somebody please change that back?
[19:00] <Laibsch> Done
[19:41] <sistpoty> hi folks
[19:41] <norsetto> sistpoty: who are you?
[19:42] <norsetto> sistpoty: hmmm, I guess you are the poorer brother of sistpoty|work
[19:42] <sistpoty> norsetto: yes... imagine sistpoty|work in the evening, with a beer at hand *g*
[19:43] <norsetto> sistpoty: cheers :-)
[19:43] <sistpoty> cheers :)
[19:51] <grimko> hi all, I'm very new to this but I'd like to create a program that would warn the user if disk space runs low
[19:53] <grimko> I've already made daemons in Perl or bash, and the idea would be to send a message to the notification area (that's just for a quick start)
[19:54] <johanbr> grimko: That already exists, I think it's part of gnome-volume-manager.
[19:54] <grimko> the problem is that I got no idea how to send a message to this notification area :)
[19:54] <grimko> volume ?
[19:55] <grimko> johanbr, not in hardy in my opinion
[19:55] <johanbr> It's there. See /usr/share/doc/gnome-volume-manager/changelog.Debian.gz
[19:56] <grimko> ok, I'll have a look thx
[19:57] <ScottK> sistpoty: Did you have a chance to have a look at nxvl's packaging of augeaus yet?  It's got some library stuff in it, so I suggested to him it'd be good for you to have a look.
[19:57] <ogra> grimko, beyond that the libnotify-bin package has a binary called notify-send that you can use from scripts
[19:58] <grimko> thx ogra, I'll take a look there too :) do you know if the low space running notification exists somewhere ?
[19:58] <ogra> i did, i didnt run out of space in hardy yet :)
[19:58] <ogra> *it did
[19:59] <sistpoty> ScottK: no, not yet... is it on revu?
[19:59] <ogra> i'm not sure about the current satatus though
[19:59] <ScottK> Yes.  I think I may have spelled it wrong though.
[19:59] <ScottK> Just a moment.
[19:59] <ScottK> sistpoty: http://revu.ubuntuwire.com/details.py?package=augeas
[20:00] <sistpoty> thanks ScottK, will take a look
[20:00] <ScottK> Great.
[20:08] <pgib> hello ubuntu-motu fellows.  I am not an Ubuntu user myself, but I am a developer of the application LMMS.  lmms.sf.net.  The package is already in universe.  We are about to release an alpha of the next major version.
[20:09] <pgib> How do I get in touch with the correct maintainer so we can make sure the next version will be properly supported by Ubuntu?  Thanks!
[20:11] <pgib> I looked around on the motu pages, but.. it doesn't seem to be helpful for me
[20:11] <norsetto> pgib: we merge lmms from Debian, therefore if you get it there we will eventually get it too
[20:12] <pgib> norsetto: OK. that makes sense.  I guess there is a schedule saying when the last merge will be before intrepid?
[20:13] <porthose> pgib: https://wiki.ubuntu.com/IntrepidReleaseSchedule
[20:13] <pgib> OK. thanks for all your help
[20:14] <norsetto> pgib: we are free to merge before freeze, after that you need an exception
[20:14] <pgib> Ah yesturday... we missed it
[20:14] <tacone> not that freeze I guess
[20:14] <norsetto> pgib: no, feature freeze on August 18th
[20:15] <pgib> June 26th: Debian import freeze
[20:15] <tacone> pgib: follow the link to know what it means :)
[20:15] <pgib> yeah I'm waiting.. the page is slow
[20:16] <pgib> OK makes sense.
[20:16] <sistpoty> oh, that reminds me that I wanted to write a mail due to DIF
[20:16] <pgib> So do I just need to bother you guys again once we have the new version in Debian?
[20:16] <norsetto> sistpoty: you can't write mail after DIF
[20:16] <norsetto> pgib: please do, we accept all currencies
[20:17] <sistpoty> norsetto: hm... I guess I didn't dist-upgrade to a post DIF state :P
[20:17] <norsetto> pgib: and major credit cards
[20:17] <pgib> lol. ok :)
[20:18] <pgib> thanks for clarifying everything for me.  You should see me around in a few weeks once the package has sat in Debian for a little while
[20:18] <getaceres> hello
[20:18] <pgib> greetings
[20:19] <norsetto> pgib: see you
[20:19] <getaceres> I'm trying to make a package but I have a problem trying to set the version
[20:20] <getaceres> I need it to be 1:3.1-1 but dh_make fails if I try to use that directory name (package_name-1:3.1)
[20:20] <getaceres> how can I force the version number (if possible using dh_make)
[20:20] <azeem> why the 1:?
[20:21] <getaceres> I want to update an Ubuntu package that has this number in the version
[20:21] <getaceres> it's at the version 1:3.0.2
[20:21] <azeem> ok, so why do you use dh_make?
[20:22] <azeem> dh_make isn't for updating, AFAIK
[20:22] <azeem> maybe look into uupdate
[20:22] <getaceres> because the sources are not debianized and Ubuntu packagers haven't updated the source package to version 3.1 yet
[20:23] <getaceres> so I cannot use the sources from the original
[20:23] <azeem> that's what uupdate is for
[20:24] <azeem> or just copy over the debian/ directory, run dch -i, and change the version number accordingly or something
[20:25] <getaceres> ok, I'll try, thanks
[20:41] <james_w> I have a package here that does "ln -s /usr/bin/foo debian/bar/usr/lib/bar/foo"
[20:41] <james_w> does that shake out to do the right thing in the binary package?
[20:47] <james_w> yes, it does apparently. It just didn't look right.
[20:47] <james_w> by right thing I meant have "/usr/lib/bar/foo -> /usr/bin/foo" in the binary package.
[20:47] <sistpoty> james_w: if /usr/bin/foo is in the depends of the package the link looks good... however the harder question is: why would you want to do such a link?
[20:47] <james_w> sistpoty: ah, all the files are in the same package.
[20:48] <james_w> I was just worried that it might get confused due to the absolute target.
[20:48] <sistpoty> james_w: but then it still doesn't make sense to me imho
[20:48] <james_w> a "cp" would obviously be wrong.
[20:49] <james_w> I think the code is there for compatibility, "foo" moved to /usr/bin, but this makes sure you can still call /usr/lib/bar/foo
[20:49] <sistpoty> but /usr/lib/bar/foo is not meant to be called directly. Do any depends call it?
[20:50] <sistpoty> (or was it an error in the first place, and should have been in /usr/bin all the time, and scripts might rely on it?)
[20:50] <sistpoty> s/depends/rdepends/ btw ;)
[20:51] <james_w> not sure I'm afraid, I'm not familiar with the package, it just caught my eye, so I wanted to check.
[20:51] <sistpoty> james_w: yeah... good catch :)
[20:52] <james_w> thanks for the help
[20:53] <sistpoty> np
[20:53] <huats> norsetto: there I am
[21:01] <getaceres> thank you for your help. It worked, now I have my package updated
[21:07] <DRebellion> Would somebody mind giving my package a review? http://revu.tauware.de/details.py?package=monkeystudio Thanks ;)
[21:09] <sistpoty> ScottK: finally commented on nxvl's package
[21:10] <ScottK> sistpoty: Thanks.  I haven't had a chance to look at it yet, but it looks like an interesting idea.  I'm glad he's working on it.
[21:11]  * sistpoty must admit that he doesn't look at packages on REVU because he thinks them useful... at least most of the time :)
[21:11] <ScottK> I don't normally hunt down reviewers without a good reason.
[21:12] <sistpoty> heh :)
[21:15] <norsetto> huats, porthose: hi guys sorry for the delay
[21:16] <huats> norsetto: no pb
[21:16] <huats> we are in meeting
[21:16] <huats> I mean ubuntu-meeting
[21:16] <huats> nxvl is not here yet
[21:17] <norsetto> huats: I think porthose left already?
[21:17] <huats> nope
[21:25] <pochu> do .xpm icons need to call dh_icons?
[21:27] <sistpoty> pochu: no idea, but I guess they should (otoh an icon cache should find newly added icons by itself, but that's not up for discussion *g*)
[21:28] <huats> raphink: are you around ?
[21:29] <huats> slomo__: are you around too ?
[21:29] <pochu> sistpoty: ok, it won't hurt adding it if they don't anyway :)
[21:30] <pochu> emgent: I'll call dh_icons in debian/rules and sponsor it, if you are OK ^
[21:32] <emgent> ok nice
[21:32] <emgent> but if i remember well it`snt necessary
[21:32] <pochu> emgent: and build-depend on debhelper >= 5.0.51~ for it, that's fine for backporting to hardy, right?
[21:32] <emgent> pochu: yes, backported in my PPA for test and work fine
[21:33] <pochu> I mean, hardy's debhelper is >= 5.0.51, right?
[21:33] <pochu> let me see
[21:34] <pochu> yes, that's fine for gutsy too
[21:34] <pochu> ok, uploading
[21:34] <emgent> yes
[21:34] <emgent> thanks pochu
[21:34]  * sistpoty will be right back after a reboot
[21:38] <emgent> hi no0tic :)
[21:38] <no0tic> hi emgent
[21:39] <jpds> evening no0tic
[21:39] <no0tic> hi jpds :)
[21:46] <sistpoty> hm.. things to not write on irc when on intrepid: "brb after reboot" *g* (epic fail!)
[22:20] <ffm> is it too late to submit a package for intrepid?
[22:20] <ScottK> No.
[22:20] <ffm> ScottK: How long do I have?
[22:24] <sistpoty> ffm: until FeatureFreeze (see wiki.ubuntu.com/IntrepidReleaseSchedule)
[22:24] <pgib> August 28th I think
[22:24] <pgib> I just asked the same question :)
[22:25] <ffm> sistpoty: merci.
[22:25] <sistpoty> ffm: de rien ;) (which is the only french I know *g*)
[22:40] <aib> what can I do to help push a package that is currently in Debian's unstable branch into the next release of Ubuntu?
[22:42] <aib> specifically, I am interested in the Debian unstable package libsoqt4-20. This is an SoQt thats linked against Qt-4, whereas the SoQt currently in Ubuntu is linked against Qt-3. Here's the url: http://packages.debian.org/unstable/libsoqt4-20
[22:44] <RoAkSoAx> aib, i believe libsoqt4-20 is already in the Intrepid repos: http://packages.ubuntu.com/search?suite=intrepid&section=all&arch=any&searchon=names&keywords=libsoqt4-20
[22:45] <aib> Nice.
[22:45] <aib> that saves me a lot of work ^_^
[23:04] <sistpoty> hm... /me is about to step motu-release on the feet: http://paste.ubuntu.com/23375/
[23:08]  * sistpoty decides to step people on the feet
[23:14] <ScottK> sistpoty: Thanks.  What I most want from motu-release this time is to not feel like it'll all fall apart if I get distracted, so thank you for stepping up.
[23:20] <sistpoty> ScottK: not too sure if I did the right thing... but I think pointing out what went wrong is important, even if it hurts ppl.
[23:21] <ScottK> I agree.  We'll see how it goes.
[23:22] <sistpoty> hm.. /me has another entity to step on the feet.
[23:41] <sistpoty> lol, that's so funny, while digging to find the "MC must vote after 12 days", I've seen so far ScottK's *motu* application and nixternal's
[23:42] <sistpoty> damn, who else did I process back then *g*
[23:42] <sistpoty> superm1: for sure ;)
[23:44] <mario_limonciell> 12 days.  ha
[23:45] <mario_limonciell> i think my app was open what like 100 days?
[23:47] <sistpoty> mario_limonciell: at least that's what I thought, that MC came to this conclusion once... but mail-archive doesn't really support my memory ;)
[23:47] <mario_limonciell> i thought i remembered reading  that too though
[23:47] <mario_limonciell> and thinking to myself, oh this app will be closed out since no one responded in 12 days
[23:50] <Laney> Can I kindly ask a backporter to look at and hopefully ACK bug #226587 please? :)