[00:01] <bdrung> ari-tczew: main is frozen
[00:01] <dupondje> when is universe frozen ?
[00:01] <tumbleweed> dupondje: feature freeze
[00:01] <Laney> some time after final freeze
[00:02] <tumbleweed> bleh
[00:02] <Laney> depending on what you mean by frozen
[00:02] <ari-tczew> frozen? wtf?
[00:02] <dupondje> not accepting new merges/syncs :)
[00:02] <ajmitch> ari-tczew: just for alpha 3
[00:02] <ari-tczew> ajmitch: it will be unfrozen?
[00:02] <ajmitch> yes
[00:02] <Laney> The method of the upload doesn't matter, just the content of the changes therein
[00:03] <dupondje> freezes are boring :) we want to live on the edge !
[00:03] <tumbleweed> dupondje: if they are important, they are accepted after feature freeze
[00:03] <dupondje> hmz ok :)
[00:03] <ari-tczew> even fix ftbfs won't be uploaded?
[00:03] <tumbleweed> well, not important so much as "probably safe"
[00:04] <Laney> tumbleweed: you are looking for "bug fixes"
[00:04] <bdrung> ari-tczew: in two days after the alpha 3 release
[00:04] <tumbleweed> Laney: thanks :)
[00:04] <ajmitch> ari-tczew: alpha freezes just last 2-3 days, and generally uploads of things that fix problems on the CDs can be uploaded
[00:04] <ajmitch> it's just a chance for the archive to settle down a bit so that an alpha can be released in an installable state
[00:04] <Laney> Freezes aren't boring, they are nice. Unfrozen things break.
[00:05] <Laney> Say hello to dpkg and autoconf recently
[00:05] <ajmitch> it's not like you actually wanted anything in your binary packages anyway
[00:05] <Laney> vacuous bug-freeness?
[00:05] <Laney> I like the idea
[00:06] <ajmitch> we were discussing this in #ubuntu-nz yesterday
[00:06] <ajmitch> 10:46 < thumper> snail: there are no bugs in no code
[00:06] <ajmitch> 10:46 < snail> there are an infinite number of bugs in no code
[00:06] <ajmitch> which is true, I do not know :)
[00:07] <ajmitch> though the code in question was LP, which changes things somewhat
[00:07] <bdrung> first it's always possible to strip one line of source code and second your program contains at least one bug.
[00:08] <bdrung> therefore you can reduce your program to one faulty line. :D
[00:09] <Laney> the second one is breaking my brain
[00:09] <Laney> I don't think it's right
[00:09] <bdrung> an other maxim: software is either buggy or outdated.
[00:09] <bdrung> Laney: you have to apply induction
[00:10] <Laney> not yours
[00:10] <Laney> that's just plain wrong :P
[00:11] <dupondje> bdrung: beta2 of audacious came out 2 days ago. Will you package it ? :)
[00:11] <bdrung> dupondje: i will put it on my todo list. it will be processed after vlc.
[00:11] <dupondje> nice nice :)
[00:12] <dupondje> cause new version is kinda sweet
[00:30] <ari-tczew> I've got ftbfs: /bin/sh: libtoolize: not found
[00:30] <ari-tczew> what's the problem?
[00:31] <dutchie> it didn't find libtoolize</obvious>
[00:32] <ari-tczew> what's the package?
[00:33] <jpds> ari-tczew: libtool.
[00:33] <jpds> ari-tczew: I suggest using apt-file for looking for files within packages.
[00:38] <bdrung> dupondje: i am working with -j2. i am compiling audacious. next step: audacious-plugins.
[01:26] <bdrung> dupondje: i am faster than i thought. i am uploading audacious
[01:47] <micahg> highvoltage: you sitll around?
[01:49] <highvoltage> micahg: yep
[01:50] <micahg> highvoltage: saw your post on u-d@l.u.c about an official PPA finder, wanted to say the Mozilla team has been kicking around the idea for a tool like that for a while now, if someone ever writes one, I can let you know
[01:51] <micahg> highvoltage: I actually discussed it at one of the UDS sessions, but the focus seems to be more on the blessed new apss for stable release
[01:53] <highvoltage> micahg: great! yeah some people aren't so crazy about the idea but I thinkit could have some value to many people
[01:58] <bdrung> DktrKranz: ready for uploading u-t-d 0.101 to unstable?
[01:59] <RAOF> A simple thing like having a PPA associated with a project would cover a lot of that, I think.
[02:00] <micahg> RAOF: well, the problem at least for the Mozilla team is switching back and forth between stable/beta/daily/archive on demand
[02:02] <highvoltage> RAOF: *nod* and it does
[02:03] <RAOF> micahg: Well, a trivial generalisation of my idea would be to display all the PPAs of the user/team which owns the project.
[02:04] <micahg> RAOF: ah, that might work, we're grouping all our PPAs under the mozillateam team and kubuntu-ppa has all theirs groups
[04:13] <micahg> I forget, are we supposed to leave the builders free in case of emergency, or can we upload unseeded packages?
[04:17] <RAOF> micahg: "Unseeded packages can be uploaded as normal"
[04:17] <micahg> RAOF: did I just not read the notice well enough?
[04:17]  * micahg apparently did :-/
[06:56] <eagles0513875> hey shadeslayer
[07:33] <DktrKranz> bdrung: did you do your changes? Yesterday, I committed changes to Maintainer and Uploaders
[07:41] <eagles0513875> hey guys is there a channel that deals with xorg and video card drivers?
[07:42] <tumbleweed> eagles0513875: #ubuntu-x
[07:42] <eagles0513875> ty tumbleweed :)
[07:53] <dholbach> good morning
[07:57] <eagles0513875> morning dholbach
[07:57] <dholbach> hi eagles0513875
[09:06] <huats> morning
[09:43] <bdrung> DktrKranz: yes. it's ready for realease
[09:44] <DktrKranz> ok
[10:26] <DktrKranz> bdrung: releasing, and uploading
[10:26] <DktrKranz> I'll do in Debian first, then immediately sync
[10:26] <bdrung> DktrKranz: yes, thanks
[10:37] <bdrung> DktrKranz: there was an merge request: https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/+activereviews
[10:39] <DktrKranz> bdrung: I didn't finalize it yet, want to merge it first?
[10:40] <bdrung> DktrKranz: looks sane. can you check it and merge it? i have to leave now. bbl
[10:40] <DktrKranz> ok
[11:18] <DktrKranz> bdrung: all done
[17:09] <CarlosRod> Hello
[17:10] <vish> could someone upload bug 550261 to -proposed?  the bug was on SRU queue for nearly 2 months  without an upload to -proposed
[17:10] <CarlosRod> I need some help packing an aplicattion and making a makefile
[17:10] <CarlosRod> Can you help me in this room? I'm in the correct place?
[17:12] <CarlosRod> Can you please tell me the correct room to get some help for my questions? :)
[17:13] <micahg> CarlosRod: try #ubuntu-packaging
[17:13] <tumbleweed> vish: is ubuntu-sponsors subscribed?
[17:13] <vish> tumbleweed: just subscribed now , apparently the nssbackup team didnt know the procedure
[17:13] <CarlosRod> Thanks you micahg
[17:14] <vish> tumbleweed: they only subscribed the SRU team ..
[17:14] <tumbleweed> vish: I'll look at it later (if nobody else has yet)
[17:14] <vish> tumbleweed: neat , thanks :)
[17:25] <CarlosRod> just one question, if I install a program, where is the binary of the program installed? at /usr/bin/?? where is the data used by the program?? For example if the program needs images, logs or something
[17:26] <dutchie> CarlosRod: the binary goes in /usr/bin, the data normally ends up in /usr/share
[17:26] <dutchie> CarlosRod: you can see what files a package installs by issuing the command "dpkg -L <package>"
[17:26] <CarlosRod> Thanks you and one more question...
[17:27] <tumbleweed> CarlosRod: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
[17:27] <CarlosRod> If I put my binary on bin and the data on share, when programing the source, Should I call these data files with the /data/share/ at the beginning?
[17:27] <CarlosRod> Or the system asumes that?
[17:28] <CarlosRod> The problem is that Im making code source for both windows and linux... And I dont want to change the path of the data used by the program
[17:28] <CarlosRod> thanks you tumbleweed, I will take a look :)
[17:28] <tumbleweed> CarlosRod: make the path configurable at compile-time
[17:28] <tumbleweed> look for the gnu coding standards, if you want to see what teh conventions are
[17:29] <CarlosRod> Ok, thanks you :)
[17:29] <tumbleweed> btw, you'll never have /data/ on a standard system
[17:29] <CarlosRod> And, then, how I should include images and more?
[17:30] <tumbleweed> CarlosRod: btw, this is off-topic for this channel. images are data (most of the time) so /usr/share/<packagename> (or /usr/local/share/<packagename> if installed from source)
[17:31] <CarlosRod> Ok, thanks you :)
[17:32] <CarlosRod> I will try your suggestions :)
[18:54] <ari-tczew> can package from universe build-depends on package from main?
[18:54] <tumbleweed> yes
[18:54] <tumbleweed> vish: looking at your sbackup bug
[18:56] <vish> tumbleweed: neat!
[18:56] <tumbleweed> vish: has it been fixed in maverick? it doesn't look like it...
[18:57] <vish> tumbleweed: no , not uploaded anywhere :(
[18:57] <tumbleweed> ok, policy is to do that first
[18:58] <highvoltage> talking about SRUs?
[18:58] <tumbleweed> highvoltage: yeah
[18:58] <tumbleweed> bug #550261
[18:59] <ari-tczew> I've got ftbfs: dh_install: python-evince missing files (debian/tmp/usr/lib/python*/*-packages/gtk-2.0/evince.so), aborting
[18:59] <ari-tczew> what happened?
[19:00] <tumbleweed> ari-tczew: recreate it :)
[19:00] <ari-tczew> tumbleweed: what recreate ?
[19:00] <tumbleweed> I mean try and build it, see what went wrong
[19:00] <tumbleweed> where that file actually is
[19:01] <ari-tczew> tumbleweed: I build it with pbuilder
[19:01] <tumbleweed> ari-tczew: I use the C10shell hook so I can debug failures
[19:06] <ari-tczew> tumbleweed: I remember some situations when change *site to *dist-packages fixes ftbfs
[19:06] <tumbleweed> ari-tczew: yes, but that was *-packages
[19:06] <tumbleweed> python 2.6 uses dist-packages, < 2.6 uses site-packages
[19:07] <ari-tczew> tumbleweed: so I can't reproduce it and can't fix it.
[19:07] <tumbleweed> ari-tczew: I'll have a look
[19:08] <ari-tczew> tumbleweed: maybe should I change to /*dist-packages?
[19:08] <tumbleweed> ari-tczew: no, that glob you pasted in th eerror looked correct
[19:09] <ari-tczew> tumbleweed: sorry, too hard for me
[19:14] <tumbleweed> ari-tczew: it just built in my pbuilder
[19:16] <ari-tczew> tumbleweed: which package?
[19:19] <tumbleweed> ari-tczew: gnome-python-desktop_2.30.0-1ubuntu3
[19:20] <tumbleweed> (was that not the ftbfs you were talking about?)
[19:21] <ari-tczew> tumbleweed: ah, 1 hour ago fixed
[19:21] <ari-tczew> tumbleweed: I got on my disk package from yesterday
[19:22] <tumbleweed> always nice when someone else fixes the bug :)
[19:22] <ari-tczew> heh
[19:26] <ari-tczew> we need perl 5.12 in ubuntu :(
[19:59] <pting> i'm trying to push up to launchpad a package that requires sun-java6-sdk, but it's complaining about the missing dependency. how do i specify to include the partner repo?
[20:01] <tumbleweed> pting: you can't depend an partner in main/universe. Does it not build with openjdk?
[20:16] <pting> tumbleweed, possibly, but i haven't tried
[20:41] <ari-tczew> please look, https://launchpad.net/ubuntu/+source/opendrim-lmp-dns/1.1.0-0ubuntu1/+build/1892064
[20:41] <ari-tczew> why it's ftbfs? Missing build dependencies: sfcb
[20:41] <ari-tczew> but it's available: https://launchpad.net/ubuntu/+source/sblim-sfcb/1.3.8-0ubuntu1/+build/1850332
[20:46] <geser> ari-tczew: look at the compontents
[20:46] <geser> sfcb is in multiverse and opendrim-lmp-dns is in universe
[20:47] <ari-tczew> geser: so it never be built?
[20:49] <geser> no, unless the components get fixed
[20:49] <geser> ari-tczew: opendrim-lpm-dns needs to get moved to multiverse (like the other opendrim-* packages)
[20:50] <geser> and I see that the opendrim-lpm-* binary packages are also in the wrong component: they are in universe while their source is in multiverse
[20:50] <ari-tczew> geser: my observation: FTBFS is gigantic chain of packages.
[20:53] <geser> what you mean with "gigantic chain of packages"?
[20:53] <ari-tczew> geser: https://launchpad.net/ubuntu/+source/red5/0.9.1-1/+build/1730707
[20:53] <ari-tczew> follow for missing packages
[20:54] <ari-tczew> 1package missing of second -> second package missing of third package -> etc..
[20:54] <ari-tczew> but there is a closed while
[20:54] <geser> ah, yes, that happens sometime
[20:54] <ari-tczew> look on this: https://launchpad.net/ubuntu/+source/tiles/2.2.1-2/+build/1731810 and https://launchpad.net/ubuntu/+source/libspring-2.5-java/2.5.6.SEC01-10/+build/1802711
[20:55] <geser> yes, some -java packages have cyclic build-dependencies or even build-depend on themselves :(
[20:55] <maco> wait what?
[20:55] <ari-tczew> how we can fix it?
[20:56] <maco> how can a package build-depend on itself?
[20:56] <hyperair> compilers need to get compiled too.
[20:56] <ari-tczew> maco: no itself
[20:57] <ari-tczew> 1st package depends on 2nd, but 2nd depends on 1st
[20:57] <maco> ari-tczew: yeah thats circular, but read what geser said
[20:57] <ari-tczew> I understand you think that 1st build on the same (1st)
[20:57] <hyperair> oh fun stuff.
[20:58] <geser> ari-tczew: I wanted to ask the Debian Java maintainers for input how to solve this bootstrapping problem for some java packages but didn't found time to do it
[20:58] <ari-tczew> aha
[20:58] <ari-tczew> I'd ping for this micahg and ttx
[20:59] <ari-tczew> ^^
[20:59] <micahg> ari-tczew: why me?
[20:59] <ari-tczew> micahg: because I think that you're familiar with java packages :)
[21:00] <micahg> ari-tczew: ah, that would be a mistaken assumption :)  I consume java packages, might have more luck with bdrung
[21:00] <micahg> ari-tczew: my extent of maintaining java packages only had to do wtih their xul components
[21:00] <micahg> *has
[21:00] <ari-tczew> aha
[21:02] <ari-tczew> hmmm, I think that MoM has been hanged
[21:03] <ari-tczew> it didn't update some time
[21:03] <tumbleweed> ari-tczew: you could retry grab udd-udd-merge
[21:04] <ari-tczew> tumbleweed: did you any updates?
[21:04] <tumbleweed> yes
[21:05] <ari-tczew> tumbleweed: could you give me a changelog?
[21:06] <tumbleweed> ari-tczew: http://bazaar.launchpad.net/~stefanor/ubuntu-dev-tools/grab-udd-merge/changes
[21:09] <ari-tczew> tumbleweed: one suggest to code
[21:09] <ari-tczew> author='Change Me <mom@ubuntu.com>',
[21:09] <tumbleweed> ari-tczew: that will be automatically changed if the user uses dch
[21:09] <ari-tczew> could is it possible to getting an user variables from Ubuntu? e.g. dch -i using this
[21:10] <ari-tczew> ah, so it;s done?
[21:10] <tumbleweed> no, I mean the developer is supposed to edit th echangelog with dch, so they sohuld never see that
[21:10] <micahg> ari-tczew: dch -e edits that away
[21:11] <tumbleweed> I was going to make it say "use dch -e <foo@example.com>" but that'd probably be even more confusing
[21:12] <ari-tczew> aha
[21:20] <ari-tczew> tumbleweed: I will try your updated script, but it not fix a problem with MoM - I'd like to see a packages for merging.
[21:21] <tumbleweed> ari-tczew: obviously, but it's a workaround to a broken mom
[21:22] <ari-tczew> tumbleweed: there is also lucas merges: http://people.ubuntuwire.org/~lucas/merges.html but there aren't a numbers
[21:24] <tumbleweed> ari-tczew: aah. I meant for quick grabbing of the sources you need to do / look at a merge
[22:39] <bdrung> DktrKranz: thanks
[22:52] <ari-tczew> bdrung: are you familiar with java packages?
[22:53] <bdrung> ari-tczew: not that much.
[22:54] <bdrung> ari-tczew: is it debian-related? then ask nthykier in #debian-java
[22:54] <ajmitch> java packages can be a little tricky & annoying at times
[22:54] <bdrung> ajmitch: especially if the source name is 'eclipse'
[22:55] <ajmitch> sorry, I don't have enough RAM to think about that one
[22:55] <ari-tczew> bdrung: we are in the same zonetime, please look on 21:57
[22:55] <ari-tczew> here
[22:57] <ajmitch> ouch, cyclic build-depends
[22:57] <bdrung> ari-tczew: go to #debian-java on otfc and ask nthykier
[22:58]  * ScottK once tried to build eclipse on a machine with 256MB RAM.  It didn't end well.
[22:58] <bdrung> ajmitch: you need only 2 GiB for the compiling process. with 5 GiB RAM you can compile it in tmpfs
[22:59] <geser> ScottK: for you, the machine or both?
[22:59] <ScottK> The machine.
[22:59] <ajmitch> ScottK: I only tend to give my maverick & sid VMs 512MB RAM
[22:59] <ajmitch> they'd have no hope
[23:00] <ScottK> This was ~gutsy, so it was less insane then.
[23:00] <bdrung> ajmitch: it takes 10 mins with enough RAM
[23:00] <ajmitch> not as bad as some
[23:01] <bdrung> ajmitch: on my laptop with only 2 GiB RAM and encrypted hard drive it takes ~ 80 mins
[23:20] <ari-tczew> didrocks: ping on bugs: bug 609634 ; bug 595499 ; bug 609754
[23:21] <ajmitch> ari-tczew: fetchmail debdiff looks to be for exim4
[23:22] <ari-tczew> ajmitch: yea, human mistake. thanks!
[23:24] <ari-tczew> ajmitch: correct file uploaded.
[23:24] <ajmitch> it's sad that I saw fetchmail, remembered merging it in recent times & seeing that it was in 2006
[23:25] <ari-tczew> ajmitch: 2006? o_O
[23:27] <ajmitch> main is still frozen for now, isn't it?
[23:28] <Laney> yep
[23:28] <ajmitch> ok, I'll hold off on uploading then
[23:29] <Laney> have these changes been sent to debian?
[23:29]  * ajmitch is just looking back to see why they were made
[23:29] <ajmitch> bug 254254
[23:30] <ajmitch> looks to be the closest
[23:30] <Laney> looks merged even
[23:30] <Laney>    * Not explicitly stop daemon on runlevel 0 and 6 (Closes: #498427).
[23:30] <ajmitch> might be the wrong bug, I was just reading from the changelog