[00:01] <pochu> RoAkSoAx: in the GNU make documentation
[00:01] <pochu> RoAkSoAx: (it's somewhat like a grep)
[00:01] <pochu> see 7.3 in the make info manual
[00:01] <pochu> package make-doc
[00:01] <RoAkSoAx> pochu, awesome thanks :)
[00:04] <RoAkSoAx> pochu, what if for example a Makefile has this: ifneq (0,$(HAVE_NL))\n  CFLAGS  += -DLIBIPVS_USE_NL\n   endif. How can I do something similar in debian/rules?
[00:06] <pochu> RoAkSoAx: just copy it :)
[00:06] <pochu> but don't tabulate it
[00:07] <pochu> (the ifneq and endif, the lines in between may have tabs or spaces if you wish)
[00:08] <RoAkSoAx> pochu, ok cool thanks :)
[00:08] <pochu> yw
[00:15] <RoAkSoAx> pochu, and how about specifying different CFLAGS for different Makefile's in the same app. For ex. I have a Makefile in the root of the source directory, and another Makefile in libipvs/Makefile. the Makefile in the root requires just -g and the one in libipvs/Makefile requires -fPIC ? How to do that in debian/rules?
[00:18] <Zhenech> bdrung_, ping :)
[00:18] <bdrung_> Zhenech: pong
[00:19] <bdrung_> Zhenech: thats faster
[00:19] <Zhenech> ah, you're on, fine
[00:19] <Zhenech> saw my mail?
[00:19] <bdrung_> yes, i was currently writing the response
[00:19] <bdrung_> your mail ending "grüße". are you German?
[00:19] <Zhenech> heh, I thought "wait, he has an @ubuntu mail, he is for sure in #motu
[00:20] <Zhenech> yes, you even wrote me mails in german already :P
[00:20] <bdrung_> Zhenech: i am in some debian channels, too.
[00:20] <bdrung_> Zhenech: too many people.
[00:20] <Zhenech> aye, I know that :)
[00:20] <bdrung_> and my brain can't remember names
[00:21] <Zhenech> and my name does not suggest I can speak german :)
[00:21] <bdrung_> german parents?
[00:22] <Zhenech> nope, just living here :)
[00:22] <bdrung_> ;)
[00:22] <bdrung_> so now to the bugs: 536582
[00:23] <bdrung_> also https://bugs.launchpad.net/ubuntu/+source/shiki-colors-murrine/+bug/399457
[00:24] <bdrung_> Zhenech: the problem is that the index files defining complete themes, so that the packages needs to depend on the shiki-metacity package.
[00:25] <bdrung_> Zhenech: what do you think? how should the problem resolved?
[00:25] <Zhenech> well, I run xfce  here
[00:26] <Zhenech> just kicked metacity from the system
[00:26] <Zhenech> and the themes still looked as they should
[00:27] <Zhenech> so I'd prolly do Depends => Recommends and stuck with it
[00:27] <bdrung_> moving metacity from depends to recommends?
[00:27] <Zhenech> yes
[00:28] <bdrung_> ok
[00:28] <Zhenech> do you have a xfce setup to test it somewhere? so you can be sure it works as expected without metacity?
[00:28] <bdrung_> should shiki-colors add the xfce package to recommends or suggest?
[00:29] <bdrung_> Zhenech: i had tested it with xubuntu.
[00:29] <Zhenech> xubuntu should be fine
[00:30] <bdrung_> for xfce you can drop the shiki-metacity package. only when you have gnome installed the theme will be broken without the shiki-metacity package.
[00:30] <bdrung_> i have crashed my debian image.
[00:31] <bdrung_> currently i am reinstalling it.
[00:31] <Zhenech> well
[00:31] <bdrung_> but there i have gnome installed.
[00:31] <bdrung_> maybe i should setup a xfce version, too.
[00:31] <bdrung_> should shiki-colors add the xfce package to recommends or suggest?
[00:32] <Zhenech> the shiki colors meta package? not at all imho
[00:32] <bdrung_> yes
[00:33] <Zhenech> you say shiki-foo-theme can't live without the shiki-colors-metacity-theme in xfce too?
[00:33] <bdrung_> no, it makes only problems if you have gnome installed, too. if you only use xfce it would be possible to drop shiki-colors-metacity-theme
[00:34] <bdrung_> have a look at the shiki-foo/index.theme files.
[00:34] <bdrung_> there is a MetacityTheme specified.
[00:35] <Zhenech> then I'd say depends: shiki-colors-metacity-theme | shiki-colors-xfce-theme on all skiki-foo-theme packages and let the metacity depends
[00:35] <Zhenech> making it clear we need metacity when we want to use the metacity theme, but only then?
[00:37] <bdrung_> there is only one problem: if you have gnome and xfce installed and you only install shiki-colors-xfce-theme. then the GNOME-Metatheme is broken.
[00:37] <Zhenech> aye
[00:38] <bdrung_> aye?
[00:38] <Zhenech> i know, thats a "general" problem with the deb depends format
[00:38] <Zhenech> aye = yes
[00:39] <Zhenech> i think that is something the use should be able to handle himself
[00:40] <bdrung_> ok
[00:43] <bdrung_> Zhenech: next: broken selection. i talked with victor. he want a screenshot, so i wrote a response.
[00:44] <bdrung_> Zhenech: next: 536480 gnome-*-icon-theme overrides my start-here icon (Debian swirl): i made some changes upstream, so the patch will get shorter. can i wait for integrating the patch for the next upstream release?
[00:44] <Zhenech> sure
[00:44] <Zhenech> please give a short msg to the bug, saing you are working with upstream on this
[00:44] <Zhenech> :)
[00:45] <bdrung_> Zhenech: k
[00:45] <bdrung_> Zhenech: so only shiki will be changed.
[00:45] <bdrung_> are there other issues for gnome- or arc-?
[00:46] <Zhenech> none I have seen yet
[00:46] <Zhenech> just finished build
[00:46] <Zhenech> installing and testing :)
[00:47] <Zhenech> haha
[00:47] <Zhenech> minimal
[00:47] <Zhenech> Shiki-Wine is displayed Shiki-Wine in my Xfce setup :)
[00:47] <Zhenech> ew
[00:47] <Zhenech> Shiki-wine
[00:47] <Zhenech> (small w)
[00:48] <bdrung_> hm
[00:48] <bdrung_> where does xfce get the name?
[00:48] <Zhenech> typo somewhere, no blocker for the upload :P
[00:48] <Zhenech> shiki-colors-murrine-4.4 % grep -r Shiki-wine .
[00:48] <Zhenech> ./Shiki-Wine/index.theme:Name=Shiki-wine
[00:48] <Zhenech> guess here? :)
[00:49] <bdrung_> ok, this will be fixed upstream with the next release
[00:50] <Zhenech> fine
[00:50] <Zhenech> then give me fixed shiki and I upload
[00:50] <Zhenech> but not tonight anymore, my dsl here at home is crappy at best
[00:50] <Zhenech> either tomorrow from work
[00:50] <bdrung_> aaah, too many windows and tabs
[00:50] <Zhenech> or monday from university :)
[00:51] <maxb> How do you do quilt with dh7 if you want it to work with pre-karmic debhelper?
[00:51] <bdrung_> university?
[00:51] <Zhenech> maxb, include quilt.make and depend in the patch target?
[00:51] <Zhenech> bdrung_, uni duesseldorf
[00:52] <bdrung_> düsseldorf?
[00:52] <Zhenech> yes
[00:52]  * bdrung_ starts google map. :)
[00:52] <Zhenech> what, you dont know where it is?
[00:53] <Zhenech> dont tell me you know cologne but not ddorf...
[00:54] <bdrung_> i know the names, but i have no clue where they lie
[00:55] <bdrung_> i am not good in geography.
[00:55] <Zhenech> meh, I mean, I know where berlin is :P
[00:55] <bdrung_> i, too. ;)
[00:56] <bdrung_> i only know something about very near locations and very far locations (galaxy).
[00:56] <Zhenech> mh, that dust theme... it looks more like rust, not dust, I expected it to be grey :(
[00:57] <jpds> Dark Room is by far the best.
[00:57] <bdrung_> Zhenech: the dust icon theme fits perfectly with the dust theme.

[00:57] <bdrung_> Zhenech: do you know where mühlacker is?
[00:58] <Zhenech> bdrung_, is mühlacker a city with more than 500k citizens a the capital of one of the german "bundesländer"?
[00:58] <Zhenech> :)
[00:58] <bdrung_> Zhenech: no, it's the city i am born.
[00:59] <Zhenech> but no, I dont know :)
[00:59]  * Zhenech is born a bit more on the east (kiew)
[00:59] <bdrung_> it's in bw
[00:59] <Zhenech> in baden or in schwaben? :)
[01:01] <bdrung_> schwaben
[01:01] <bdrung_> commit message: "shiki-*-theme: Depend on either the Metacity or the Xfwm theme." <-- good?
[01:01] <Zhenech> kk, my gf is from baden :)
[01:02] <Zhenech> lemme see the commit, but I guess it is :)
[01:02] <Zhenech> Internal Server Error
[01:02] <Zhenech> \o/
[01:04] <Zhenech> mhh,  bazaar.lp.net fails on me, code.lp.net works
[01:05] <bdrung_> "bzr branch lp:shiki-colors-pkg" is the shortest
[01:05] <lifeless> Zhenech: fails how?
[01:05] <bdrung_> Zhenech: it's up now.
[01:06] <Zhenech> lifeless, fails as in gives me internal server error when accessing via web
[01:06] <lifeless> pop into #launchpad if that happens
[01:06] <Zhenech> oook, whatever that was, works here now too
[01:06] <bdrung_> Zhenech: how long did you need to build gnome-colors?
[01:14] <bdrung_> Zhenech: shiki updated. now testing
[01:14] <Zhenech> oke, smoking and going to bed
[01:15] <Zhenech> mail me a short notice you updated the stuff and I upload
[01:15] <bdrung_> do i need to upload the package to mentors, or can you build the package from the bzr branch?
[01:15] <Zhenech> mentors pleas
[01:15] <Zhenech> I have no clue about bzr
[01:15] <bdrung_> ok
[01:16] <bdrung_> for our branches: simple run "uscan --force; bzr bd"
[01:16] <bdrung_> then you have the binary packages.
[01:16] <Zhenech> first I'd need to install bzr :)
[01:17] <lifeless> Zhenech: thats pretty easy to do
[01:18] <bdrung_> Zhenech: bzr is simple (nearly like svn).
[01:18] <bdrung_> git is faster, but complex
[01:19] <Zhenech> well, I use svn and git for my stuff
[01:19] <Zhenech> and maybe I find some time to look at bzr in the future, but for now a .tar.gz is preferred :)
[01:19] <Zhenech> anyways, going to bed now
[01:20] <bdrung_> Zhenech: you will get the mail
[01:20] <Zhenech> thanks
[01:21] <Zhenech> n8 :)
[01:21] <bdrung_> Zhenech: do you know why http://packages.qa.debian.org/g/gnome-colors.html is not correct?
[01:21] <bdrung_> gn8
[04:21] <woohoo> hi, can one of you help me with a script?
[04:21] <micahg> woohoo: just post your question
[04:22] <woohoo> I need to know a command where i can add a APT line to sources.list
[04:22] <woohoo> Like something that can echo into a document really
[04:24] <woohoo> micahg, you know what i mean?
[04:25] <micahg> well
[04:25] <micahg> do you already have the apt line and you want to put it somewhere
[04:25] <micahg> or are you building hte apt line?
[04:25] <woohoo> micahg, yeah, it, i just need a command to add it to sources.list
[04:27] <micahg> woohoo: http://stackoverflow.com/questions/850730/how-can-i-append-text-to-etc-apt-sources-list-from-the-command-line
[04:28] <woohoo> k thanx. This helps a lot.
[04:30] <woohoo> micahg, is there a command to check if you're root?
[04:30] <micahg> whoami?
[04:30] <woohoo> i mean, for the script to stop micahg if it is not root
[04:30] <micahg> check the return of whoami?
[04:31] <woohoo> lol, nevermind
[04:31] <micahg> why would you do that
[04:31] <micahg> oh
[04:31] <micahg> I see
[04:31] <micahg> otherwise you need a passwd for sudo
[04:32] <micahg> you can check the effective user id
[04:32] <micahg> I don't remember offhand how to do that
[04:32] <ajmitch> id -u
[04:32] <micahg> there you go :)
[04:32] <micahg> thanks ajmitch
[04:33] <woohoo> micahg, Ill tell you when I am done making it. 1 thing at a time
[04:35] <woohoo> micahg, if i execute a script with sudo, the other commands dont have to have sudo, right?
[04:49] <micahg> correct
[05:10] <hyperair> Laney: thanks for the ack. now to wait for someone to sync it..
[06:27] <dholbach> good morning
[06:33] <RoAkSoAx> morning dholbach
[06:33] <fabrice_sp> Good morning dholbach
[06:34] <dholbach> hi RoAkSoAx, hi fabrice_sp
[07:17] <RoAkSoAx> Hey guys, if anyone has time could you please review: http://revu.ubuntuwire.com/p/gnome-gmail-notifier and http://revu.ubuntuwire.com/p/lekhonee. It would be very much appreciated. Thanks a lot.
[07:17]  * RoAkSoAx off to bed. bye all
[08:20] <Zhenech> bdrung_, correct now? :)
[08:20] <Zhenech> (the site)
[08:28] <didrocks> good morning o/
[08:35] <geser> good morning
[08:46] <\sh> moins
[09:33] <qiyong> what is the kqemu-common pkg used for?
[09:33] <qiyong> i thought kqemu-source provides the kernel module, that's enough, isn't it?
[09:35] <slytherin> qiyong: Install the package and check yourself.
[09:39] <gaspa> Laney: hi, news on hugs strangeness?
[10:45] <callekabo> Hi, I have a few questions regarding generating .deb-packages
[10:45] <callekabo> is this a good place? :)
[10:45] <bdrung_> Zhenech: yes
[10:46] <maxb> callekabo: yes
[10:46] <callekabo> excellent
[10:46] <callekabo> I have a PHP-project that depends on a few packages
[10:46] <callekabo> php5, php5-sybase, php5-imagick etc.
[10:47] <callekabo> and I'd like to put my project in a .deb file which lists theese packages as depencies
[10:47] <Zhenech> bdrung_, packages.qa. is sometimes slow :)
[10:47] <callekabo> and then put the .deb-file in a local repository (reprepro)
[10:48] <callekabo> but all the tutorials I can find for generating .deb-files talks about makefiles and how to set that up
[10:48] <bdrung_> Zhenech: seams so
[10:48] <callekabo> but php-projects doesn't have a makefile
[10:48] <callekabo> I just want my files put in /var/www
[10:48] <callekabo> how do I do that?
[10:49] <callekabo> is .deb-files and a repository a good aproach for this?
[10:51] <callekabo> the best would be a shell script that took the folder with the php-files as an argument, read a file 'deps' inside the folder and than generated a .deb out of that
[10:51] <callekabo> is this possible?
[10:52] <callekabo> using ubuntu 8.04 BTW
[11:18] <callekabo> does anybody know a better place where I can find answers to my questions?
[11:27] <james_w> shouldn't rmadison handle 302?
[11:30] <geser> I guess you're talking about backporting the fix for bug 399891
[11:31] <james_w> well, it seems like it shouldn't need a fix
[11:31] <james_w> the server is telling it where to find the page it wants
[11:31] <james_w> it's just ignoring it
[11:32] <geser> the curl call seems to be missing the option to follow redirects
[11:36] <Laney> gaspa: hahaha, grand timing
[11:36] <Laney> new GHC!
[11:37] <gaspa> O_o
[11:37] <Laney> I was just responding to that post on u-d-d
[11:37] <Laney> and saw it
[11:37]  * Laney pokes kaol
[11:37] <gaspa> LOL
[11:37] <gaspa> right.
[11:40] <Laney> Fri Jul 17 10:15:29 UTC 2009  Joachim Breitner <mail@joachim-breitner.de> * A script to draw a dependency graph (output not yet great)
[11:40] <Laney> \o/
[11:40] <slytherin> james_w: It is already fixed in jaunty. I have backported the fix to hardy and posted the debdiff to that bug.
[11:41] <james_w> slytherin: you made it follow redirects?
[11:42] <slytherin> james_w: Yes. curl has -L option which follows redirect. The fix was provided by some other user. You also have option to uninstall curl in which case wget will be used.
[11:42] <james_w> excellent, thanks
[11:43] <slytherin> james_w: The debdiff for hardy still needs sponsoring though. :-)
[11:44] <james_w> it's not a valid SRU bug yet though
[11:44] <slytherin> james_w: Why not?
[11:44] <james_w> there's no TEST CASE, ubuntu-sru aren't subscribed etc.
[11:45] <slytherin> Oh. I think I subscribed sponsors first.
[11:46] <slytherin> ﻿﻿callekabo: You need to have a debian/rules file which is a Makefile. And the in install target in that file you can copy the files in appropriate places.
[11:48] <slytherin> james_w: Subscribed ubuntu-sru. What more information does it need? The fix is in jaunty already. I simply applied same fix in hardy and tested it.
[11:48] <james_w> https://wiki.ubuntu.com/StableReleaseUpdates
[11:52] <gaspa> Laney: are you replying to u-d-d mail?
[11:53] <Laney> yep
[11:54] <gaspa> ok, so i wont :P
[11:57] <slytherin> james_w: Hmm. All the needed data is in the bug.
[11:58] <james_w> that may be so, but it's not laid out like requested
[11:59] <james_w> the SRU team deals with a lot of bugs, and so they ask for some consistency in order to help them get through them quickly
[11:59] <slytherin> james_w: Do you have link to any idea SRU bug?
[11:59] <james_w> "Examples" in the page
[12:13] <slytherin> done
[12:46] <AnAnt> slytherin: thanks
[12:47] <slytherin> AnAnt: Welcome.
[12:48] <AnAnt> slytherin: thanks for ttf-liberation suggestion !
[12:48] <AnAnt> so I need another advocate, right ?
[12:49] <slytherin> AnAnt: Yes. Considering that it is java app, it is hard to find one. :-)
[12:52] <AnAnt> slytherin: you know how to write build.xml ?
[13:13] <slytherin> AnAnt: as in the one used by ant?
[13:14] <AnAnt> slytherin: yeah
[13:14] <slytherin> AnAnt: yes I know.
[13:14] <AnAnt> slytherin: ok, I'll need help about something , hang on
[13:16] <AnAnt> slytherin: http://pastebin.com/m16d0c0fb
[13:16] <AnAnt> slytherin: the help I need is with creating manifest file
[13:17] <AnAnt> slytherin: I did this: <attribute name="Class-Path" value="${buildlibs}" /> , but that didn't work
[13:18] <AnAnt> slytherin: ${buildlibs} is a path id
[13:18] <slytherin> AnAnt: Let me check.
[13:18] <AnAnt> slytherin: what's the correct way to do this ? other than having to list the jar files again as I did in buildlibs ?
[13:20] <slytherin> AnAnt: Where is buildlibs defined?
[13:20] <AnAnt> slytherin: in build.xml
[13:20] <AnAnt> slytherin: have you seen the pastebin URL ?
[13:21] <slytherin> yes, found it.
[13:21] <slytherin> I was not looking hard enough
[13:24] <slytherin> AnAnt: Don't see any problem here. What is the issue?
[13:25] <AnAnt> slytherin: it doesn't subsitute ${buildlibs} with the classpaths listed in ${buildlibs} path id
[13:25] <AnAnt> slytherin: it instead puts a literal '${buildlibs}
[13:25] <AnAnt> slytherin: it instead puts a literal '${buildlibs}' in the manifest
[13:27] <slytherin> AnAnt: can you try 'ant -verbose <target>'
[13:28] <AnAnt> slytherin: did that, but got nothing useful
[13:30] <slytherin> AnAnt: looks like you need pathconvert. Check http://martin.ankerl.com/2005/11/30/howto-create-manifestmf-classpath-from-ant/ and http://www.guydavis.ca/log/view.jsp?id=851
[13:32] <AnAnt> cool ! thanks
[13:47] <highvoltage> dholbach: enjoy your holiday!
[13:47] <dholbach> thanks highvoltage :)
[13:48] <AnAnt> dholbach: where is it going to be ?
[13:49] <dholbach> Iceland :)
[13:49] <dholbach> and afterwards to Austria: Mimi's sister is marrying
[13:49] <AnAnt> ah, not Debconf
[13:50] <dholbach> I don't think Mimi would appreciate the idea of going to Debconf during holidays :)
[13:50] <dholbach> that's not her idea of holidays :)
[13:50] <dholbach> but anyway I'm very much looking forward to lots of nature and hiking
[13:50] <AnAnt> cool, you must take pics
[13:51] <dholbach> I will surely do that :)
[13:53] <dstansby> Hi all, does anyone here know how easy (or hard) it is to change the name of a package that is in the repos?
[13:54] <coolbhavi> dholbach, hope you ll enjoy holidays .. supermen with superpowers also need rest :)
[13:54] <AnAnt> coolbhavi: source package ?
[13:54] <AnAnt> coolbhavi: or just binary package ?
[13:54] <slytherin> dstansby: depends on package
[13:54] <dholbach> coolbhavi: I don't have super powers - that's cjwatson :-)
[13:54] <coolbhavi> AnAnt, its not me its dstansby
[13:55] <AnAnt> coolbhavi: oh sorry !
[13:55] <dstansby> It's ddrescue from universe
[13:55] <coolbhavi> dholbach, you are a superman.. thats accepted by everyone I believe :D
[13:56] <dstansby> Trouble is it's name conflicts with another binary packages name, so it is proving confusing for some people
[13:57] <dstansby> Sorry, ddrescue is a source package, whose name conflicts with that of a binary package installed by gddrescue
[14:03] <slytherin> dstansby: What binary packages does ddrescue source package create?
[14:04] <dstansby> slytherin: I'm not sure, is there a way of finding out?
[14:06] <slytherin> dstansby: Looking at https://edge.launchpad.net/ubuntu/karmic/+source/ddrescue and https://edge.launchpad.net/ubuntu/karmic/+source/gddrescue I don't see any conflicts
[14:08] <dstansby> slytherin; Sorry, I think I've figured it out now
[14:11] <dstansby> slytherin: I think it was a case of the bug reporter getting confused when reporting, and me getting even more confused when trying to understand his origional bug. Thanks for your help though :D
[14:15] <Dabian> Hey, I need some help with Launchpad, or there is something broken about danish translation ...
[14:17] <Dabian> I joined the danish translation team, but when I want to translate something, I get "This translation is managed by 'De danske oversættere af Ubuntu". (This means, "The danish translators of Ubuntu".  When I click this group, I don't get a chance to try and join this group, and if I try to open "Translation guidelines", I get: "Not allowed here               Sorry, you don't have permission to access this page.   "
[14:17] <AnAnt> slytherin: that worked like a charm ! thanks
[14:17] <slytherin> good.
[14:17] <Dabian> Hehe .. A Slytherin charm? :)
[14:17] <slytherin> :-)
[14:17] <dpm> Dabian: can you come to the #launchpad channel, and we'll see if we can solve it there?
[14:18] <Dabian> dpm: Thanks.
[14:18] <Dabian> dpm: I am there! :)
[14:18] <Dabian> dpm: Do you wish me to repost the question?
[14:18] <dpm> Dabian: yes please
[14:31] <dkg0> hey folks -- any chance we can get version 0.25 of monkeysphere synced from debian unstable?
[14:31] <dkg0> https://bugs.launchpad.net/ubuntu/+source/monkeysphere/+bug/345054 has been open for 4 months now
[14:42] <ScottK> dkg0: Is ubuntu-universe-sponsors subscribed?
[14:42] <dkg0> it is, yes.
[14:42] <ScottK> Then it should get reviewed at some point.
[14:42] <dkg0> (as of today only, though)
[14:43] <dkg0> is it possible that it will make it for karmic?
[14:43] <simon-o> dkg0: Maybe you should provide all the information asked for: https://wiki.ubuntu.com/SyncRequestProcess#Content%20of%20a%20sync%20request
[14:47] <dkg0> simon-o: i think everything there has been supplied for the last 4 months.
[14:47] <dkg0> is there something i'm missing?
[14:49] <simon-o> dkg0: Source package version number to sync  (0.25-1) and that it is in debian main are missing. But I think that's less important
[14:51] <dkg0> i've just made those points explicit in a followup comment.  i can't imagine that they would have confused anyone, but being explicit is better than being vague.  thanks for pointing that out, simon-o.
[14:52] <simon-o> dkg0: in ubuntu-dev-tools is the script requestsync. It provides all the information you need and files a bug automatically. Maybe you could try that next time :)
[14:53] <dkg0> i'll take a look, thanks.  it was a little bit frustrating to have the bug get no response for 4 months :(  Now i see that apparently i didn't have the right group subscribed to it.
[14:54] <dkg0> maybe there's a way that launchpad could automatically subscribe *someone* for bugs against a given package?  It just seems odd that there was not even any triage there.
[14:55] <dkg0> and now i see that it's "declined for karmic by iain lane
[14:55] <dkg0> with no other details?
[14:56] <ScottK> dkg0: monkeysphere 0.25 was uploaded to Debian TODAY.
[14:56] <dkg0> yes, it was.
[14:56] <dkg0> and 0.24 has been around for 4 months.
[14:56] <ScottK> So up until several hours ago there was nothing to sync.
[14:56] <dkg0> ubuntu is still shipping 0.22
[14:57] <ScottK> dkg0: No.  0.24 is in Karmic already
[14:57] <dkg0> not according to http://packages.ubuntu.com/monkeysphere
[14:57] <dkg0> should i be looking somewhere else?
[14:58] <Laney> https://launchpad.net/ubuntu/+source/monkeysphere
[14:58] <Laney> and yes I declined it for karmic because this is not a release goal
[15:00] <ScottK> Laney: That doesn't make any sense.
[15:00] <dkg0> ok, i'm glad to see that 0.24 is shipping in karmic at least.
[15:00] <Laney> what doesn't?
[15:00] <Laney> I declined the release nomination
[15:00] <ScottK> "Not a release goal" as a reason to not sync a package at this point in the cycle.
[15:01] <Laney> I didn't close the bug
[15:01] <dkg0> i "nominated it for karmic release" thinking that meant "i'd like this to happen for karmic"
[15:01] <ScottK> "Declined" carries the idea that we won't do it in this cycle.
[15:01] <ScottK> dkg0: It's really unneeded for the development release.
[15:01] <dkg0> if what it really means is "this is a release goal" then i was mistaken in marking it that way.
[15:01] <Laney> that's not the case :)
[15:02] <ScottK> Laney: that's why declining is a problem.  Other MOTU will look at it and think "there must be a reason we don't want to do this."
[15:02] <dkg0> i think it would help to clarify the semantics of what "nominated for a release" means.
[15:02] <slytherin> dkg0: monkeysphere 0.24 has failed to build. That is why you don't see it on packages.ubuntu.com
[15:03] <Laney> ScottK: Really? I would look at the status of the bug and not whether it has been accepted or declined
[15:03] <slytherin> dkg0: https://edge.launchpad.net/ubuntu/karmic/+source/monkeysphere/+builds
[15:03] <dkg0> slytherin: could you point me toward the build log then?
[15:03] <dkg0> ah, thanks.
[15:03] <Laney> if it were really rejected then I would have set it to Invalid or Won't Fix
[15:04] <Laney> but yes I accept there is general confusion about the nomination feature as applied to the development series
[15:06] <mfoster> I'm trying to backport passenger to hardy and running into a weird build-depends issue
[15:06] <mfoster> it needs rake to compile, but when I have rake in the Build-Depends: it complains that it is a virtual package
[15:06] <dkg0> slytherin: that failure is related to http://bugs.debian.org/527765 -- building within a group-writable or world-writable directory will cause the test suite to fail because the test suite emulates dealing with sensitive files related to ssh authentication.
[15:08] <slytherin> mfoster: Do you have universe component enabled in pbuilderrc?
[15:08] <slytherin> dkg0: The bug is marked as 'won't fix'.
[15:09] <dkg0> that's correct.
[15:09] <dkg0> the point of the test suite is to ensure that the package properly detects files and paths that could be modified by other people
[15:09] <dkg0> so that it doesn't feed those files to sshd for authentication purposes.
[15:10] <dkg0> we could disable the test suite, but then we would lose the check that the package is actually working as expected for users.
[15:10] <dkg0> that seems like a bad security tradeoff.
[15:11] <mfoster> slytherin: COMPONENTS was commented out, I'll try that, thanks!
[15:11] <dkg0> in particular, the problem (from the test's perspective) is that /build/buildd is group-writable.
[15:12] <slytherin> mfoster: you need to do 'pbuilder --update --override-config' after that.
[15:13] <slytherin> dkg0: I can't say I understand all of that. But I guess you will have to wait for someone to see if 0.25 builds properly before it actually get synced.
[15:13] <slytherin> dkg0: It will be great if you yourself can verify that in pbuilder.
[15:13] <dkg0> 0.25 will have the same issue if /build/buildd is group writable.
[15:15] <dkg0> is there an explicit design decision that it /build/buildd should be g+w ?
[15:18] <mfoster> slytherin: so just to be clear, it's OK to use virtual package names in Build-Depends: ?
[15:21] <slytherin> mfoster: That error is confusing. The package is in universe. By default only main component is enabled in pbuilderrc.
[15:23] <mfoster> slytherin: thanks a mil! I've got it to build now :)
[15:31] <AnAnt> Hello, can someone confirm this syncrequest: LP 399123
[15:31] <AnAnt> This fixes a bug making dicoweb uninstallable
[15:36] <alkisg> Some packaging help, please? I've a package A that depends on package B. In a later version I decide that A should also depend on a third package C.
[15:36] <alkisg> Now, if I use synaptic, it upgrades the package A and installs C to satisfy the dependencies.
[15:36] <alkisg> But if I use apt-get update, then I get the error: The following packages have been kept back: A
[15:36] <alkisg> How can I instruct apt-get to automatically install the new depencency C?
[15:36] <ScottK> alkisg: apt-get dist-upgrade.
[15:37] <alkisg> ScottK, is that really necessary? It won't be easy to tell my users to use that... :(
[15:37] <alkisg> I'd rather do something from my (=packaging) side, if I could
[15:38] <ScottK> Yes.  It's necessary.
[15:38] <alkisg> Thank you.
[15:38] <ScottK> That's what dis-upgrade does is say to go ahead and add new packages if needed.
[15:38] <alkisg> And synaptic is smart enough to decide when that is needed?
[15:38] <geser> alkisg: apt-get upgrade doesn't install new packages (or remove conflicting ones), you need dist-upgrade for that
[15:39] <woohoo> what is 'ldconfig'?
[15:39] <alkisg> Thank you guys. I thought that I could have a package named "secondary_edu_apps" that would depend on new apps when they became available. OK, if dist-upgrade is needed for that, so be it :)
[15:40] <ScottK> alkisg: synaptic probably has some equivalent, but I don't use it, so I can't say what.
[15:40] <alkisg> ScottK: it does it automatically, so it's ok with me.
[15:42] <joaopinto> woohoo, man ldconfig
[15:42] <woohoo> thanks joaopinto
[17:10] <_andre> hello
[17:10] <_andre> hyperair: ping :)
[17:36] <dholbach> can anybody PM me a current email address of jawnsy please?
[18:05] <pochu> dholbach: if you didn't get one, just /msg jawnsy and ask him ;)
[18:05] <dholbach> pochu: I did that in the end :)
[18:06] <dholbach> have a good time without me - see you soon again! have a great WE my friends!
[18:06] <pochu> :)
[18:06] <pochu> dholbach: have a good trip!
[18:06] <dholbach> thanks
[18:06] <pochu> read it in your blog ;)
[18:06] <dholbach> :-)
[18:10] <RoAkSoAx> Heya guys. What would be the difference in specifying the CFLAGS on debian/rules and not doing so?
[18:10] <asomething> dholbach: have fun!
[18:11] <dholbach> thanks asomething
[18:11] <dholbach> take care!
[18:56] <RoAkSoAx> DktrKranz, ping
[18:56] <DktrKranz> RoAkSoAx, pong
[18:57] <RoAkSoAx> DktrKranz, heya. would you please be so kind to take a look to http://revu.ubuntuwire.com/p/lekhonee since you are the python packaging expert please :)
[18:58] <RoAkSoAx> if you have some free time of course :)
[18:59] <DktrKranz> RoAkSoAx, sure thing. Probably I won't make it this evening, I'm out in an hour, but if you remind me, I'll have a look ;)
[18:59] <RoAkSoAx> DktrKranz, ok. awesome. thanks a lot :)
[19:03] <c_korn> hm, this command I have found in a Makefile: wx-config --libs
[19:03] <c_korn> but there is no wx-config in ubuntu. is there an alternative?
[19:38] <evanrmurphy> I have a debian/control where the Depends: for a package are separated by '|' instead of ','. Does this mean the package has an OR dependency list instead of an AND dependency list? Thank you.
[19:38] <azeem_> yes
[19:39] <evanrmurphy> thanks azeem_
[20:09] <RoAkSoAx> Is it strictly necessary to have ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) in debian/rules?
[20:10] <jpds> No.
[20:11] <RoAkSoAx> jpds, so I can omit using it on debian/rules and just let the Makefile to use it's own CFLAGS?
[21:13] <rgreening> ScottK: ping
[21:15] <ScottK> rgreening: Pong
[21:16] <rgreening> ScottK: trying to add quilt patch system to a package. Is the correct include /usr/share/quilt/quilt.make or the quilt.debbuild.mk
[21:16] <rgreening> the quilt.make doesn't seem to work (unless I've done it worng)
[21:16] <ScottK> rgreening: Quilt and correct don't compute.
[21:16] <ScottK> IMO
[21:16] <rgreening> lol
[21:18] <ScottK> rgreening: No idea actually.  Look what kde.mk does and do that.
[21:19] <rgreening> ScottK: thats cdbs though?
[21:19] <ScottK> Oh.  right.
[21:20] <rgreening> /usr/share/cdbs/1/rules/patchsys-quilt.mk
[21:20] <rgreening> weird
[21:20] <rgreening> hmm...
[21:20] <ScottK> My advice is dpatch
[21:20] <rgreening> no
[21:20] <rgreening> haha
[21:20] <rgreening> any reason why?
[21:35] <MT-> does kernel work and motu merge well together?
[21:35] <MT-> or is kernel work pretty separate?
[21:35] <pochu> MT-: it's totally different, I'd say
[21:36] <MT-> oh
[21:36] <MT-> I want to learn both..
[21:37] <ScottK> rgreening: It's dead easy to use dpatch-edit-patch and less risk of misfortune than with quilt except for complex packages with piles of patches.
[21:37] <rgreening> ScottK: for future... cdbs+quilt for build dep
[21:37] <rgreening> heh
[21:37] <rgreening> I suppose :)
[21:38] <rgreening> got it working though...
[21:38] <rgreening> so, Im happy in any case...
[21:38] <rgreening> ty though.
[21:38] <rgreening> now, to patch the broken tac_plus Makefile...
[22:01] <pochu> jpds: you could have synced terminator from Debian ;)
[22:02] <jpds> pochu: Blah, bugger it.
[22:02] <pochu> Ng: we didn't like your joke :P
[22:02] <jpds> ;)
[22:17] <mrooney> hey motu friends!
[22:17] <mrooney> does having package sources in launchpad mean anything different for upstreams in launchpad as well?
[22:18] <mrooney> more specifically, can it make anything easier for the upstream/downstream maintainer?
[22:22] <pochu> mrooney: I'm not sure I understand
[22:22] <ScottK> From an Ubuntu perspective it doesn't matter.
[22:22] <pochu> do you mean for projects hosted on Launchpad or externaly?
[22:23]  * ScottK thinks so
[22:23] <mrooney> yeah so if I am the maintainer of a project which is hosted on Launchpad, and has a package in Ubuntu
[22:23] <ScottK> If anything it's a disadvantage because it gets really confusing between distro and upstream bug tasks.
[22:24] <mrooney> it seems like I should be able to do useful things like propose merges for updates or even potentially have commit privileges to the ubuntu source branch
[22:24] <ScottK> mrooney: Why should your choice of hosting providers affect your ability to put code into Ubuntu?
[22:24] <mrooney> well, it is currently a painful process IMO
[22:24] <mrooney> I was thinking if we are both in launchpad it can be easier
[22:25] <mrooney> via just proposing merges or committing directly as I've said
[22:25] <ScottK> Right, but it's restricted by distro policy to distribution developers.
[22:25] <mrooney> okay, so, the answer is no? :)
[22:25] <ScottK> Just because a project is hosted on Launchpad that restriction isn't affected.
[22:25] <mrooney> I've just had to wait months to get an update in and ping a bug report over and over
[22:25] <mrooney> I was hoping maybe the process is easier
[22:25] <ScottK> I can't even comprehend why you think it would be.
[22:26] <mrooney> not necessarily the restriction
[22:26] <mrooney> just improvements to the workflow
[22:26] <mrooney> since as I've said twice already, merge proposals seem like a nice solution?
[22:26] <ScottK> If you want to get upload rights, then you need to become a distro developer.
[22:26] <ScottK> mrooney: Yes, for the subset of developers that use such things.
[22:26] <mrooney> yes that was precisely my question
[22:27] <mrooney> for the subset of upstreams using launchpad, does it/ can it mean anything different / easier
[22:27] <ScottK> Actually while such things might make the mechanics of updating easier, it probably makes the odds of it getting done lower since not all developers use or look at such tings.
[22:27] <mrooney> yeah
[22:27] <ScottK> The easiest way to get an update into Ubuntu is to get it into Debian.
[22:28] <ScottK> In the long run we'll use bzr for everything and it probably will be easier, but not right now.
[22:28] <mrooney> I see
[22:29] <mrooney> what about package-specific upload rights? couldn't that be accomplished by giving a person write access to that specific source project in LP?
[22:29] <mrooney> that part seems easier
[22:30] <ScottK> It could if you met the qualifications for per package upload rights.
[22:30] <mrooney> then I just need to get someone to upload it instead of the current process
[22:31] <mrooney> how interesting, what are such qualifications
[22:31] <ScottK> Which are also not related to is your project hosted on Launchpad
[22:31] <ScottK> There's a wiki page somewhere on it.
[22:31] <mrooney> right.
[22:31] <mrooney> but it would make my life easier if it was
[22:31] <mrooney> because then I can just merge from one branch to another and link bug reports / open tasks appropriately as such
[22:33] <mrooney> I don't necessarily want the ability to upload a specific package. Now that they are in bzr, I would be happy just being to push there, which seems like it would require less permissions. Maybe not
[22:33] <mrooney> I just want to make my work and MOTUs work easier
[22:34] <mrooney> instead of all this going back and forth, when I am perfectly happy to maintain packaging
[22:43] <james_w> mrooney: soon you'll be able to propose bug-fix branches for merging directly in to the Ubuntu packages
[22:44] <mrooney> james_w: yes that is exactly a thing that would be easier!
[22:44] <james_w> mrooney: so if there's a critical fix you should be able request that it get in more easily
[22:44] <james_w> nothing you can't do if you host elsewhere, but it's an example of something we can streamline
[22:44] <mrooney> yeah, definitely
[22:44] <james_w> also, upstreaming bugs is damn site easier
[22:44] <james_w> and downstreaming
[22:45] <james_w> "this bug should really get fixed in Hardy"
[22:45] <mrooney> yeah, my "Report a bug" entry in the menu actually files "upstream"
[22:46] <ScottK> james_w: My experience is that if upstream is in LP, it's very confusing about what's a distro bug task and what's upstream when following bugmail.
[22:47] <james_w> perhaps
[22:47] <james_w> but it's easier to actually upstream the bug in the general case
[22:47] <cody-somerville> Does this mean anything to sound people?: [ 3828.402585] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
[22:48] <mrooney> james_w: so let's say I want to update to a new version though in Karmic, am I still best off filing "please update..." bug? Would branching the source, merging updates, and pushing that to say ~mrooney/ubuntu/karmic/package/package-newversion be useful at all?
[22:53] <rgreening> ScottK: ping
[22:53] <ScottK> rgreening: Pong
[22:53] <rgreening> ScottK: the tac_plus src includes a basic Makefile, but no install target. I tried adding.. but I can't make it work.. ideas?
[22:54] <ScottK> Not immediately.  No.
[22:55] <rgreening> ScottK: here's the makefile... http://paste.ubuntu.com/220799/
[22:56] <rgreening> and the error ScottK: http://paste.ubuntu.com/220801/
[22:56] <rgreening> ScottK: is it because I didn't include a dirs file with /usr/sbin?
[22:57] <ScottK> rgreening: No.
[22:57] <rgreening> ok
[22:57] <rgreening> thoughts?
[22:57] <ScottK> rgreening: Are you targeting /usr/bin or usr/bin?
[22:57] <rgreening> ScottK: well, the src package install inst. says to install to /usr/sbin
[22:58] <rgreening> so I added that to the makefile
[22:58] <ScottK> I suspect you are trying to actually install it in /usr/bin during the build and so should be glad you are using fakeroot.
[22:58] <rgreening> i'm lost
[22:58] <rgreening> heh
[23:00] <rgreening> this is in rules: $(MAKE) DESTDIR=$(CURDIR)/debian/tac-plus install
[23:00] <ScottK> As a first guess, I'd drop the leading '/' from /usr/bin in the makefile.
[23:01] <jpds> cody-somerville: http://lkml.org/lkml/2008/9/13/112
[23:01] <rgreening> ScottK: install: cannot create regular file `usr/sbin/tac_plus': No such file or directory
[23:02]  * cody-somerville sighs.
[23:02] <ScottK> rgreening: Then maybe the dir file is needed now.
[23:05] <rgreening> ScottK: yep. adding dirs with usr/sbin and adding $(DESTDIR)/ in install worked
[23:06]  * rgreening hates makefiles
[23:09] <agent_j> i'm trying to package a game, but it doesn't work. do i compile the game and then make the package, or do i just make the package without compiling first?
[23:10] <azeem> agent_j: if you don't compile it, what would you put into the package?
[23:11] <agent_j> hmmm good point
[23:11] <ScottK> Generally we package the source and then build the binary package from that.
[23:11] <agent_j> does debuild have super cow powers?
[23:11] <azeem> how is that relevant?
[23:13] <Ng> pochu: it's not my fault some people have no taste ;)
[23:14] <pochu> Ng: it's rather some people don't get the joke :)
[23:14] <pochu> like me ;)
[23:14] <rgreening> ScottK: one last question... tac_plus uses a sql db in the back-end. any idea on appropriate way to create the db? src cmes with an sql script to run. I assume to do this via postinst or something?
[23:14] <ScottK> possible, but remember postinst runs on upgrades too, not just initial installs.
[23:15] <rgreening> hmm...
[23:15] <rgreening> not easy packaging this from scratch :)
[23:15] <rgreening> hah
[23:16] <Laney> rgreening: I believe dbconfig-common is the recommended way to set up databases
[23:16] <rgreening> Laney: ty. any pointers on usage?
[23:16] <Laney> never used it myself
[23:16] <rgreening> lol
[23:16] <Laney> either look at some rdeps or visit google
[23:20] <rgreening> Laney: ty. will try the rdepends.. see what packages I can scarf from :P