[00:04] <kostmo> it looks like there are only symbolic links in the /usr/bin directory - no subdirectories
[00:04] <kostmo> aside from the executable files, of course
[00:09] <RAOF> kostmo: Your first .py file requires the second to exist before it works?
[00:10] <neversfelde> do I have to run the full pbuilder procedure every time, or ist there a way to get a shorter build?
[00:10] <kostmo> RAOF: that's correct
[00:11] <RAOF> Then you'll need to make a rather more proper python package.  You can check out the specto package for an example.
[00:15] <lifeless> neversfelde: 'ccache'
[00:17] <neversfelde> lifeless: thx, I'll take a look at it
[00:19] <neversfelde> ah, got it in the pbuilder howto
[00:19] <directhex> neversfelde, use a chroot rather than what pbuilder does (extract a base chroot, install all build-deps every time)
[00:22] <neversfelde> will try it tomorrow, gn8 now and thx for your help
[00:41] <nxvl> siretart: around?
[02:32] <RAOF> Hm.  Something's strange in our python/gtk stack; Miro has a broken folderchooser on Intrepid, but it works fine on Sid.
[02:34] <RAOF> This may be due to havinrg 2.13.3 in Ubuntu and 2.12.10 in Sid.  Interesting.
[02:43] <borschty> hi, how can i configure pbuilder to include updates from updates and proposed?
[02:46] <RAOF> borschty: pbuilder login --save-after-exit (or similar), edit the appropriate files, aptitude update.
[02:49] <StevenK> --save-after-login
[02:49] <RAOF> Ah, right.
[02:49] <RAOF> Something of that kidney.
[02:49] <borschty> ah ok, thanks
[02:49] <StevenK> Also, 'apt-get clean' before you logout.
[02:50] <StevenK> Otherwise pbuilder happily includes /var/cache/apt/archives/* in the base tarball
[02:50] <RAOF> :)
[03:34] <AnAnt> Hello, when is the next sync with Debian ?
[03:37] <RAOF> AnAnt: All the time?  Or, rather, when an admin next runs the autosync script, I think.
[03:37] <AnAnt> gpm needs to be sync'ed , the current package in Intrepid has some issues
[03:38] <RAOF> Oh?  You're one of those crazy mouse-on-the-console users?
[03:38] <RAOF> :)
[03:39] <AnAnt> yup
[03:39] <RAOF> Have you filed a sync bug?  Is it a sync?  There are currently Ubuntu changes.
[03:41] <AnAnt> what does that question "is it a sync" mean ?
[03:42] <RAOF> AnAnt: Is it a sync, or a merge?  Can the current Ubuntu changes be dropped?
[03:43] <RAOF> Also, what are the current bugs, and are they actually fixed in Debian?
[03:44] <AnAnt> yes, gpm_1.20.4-1 & -2 fixes several bugs in Debian
[03:44] <AnAnt> -2 is now in unstable
[03:44] <AnAnt> as for Ubuntu changes, I dunno what is -D_GNU_SOURCE for
[03:44] <AnAnt> but that Ubuntu change is not in Debian
[03:46] <chubs_> Hi, I'm not entirely sure if this is the proper place to be asking this, so feel free to scream at me (or direct me to the right area). I'm trying to build a package in pbuilder against a hardy chroot, but the package requires yamp .7, which is in the intrepid repos. Even if i set the mirror to the intrepid universe it won't update the package, and I can't build it
[03:50] <RAOF> AnAnt: Heh.  apt-cache showsrc gpm suggests that Debian's gpm package has been merged, but not yet built, or possibly FTBFS.
[03:50] <RAOF> chubs_: You'll need an Intrepid chroot.  Alternatively, how did you set the mirror to Intrepid?  It's entirely possible that change didn't stick.
[03:51] <chubs_> raof: I don't want to build it againts intrepid packages, as it's intended for use on hardy. I guess I never considered that that might be alright (would it?). Anyways i set it in the pbuilderrc and i'm positive the change has stuck
[03:52] <chubs_> it gets packages from the mirror every time
[03:52] <chubs_> just won't upgrade any
[03:53] <RAOF> AnAnt: In fact, looking at https://edge.launchpad.net/ubuntu/intrepid/+source/gpm/1.20.3~pre3-3.1ubuntu1 suggests that the new gpm package FTBFS.  Feel free to fix this ;)
[03:53] <AnAnt> RAOF: well, maybe they should try 1.20.4-2
[03:54] <PMantis> Hi. I struggled to create a couple packages, but it works! However, when the package is upgraded, the config file is replaced w/o question. I've seen some packages ask if it should overwrite, option to diff, etc. How?
[03:54] <RAOF> AnAnt: Maybe.  Again, feel free to merge ;)
[03:55] <AnAnt> RAOF: I built it on hardy without any problems
[03:55] <RAOF> But it (presumably) still needs the _GNU_SOURCE change.
[03:56] <RAOF> Unless you know that's not needed...
[03:56] <RAOF> Alternatively, ask in #ubuntu-devel.  gpm seems to be in main.
[03:57] <StevenK> I daresay _GNU_SOURCE was added due to a libc change
[03:57] <StevenK> (Difference in toolchain between Ubuntu and Debian)
[03:57] <StevenK> PMantis: Is the config file marked as one?
[03:57] <AnAnt> ah
[03:58] <PMantis> StevenK: Probably not, I don't know how.
[03:58] <StevenK> PMantis: If it's installed under /etc, and you're using debhelper > 5, it should be automatically
[03:58] <RAOF> Anything installed under /etc should be automatically marked as a config file.
[03:59] <PMantis> Hmmm Build-Depends: debhelper (>= 5), cdbs
[03:59] <RAOF> Or, listen to the more-experienced StevenK :)
[03:59] <PMantis> heh
[04:04] <AnAnt> RAOF: where should I put it after merge ? REVU ?
[04:05] <RAOF> You should attach the debdiff against the debian version (and possibly one against the previous Ubuntu version) to a merge bug.
[04:05] <RAOF> Note that gpm doesn't seem to be up on merges.ubuntu.com; I'm not sure why this is.
[04:07] <AnAnt> what does that mean ?
[04:07] <RAOF> Possibly that merges.ubuntu.com hasn't been updated since gpm 1.20.4 entered Sid?
[04:08] <RAOF> Possibly some other problem.  It's easier to pull merges from m.u.c; there's a bunch of stuff already done for you.
[04:15]  * StevenK notices his name on 3 manual merges
[04:15] <StevenK> Er, make that six :-(
[04:17] <chubs_> Is it okay to build a package intended for hardy installation inside intrepid? Is it just a dependency thing or will it screw stuff up?
[04:17] <chubs_> intrepid chroot*
[04:18] <StevenK> chubs_: If it's intended for Hardy, build it against Hardy, otherwise you might depend on a toolchain package version that isn't in Hardy.
[04:19] <chubs_> stevenk: I figured i should, just building the package requires yasm .7, which is only in the intrepid repos.
[04:19] <StevenK> Which means you should start by back-porting yasm
[04:22] <chubs_> I'll go off and learn how to do that. I saw a backporting section and figured it didn't apply. Thanks for the help!
[04:22] <StevenK> chubs_: No trouble.
[04:24] <AnAnt> 1.20.4-2 is building in PPA
[04:25] <AnAnt> StevenK: _GNU_SOURCE is needed if package does not build, right ?
[04:25] <StevenK> AnAnt: May be needed, it depends on the error
[04:25] <AnAnt> ok
[04:27] <PMantis> I'm not going to worry about the config file issue right now... but I *really* wish my apt repo was secure. When I add a Release.gpg, apt-get cannot download Release...
[04:30] <bliZZardz> Hello!
[05:01] <kostmo> If I have a python application that can be installed with a "setup.py" script, how can I wrap that as a .deb package?
[05:02] <RAOF> kostmo: By calling 'setup.py' in debian/rules.  Or using the CDBS magic.
[05:03] <kostmo> ok, I tried that, but I get a 'permission denied' when I run debuild.
[05:04] <kostmo> it seems to be actually installing the python application into my system, when all I really want to do is roll the .deb package
[05:05] <RAOF> Right.  So, you'd need to set the install path when using setup.py.
[05:06] <AnAnt> RAOF: ok, gpm built on my PPA (https://launchpad.net/~aelmahmoudy/+archive) how do I file a merge bug for gpm ?
[05:07] <kostmo> the line that gets permission denied is: copying build/lib/rocket_backend.py -> /usr/lib/python2.5/site-packages
[05:07] <kostmo> will setting the install path via setup.py make some kind of chroot environment?
[05:07] <RAOF> kostmo: Yeah, you need to set the install prefix to something that isn't system-wide.
[05:09] <kostmo> ok, once I do that, is there an easy way to grab the list of files that setup.py installed and pass them to dh_install?
[05:10] <RAOF> kostmo: You won't have to.  You should get setup.py to install the files to where they need to be (generally $(CURDIR)/debian/$pkgname)
[05:11] <RAOF> AnAnt: https://wiki.ubuntu.com/MOTU/Contributing or https://wiki.ubuntu.com/MOTU/Launchpad/Guide
[05:22] <AnAnt> RAOF: thanks
[05:28] <kostmo> ok, now I'm running this in my debian/rules: python setup.py install --prefix=`pwd`/debian/`dh_listpackages`/usr
[05:29] <kostmo> and it gets past several commands after the line "running install_lib"
[05:30] <TheMuso> Those backticks probably won't get properly expanded. Since debian/rules is a makefile, you probably want something like $(CURDIR)/debian/
[05:30] <persia> kostmo: I suspect you want $(CWD) in place of `pwd`
[05:30] <kostmo> but then it stops at this:
[05:30] <kostmo> running install_data
[05:30] <kostmo> creating /usr/share/pyrocket
[05:30] <kostmo> error: could not create '/usr/share/pyrocket': Permission denied
[05:30] <persia> or $(CURDIR) is even better :)
[05:30] <persia> If you get that error, it usually means your setup.py isn't honoring your prefix request.
[05:32] <kostmo> it honored it for the py_modules keyword, but not for the data_files keyword, it seems
[05:44] <ScottK-laptop> Where do you tell setup.py to install it?
[05:44] <ScottK-laptop> kostmo: ^^^
[05:46] <kostmo> this was the line from setup.py: data_files=[('/usr/share/pyrocket', ['joystick.svg', 'pyrocket.png'])]
[05:47] <kostmo> my rules file says: python setup.py install --prefix=$(CURDIR)/debian/`dh_listpackages`/usr
[05:48] <ScottK-laptop> kostmo: IIRC for data files in distutils /usr is assumed.  Try leaving that off.
[05:49] <kostmo> what if I want the same installation behavior whether my application is installed via setup.py directly or via a .deb?
[05:50] <RAOF> The same thing applies; 'python setup.py install --prefix=/foo/bar' should stick _everything_ under /foo/bar
[05:51] <RAOF> kostmo: You might want to pastebin your setup.py; that's likely to help people to help you.
[05:52] <kostmo> i'm going to try omitting the usr part quick
[05:55] <kostmo> I'm also getting a lintian error: E: pyrocket_0.5_i386.changes: bad-distribution-in-changes-file hardy
[05:57] <ScottK-laptop> You'll want to call it 0.5-0ubuntu1
[05:57] <RAOF> You'll also want to make it arch: all rather than arch: any
[06:08] <kostmo> RAOF: in my control file, it already does say Architecture: all
[06:08] <kostmo> I'm not sure where that i386 is coming from
[06:12] <kostmo> Here is my setup.py: http://paste.ubuntu.com/22286/
[06:13] <kostmo> debuild now completes, but the files that the setup.py installed do not copy into my system when I install the .deb file
[06:14] <kostmo> do I need to respecify all the files in the *.install file for dh_install?
[06:17] <kostmo> and here is my debian/rules file: http://paste.ubuntu.com/22289/
[06:28] <nxvl> and where is the package itself?
[06:28] <nxvl> already in revu?
[06:30] <bliZZardz> is it necessary that i have to fix some bugs(etc) before i can apply for a team?
[06:31] <nxvl> nop
[06:31] <nxvl> but the administrators won't accept you if they aren't sure you are woking
[06:31] <nxvl> so you need to show some work
[06:31] <nxvl> and make you known
[06:32] <nxvl> for example
[06:32] <nxvl> i started working on the server team on my early stages
[06:32] <bliZZardz> nxvl :i was looking at some bugs in Pythonista, but wasnt sure of teh fixes as most of them require some expertise in the modules
[06:32] <nxvl> but i didn't get approved on the LP team until i demostrate some work on the team
[06:32] <bliZZardz> i am comfortable with Python, and hence am looking at contribution on the same lines. Can you guide me to some suitable starting points?
[06:33] <ScottK-laptop> bliZZardz: If you can find bugs in python packages worth fixing (you figure out the python) we will help you learn to package the fix.
[06:33] <nxvl> that is quite a big horizont
[06:33] <nxvl> the python guy here is ScottK-laptop
[06:33] <nxvl> but it's more important to find the type of packages you want to work with
[06:34] <bliZZardz> ok.
[06:34] <bliZZardz> nxvl : exactly. that is where i am going berserk.
[06:34] <bliZZardz> ScottK-laptop: can you give me a few good starting tips. I did not quite understand " If you can find bugs in python packages worth fixing"
[06:34] <nxvl> because to be comfortable with python doesn't mean you will be comfortable with pygtk or pyqt (if it exists)
[06:34] <ScottK-laptop> bliZZardz: Perhaps have a look at Bug #241352 and tell me what you think.
[06:35] <bliZZardz> ok..give me few mins - let me have a look at it
[06:35] <nxvl> so you need to focus on your packages of interes
[06:36] <nxvl> for example i'm also comfortable with python, but i work on C packages because im interested in server stuff
[06:36] <bliZZardz> so - most of the problems are with python packaging? ultimately leading to upstreams?
[06:37] <nxvl> well yes
[06:37] <nxvl> we use to work with upstream a lot
[06:37] <nxvl> but not always
[06:37] <nxvl> so you will need to code also
[06:37] <nxvl> ScottK-laptop: btw, i finally started my nm process
[06:37] <nxvl> :D
[06:38] <ScottK-laptop> nxvl: Great.  You may beat me at the rate I'm going.
[06:38] <nxvl> ScottK-laptop: my advocate will be kees, i'm really happy
[06:38] <bliZZardz> nxvl, ScottK-laptop : i would be more interested in development than packaging
[06:39] <nxvl> ScottK-laptop: we are not far away in the list :D
[06:39] <ScottK-laptop> bliZZardz: OK.  What are your interests?  KDE, Gnome, server?
[06:39] <nxvl> in developing what?
[06:40] <bliZZardz> ScottK-laptop : anything in python. would prefer something on server, also applications are fine.
[06:40] <nxvl> heh
[06:40] <ScottK-laptop> bliZZardz: Do you use KDE or Gnome?
[06:40] <bliZZardz> gnome
[06:40] <nxvl> so python is your new toy and you want to play with it?
[06:40] <nxvl> or something like that?
[06:40] <ScottK-laptop> nxvl: Are you writing your centralized server admin stuff in Python?
[06:40] <nxvl> lucas: hi!
[06:41] <nxvl> ScottK-laptop: not yet
[06:41] <bliZZardz> nxvl : nope. i have been doing lots of application programming, which is like lot more boring stuff. not want to build more on top of that
[06:41] <nxvl> ScottK-laptop: i'm writing lenses now
[06:41] <pwnguin> hey, if anyone's into python packaging
[06:41] <nxvl> ScottK-laptop: and i think augeas will have enought lenses for intrepid+1
[06:41] <pwnguin> i have a fun bug
[06:41] <nxvl> ScottK-laptop: so i will start writing it then
[06:41] <bliZZardz> pwnquin : share it, let me try
[06:42] <nxvl> well
[06:42] <nxvl> you will have to package a lot
[06:42] <pwnguin> its fixed in debian
[06:42] <nxvl> but also to write code
[06:42] <nxvl> so is not so packaging oriented
[06:42] <pwnguin> so a novice might be able to figure it out
[06:42] <pwnguin> https://bugs.edge.launchpad.net/gnome-games/+bug/234865
[06:43] <pwnguin> technically, i think its part of main :/
[06:45] <ScottK-laptop> Looks like python-support needs to be updated in Intrepid then.
[06:45] <bliZZardz> pwnguin : am a n00b on it, but can you guide me as to how one goes on fixing it(so that i can get a flavour of it)
[06:45] <pwnguin> well, this one's got a patch in debian, so you'll need to look there
[06:46] <pwnguin> bliZZardz: from a packaging perspective, have you done anything like read the guide yet?
[06:47] <bliZZardz> pwnguin :this one : https://wiki.ubuntu.com/PackagingGuide ?
[06:48] <pwnguin> I think so. there's also a video by dholbach
[06:48] <bliZZardz> pwnguin :i went though the video - one in youtube.
[06:49] <bliZZardz> let me read the guides more and ask Qs(if i have any)
[06:50] <bliZZardz> quick Q -> is packaging the first step for a Ubuntero?
[06:50] <pwnguin> uuh no?
[06:51] <pwnguin> if i remember correctly, you just need to sign the CoC
[06:51] <bliZZardz> pwnguin : CoC?
[06:51] <Flannel> !coc
[06:52] <Flannel> See also: https://help.ubuntu.com/community/SigningCodeofConduct
[06:53] <bliZZardz> and after that?
[06:53] <pwnguin> after that you live by the code?
[06:54] <bliZZardz> :)
[06:55] <bliZZardz> i meant - CoC -> Packaging -> and then?
[06:57] <persia> bliZZardz: It's not really a direct progression.
[06:58] <bliZZardz> persia : Hi. ok.. i understand that some time is required in it
[06:58] <persia> There are lots of different ways to help Ubuntu.  Those participating in the community are encouraged to sign the CoC.  After that, it's best to do as much as you like.
[06:59] <pwnguin> bliZZardz: we try to avoid declaring a hierarchy
[06:59] <pwnguin> except maybe sabdfl
[06:59] <persia> This can be packaging, it can be artwork, it can be documentation, it can be testing, it can be community work, or really anything else.
[06:59] <persia> This channel mostly concentrates on packaging.
[07:00] <bliZZardz> ok.
[07:00] <pwnguin> there is a percieved Ubuntu developer path of Ubuntero -> Member -> Motu -> Core Dev
[07:00] <bliZZardz> pwnguin : what is sabdfl ?
[07:00] <pwnguin> Mark Shuttleworth
[07:00] <Flannel> !sabdfl
[07:01]  * pwnguin thinks the bot should know more about "Self Appointed Dictator For Life" and less about astronauts
[07:02] <nxvl> sabdfl the nearest we have to a Big Boss
[07:02] <nxvl> :D
[07:02]  * nxvl HUGS persia 
[07:02] <bliZZardz> aha... bdfl and sadfl!
[07:02]  * bliZZardz smiles
[07:02] <pwnguin> yes
[07:02] <bliZZardz> this forum has been amazing...thanks for the members patience. i will read up more and contribute to the max.
[07:04] <bliZZardz> q: request for a mentor can happen only after i contribute something? I am clueless sometimes and need some experienced eyes to correct me :)
[07:05] <ScottK-laptop> bliZZardz: You can ask anytime, but it's not mandatory to have one.  You can also just work with various people here in the channel.
[07:05]  * ScottK-laptop thinks that is actually better because you learn more from different people.
[07:05]  * bliZZardz concurs
[07:06]  * bliZZardz hopes to get some nice tshirt with ubuntu on soon ;)
[07:08] <ScottK-laptop> My upstream project update that I hoped to get released/uploaded to Debian prior to DIF is done and uploaded.
[07:08] <nxvl> ScottK-laptop: i have a doubt on the debian-policy
[07:09] <nxvl> ScottK-laptop: a package can Suggest a package outside of main?
[07:09] <pwnguin> yes?
[07:09] <pwnguin> afaik, universe/multiverse were enabled by default a while ago
[07:10] <persia> pwnguin: It's a somewhat false perception.  While that sometimes happens, there are people who each any of those states directly
[07:10] <pwnguin> persia: of course
[07:10] <nxvl> i mean in debian-policy, not the ubuntu adaptation of it :P
[07:10] <ScottK-laptop> nxvl: You mean can it suggest something non-free or contrib?
[07:10] <persia> nxvl: Suggest is OK, Recommends is not OK.
[07:10] <pwnguin> some of the core devs are now approved on a "dont touch the kernel" basis etc
[07:11] <bliZZardz> can i suggest a package to be included?
[07:11] <nxvl> ScottK-laptop: yep
[07:11] <persia> pwnguin: There's been a couple now.  It's not just kernel.
[07:11] <RAOF> pwnguin: "Self Appointed"?  "South African", right? :)
[07:11] <ScottK-laptop> nxvl: Then what persia said.
[07:11] <ScottK-laptop> Actually one of them was you may touch ONLY the kernel.
[07:11] <nxvl> persia: yes, i know that Recommends, Depend and Build-Depends aren't ok, but i was unsure about Suggests
[07:11] <pwnguin> hence the etc
[07:11] <persia> SCottK: I suspect the policy will move back into alignment, with Recommends-by-default.
[07:13] <nxvl> persia: i'm reading the new policy (3.8)
[07:13] <nxvl> and i think it's post-default_Recommends
[07:14] <persia> nxvl: It is.  Debian had recommends-by-default much earlier than Ubuntu.  Ubuntu currently allows main to recommend universe, but that will likely change.
[07:15] <nxvl> persia: intrepid will we a nightmare
[07:15] <wgrant> Is it allowed, or just not explicitly forbidden?
[07:15] <persia> (unless main/universe ceases to mean anything before such a rule is implemented)
[07:15] <wgrant> Which may well happen.
[07:15] <persia> wgrant: It was explicitly allowed at one point, which is part of why recommends-by-default was delayed.
[07:16] <wgrant> persia: Ah, I hadn't realised.
[07:16] <wgrant> Is such policy actually documented anywhere?
[07:17] <persia> Not as such.  There was a mailing list thread about it some long time back, and it basically reached consensus as "doesn't matter".  When recommends-by-default came in Debian, it was blocked in Ubuntu due to that consensus.
[07:17] <persia> (As I remember and understand: ask someone more intimately involved with apt packaging to get a better story)
[07:19] <ScottK-laptop> slangasek suggested MIRs would be required for stuff to stay recommends if it was in Universe.  Not sure if he was speaking policy or perspective.
[07:20] <persia> ScottK: It's a result of the current implementation of main.  Without either an MIR or recommends-removal, it's hard to make a CD.
[07:20] <persia> Whether such an implementation accurately reflects intentional policy is a different matter.
[07:21] <ScottK-laptop> BTW, not all installs have Universe enabled.  It was just enabled for new installs.  Upgraders may not have it enabled.
[07:21] <persia> That's not such a huge impact.  Even with recommends-by-default, apt will allow installs/upgrades cleanly (but with a different package set).
[07:21] <dholbach> ggood morning
[07:22] <persia> It's about how packages are selected for a CD, or for the images.
[07:22] <nxvl> dholbach: guten nacht mein freund!
[07:23] <dholbach> nxvl: sleep tight :)
[07:23] <nxvl> i still have some time here
[07:23] <nxvl> but it's funny how you wake up at the same time i go sleep
[07:23] <nxvl> :D
[07:23] <dholbach> :-)
[07:24] <nxvl> btw
[07:24] <nxvl> i didn't told you (i think)
[07:24] <nxvl> they confirm me the next Packaging Jam
[07:24] <geser> Guten Morgen dholbach
[07:24] <nxvl> i will have a 4 hours session
[07:24] <dholbach> hi geser
[07:25] <dholbach> nxvl: NICE - that's great - is there a lot of excitement in your loco?
[07:25] <nxvl> yes
[07:26] <nxvl> they are really exited about the GBJ
[07:26] <dholbach> ROCK :)
[07:26]  * dholbach hugs nxvl
[07:26] <nxvl> so they are making me run some packaging jams to have more people be able to fix some bugs :D
[07:26]  * nxvl HUGS dholbach back
[07:26] <dholbach> :)
[07:26] <RoAkSoAx> hi guys!! anyone know which package provides mozilla-xpcom
[07:26] <nxvl> for example RoAkSoAx is in charge of running he's city GBJ
[07:26] <nxvl> :D
[07:27] <RoAkSoAx> nxvl, still can't build after doing the patch by hand, now it shows checking for MOZILLA_COMPONENT... configure: error: Package requirements (mozilla-gtkmozembed >= 1.7 mozilla-xpcom >= 1.7) were not met:
[07:27] <nxvl> using pbuilder?
[07:28] <RoAkSoAx> nxvl, i'll do the GBJ if i get my things done by that date
[07:28] <RoAkSoAx> nxvl, yep
[07:28] <ScottK-laptop> Debian accepted my upload, so I think it's time for me to go to sleep.
[07:28] <ScottK-laptop> Good night all.
[07:29] <RoAkSoAx> nxvl, what could be wrong?? i'm guessing have to add a new build-dep?
[07:32] <nxvl> did you merged the build-depends as i told you to do?
[07:33] <RoAkSoAx> yeaaaaah
[07:35] <nxvl> mm
[07:35] <nxvl> then dunno
[07:35] <nxvl> :D
[07:35] <RoAkSoAx> maybe it is because i have to make a change in the patch or maybe i missed something i'll check T.T
[07:47] <RoAkSoAx> lol it built with a supposed old library
[07:49] <nxvl> dholbach: i'm just going to sleep, can you please help RoAkSoAx
[07:49] <RoAkSoAx> i'm going to sleep too
[07:50] <RoAkSoAx> i'll take a look at it tomorrow :)
[07:50] <dholbach> sleep tight RoAkSoAx and nxvl
[07:50] <RoAkSoAx> thanks dholbach, have a nice day :)
[07:50] <RoAkSoAx> chau nxvl
[07:51] <nxvl> well good night!
[07:51] <nxvl> read you tomorrow!
[07:52]  * nxvl HUGS everyone
[07:52] <siretart> nxvl: now im around :)
[07:54] <nxvl> siretart: i'm just going
[07:54] <nxvl> but
[07:55] <nxvl> can you please take a look at augeas?
[07:55] <nxvl> http://revu.ubuntuwire.com/details.py?package=augeas
[07:55] <nxvl> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=augeas
[07:58] <nxvl> siretart: if you have some comments on it please send me an e-mail or comment there
[07:59] <nxvl> siretart: i will be really thankful if you give it a look
[07:59] <nxvl> :D
[07:59] <nxvl> now i'm gone
[08:28] <bliZZardz> ScottK: looked at Bug #241352 in enthought-traits-ui (Ubuntu) . Quite interesting.
[08:39] <bliZZardz> can someone correct me w.r.t Bug #242275 ?
[08:41] <bliZZardz> ScottK, persia, pwnguin : anyone there?
[08:44] <persia> bliZZardz: For myself, I'm not more likely to check an IRC channel for being pinged.  That said, I'm not the best person to answer that: you likely will find help in #ubuntu-bugs for the best way to help with triage.
[09:16] <Pasteurized> hi all
[09:16] <bliZZardz> Hello
[09:17] <Pasteurized> I want to request a sync for Midori web broswer 0.0.18
[09:17] <Pasteurized> I was building my own deb package for Hardy when a Midori dev told me to ask for a sync here
[09:18] <dholbach> Pasteurized: make sure you follow the steps on https://wiki.ubuntu.com/SyncRequestProcess
[09:18] <persia> Pasteurized: Have you reviewed the Ubuntu changes, and confirmed they are no longer required?
[09:18] <persia> Given our preference for not implying Ubuntu is Debian, I suspect it needs a merge, rather than a sync.
[09:19] <persia> (or maybe just a backport)
[09:20] <elmargol> Pasteurized, does flash work now using midori?
[09:20] <Pasteurized> I didnt try yet the .18
[09:21] <persia> Pasteurized: There's an .18 in intrepid (and a different one in Debian experimental).  You might want to try one of those first.
[09:22] <Pasteurized> I could use the .18 Intrepid version on my hardy ?
[09:22] <elmargol> no epiphany-webkit  package jet :(
[09:23] <Pasteurized> Or maybe it'll better to finish my package building of v0.0.18 and install it
[09:24] <persia> Pasteurized: Only if you really want.  As two other people already packaged .18, I'd think you might save yourself some effort if you used one of theirs.
[09:25] <Pasteurized> ok, so now I just need to know where to find it (I was hoping to find it one getdeb.net)
[09:25] <Pasteurized> find it on getdeb.net*
[09:26] <persia> Pasteurized: You can get source from launchpad.net/ubuntu/+source/midori
[09:26] <persia> There are binaries compiled for intrepid, but they may not work if you are running hardy.
[09:26] <persia> If it works for you, please request a backport so others may also share.
[09:26] <persia> !backports
[09:35] <Pasteurized> I have a dependency error (libpango1.0-0) while installing .18 on my hardy
[09:38] <persia> Pasteurized: Try recompiling the source against hardy then.  That might solve it.
[09:40] <Pasteurized> i'm going to try it
[09:43] <amikrop> I guess dustutils' deb packages, are not "valid", right?
[09:43] <amikrop> * distutils
[09:43] <RAOF> amikrop: Does distutils actually have a deb target?
[09:44] <amikrop> RAOF: Hmm... it seems not....
[09:44] <RAOF> Heh.
[09:45] <amikrop> :P
[10:09] <ianm_> hi RainCT
[10:09] <\sh> emgent: bug #227859 I'll take care of it when my buildds are updated
[10:17] <ianm_> RainCT: should screenruler be showing up in hardy at this point?
[10:20] <RainCT> Hi ianm_
[10:22] <RainCT> ianm_: not yet, I'm looking for someone who can upload it to Debian. Then it'll be for a while in the "NEW" queue (this can be just some days or up to a few weeks) and finally it will be in the Debian sid repos and will be copied into Intrepid's (once it's there you/me can request a backport for Hardy).
[10:22] <ianm_> wow what a process :)
[10:23] <persia> ianm_: There are also shorter processes, but that one is used to increase the number of users who will benefit from the new package.
[10:25] <amikrop> In debian/rules, what entries are necessary?
[10:26] <amikrop> I mean, which "make" entries are required?
[10:27] <persia> amikrop: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[10:28] <persia> Please do include get-orig-source and patch if they have meaning for your package (non-native or patched, respectively)
[10:28] <amikrop> persia: ok, thanks
[10:41] <amikrop> Do I need the dh_test* commands?
[10:45] <persia> amikrop: If you do.  What are you trying to accomplish, and how would the presence or absence of dh_test* help?
[10:45] <RainCT> yes, dh_testdir and dh_testroot
[10:46] <amikrop> persia: Alright, I understand :-)
[10:47] <persia> RainCT: Those are certainly not required (although they are likely to be helpful)
[10:49] <RAOF> If a package has an ubuntu revision, do we append build1 for rebuilds?
[10:49]  * RAOF looks at the uninstallable monodevelop
[10:50] <amikrop> Doesn't dh_clean call the clean debian/rules entry?
[10:50] <RAOF> amikrop: No
[10:50] <amikrop> I ask this, because I don't see $(CURDIR)/build deleted after each package generation.
[10:50] <persia> RAOF: No, just bump the Ubuntu revision.  "build1" is code for "We built this too soon, and need to rebuild, but still want to sync, and Soyuz still doesn't support binary NMUs".
[10:50] <RAOF> persia: Thought so.
[10:51]  * RainCT would say "dh_clean is called as part of clean", but better doesn't say nothing as he only knows cdbs :)
[10:51] <RainCT> s/nothing/anything
[10:51] <\sh> amikrop: dh_clean is being called inside clean: target
[10:52] <amikrop> ok
[10:53] <Tooba1> hello. Some days ago I created a package for Debian, but I'm not finding any sponsor. What should be changed in it to try to get it uploaded in Ubuntu Universe? (Is there any useful link?) (I just joined the REVU Uploaders team)
[10:53] <persia> RainCT: dh_clean can make clean: easier, but one is free to delete all the modified files differently if one prefers.
[10:54] <persia> Tooba1: In 95% of cases, the change is to switch the version to -0ubuntu1, the target to intrepid, and the bug closure syntax in debian/changelog.
[10:54] <RainCT> persia: yes, I know it's possible to create a package without debhelper at all, but that doesn't really make sense in most cases :)
[10:54] <RainCT> imho
[10:54] <persia> RainCT: Why not?
[10:54] <amikrop> persia: I have this http://paste.ubuntu.com/22316/ debian/rules but $(CURDIR)/build stays on, after the generation, and I can't see why.
[10:55] <Tooba1> thanks, so I'll take a look at other package for those points
[10:55] <Tooba1> s/ckage/ckages
[10:55] <RainCT> Tooba1: and change the Maintainer to be MOTU if the current address isn't @ubuntu.com
[10:55] <wgrant> And also think very carefully about whether you want to do it.
[10:55] <Tooba1> You mean, remove my address?
[10:56] <RainCT> Tooba1: you can keep it in a XSBC-Original-Maintainer field
[10:56] <Tooba1> ok
[10:57] <RainCT> persia: well, because it's doing the same work yourself (and note the "imho" :))
[10:57] <amikrop> persia: Neither $(CURDIR)/debian/files is removed (although I have removed -k from dh_clean). It seems the "clean" entry is never called :-/
[10:57] <persia> RainCT: Where it is indeed the same work, I agree with you.  I can imagine a package construction where it isn't, but perhaps I'm thinking too deeply :)
[11:00]  * RainCT syncs the REVU keyring
[11:00] <persia> amikrop: What happens if you call debian/rules clean?
[11:00] <amikrop> $ ./rules clean
[11:00] <amikrop> dh_clean
[11:00] <amikrop> dh_clean: cannot read debian/control: No such file or directory
[11:00] <amikrop> make: *** [clean] Error 1
[11:01] <RainCT> amikrop: cd .. ;)
[11:01] <persia> amikrop: That would be the issue.  debian/control is definitely required.
[11:01] <amikrop> persia: debian/control is present
[11:01] <persia> RainCT: Is dh_clean so broken as to only work from that location?
[11:02] <RainCT> persia: iirc, yes
[11:02] <persia> Bah!
[11:03] <amikrop> persia: http://paste.ubuntu.com/22317/
[11:04] <amikrop> persia: The logs say that the "clean" entry was called, but neither dh_clean, nor my custom "rm -fr" had any effect.
[11:05] <amikrop> The logs didn't output any error message, though.
[11:05] <RainCT> amikrop: it calls it *before* building, to ensure that the source is clean
[11:05] <RainCT> but not afterwards
[11:05] <amikrop> RainCT: http://paste.ubuntu.com/22316/
[11:05] <RainCT> if you want to clean-up after dpkg-buildpackage you've to execute   fakeroot debian/rules clean    manually
[11:06] <amikrop> Look here, I have "clean" after "build" next to the "install" entry.
[11:06] <persia> Yeah.  That would fix it.  Looks like the source isn't clean.
[11:06] <amikrop> install: build clean
[11:06] <persia> Could also try with dpkg-buildpackage -rfakeroot (or debuild)
[11:07] <amikrop> first "build", then "clean"
[11:07] <amikrop> Did you understand what I say?
[11:08] <amikrop> I mean, I think I tell it, first to build, then to clean.
[11:08] <RainCT> persia: uhm.. isn't fakeroot now used by default with dpkg-buildpackage, when it's enabled?
[11:08] <persia> Looking at your log, it's doing clean before build.
[11:08] <RainCT> amikrop: ah I see, yes, it does it twice
[11:08] <persia> RainCT: Is it?  I still see people suggest -rfakeroot (and have been using debuild alone for some time now)
[11:09] <RainCT> but it's doing it before install
[11:09] <RainCT> persia: from the manpage, «if  none  has been specified, fakeroot will be used by default, if the command is present.»
[11:09] <persia> Aha!  That's a sane improvement.
[11:10] <Tooba1> even if I'm not the maintainer, I still have to sign the package with my GPG key, right?
[11:10] <RainCT> amikrop: try:    binary-indep build install clean
[11:11] <RainCT> Tooba1: if you are not going to upload it to Ubuntu yourself, not really
[11:11] <amikrop> RainCT: Why? In debian/rules, in the "install" entry, I have written build, and *then* clean. Why does it reverse order?
[11:11] <Tooba1> I know
[11:11] <Tooba1> I mean to upload to REVU
[11:11] <RainCT> amikrop: like now it's doing:   build, clean, install, binary-indep
[11:11] <RainCT> Tooba1: ah, indeed
[11:12] <persia> amikrop: There's no requirement that make enforce dependencies in a given order.  Additionally, dpkg-buildpackage calls several rules, rather than just one.
[11:12] <amikrop> The order is defined in .PHONY, you say?
[11:12] <amikrop> RainCT: How can I change that order?
[11:13] <RainCT> amikrop: uhm.. if you move the clean to binary-indep it woul be     build, install, clean, binary-indep     but I'm not sure if binary-indep also creates files, so it might still not work
[11:14] <amikrop> OK, I will try it.
[11:14] <RainCT> (in which case, if I'm not wrong, the solution would be to move the dh_* stuff from binary-indep to real-binary-indep or something and have     binary-indep: build install real-binary-indep clean)
[11:15] <RainCT> btw, why do you want it to clean up automatically? I can't recall any package doing this
[11:15] <persia> RainCT: Not cleaning up tends to cause the failure-to-build-twice-in-a-row bug
[11:16] <amikrop> OK. What do you recommend me to do? Cleaning up automatically? Not doing so? And how to do the right thing?
[11:16] <RainCT> persia: no, dpkg-buildpackage calls the 'debian/rules clean' before building
[11:18] <persia> RainCT: Right.  Different definition of "automatic" :)
[11:18] <amikrop> I mean, if you recommend to clean up automatically, how should I do this, and if you don't recommend to clean up automatically, where to place my clean commands, and how to act?
[11:18] <RainCT> :)
[11:18] <amikrop> In a word, what do you suggest?
[11:18] <persia> amikrop: If you have a well defined clean: rule, the build tools should take care of it.
[11:18] <persia> Drop the dependency from install:
[11:19] <amikrop> The entries nect to someentry: are dependencies?
[11:19] <amikrop> *next
[11:19] <persia> Yes.
[11:22] <amikrop> persia: And how "dependencies" work? If we have "someentry: foo bar", that means for "someentry" to work, "foo" and "bar" must be defineD?
[11:22] <amikrop> * defined
[11:23] <persia> Yes, and then make will ensure foo and bar are present before processing someentry (unless foo or bar are defined in .PHONY, in which case they get processed regardless of presence)
[11:27] <RainCT> persia: btw, what is .PHONY for?
[11:28] <persia> RainCT: .PHONY indicates to the make processor that the rule should always run, regardless of the presence of a file of that name.
[11:28] <persia> When processing dependencies, make will ensure that if any dependency is updated, the rule will be rerun making the newer file, although .PHONY complicates this.
[11:29] <persia> Think about the case where there is a .c file, and an executable.
[11:29] <persia> The rule to make the executable depends on the .c file, and generates the executable file.
[11:29] <bliZZardz> anyone lookedat Bug #242303?
[11:29] <persia> If the .c file is newer than the executable, it will be run again.  If the .c file is older than the executable, it will not be rerun.
[11:30] <persia> If you add a .PHONY clean rule, it will always run clean, even if there is a file called clean in the target directory.
[11:30] <amikrop> persia: So, how do you recommend to have my debian/rules file?
[11:30] <persia> amikrop: I tend towards CDBS, but you've not gone that way, and I don't suggest you change now.  Just don't have install depend on clean.
[11:30] <amikrop> http://paste.ubuntu.com/22324/
[11:30] <amikrop> Is that alright?
[11:31] <RainCT> persia: thanks for the explanation
[11:32] <RainCT> amikrop: if it's a Python package, you've to make use of either dh_pycentral or dh_pysupport
[11:32] <RainCT> so that they take care of byte-compilation
[11:33] <amikrop> OK. What about the .PHONY? Do I really need it?
[11:39] <amikrop> persia: So, you recommend CDBS? Is that https://wiki.ubuntu.com/PackagingGuide/Complete#head-3111e8aa0617da09b4fb3f0f2b1df8fa19f5d33d enough to read to get started? Will CDBS integrate well with Python's dustutils? Is it easy? Will it cover my needs? Sorry for the many questions :P
[11:40] <persia> amikrop: I don't do much with python, but I believe there's a simple example in the CDBS documentation
[11:40] <amikrop> * distutils
[11:40] <RainCT> amikrop: with cdbs, you just have to include a file for distutils and that will do everything
[11:41] <amikrop> So, you guys, recommend CDBS over manual DebHelper?
[11:41] <mok0> amikrop: https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS
[11:41] <RainCT> see http://wiki.debian.org/DebianPython/NewPolicy
[11:41] <mok0> amikrop: For simple stuff, yes
[11:43] <amikrop> Okay. Thank you, all.
[11:45] <persia> amikrop: Be warned: CDBS is magic.  When it works, it's nice.  When it doesn't work, it can be difficult to understand.
[11:46] <amikrop> persia: Yes, from what I 've read, that is what I thought, too :(
[11:48] <bliZZardz> persia : CDBS more used for Py modules?
[11:48] <persia> bliZZardz: There's a wide variety of packaging methods.  Take a look at those in the Python team SVN repo
[11:52] <LucidFox> Farewell, OOXML.
[11:52] <LucidFox> http://osnews.com/story/19893/Microsoft:_ODF_Has_Clearly_Won
[12:18]  * TheMuso is going to see if he can get the sponsors queue down to 75 or less by the time he goes to bed. Anyone care to join me to make things happen more quickly?
[12:25] <bliZZardz> What is sponsors Q?
[12:27] <TheMuso> bliZZardz: The sponsors queue is a team in launchpad that gets subscribed to bugs that ubuntu contributors file when they want to get a package change uploaded to Ubuntu.
[12:27] <bliZZardz> TheMuso : link please
[12:27] <TheMuso> bliZZardz: http://launchpad.net/~ubuntu-universe-sponsors
[12:28] <bliZZardz> how does it work?
[12:29] <TheMuso> bliZZardz: I suggest you read the links that are given on that page, to apges on the Ubuntu wiki about the sponsorship process.
[12:30] <TheMuso> tjaalton: Re bug 239915, it seems that the latest Debian revision builds successfully on amd64, without needing a merge. Granted I can't test on ia64 for example, but I'm wondering whether this change is still needed.
[12:33] <directhex> TheMuso, honestly, who runs vdr on itanium?
[12:34] <TheMuso> directhex: Yes I know, but if we can avoid an FTBFs even on an architecture that isn't officially supported, its a bonus.
[12:47] <Tooba1> the list at http://revu.ubuntuwire.com/ should be automatically updated after uploading with dput, right?
[12:48] <directhex> TheMuso, well, i don't have anything vaguely debianish on ia64, so can't help with that. want some sles rpm's building, i can see what i can do
[12:49] <TheMuso> directhex: I don't really think its worth worrying about.
[13:07] <siretart> tjaalton: hey, I've noticed that you seem to care and maintain the vdr packages in hardy and intrepid, is that right?
[13:48] <TheMuso> Yay! 8 more merges to get below 100 in the queue!
[13:50] <TheMuso> Well, some of those are bug watches, but meh.
[13:54] <Nitrofurano> hi! i'm looking for people may get interested on packaging wxBasic!
[13:54] <dholbach> TheMuso: we have 41 people in Ubuntu Universe Sponsors - it should be no problem to get the queue cleared :)
[13:54] <TheMuso> dholbach: Should be, yes I agree. Is... Not at the moment.
[13:55] <directhex> i'm waiting for a package or two to hit unstable before i can get merging dealt with
[13:55] <Nitrofurano> people used to package projects using wxWidgets may be skilled enough to package wxBasic?
[13:56] <directhex> TheMuso, a few packages listed on merges.ubuntu.com appear to only need syncing now. is there a proper way to mark them as no longer needing merging?
[13:58] <TheMuso> directhex: Not on MoM.
[13:58] <TheMuso> directhex: What is supposed to happen is that they vanish from MoM once they are synced, but MoM doesn't appear to be updating.
[14:00] <Tooba1> forget my last message; now my package appears in http://revu.tauware.de, I just had given wrong dput arguments
[14:05] <Nitrofurano> btw, i registered over 100 projects on launchpad.net - how can MOTU people see them and check the possibility of packaging them?
[14:06] <directhex> Nitrofurano, IMHO, a very important rule of packaging is "only package things you personally use"
[14:09] <TheMuso> directhex: Totally agree.
[14:11] <sistpoty|work> hi folks
[14:11] <TheMuso> Hey sistpoty|work.
[14:11] <sistpoty|work> hi TheMuso
[14:13] <ScottK> Nitrofurano: Most MOTU are pretty busy.  They've no shortage of stuff to work on, so if you want something packaged, the most reliable way to get that done is learn how and do it yourself.
[14:16] <Nitrofurano> thanks...
[14:17] <Nitrofurano> i'm having difficulties to packaging even following the usual documentation (from debian and ubuntu documentation webpages)
[14:19] <Nitrofurano> the reason of some projects i registered at launchpad were projects were only available as source and i had difficulty on compiling them, as well having them officially packaged would be easier to newbies istall them, as well would make them more visible, at least from Ubuntu users...
[14:19] <Nitrofurano> but the most i were using were wxBasic and sdlBasic anyway...
[14:20] <Nitrofurano> Miriam Ruiz tried to start packaging sdlBasic, but she has lack of time and with some specific difficulties compiling it...
[14:22] <Nitrofurano> Maybe people used to package wxWidget-based tools could help packaging wxBasic as easy, since they used to have preinstalled wxWidgets libraries, and have the experience enough, than me constantly getting frustrating on hugelly trying and getting no results...
[14:23] <Nitrofurano> a goal would be if some wxWidgets-based packager would enjoy somehow wxBasic, and getting interesting on help packaging - what do you all think?
[14:24] <Nitrofurano> thanks! :-D
[14:25] <Nitrofurano> Personally i had some very naif experience on making .deb files from .sh scripts with 'ar' command - but the result is hugelly amateur - and my make/configure experience is completelly disastrous...
[14:39] <Tooba1> I'm not a big Launchpad expert, but does it even make sense to register on Launchpad projects that 1) you don't develop 2) use none of Launchpad's features and 3) already have an official site? I'm looking at https://launchpad.net/sdlbasic/, and don't understand how it's useful.
[14:40] <TheMuso> Tooba1: If it already has an official site/version control repository with code, the only real use is to store bzr branches for ubuntu-specific changes if any. Otherwise, yes IMO it is useless.
[14:41] <Tooba1> sure. I'm afraid this is the second case.
[14:41] <broonie> Don't the project pages get created automagically for anything with an Ubuntu package?
[14:42]  * TheMuso does one merge before turning his attention elsewhere, like a meeting he is attending, then bed. :)
[14:42] <TheMuso> broonie: No afaik.
[14:42] <Tooba1> broonie: I think what you say applies only on apps' packages
[14:42] <broonie> Interesting. There were certainly an awful lot created in that way at some point in the past.
[14:42] <Tooba1> not on apps themselves
[14:43] <broonie> Tooba1: I'm not sure what you mean by an "apps package"?
[14:43] <broonie> Obviously, the automagic creation is based on the name it's packaged with...
[14:45] <Tooba1> maybe I used the wrong words, but I mean the difference between https://bugs.launchpad.net/blender and https://bugs.launchpad.net/ubuntu/+source/blender
[14:46] <Tooba1> AFAIK, the first is not created automagically
[14:47] <TheMuso> Ok, thats enouh for this evening. The total number of entries in the uus queue is now below 100, at least for a while.
[14:48] <Tooba1> Nitrofurano: are you sure all those 100 and over projects registered on launchpad have a sense?
[14:48] <sistpoty|work> excellent TheMuso!
[14:48] <TheMuso> sistpoty|work: Thanks, the queue still has a fair bit of stuff left to be processed, but its size is hopefully reduced somewhat.
[14:49] <sistpoty|work> :)
[14:59] <broonie> Tooba1: No, the first one appears (or used to appear) all by itself too.
[15:00] <mouz> can someone please nuke touchfreeze on REVU? It was intended for my PPA.
[15:00] <TheMuso> mouz: Simply log into revu, and archive it. As simple as that.
[15:01] <dholbach> TheMuso: THANKS for sending that mail :)
[15:01] <TheMuso> dholbach: wow that was quick, np anyway.
[15:03] <Tooba1> broonie: you're right. They are (were?) registered by http://launchpad.net/~registry
[15:05] <Tooba1> bye
[15:06] <lukehasnoname> oh my GOD Brainstorm isn't slow anymore
[15:07] <Nitrofurano> all those 100 and over projects have sense, specially when i'm seeing some of them becoming packaged anyway...
[15:11] <Nitrofurano> a personal project i registered there, https://launchpad.net/bitmapdump, is dependant on both sdlBasic and wxBasic - be welcome running it! :-D
[15:11] <mouz> TheMuso: I don't understand: I'm logged in but I can not find the option to archive the package
[15:12] <Nitrofurano> registered there also a game, depending on sdlBasic: https://launchpad.net/bwekamba
[15:13] <TheMuso> mouz: Its on the index page.
[15:13] <sistpoty|work> TheMuso: iirc only reviewers/admins can archive a package
[15:14] <sistpoty|work> (but I'll archive it right now)
[15:14] <TheMuso> sistpoty|work: Right.
[15:18] <mouz> TheMuso: there is a link to archived uploads, there is a paragraph about nuking and archiving, but there is no option to do the action of archiving. I do not see it. Is a package 'accepted' (see mentioned paragraph) when it is in the list? If not: maybe I can not archive because of that?
[15:19] <TheMuso> mouz: As sistpoty|work said above, only reviewers/admins can archive. I'd forgoten about that.
[15:19] <wgrant> mouz: You lack the privileges to archive things. By 'accepted' it means accepted into Ubuntu.
[15:19] <mouz> TheMuso, wgrant: thanks.
[15:19] <sistpoty|work> mouz, TheMuso: I just nuked it
[15:20] <mouz> ok :)
[15:21] <huats> I am merging a package with 2 patches named 03_XXXXX and 03-XXXX (one of them is from debian the other from ubuntu). Would it be a good idea to rename the ubuntu one ?
[15:31] <huats> and in the changelog, do I explain all the ubuntu changes that I drop (because added in debian or upstream) or just the remaining ones ?
[15:38] <bliZZardz> hi - would be this the right forum to ask for some help w.r.t a bug. I can see the fix(or the lack of it). need some help in structuring it
[15:42] <geser> huats: I'd rename the Ubuntu one, just to avoid confusions
[15:43] <geser> huats: I usually only mention the remaining changes
[15:45] <huats> geser: thanks geser
[15:45] <huats> that was my opinion too :)
[16:28] <jdstrand> zul: re bug 239129, I don't think there is a way to nominate for release just one of the several packages
[16:31] <zul> jdstrand: gimma sec
[16:31] <zul> jdstrand: dont think so
[16:31] <jdstrand> zul: I am responding to the comment you made in the report
[16:32] <zul> jdstrand: heh I didnt make that comment though :)
[16:32] <jdstrand> oh heh, of course you didn't :)
[17:37] <Kopfgeldjaeger> could somebody have a look at bug #240191 ?
[17:37] <ScottK> Sure.
[17:38] <ScottK> Kopfgeldjaeger: What is the problem with the current version in Hardy?
[17:38] <Kopfgeldjaeger> ScottK: It does not work because of authentication problems with flickr AFAICS.
[17:39] <ScottK> OK.  To get this in as an SRU, then you need to edit the bug to include a test case.
[17:39] <ScottK> Describe in detail how to demonstrate the problem and then how to test if it's fixed with the new package.
[17:39] <ScottK> Assume the person doing it knows nothing about the package.
[17:39] <ScottK> Add that and then ping me.
[17:40] <Kopfgeldjaeger> OK
[17:51] <Yannig> Hello
[17:51] <Yannig> Can someone help me?
[17:52] <Yannig> I'm coming here on part of Martin Pitt: there is an Occitan dictionary (myspell/hunspell) and I'd like it to be packaged for Ubuntu (in order to have it in language-support-oc).
[17:57]  * sistpoty|work heads home
[17:57] <sistpoty|work> cya
[18:36] <dholbach> Yannig: try talking to pitti on #ubuntu-devel
[18:36] <dholbach> Yannig: you could try ArneGoet1e too, although I guess he'll be asleep
[18:44] <Yannig> Thanks dholbach
[19:50] <emgent> TheMuso: ping
[19:53] <norsetto> greetz
[20:02] <jpds> even' norsetto
[20:02] <norsetto> jpds: hi there
[21:04] <norsetto> Can everybody please shut up for a second? I'm getting confused with all these talks.
[21:04] <DktrKranz> bla bla bla
[21:04] <geser> norsetto: it's so entertaining right now
[21:05] <norsetto> ah, I knew you two had to keep talking :-)
[21:05]  * DktrKranz hides
[21:06]  * norsetto takes the bus to DktrKranz lost tiny village somewhere in Padania
[21:06] <DktrKranz> we have just fog, really hard to discover
[21:06] <lukehasnoname> Where is the root FTP folder by default in Ubuntu?
[21:09] <DktrKranz> norsetto, if you lose yourself along the way, stop in maranello and ask Raikkonen, he will tell you
[21:09] <norsetto> DktrKranz: hey, I might even get a lift ;-)
[21:10] <DktrKranz> better, you will have your ride pimped :)
[21:10] <devfil> DktrKranz: call Xzibit
[21:10] <DktrKranz> devfil, Xzibit is for U.S. version, we should call GdV
[21:11] <devfil> DktrKranz:  then call Fat Joe and Lil' Jon
[21:26] <lukehasnoname> Where is the root FTP folder by default in Ubuntu?
[21:37] <bdoss> If anyone has a spare moment, would they be able to take a look at this? It would be much appreciated: http://paste.ubuntu.com/22428/
[21:38] <Kopfgeldjaeger2> lukehasnoname: I guess that depends on the FTP server. But maybe it's /var/ftp or so
[21:39] <lukehasnoname> I realized that Ubuntu doesn't have an "official" ftp program like it does with web
[22:05] <norsetto> bdoss: and what can we do about your problem?
[22:05] <bdoss> norsetto: was wondering if anyone else had experienced the same problem
[22:05] <directhex> lukehasnoname, nautilus
[22:06] <directhex> oh, you mean server
[22:06] <norsetto> bdoss: if you tell us at least the name of the package, we might be able to check
[22:06] <lukehasnoname> ya, I figured out what I need to know I think
[22:06] <lukehasnoname> thanks though directhex
[22:06] <bdoss> norsetto: it's an internal package hosted by our department that's not kept on the main ubuntu mirrors
[22:07] <directhex> then your debian/control is wrong
[22:07] <norsetto> bdoss: ok, can you paste the control file? Is your archive consistent?
[22:08] <ScottK> bdoss: It's hard to know exactly what the problem is without the actual package.
[22:08] <bdoss> norsetto: can do, one second
[22:08] <bdoss> norsetto: the problem originated when we changed the "Section" field in the debian control file
[22:09] <norsetto> bdoss: so you may need to change the archive override
[22:11] <bdoss> norsetto: here are the current control files, the base package first and the dependency listed second: http://paste.ubuntu.com/22432/
[22:13] <bdoss> norsetto: i'm not familiar with changing the archive override, for the most part everything in the Packages and Sources file in our mirror's directory seem up to date
[22:13] <ScottK> What is the exact (and complete) error you get when you try to install.
[22:15] <bdoss> ScottK: http://paste.ubuntu.com/22433/
[22:17] <bdoss> ScottK: additionally, I have checked the incoming folder in mini-dinstall can nothing was in it
[22:17] <ScottK> And you did apt-get update before the install so apt knew about the current versions of everything in the archive?
[22:18] <bdoss> ScottK: yes
[22:18] <norsetto> bdoss: what does apt-cache say about lcsee-mail-setup?
[22:19] <ScottK> Did you look in /var/log/dpkg to see if there were any hints about it there?
[22:19] <bdoss> bdoss: apt-cache policy can find the package in our repository with 500 as the pinning
[22:19] <directhex> is that apt-get or aptitude?
[22:19] <bdoss> err.
[22:19] <bdoss> norsetto: apt-cache policy can find the package in our repository with 500 as the pinning
[22:19] <norsetto> bdoss: and the correct version?
[22:20] <bdoss> ScottK: I didn't think to check there, but I will next time I encounter it (going to replicate ASAP)
[22:20] <bdoss> norsetto: yes
[22:21] <bdoss> norsetto: everything I've looked through seem fine, and I've even searched some of the config files in the repository but could find nothing -- my gut tells me there's something wrong with our database? maybe was corrupted somehow? mini-dinstall has been failing periodically on our mirror recently
[22:27] <norsetto> bdoss: I can't pinpoint any particular issue with this info, try to regenerate the whole archive, it can't make matter worse
[22:27] <RoAkSoAx> asac, ping
[22:28] <bdoss> norsetto: ok, thanks for the help
[22:28] <lukehasnoname> £68 today
[22:28] <norsetto> bdoss: np
[22:29] <asac> RoAkSoAx: ?
[22:29] <RoAkSoAx> asac, need your help :)
[22:29] <RoAkSoAx> asac, you merged blam the last time right?
[22:29] <bdoss> ScottK: thanks for the help as well
[22:29] <ScottK> Such as it was ...
[22:32] <RoAkSoAx> asac, im trying to merged it fro intrepid, and i have some questions about it... in the Build-Deps you changed libxul-dev (>= 1.8) for xulrunner-1.9-dev right? the thing is that now, i updated the autotools rerun patch, but if i use xulrunner-1.9-dev instead of libxul-dev in the Build-Deps, it won't build... and it builds when using libxul-dev
[22:33] <asac> RoAkSoAx: did you keep the patch (if any)?
[22:33] <sebner> norsetto: ping my big bear
[22:33] <RoAkSoAx> asac, i kept 10_xul1.9.patch and updated the 99_autotools_rerun.patch
[22:34] <asac> RoAkSoAx: how does it fail then?
[22:34] <sebner> asac: will annoy you tomorrow with a question about monodevelop =)
[22:34] <norsetto> sebner: big and hairy ...
[22:34] <RoAkSoAx> asac, when using xulrunner-1.9-dev in the build-deps instead of libxul it shows: checking for MOZILLA_COMPONENT... configure: error: Package requirements (mozilla-gtkmozembed >= 1.7 mozilla-xpcom >= 1.7) were not met:
[22:34] <norsetto> sebner: good news I hope? Shall we call you doktor already?
[22:34] <sebner> norsetto: PASSED!!! :D
[22:34] <RoAkSoAx> but when using llibxul-dev (>= 1.8) it builds
[22:35] <asac> RoAkSoAx: most likely the autotools rerun patch isnt right then
[22:35] <norsetto> i.e. sebner sounds good
[22:35] <sebner> norsetto: thanks
[22:35] <sebner> norsetto: btw
[22:35] <asac> RoAkSoAx: do you see libxul-embedding in the "patched" configure.in ?
[22:36] <asac> RoAkSoAx: if so. look in "patched" configure and see if its in there too
[22:36] <sebner> norsetto: you konw. *I* am an ubuntu contributor so don't even *think* about it that I just copy&paste the last changelog entry. have you even looked at the flightgear debdiff? I suppose no ;) I usually paste the old changelog entry so the sponsor can look at the changes exactly
[22:37] <asac> sebner: whats up with monodevelop?
[22:37] <asac> you gecko-cli merge missing?
[22:37] <asac> gecko-cil ;)
[22:37] <sebner> asac: bah, have to look closly. I'm really tired. passed today my exams aka abitur in germany ;)
[22:37] <RoAkSoAx> asac, yep i see them im both
[22:37] <norsetto> sebner: What are you bubbling about? what is the problem?
[22:38] <asac> RoAkSoAx: post config.log
[22:38] <sebner> norsetto: Your comments (flightgear). You complained about things that aren't in my debdiff ^^
[22:38] <asac> sebner: congrats !
[22:38] <sebner> asac: thx :D
[22:39] <norsetto> sebner: and what would that be?
[22:39] <RoAkSoAx> asac, asac, autotools_rerun patch: http://pastebin.ubuntu.com/22439/ ...  xul1.9 patch  http://pastebin.ubuntu.com/22440/
[22:39] <sebner> norsetto: debian/control: we can keep the debian standards-version and also remove the relative changelog entry
[22:39] <norsetto> sebner: yes?
[22:39] <sebner> norsetto: remove config.sub config.guess from debdiff
[22:39] <sebner> not in my debdiff ...
[22:40] <asac> RoAkSoAx: config.log ;)
[22:40] <norsetto> sebner: what, the config files?
[22:41] <RoAkSoAx> asac, and there's no config.log (or where can i find it) ?? (im a newbie :P)
[22:41] <asac> RoAkSoAx: build the package. if it fails there should be a config.log :)
[22:41] <asac> either in the top level dir (next to the configure.in file) ... or otherwise run find -name config.log in the build tree ;)
[22:41] <asac> there should be one
[22:42] <sebner> norsetto: one of your comments was: "remove config.sub config.guess from debdiff" <-- but in my debdiff aren't that files to delete ....
[22:42] <norsetto> sebner: ok, anything else?
[22:43] <sebner> norsetto: I'm suprised why we now go back to debian/menu and debian/copyright because you changed that
[22:44] <norsetto> sebner: yes, its not worth to keep that delta
[22:44] <sebner> norsetto: ^^, you should have told me earlier :)
[22:45] <norsetto> sebner: why? What is the added value of a contributor brain then?
[22:45] <RoAkSoAx> asac, ok this is the error showed: http://pastebin.ubuntu.com/22443/ and there's no config.log generated
[22:45] <sebner> norsetto: well, it's true that I'm brainless today (at least) ^^
[22:47] <leleobhz> gn8 guys!
[22:48] <sebner> norsetto: what's now worth keeping? the .xpm? what else?
[22:49] <norsetto> sebner: just read it again tomorrow with a fresh mind
[22:53] <sebner> norsetto: kay ^^
[23:02] <sebner> gn8 folks =)
[23:06] <RoAkSoAx> asac, the error showed is: http://pastebin.ubuntu.com/22443/ and there's no *.log generated
[23:09] <asac> RoAkSoAx: looks wrong :)
[23:10] <asac> RoAkSoAx: did you merge debian/rules too?
[23:10] <RoAkSoAx> asac, nopee, this is my debian/rules: http://pastebin.ubuntu.com/22450/
[23:11] <asac> RoAkSoAx: yeah. that should be auto discovered
[23:11] <asac> cant tell if you dont find you config.log :)
[23:12] <asac> my guess is still that configure or so isnt applied properly
[23:12] <asac> as it doesnt try libxul-embedding-unstable ... which would be available if xulrunner-1.9-dev is installed+
[23:12] <asac> and libxul-embedding-unstable comes before mozilla-gtkmozembed in configure.in for me
[23:13] <asac> RoAkSoAx: go in the patches build tree and run:
[23:13] <asac> ./configure --help
[23:13] <asac> and paste the output
[23:15] <RoAkSoAx> asac, here: http://pastebin.ubuntu.com/22451/
[23:15] <asac> RoAkSoAx: look at line 89
[23:16] <asac> the autoconf rerun patch is not properly applied
[23:16] <asac> or even configure.in is not properly applied
[23:16] <asac> there should be libxul-embedding-unstable in the options
[23:16] <asac> if you look at the xul 1.9 patch you should see that
[23:25] <asac> RoAkSoAx: ok i think i see whats going on. its indeed that mozilla-gtkmozembed is tested in configure.in before libxul-... is tested
[23:25] <asac> so flip that order in the xul patch ... and update autoreconf patch
[23:25] <asac> e.g. move the test for mozilla to test end of the tests
[23:25] <Falken> Hi, my package needs to be reviewed : http://revu.ubuntuwire.com/details.py?package=flabber
[23:25] <RoAk> asac, sorry lost my inet connect for some secs, the last thing i read was <asac> if you look at the xul 1.9 patch you should see that
[23:27] <RoAkSoAx> asac, in both patches that's changed
[23:27] <RoAkSoAx> -  --with-mozilla[=mozilla|firefox|thunderbird|xulrunner|seamonkey]
[23:27] <RoAkSoAx> +  --with-mozilla[=mozilla|firefox|thunderbird|libxul-embedding-unstable|xulrunner|seamonkey]
[23:27] <RoAkSoAx> and here:
[23:27] <RoAkSoAx> -	AC_HELP_STRING([--with-mozilla@<:@=mozilla|firefox|thunderbird|xulrunner|seamonkey@:>@],
[23:27] <RoAkSoAx> -		       [Whether to use mozilla, firefox, thunderbird, xulrunner or seamonkey gtkmozembed (default: mozilla)]),
[23:27] <RoAkSoAx> +	AC_HELP_STRING([--with-mozilla@<:@=mozilla|firefox|thunderbird|libxul-embedding-unstable|xulrunner|seamonkey@:>@],
[23:27] <RoAkSoAx> +		       [Whether to use mozilla, firefox, thunderbird, libxul-embedding-unstable, xulrunner or seamonkey gtkmozembed (default: mozilla)]),
[23:28] <RoAkSoAx> (sorry for flooding)
[23:28] <asac> RoAkSoAx: thats all ok . the order of the tests further down is what matters
[23:28] <asac> in the patch you see that firefox is tested before libxul-embedding
[23:28] <asac> if you look in configure.in you will see that mozilla i even tested before
[23:29] <asac> move mozilla test further down
[23:29] <asac> or pass --with-mozilla=libxul-embedding-unstable to configure in debian/rules
[23:29] <RoAkSoAx> asac, this one? +elif test "x$with_mozilla" != "xmozilla" -a "x$with_mozilla" != "xfirefox" -a "x$with_mozilla" != "xthunderbird"-a "x$with_mozilla" != "xxulrunner"-a "x$with_mozilla" != "xseamonkey"-a "x$with_mozilla" != "xlibxul-embedding-unstable"; then
[23:29] <RoAkSoAx> i should move xlibxul-embedding-unstable before the xxulrunner?
[23:30] <asac> RoAkSoAx: no before the "mozilla" even.
[23:30] <asac> its mozilla that causes issues here
[23:30] <asac> RoAkSoAx: better pass --with-mozilla=... as configure flag in debian/rules
[23:30] <asac> moving things in configure.in is an ugly hack if you can just use --with-mozilla :)
[23:31] <RoAkSoAx> asac, oh so i just pass --with-mozilla=... in debian/rules and that should be good enough?
[23:36] <TheMuso> emgent: Hi. What can I do for you?
[23:36] <tbielawa> hey RoAkSoAx long time no talk
[23:37] <RoAkSoAx> asac, so i would have to left my debian/rules like this?? http://pastebin.ubuntu.com/22458/ _(adding the build, is it ok??)
[23:37] <RoAkSoAx> tbielawa, heya!! yeah pretty long time, how ya doing?
[23:37] <tbielawa> RoAkSoAx, good! playing WoW is not condusive to getting MOTU things done
[23:38] <RoAkSoAx> tbielawa, hahaha yeah i'm back to packaging after a Few weeks of playing NFS Pro Street and finishing my thesis :)
[23:39] <asac> RoAkSoAx: if you pass just one option it could work :)
[23:40] <RoAkSoAx> asac, so i should just pass libxul-embedding-unstable, right?
[23:40] <asac> RoAkSoAx: y
[23:41] <asac> RoAkSoAx: oh. it wont work
[23:41] <asac> RoAkSoAx: figure how to do that properly with CDBS
[23:41] <asac> cdbs
[23:41] <asac> but you dont need me for that I guess ;)
[23:42] <RoAkSoAx> asac, haha yeah, but just to be sure i just need to create a new patch, patching debian/rules by adding " build: ./configure --with-mozilla=libxul-embedding-unstable "
[23:43] <RoAkSoAx> right?
[23:44] <asac> no
[23:44] <asac> but you will find a way to add that configure option ... i am sure
[23:44] <asac> hint: you never patch debian/rules
[23:45] <asac> there are hundreds of packages that add configure flags through cdbs :)
[23:45] <asac> look at one of the none-trivial gnome packages for instance
[23:45] <RoAkSoAx> asac, oh ok :) i'll investigate then :D thank you very much for your help
[23:46] <Laney> RoAkSoAx: You just need to set DEB_DH_CONFIGURE_EXTRA_FLAGS
[23:47] <Laney> Sorry, DEB_CONFIGURE_EXTRA_FLAGS
[23:47] <RoAkSoAx> Laney, thanks :D
[23:49] <rawler> can someone help me figure why pbuilder considers libqt4-opengl-dev to be "a virtual package" ?
[23:49] <rawler> (for hardy)
[23:50] <emgent> TheMuso: if you have time please see bug #229097+
[23:50] <TheMuso> emgent: Ok I'll probably get to it some time today.
[23:51] <rawler> $(dpkg -L ﻿libqt4-opengl-dev) seems to have some files installed at least, so not sure what pbuilder means by virtual?
[23:51] <emgent> TheMuso: nice, thanks :)
[23:55] <rawler> I've tried adding universe to the fakeroot, but that doesn't seem to have helped.. anyone's got any ideas?