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