| slicer | How do I actually close a "needs-packaging" bug after the package is included in hardy? | 00:10 |
|---|---|---|
| ScottK | slicer: After the package is uploaded to the Ubuntu repository, just change it to fix released in LP. | 00:12 |
| slicer | ScottK: Fix released. Rgr :) | 00:12 |
| === a3p is now known as a7p | ||
| bddebian | Heya gang | 00:51 |
| RAOF | Howdie bddebian. | 00:52 |
| bddebian | Hi RAOF | 00:52 |
| TheMuso | Anybody from the MOTU media team around who works on mplayer? | 00:53 |
| superm1 | TheMuso, i've touched it a lot | 00:59 |
| superm1 | but i'm not on MOTU media... | 00:59 |
| TheMuso | superm1: Thats alright. Do you know if the pulseaudio code for mplayer is the latest? Doing a straight diff between whats in bzr and svn shows a lot of changes, but I'm not sure at a glance whether lots has been changed. | 01:00 |
| superm1 | TheMuso, it should | 01:00 |
| TheMuso | superm1: I ask because I'm making sure mplayer has the best support for pulseaudio available, and crimsun_ said I'd need to fetch the latest code from svn to make sure of this. | 01:00 |
| superm1 | i can verify on my work laptop, give me a few minutes to get it installed there | 01:00 |
| superm1 | TheMuso, appears to work on my work laptop, it was a fresh hardy install a few days ago, so pulseaudio should be set to default right? | 01:06 |
| TheMuso | superm1: I don't know how mplayer works in this regard. Does it just use pulseaudio if pulseaudio is running? | 01:06 |
| superm1 | well i'd expect so. | 01:07 |
| superm1 | let me force the driver to make sure its pulse then | 01:07 |
| superm1 | TheMuso, yeah it continues to work when I forced it with asoundconf | 01:08 |
| TheMuso | superm1: asoundconf? Do you mean using the pulse alsa plugin? | 01:14 |
| superm1 | yeah | 01:14 |
| TheMuso | Hrm I'll have to try it here myself. | 01:14 |
| superm1 | asoundconf set-pulse | 01:14 |
| TheMuso | I mean pulse natively. | 01:14 |
| TheMuso | anyway, I'll test it. | 01:14 |
| superm1 | er asoundconf set-pulseaudio | 01:14 |
| superm1 | TheMuso, oh if you want to test natively | 01:15 |
| superm1 | mplayer -ao pulse | 01:15 |
| superm1 | which also works | 01:15 |
| TheMuso | superm1: But it doesn't use pulse by default? | 01:16 |
| superm1 | TheMuso, i dont believe pulse is the default audio output | 01:16 |
| TheMuso | superm1: Right, do you think its something worth considering/ | 01:16 |
| superm1 | TheMuso, its set as alsa, | 01:16 |
| superm1 | which means alsa and then anything else | 01:16 |
| superm1 | if that doesn't work | 01:17 |
| TheMuso | Oh ok. | 01:17 |
| TheMuso | I'll test here anyway. | 01:17 |
| superm1 | well i suppose that priority can be adjusted | 01:17 |
| superm1 | see /etc/mplayer.conf | 01:17 |
| superm1 | it instead its set to | 01:17 |
| superm1 | ao=alsa,pulse, | 01:17 |
| superm1 | er | 01:17 |
| superm1 | ao=pulse,alsa | 01:17 |
| superm1 | ao=pulse,alsa, | 01:17 |
| superm1 | that will do pulse, alsa, and then anything else | 01:18 |
| superm1 | and i just tried it with no pulseaudio running, it just falls back to alsa fine with that setting | 01:18 |
| superm1 | TheMuso, my only worry would be how well does pulse handle multichannel audi | 01:20 |
| superm1 | like more than 2 channels? | 01:20 |
| TheMuso | superm1: I hav eben stress testing it bit here lately, and I've not had any issues. | 01:20 |
| superm1 | TheMuso, against more channels? | 01:21 |
| TheMuso | Yeah I tried using pulse here, and it decided to try alsa, then used esd. | 01:21 |
| superm1 | do you not have alsa available? | 01:21 |
| TheMuso | superm1: Yes, because I've been looking into getting speech using pulse as well. | 01:21 |
| TheMuso | I do, but pulseaudio is the default for GNOME. | 01:21 |
| TheMuso | And it grabs the ALSA device directly, using hw:number | 01:21 |
| superm1 | TheMuso, I think a commit with it defaulting like that (pulse,alsa,) would be worthwhile | 01:22 |
| superm1 | any systems without pulse don't break as it just skips over it | 01:22 |
| TheMuso | Ok, I'll take care of it. | 01:22 |
| superm1 | you have the branch checked out already? (it's a big checkout) | 01:22 |
| superm1 | make sure that the version in the branch matches the current version in the archive. some folks have a horrible habit of updating the version in the archive with changes without committing back to the branch since its so big | 01:23 |
| TheMuso | Yep will do. The first thing I do before working on a new src package these days is check for a VCS. | 01:24 |
| superm1 | if you dont have it checked out already, dont worry i can take care of it if that is all you were intending on changing in it | 01:25 |
| TheMuso | Grrr! And that is very much the case. | 01:25 |
| TheMuso | No I have it checked out. | 01:25 |
| superm1 | okay then carry on :) | 01:25 |
| * TheMuso will fix this up after lunch, including importing Jani's changes! :S | 01:28 | |
| * superm1 shrugs. this is why a warning needs to be issued on debuild if there is a VCS and you haven't updated the VCS | 01:28 | |
| TheMuso | yeah | 01:31 |
| === n3xu|laptop is now known as nexu|laptop | ||
| vorian | how do you properly use --logfile in pbuilder? | 02:04 |
| zul | sudo pbuilder build --logfile <name of log file> | 02:08 |
| vorian | thanks zul | 02:15 |
| TheMuso | Ok, mplayer change made, will not upload, as I'm sure others have things to do with it. :) | 02:17 |
| tonyyarusso | Has anyone asked yet why dholbach a) has posters or nearly naked guys in his room, and b) would include them in a picture posted to Planet? :S | 02:38 |
| === zakame_ is now known as zakame | ||
| === asantoni_ is now known as asantoni | ||
| rjmyst3 | TheMuso: I think I've solved my premake problems | 04:05 |
| TheMuso | rjmyst3: great | 04:11 |
| rjmyst3 | TheMuso: I realized that premake is only useful if the source will move from one operating system to another, or to generate build files for different IDEs | 04:13 |
| rjmyst3 | so now, the orig.tar.gz includes Makefiles, and not premake | 04:13 |
| rjmyst3 | that makes the source architecture independent, as it should be | 04:13 |
| rjmyst3 | with no weirdness with building premake | 04:13 |
| TheMuso | rjmyst3: Sounds great. | 04:15 |
| rjmyst3 | so, i've got a new orig.tar.gz and a new .diff.gz - would you mind taking a look? | 04:15 |
| TheMuso | rjmyst3: Well since its feature freeze, you now have to request an exception to update the package to a new upstream version. I know you're upstream, but it has to be done. | 04:17 |
| TheMuso | rjmyst3: See https://wiki.ubuntu.com/FreezeExceptionProcess fo more info. | 04:18 |
| TheMuso | c | 04:18 |
| rjmyst3 | TheMuso: I interpreted this as a bug fix, not a feature. But, is this worth pursuing? Is an exception likely? Should I just wait until the appropriate time? | 04:18 |
| superm1 | TheMuso, that was something that was talked about i thought, that new versions aren't necessarily needing and exception | 04:20 |
| superm1 | otherwise we are just back at having a UVF | 04:20 |
| superm1 | s/and/an/ | 04:20 |
| TheMuso | superm1: Ah yes, this is true. | 04:20 |
| rjmyst3 | superm1, TheMuso: what should I do? | 04:23 |
| superm1 | rjmyst3, I would be of the opinion get all the appropriate files on a bug, but don't file a freeze exception for this. Just indicate everything that has changed (which i haven't been following, but sounds like it was just the build system to make ppc work) | 04:23 |
| ScottK | Since it's new, we need agreement on how to handle (bugfix only uploads). I've got 4 of 5 motu-release to agree to the proposal I made to the MOTU ML. I get #5 and I'll declare it the policy until a MOTU meeting can agree/disagree. | 04:23 |
| superm1 | rjmyst3, so for now as long as they're all o the bug, as soon as policy is declared we can figure out what to do | 04:24 |
| rjmyst3 | ok, i'll create the bug, thank you | 04:25 |
| slomo__ | superm1: ping? :) | 05:22 |
| Hobbsee | boo | 05:23 |
| * RAOF is startled. | 05:23 | |
| * Hobbsee tickles RAOF with a feather | 05:23 | |
| RAOF | ...and flies up into the canopy. | 05:23 |
| superm1 | hi slomo__ | 05:23 |
| superm1 | thanks for the upload of totem | 05:23 |
| === zakame__ is now known as zakame | ||
| rjmyst3 | TheMuso, superm1, ScottK: The bug# is 192818 | 05:31 |
| rjmyst3 | https://bugs.launchpad.net/ubuntu/+source/wxformbuilder/+bug/192818 | 05:32 |
| ubotu | Launchpad bug 192818 in wxformbuilder "FTBFS on all architectures except i386, amd64, and lpia" [Undecided,New] | 05:32 |
| Hobbsee | email email email... | 05:43 |
| Hobbsee | it's very overrated | 05:43 |
| dholbach | good morning | 05:53 |
| === asac_ is now known as asac | ||
| slomo__ | superm1: so do you want to maintain gmyth in debian too? if so, please give me a package for review :) | 06:03 |
| superm1 | slomo__, yes that would be most ideal | 06:04 |
| superm1 | changes shouldn't be too much to put it in debian, give me a little bit | 06:04 |
| slomo__ | superm1: great :) did you contact the debian multimedia team if they're interested in it too? whatever, i'll be back in 30 minutes ;) | 06:04 |
| === slangase` is now known as slangasek | ||
| warp10 | Good morning | 06:57 |
| superm1 | slomo__, okay i've got it all together and an ITP all ready. | 07:03 |
| slomo__ | superm1: great :) | 07:05 |
| superm1 | slomo__, let me get an account at mentors.debian.net made, and i'll throw it up there | 07:06 |
| superm1 | slomo__, http://mentors.debian.net/debian/pool/main/g/gmyth/ | 07:10 |
| slomo__ | superm1: thanks, will take a look now | 07:11 |
| superm1 | thanks | 07:11 |
| slomo__ | superm1: you repacked the tarball? then please name it 0.7.debian1-1 or similar | 07:12 |
| superm1 | slomo__, yeah i had to repack it because of upstream including a broken debian directory :( | 07:12 |
| superm1 | ok | 07:13 |
| slomo__ | superm1: libmysqlclient-dev | libmysqlclient15-dev | libmysqlclient14-dev please... the first is a new version in debian | 07:14 |
| superm1 | ok | 07:14 |
| slomo__ | superm1: what about the UPNP stuff from configure.ac? | 07:15 |
| superm1 | slomo__, afaik the upnp stuff isn't complete yet | 07:15 |
| slomo__ | ok :) | 07:15 |
| slomo__ | superm1: and it checks for doxygen stuff to build the docs... maybe add those to build-depends and add a documentation package... but only if you want and think it's useful :) | 07:15 |
| superm1 | i dont think its that useful yet - later it will be | 07:16 |
| superm1 | when the project matures more | 07:16 |
| slomo__ | superm1: please wrap the build depends, one in each lines... makes it easier to read diffs later, see a random gnome package as example :) | 07:16 |
| slomo__ | ok | 07:16 |
| superm1 | yeah i've seen those gnome packages, that does make it a lot easier to read diffs indeed | 07:17 |
| slomo__ | superm1: the -dev package needs to depend on libglib2.0-dev (pkg-config file requires it) | 07:17 |
| superm1 | yeah that was probably missed because every app it is compiled with has already had it | 07:18 |
| superm1 | i'll add that in | 07:18 |
| slomo__ | superm1: upper/lowercase mixup in the descriptions it seems... GLib and GObject and i thought it's MythTV, not MythTv but i might be wrong :) | 07:18 |
| slomo__ | superm1: for the short description... i'd make it more like "GObject based library for accessing a MythTv backend" for the two lib* packages, and then "(runtime files)" for the *0 one, "(development files)" for the -dev one | 07:20 |
| superm1 | k | 07:20 |
| slomo__ | wooh, manpages :) | 07:21 |
| superm1 | kinda boring manpages though :) | 07:21 |
| slomo__ | they exist, that's better than for most packages ;) | 07:21 |
| slomo__ | superm1: i'd exclude the *.la file(s) from the -dev package, they're annyoing and not very useful if you have pkg-config files anyway | 07:22 |
| slomo__ | superm1: http://sf.net/gmyth/gmyth-(.*)-indt1\.tar\.gz <--- so it the version not more something like 0.7.indt1-1? can there be a 0.7.indt2? | 07:22 |
| superm1 | every time they've done public releases its been with the indt1 | 07:23 |
| slomo__ | ok | 07:23 |
| slomo__ | superm1: DEB_CONFIGURE_EXTRA_FLAGS := --includedir=/usr/include/gmyth <--- why is this encessary? seems weird | 07:23 |
| superm1 | it was missing files when I didn't have it in before | 07:24 |
| slomo__ | ok :) | 07:24 |
| superm1 | if i can try to remember back a week ago | 07:24 |
| slomo__ | superm1: in debian/rules, the URL and everything variables should have a "=" instead of a "+="... you don't want to append to anythnig that might be set before already | 07:24 |
| superm1 | those rules will need some big mods at this point still too, with adding a .debian1 to the version | 07:25 |
| slomo__ | :) | 07:25 |
| slomo__ | superm1: in debian/copyright... the file is GPL-2 (as you need GPL version 2 or higher) | 07:26 |
| slomo__ | ah, now i finally know what indt is ;) | 07:26 |
| superm1 | :) | 07:26 |
| slomo__ | superm1: the copyright is 2006-2007, not 2007 only | 07:27 |
| superm1 | well actually 2006-2008 now I suppose. they've modified code this year | 07:27 |
| slomo__ | ok | 07:27 |
| slomo__ | good that you link to libcurl-gnutls :) | 07:28 |
| superm1 | i'm relieved it worked with it :) | 07:28 |
| superm1 | would have been hell getting this into main otherwise | 07:28 |
| slomo__ | well, i doubt it would be possible to get it even in non-free or ubuntu multiverse... iirc the GPL and openssl license are simply incompatible | 07:29 |
| slomo__ | superm1: uh oh... you need some patching :) | 07:30 |
| superm1 | in what? | 07:30 |
| slomo__ | superm1: libgmyth.so is not linked against libglib but should | 07:30 |
| slomo__ | superm1: it's only linked indirectly... so better get this fixed, otherwise dpkg-shlibdeps gives many warnings | 07:31 |
| superm1 | ooh yay. | 07:31 |
| slomo__ | superm1: in src/Makefile.am | 07:31 |
| slomo__ | libgmyth_la_LDFLAGS | 07:31 |
| slomo__ | contanis some _CFLAGS variables | 07:31 |
| slomo__ | should be _LIBS instead | 07:31 |
| slomo__ | and needs patching in the Makefile.in too then | 07:31 |
| slomo__ | this already fixes it i guess | 07:32 |
| slomo__ | superm1: then you want "LDFLAGS+=-Wl,-z,defs -Wl,-O1 -Wl,--as-needed" in debian/rules and the ltmain-as-needed patch from one of the gnome packages to prevent unnecessary dependencies | 07:33 |
| slomo__ | and then everything is good :) | 07:33 |
| slomo__ | sorry if i'm a bit picky | 07:33 |
| superm1 | slomo__, okay :). you sure caught a lot of stuff there | 07:33 |
| superm1 | i'll get those cleaned up in the morning and shoot you an email once they're in | 07:34 |
| superm1 | it's a little past bed time :) | 07:34 |
| slomo__ | ok, one thing left though :) | 07:34 |
| superm1 | sure | 07:34 |
| slomo__ | superm1: what about the other source releases from the gmyth sourceforge project page? | 07:34 |
| superm1 | they're not necessary for gmyth's functionality | 07:35 |
| superm1 | but eventually will get those in too | 07:35 |
| superm1 | gmyth is the more urgent one | 07:35 |
| slomo__ | ok :) | 07:35 |
| slomo__ | superm1: could you write me a mail when you're done with the package? | 07:35 |
| superm1 | slomo__, yeah i'll do that | 07:35 |
| slomo__ | thanks :) | 07:35 |
| slomo__ | good work btw | 07:35 |
| superm1 | okay night night, and thanks for helping me get this in | 07:35 |
| slomo__ | np :) good night | 07:36 |
| DktrKranz | persia: got a reply from liw. He does use of a piuparts SVN snapshot, so it's safe for him to merge piuparts from Debian. I'll collect some details and apply for a FFe, but I'd like to inform interested party via ubuntu-devel. Sounds reasonable? | 08:10 |
| DktrKranz | also, he told me he wants to schedule piuparts for universe soon :) | 08:10 |
| slicer | Er, is PulseAudio installed (and used) by default now? | 08:39 |
| === \sh_away is now known as \sh | ||
| \sh | moins | 08:58 |
| verb3k | Is Hardy universe freezed now or is there a chance that a package is accepted? | 08:58 |
| DktrKranz | verb3k: which one? | 08:59 |
| verb3k | Hardy | 08:59 |
| DktrKranz | I mean which package | 08:59 |
| verb3k | DktrKranz, The "Gens" Genesis emulator, I can't find it in the repositories | 09:00 |
| verb3k | DktrKranz, https://bugs.launchpad.net/ubuntu/+bug/107927 | 09:01 |
| ubotu | Launchpad bug 107927 in ubuntu "[needs-packaging] gens" [Wishlist,Confirmed] | 09:01 |
| DktrKranz | verb3k: if it is not into hardy archives, you need to request a Feature Freeze exception (https://wiki.ubuntu.com/FreezeExceptionProcess) | 09:02 |
| verb3k | DktrKranz, do you think it's worth it ? :) | 09:02 |
| verb3k | DktrKranz, and it's not a feature it's a package in the universe(not supported) | 09:04 |
| DktrKranz | Personally, I don't think so, but I'm not a ~motu-release member, so my words might be false. | 09:05 |
| DktrKranz | verb3k: Feature Freeze exceptions apply to new packages too. | 09:05 |
| verb3k | DktrKranz, someone already prepared nice packages and sources for ubuntu http://ubuntuforums.org/showthread.php?t=290008 | 09:06 |
| verb3k | DktrKranz, whom do you think I should talk to in this channel about this? | 09:08 |
| \sh | grmpf..brb | 09:09 |
| DktrKranz | verb3k: someone from ~motu-release (https://launchpad.net/~motu-release/+members) | 09:09 |
| === \sh is now known as \sh_away | ||
| verb3k | DktrKranz, anyone you know from them is a gamer? that's a bigger chance to include this package :) how about Daniel Holbach? | 09:11 |
| dholbach | verb3k: sorry, I'm not much of a gamer and quite busy right now | 09:12 |
| === \sh_away is now known as \sh | ||
| verb3k | dholbach, ok, but do you think the package can be accepted? if yes, who do you think I should talk to? | 09:13 |
| DktrKranz | verb3k: I think none of them, but I may be wrong. | 09:13 |
| dholbach | verb3k: http://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for how to get it submitted for review | 09:15 |
| dholbach | bear in mind though that it will be tougher after Feature Freeze to get it 1) reviewed, 2) included even after FF because people are mostly busy fixing other packages | 09:16 |
| verb3k | dholbach, I see, it's already been requested in LP: https://bugs.launchpad.net/ubuntu/+bug/107927 | 09:17 |
| ubotu | Launchpad bug 107927 in ubuntu "[needs-packaging] gens" [Wishlist,Confirmed] | 09:17 |
| dholbach | then best to get the package uploaded to REVU an link it in the bug report | 09:18 |
| verb3k | I see, then I will try my best to get it before release, thanks for your time dholbach DktrKranz | 09:22 |
| dholbach | anytime | 09:22 |
| DktrKranz | verb3k: you're welcome | 09:23 |
| geser | good morning | 09:24 |
| TuxCrafter | is this the correct channel for the dev week? or is that ubuntu meeting? | 09:43 |
| Unksi | TuxCrafter: #ubuntu-classroom and #ubuntu-classroom-chat are the channels used for it | 09:47 |
| dholbach | https://wiki.ubuntu.com/UbuntuDeveloperWeek/JoiningIn | 09:48 |
| === man-di_ is now known as man-di | ||
| TuxCrafter | Unksi: thanks | 10:04 |
| Unksi | youre welcome :) | 10:05 |
| === man-di_ is now known as man-di | ||
| persia | DktrKranz: Thanks for tracking that down. Is the change significant enough to really warrant an email to ubuntu-devel? For a little merge, I'd think an FFe is enough. If there's a big change, such an email sounds right. | 10:12 |
| DktrKranz | persia: http://pastebin.ubuntu.com/4708/ | 10:14 |
| DktrKranz | from 65k to this :) | 10:14 |
| DktrKranz | of course it lacks changelog entries, but that's the most important part | 10:15 |
| persia | DktrKranz: Is that against current, or against Debian? | 10:18 |
| DktrKranz | persia: current, but there aren't main changes from 0.30 in Debian. | 10:18 |
| persia | 0.30! It was 0.29 last I looked. Still, I think for the most part it's gone native, so the version bumps don't actually indicate the volume of change one often expects from a new upstream. Based on what you've listed, I don't see any new features or functionality, although I'd think it might be good to get a wave from motu-release just in case. I don't think something that small will get much response from ubuntu-devel. | 10:20 |
| persia | Were you changing dpkg, it would be a different story :) | 10:20 |
| DktrKranz | me too, I think 0.30 was uploaded saturday | 10:21 |
| DktrKranz | persia: ok, then. I'll gather material required for a FFe, do some tests and submit the whole stuff. | 10:22 |
| DktrKranz | we should have it in shape soon :) | 10:22 |
| persia | DktrKranz: Thanks again for chasing this. I'm looking forward to using it to generate a whole heap of bugs. I'm not sure we can fix everything for hardy, but we should see significant improvement. | 10:24 |
| DktrKranz | I hope so. I'd like to do something for {dapper,gutsy} -> hardy upgrade tests, I'll ask mvo about them | 10:26 |
| mok0 | A -dev package with a library, that depends on other libraries in order to link, should that include those libraries' -dev packages as a Recommends or a Depends? I seem to remember that you cannot depend on a -dev package | 10:30 |
| geser | mok0: does the first -dev package use headers from the other -dev packages? | 10:32 |
| mok0 | geser: I can't remember, probably | 10:33 |
| persia | mok0: A -dev package may depend on a -dev package, but only if it is actually required. For library dependencies, it is safe to rely on the libfoo package depending on the support libraries. | 10:33 |
| geser | if it uses them, then the -dev package should depend on the other headers/-dev package | 10:33 |
| mok0 | geser: so if headers are used -> Depends, otherwise Recommends?' | 10:34 |
| geser | mok0: why would you want to recommend them? | 10:35 |
| mok0 | geser: because the library calls the lower libraries | 10:35 |
| mok0 | geser: and you can't link without them | 10:35 |
| persia | mok0: That should be handled by the dependencies of the library package, no? | 10:35 |
| mok0 | geser: that's what I am asking | 10:36 |
| mok0 | persia: -"- | 10:36 |
| geser | mok0: If I use libA-dev in a package it shouldn't matter to me which package libA depends on | 10:36 |
| mok0 | geser: right, but if libA-dev calls functions in libB-dev | 10:37 |
| geser | libA should link to the libs it needs and not the app | 10:37 |
| persia | mok0: When libfoo uses symbols from libbar, libfoo should depend on libbar. libfoo-dev depends on libfoo, and need not reference libbar. If the libfoo-dev headers #include libbar-dev headers, then libfoo-dev needs to depend on libbar-dev. These are separable concerns. | 10:37 |
| * mok0 ponders... | 10:38 | |
| mok0 | Got it | 10:38 |
| mok0 | A lot of that is handled by dh_shlibdepends I guess | 10:39 |
| geser | dh_shlibdepends add the dependency on libbar to libfoo during its build | 10:40 |
| mok0 | However, I need to do gcc prog.c -lA -lB | 10:40 |
| mok0 | and if libB is not there... boom | 10:40 |
| geser | does prog.c use both libs or only A? | 10:40 |
| mok0 | functions from libB are called from libA | 10:41 |
| geser | is libA linked with libB? | 10:41 |
| mok0 | geser: no | 10:41 |
| geser | please fix libA, it will it make easier when libB needs a transition | 10:42 |
| mok0 | geser: right | 10:42 |
| mok0 | Thanks | 10:42 |
| === pochu_ is now known as pochu | ||
| warp10 | Hi all! | 11:36 |
| zul | hello | 12:02 |
| Unksi | hiya | 12:05 |
| === czessi_ is now known as Czessi | ||
| norsetto | howdy all | 12:40 |
| geser | hi norsetto | 12:41 |
| norsetto | heya geser | 12:41 |
| ki|A-F-MOTHERFUC | So let's get a party going (let's get a party going) | 13:07 |
| ki|A-F-MOTHERFUC | Now it's time to party and we'll party hard (party hard) | 13:07 |
| Iulian | Weird guy. | 13:11 |
| === ogra_ is now known as ogra | ||
| mruiz | hi all | 13:34 |
| Iulian | Hey mruiz | 13:44 |
| mruiz | hey Iulian | 13:44 |
| smarter | hi | 13:53 |
| smarter | Could someone explain me what to do with that(dpkg-shlibdeps complains)? http://pastebin.com/m7b68f3bf | 13:53 |
| persia | smarter: Looks like an overzealous LDFLAGS in the build system | 13:54 |
| smarter | I didn't change the LDFLAGS | 13:55 |
| smarter | dpkg-buildpackage says: "dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions" | 13:55 |
| persia | smarter: Check your buildlog: maybe upstream set LDFLAGS? | 13:55 |
| geser | persia: dpkg-buildpackage from the recent dpkg sets now LDFLAGS, CFLAGS and others | 13:57 |
| smarter | persia: nothing special in the logs | 13:57 |
| persia | geser: Yes, but upstream can still break that, depending on how it is defined. | 13:58 |
| smarter | maybe if I recreate the automake/autoconf stuff | 13:58 |
| persia | smarter: In the buildlogs, is there not a line that has -lfoo -lbar, etc. | 13:58 |
| geser | smarter: check in the build logs the linking stage | 13:58 |
| smarter | geser: where is the linking stage? | 13:59 |
| geser | smarter: can you make the complete build log available? | 14:00 |
| smarter | example: g++ -DHAVE_CONFIG_H -I. -I.. -DPP_DATADIR=\"/usr/share/games/etracer\" -DTUXRACER_NO_ASSERT=1 -DHAVE_SDL_MIXER=1 -g -O2 -g -Wall -O2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/tcl8.5 -I/usr/include/libpng12 -I/usr/include/freetype2 -c -o joystickconfig.o joystickconfig.cpp | 14:00 |
| smarter | geser: ok | 14:00 |
| persia | smarter: The source of the complaint is that there are lots of lines like -l/usr/include/libpng12 when the analysis of the binary doesn't appear to indicate that such symbols are actually used. | 14:01 |
| smarter | persia: what should I do? | 14:01 |
| persia | smarter: I'd recommend checking the source to see if they are used (that message isn't always right), and if not, patching the upstream build system to not link against the unused libraries. | 14:02 |
| smarter | geser: build log: http://launchpadlibrarian.net/11945971/buildlog_ubuntu-hardy-i386.extremetuxracer_0.4-0ubuntu1_FULLYBUILT.txt.gz | 14:02 |
| === _emgent is now known as emgent | ||
| geser | smarter: g++ -g -O2 -g -Wall -O2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I -I/usr/include/tcl8.4 -I/usr/include/libpng12 -I/usr/include/freetype2 -Wl,-Bsymbolic-functions -o etracer ssbutton.o checkbox.o textarea.o ui_mgr.o ui_snow.o ui_theme.o button.o frame.o entry.o widget.o color.o matrix.o quat.o vec2d.o vec3d.o plane.o glhelper.o poly.o audio.o audio_data.o image.o png_reader.o | 14:11 |
| geser | rgb_reader.o ppm_writer.o course_load.o course_mgr.o course_quad.o course_render.o credits.o debug.o error_util.o event_select.o file_util.o fog.o fps.o game_config.o game_type_select.o game_over.o gl_util.o hier.o hier_cb.o hier_util.o highscore.o hud.o intro.o joystick.o keyframe.o lights.o loading.o loop.o main.o mirror_course.o player.o nmrcl.o os_util.o part_sys.o paused.o phys_sim.o quadtree.o | 14:11 |
| geser | race_select.o event_race_select.o racing.o render_util.o reset.o screenshot.o snow.o splash_screen.o string_util.o tcl_util.o tex_font_metrics.o textures.o track_marks.o model_hndl.o tux_shadow.o view.o viewfrustum.o winsys.o videoconfig.o audioconfig.o configmode.o configuration.o graphicsconfig.o joystickconfig.o keyboardconfig.o stuff.o game_mgr.o bench.o callbacks.o translation.o alignment.o | 14:11 |
| geser | model.o model_ac.o font.o label.o FTCharmap.o FTFace.o FTFont.o FTGLTextureFont.o FTGlyph.o FTGlyphContainer.o FTLibrary.o FTPoint.o FTSize.o FTTextureGlyph.o -lSM -lICE -lX11 -lXi -lXext -lXmu -lXt -ldl -lm -L/usr/lib -lSDL -lSDL_mixer -lGL -lGLU -L/usr/lib -ltcl8.4 -ldl -lpthread -lieee -lm -lpng12 -lfreetype -lz | 14:11 |
| geser | make[3]: Leaving directory `/build/buildd/extremetuxracer-0.4/src' | 14:11 |
| geser | Making all in data | 14:11 |
| geser | oops, a little bit long | 14:11 |
| geser | smarter: that the linking stage | 14:11 |
| LucidFox | smarter, did you receive my email about qdevelop? | 14:11 |
| geser | -lXXX means link with libXXX.so | 14:11 |
| smarter | LucidFox: yes, didn't have time to answer, sorry | 14:12 |
| LucidFox | ah | 14:12 |
| smarter | LucidFox: I think we should try to integrate this with upstream | 14:12 |
| LucidFox | But isn't -qt4 Ubuntu-specific? | 14:12 |
| smarter | Debian use it also | 14:12 |
| smarter | but upstream could first check for qmake-qt4, then qmake, ... | 14:13 |
| LucidFox | well, Debian-based-specific | 14:13 |
| LucidFox | ah, that makes sense | 14:13 |
| smarter | LucidFox: I'll try to speak with the upstream author | 14:13 |
| LucidFox | good, thanks | 14:13 |
| smarter | he's very responsive | 14:13 |
| HighNo | hi there, I want to provide my older dists users with a package too (until backports is getting it done) and thought of a very quick and even dirtier solution to just patch the .deb file directly. So I did - changed the python-support entry in the debian/control file to accept version 0.5.6 (feisty) and repacked the hole stuff. Now I get strange results. dpkg installs it nicely - the software is completely installed and runs perfectly. GD | 14:13 |
| smarter | LucidFox: he provided a tar.gz package instead of the .zip the day after I asked | 14:14 |
| LucidFox | I like responsive upstreams. | 14:14 |
| smarter | geser: and how can I remove the unused -l libs ? | 14:17 |
| smarter | force LDFLAGS? | 14:17 |
| l1unatic | Hello everyone. I am getting an error when i debuild.The error says: clearsign failed. I have checked my key. The entry is correct in changelog. Can anyone help please? | 14:18 |
| geser | smarter: check in the build system where they are added | 14:20 |
| geser | l1unatic: did it say whey clearsignig failed? | 14:21 |
| Iulian | l1unatic: Afaik, you'll need an entry in ~/.bashrc also. | 14:21 |
| l1unatic | geser: Secret key not available. | 14:23 |
| HighNo | l1unatic: set the DEBEMAIL variable to the mail address of your key | 14:23 |
| geser | DktrKranz: re your dietlibc upload in Nov 2007, looks like we need to undo the -1ubuntu2 changes back to -1ubuntu1 as it breaks the build of bglibs (see also Debian bug 374349) | 14:24 |
| ubotu | Debian bug 374349 in dietlibc-dev "Causes bglibs to FTBFS: undefined reference to `main'" [Serious,Fixed] http://bugs.debian.org/374349 | 14:24 |
| geser | l1unatic: check if Changed-By in the changes file contains your complete key id (incl. all comments) | 14:25 |
| mok0 | norsetto: ping | 14:25 |
| norsetto | mok0: pong | 14:25 |
| mok0 | norsetto: Hey! do you have time to look at xtide? | 14:25 |
| norsetto | mok0: no, but when did I ever say no .... | 14:26 |
| mok0 | norsetto: :-) | 14:26 |
| HighNo | l1unatic: and just to be sure, set the DEBFULLNAME variable to that value too (the full name used for the key) | 14:26 |
| DktrKranz | geser: it brings in several troubles. Revert to ubuntu1 leads to segfaults in *every* package which depends on dietlibc, unless compile them with --fno-stack-protector. I didn't manage it before because I was looking for a better solution, but I've found none so far. | 14:26 |
| mok0 | norsetto: just to clear up the comments on LP. We need to get xtide-data and the merged xtide uploaded | 14:27 |
| HighNo | anyone got an idea on my hand-edited .deb file? Maybe a hint where I should look, other channels to ask? | 14:27 |
| geser | DktrKranz: so we have the choice between breaking other apps or bglibs? | 14:27 |
| norsetto | mok0: so far so good | 14:28 |
| mok0 | norsetto: you had some comments on xtide | 14:28 |
| DktrKranz | geser: we have the choice to revert dietlibc and uploading fifteen packages with --fno-stack-protector | 14:28 |
| norsetto | mok0: yes, there seems to be some unneeded changes | 14:28 |
| DktrKranz | or waiting for a better solution, but I don't think it will come before release | 14:29 |
| geser | HighNo: what "strage results" did you have? "dpkg installs it nicely - the software is completely installed and runs perfectly" sounds good. | 14:29 |
| mok0 | norsetto: it is true that the diffs to debian are getting very small, except for the Recommends to the new data (xtide-wvs1-data) | 14:29 |
| l1unatic | geser: Ya. The entry is complete. | 14:29 |
| norsetto | mok0: but that is not a carried over change | 14:29 |
| l1unatic | HighNo: Ok. I'll just check. | 14:29 |
| === lamalex_2 is now known as lamalex | ||
| mok0 | norsetto: I created xtide-wvs1-data, and I have tried to offload it to the Debian maintainer of xtide, but have not yet heard from him | 14:30 |
| persia | mok0: Part of the issue is that we cannot upload a version less than the current one. If you want to revert to Debian, create a new patch that includes all the changelog entries, and maintainer mangling, and otherwise leaves the package alone, with a final changelog entry of "Revert to Debian packaging". | 14:30 |
| mok0 | norsetto: no it's a change I made for the new wvs1 stuff | 14:30 |
| geser | DktrKranz: I looked at bglibs and I don't understand why it complains it can't find main. | 14:30 |
| norsetto | mok0: right, now we have it in the repos and it makes sense to use it, thats what you are saying | 14:30 |
| mok0 | persia: ok, that's what I've done to xtide-data (except that "Revert..." comment) | 14:31 |
| norsetto | mok0: so just prepare a new debdiff where you sync xtide from debian and add this new change | 14:31 |
| DktrKranz | geser: it's a known issue with propolice, Debian solved it by disabling WANT_SSP in dietlibc (and binNMU everything), but that's incompatible with our toolchain. | 14:31 |
| persia | mok0: It's the except that was part of what was confusing :) | 14:31 |
| mok0 | norsetto: I have, it's that old patch | 14:31 |
| norsetto | mok0: which old patch? | 14:32 |
| mok0 | norsetto: from 2008-02-01 | 14:32 |
| norsetto | mok0: yeah, but where is that, in a comment in the bug report? | 14:32 |
| geser | DktrKranz: do you know more about it? what the exact problem? | 14:32 |
| mok0 | norsetto: It's in bug 188086 | 14:32 |
| ubotu | Launchpad bug 188086 in xtide "[needs-merge] xtide-2.9.5-2 from sid" [Wishlist,In progress] https://launchpad.net/bugs/188086 | 14:32 |
| norsetto | mok0: I see quite a lot more than that in that debdiff | 14:33 |
| mok0 | norsetto: I did it as a standard merge, so the old changelog entries have been carried over | 14:34 |
| HighNo | geser: the problem is GDebi doesn't even open the new .deb file - telling me it's corrupt | 14:34 |
| norsetto | mok0: its not a merge, its a sync with a new change (the addition of xtide-vws1-data) as we just discussed | 14:35 |
| mok0 | norsetto: so, you want me to make a new debdiff that only includes that? | 14:35 |
| norsetto | mok0: I'm all for minimise the delta wrt debian, unless justified (which in this case I don't think it is) | 14:36 |
| geser | HighNo: ah, your first message got cut of at "...runs perfectly. GD" | 14:36 |
| mok0 | norsetto: that's fine, I'll fix that. Now, what about xtide-data? | 14:36 |
| geser | HighNo: is the same version of the deb also in the archive? | 14:36 |
| RainCT | Hi | 14:37 |
| norsetto | mok0: wait a sec, what about the dirs change? Thats not even in the changelog | 14:37 |
| mok0 | norsetto: that's reverting to debian | 14:37 |
| HighNo | geser: ? do you mean the cache? it's not in universe - at least not for feisty | 14:37 |
| norsetto | mok0: well, if we sync you don't need to do that, its a dropped change | 14:38 |
| DktrKranz | geser: it seems SSP mangles main in a way linker is unable to find it. IIRC, with gcc-4.1 upstream provide a fix (or a workaround), but gcc-4.2 broke it again. My knowlegde of gcc internals is not so good to provide a fix myself. | 14:38 |
| === dholbach_ is now known as dholbach | ||
| mok0 | norsetto: afai understood persia just before, we can not go down in version number | 14:38 |
| norsetto | mok0: ah, you mean the version you want to sync its an older version!? | 14:39 |
| DktrKranz | geser: I asked upstream if there's something I can do, but never received a reply. | 14:39 |
| persia | norsetto: It ought be a sync, except that first requires a Debian update :) | 14:39 |
| norsetto | mok0: then yes, we need to do as you did (...what a mess....) | 14:39 |
| mok0 | norsetto: it has release -1 instead of -1ubuntu1 | 14:39 |
| norsetto | persia: yes :-( | 14:40 |
| mok0 | norsetto: yes, a mess. | 14:40 |
| DktrKranz | (and Debian is not of aid, since it's not its business) | 14:40 |
| mok0 | norsetto: sorry about that. It is my fault. The Debian admin was in agreement with the change, but we later decided to do it differently | 14:40 |
| persia | The next version must be -1ubuntu2. Using a comment like "Revert to Debian packaging" makes it clear to sync next time. I ended up with the same mess for uqm-content. | 14:40 |
| mok0 | persia: it is 1ubuntu2 in the patch on LP | 14:41 |
| persia | mok0: Ah, good. Last time I looked, there status was perhaps a bit more confusing (that being the 14th). | 14:41 |
| norsetto | mok0: for xtide-data is the same, just limit yourself to reverting the changes, do not add any cosmetic change so that we just sync the next update from Debian | 14:42 |
| mok0 | persia: it's been on my list for a while and I want to get rid of it | 14:42 |
| mok0 | norsetto: what cosmetic changes do you mean? | 14:42 |
| norsetto | mok0: for instance the lintian warnings | 14:43 |
| mok0 | norsetto: there was a small bug in rules that I fixed, and I also changed the Standards-version | 14:43 |
| mok0 | norsetto: I'll submit those to debian maintainer, then he can release a new one | 14:44 |
| norsetto | mok0: that would be the best course | 14:44 |
| persia | And we could sync that :) | 14:44 |
| mok0 | persia: exactly | 14:44 |
| mok0 | So, can we get xtide-data off the shelf? | 14:46 |
| === azeem_ is now known as azeem | ||
| mok0 | I'll fix xtide cf. norsetto's comments and upload a new patch | 14:46 |
| === jcfp_ is now known as jcfp | ||
| persia | mok0: Isn't there an interrelationship between xtide and xtide-data such that it makes sense to upload them together? | 14:48 |
| norsetto | mok0: when I said the best course I meant that we get these two cosmethic fixes from debian .... | 14:48 |
| l1unatic | HighNo: Sorry but i cannot find any of these options. | 14:48 |
| mok0 | persia: well -1ubuntu1 is buggy so I'd like to get it out the the archives ASAP | 14:48 |
| persia | mok0: How does buggy matter now? If there's a clear plan to fix pre-BetaFreeze, best to just execute the plan. | 14:49 |
| HighNo | l1unatic: options? those are variables in the environment to set like this: DEBFULLNAME | 14:49 |
| persia | (saves wear and tear on the buildd bearings :) ) | 14:49 |
| HighNo | l1unatic: args, wait | 14:49 |
| HighNo | l1unatic: # export DEBFULLNAME="Lars Friedrichs" | 14:49 |
| l1unatic | HighNo: Ok | 14:50 |
| persia | Err. That ought always be $ export DEBFULLNAME... Running under # is likely to cause other issues when testing a build. | 14:50 |
| mok0 | norsetto, persia: I haven't heard from Deb maint. on my last email, so I don't know if he'll respond quickly. I'd rather get the fix -1ubuntu2 in now, and then we can see if -2 makes it before hardy release | 14:51 |
| LucidFox | why not just add DEBFULLNAME="Full Name" to ~/.bashrc? | 14:51 |
| HighNo | hm, is Michael Vogt or Sebastian Heinlein around? | 14:51 |
| persia | mok0: How long? BetaFreeze isn't for a few weeks: may be worth waiting a bit longer, no? | 14:51 |
| LucidFox | that's what I did | 14:51 |
| geser | HighNo: my guess was that it perhaps checks a checksum | 14:51 |
| HighNo | LucidFox: thats possible too | 14:51 |
| mok0 | persia: ok | 14:51 |
| dholbach | HighNo: ask mvo or glatzor on #ubuntu-devel | 14:52 |
| * persia doesn't use DEBFULLNAME, but just DEBEMAIL="My Name <my.email@provider.tla>" and everything works :) | 14:52 | |
| geser | DktrKranz: -rw-r--r-- 1 root root 527492 Feb 18 14:51 bglibs-dev_1.041-2_amd64.deb :) | 14:52 |
| HighNo | geser: I have checked that - there are no md5sums on the control file... | 14:52 |
| HighNo | persia: good to know, I guess I've set it then to make dch enter the correct name | 14:52 |
| mok0 | norsetto: ok, well that's settled then. I know what to do. Thanks | 14:52 |
| norsetto | mok0: de nada | 14:53 |
| geser | DktrKranz: I got inspired by an old patch to mailfront with a similar problem: link explicity against the object file containing main even if it's inside an ar archive | 14:54 |
| geser | can you make the deb available for checking? | 14:55 |
| geser | HighNo: ^^^ | 14:55 |
| DktrKranz | geser: ah, interesting workaround. Keep in mind several packages segfaulted at startup, so it's better to check them before the release (and I finally understood why our core-devs don't want dietlibc in main) | 14:59 |
| DktrKranz | geser: I wanted to make sure dietlibc is compiling on sparc and ppc too before pushing stuff | 15:00 |
| DktrKranz | so at least I need a sparc box, which I don't have | 15:01 |
| HighNo | geser, hm - where to? | 15:01 |
| geser | HighNo: have you no webspace? | 15:02 |
| ScottK | DktrKranz: See sistpoty or siretart about trying on sparky (REVU's host). | 15:02 |
| DktrKranz | ScottK: ah, good point. Thanks. | 15:02 |
| HighNo | geser: hm, not really - wait a sec, then it should be at sourceforge... | 15:03 |
| geser | DktrKranz: I'll check if bcron builds with the new bglibs and doesn't segfault directly before uploading bglibs. | 15:03 |
| HighNo | geser: gosh, seems like sourceforge can't handle \~ in filenames... | 15:05 |
| DktrKranz | geser: I think we should wait until a "final" dietlibc is available, this way we can avoid rebuilds. Since SSP is PITA for i386 and amd64 only, limiting my patch just for these archs would solve almost every issue. | 15:06 |
| DktrKranz | #ifdefs should work, unless a better (and tested) solution is found by upstream | 15:06 |
| emgent | heya people | 15:07 |
| DktrKranz | FYI, this spec covers every package which needs dielibc love: https://blueprints.edge.launchpad.net/ubuntu/+spec/better-dietlibc | 15:08 |
| geser | HighNo: how big is the deb? | 15:09 |
| HighNo | geser: 288k | 15:09 |
| geser | HighNo: mail it then to geser@ubuntu.com | 15:09 |
| HighNo | geser: thanks - it's on the way | 15:11 |
| DktrKranz | persia: candidate piuparts merge tested successfully, now filing a FFe. | 15:11 |
| geser | DktrKranz: bglibs last build in dapper successfully. I would prefer to have a version that builds in hardy (in case someone wants to do a security upload) | 15:12 |
| ScottK | RainCT: Would it be possible to teach pbuilder-dist about oldstable, stable, testing, and unstable in addition to the release names? | 15:12 |
| persia | DktrKranz: Please subscribe me to the FFe bug, and thanks again for taking care of that. | 15:12 |
| DktrKranz | geser: these issues came up in edgy, due to SSP enabled by default | 15:12 |
| DktrKranz | so, dapper binaries are all good | 15:13 |
| geser | DktrKranz: so we should better keep the working ones which we can't rebuild anymore? | 15:15 |
| RainCT | ScottK: Sure. I think they were already there, but might have been removed because of some problem. Perhaps they need to be translated to their codename before passing the value to pbuilder? | 15:15 |
| mok0 | What is the current policy on export DH_COMPAT=5 in rules? | 15:16 |
| ScottK | RainCT: I'm not sure. I was helping a friend of mine who runs debian set up a pbuilder yesterday and we used pbuilder-dist (I always love pointing Debian people at Ubuntu resources) and he tried testing first and it didn't work. | 15:16 |
| ScottK | mok0: Don't do it. Add debian/compat instead. | 15:16 |
| mok0 | ScottK: It's in the debian version | 15:16 |
| DktrKranz | geser: since they're statically compiled against dietlibc, the ones before edgy are good, the ones after edgy, segfault on startup. | 15:16 |
| mok0 | ScottK: The real question is: should I send the fix to the Debian maintainer, or will he frown at that | 15:17 |
| ScottK | mok0: If it's the only difference with Debian, I wouldn't maintain a diff for it, but if you're making other changes, I'd change it. Your call. | 15:17 |
| RainCT | mok0: iirc, DH_COMPAT in rules is only allowed to temporary overwrite debian/compat for testing purposes | 15:17 |
| ScottK | mok0: Run linitian on the package and see what it tells you (it may need the I (big i) flag). If lintian complains, then I think it's fair game (IIRC it does). | 15:18 |
| mok0 | ScottK: good idea | 15:18 |
| * persia plans fun for the ides of March | 15:20 | |
| DktrKranz | persia: done. bug 175821. | 15:20 |
| ubotu | Launchpad bug 175821 in piuparts "[FFe] piuparts for debian packages doesn't work" [Medium,New] https://launchpad.net/bugs/175821 | 15:20 |
| geser | DktrKranz: but in case of bglibs we ship binaries which don't match the source we provide (since edgy) | 15:20 |
| * persia advocates rebuilding everything for each release to ensure that doesn't happen: better to FTBFS and not ship binaries than violate the license by shipping binaries for which the source is not available. | 15:23 | |
| DktrKranz | geser: I wanted to make sure dietlibc was in good shape before rebuilding packages which depend on it, since similar problems may arise with every new gcc minor versions. I think I'm close to a solution (aka workaround), but needs to test at least on on sparc (since it actually FTBFS). | 15:24 |
| geser | persia: that would only work if you don't copy the binaries from the previous release | 15:25 |
| persia | geser: Exactly. | 15:25 |
| persia | There are packages in the archive that have not been recompiled since before the Warty release. That can't be good. | 15:26 |
| DktrKranz | I need to ask sistpoty a temporary account on REVU server to test them. They're not huge packages, so workload won't be too much. | 15:26 |
| persia | DktrKranz: You should have an account. Try ssh. | 15:26 |
| persia | The reason for asking is about the workload: the server is fairly old. | 15:27 |
| DktrKranz | persia: sparky.ubuntu.com ? | 15:27 |
| persia | ubuntuwire | 15:27 |
| DktrKranz | well, dietlibc needs five minutes on my old boxes to build | 15:27 |
| DktrKranz | and util-vserver and friends are similar | 15:28 |
| HighNo | Hm, I'd like to change a package that is supposed to be in hardy. That would make backporting a breeze. Is that still possible? | 15:29 |
| geser | persia: we should ask lucas if he can schedule a hardy universe rebuild | 15:29 |
| HighNo | the change would only affect the control file lowering the python-support release | 15:29 |
| DktrKranz | persia: I'm in, but I don't know if I have permissions to run pbuilder/pdebuild | 15:29 |
| persia | geser: Those rebuilds only test FTBFS. What about .deb contents differ from rebuild issues (which are also of interest). | 15:29 |
| mruiz | dholbach, Five-a day is a very good idea... I'm finishing my fifth bug | 15:30 |
| geser | DktrKranz: do you know when the new dietlibc will be in hardy? | 15:30 |
| persia | DktrKranz: I don't even know if those are installed. Ask one of the two previously mentioned people. | 15:30 |
| persia | mruiz: Just because you hit your target today is no excuse to stop :) | 15:30 |
| mruiz | persia, sure :D | 15:30 |
| geser | persia: true, but at least we would know which packages don't build anymore | 15:30 |
| dholbach | mruiz: nice - do you make use of https://wiki.ubuntu.com/5-A-Day#Log ? | 15:30 |
| persia | geser: I suppose. I'd rather just rebuild everything. Let me find some excuses... | 15:31 |
| mruiz | dholbach, I'll do it soon | 15:31 |
| dholbach | mruiz: greazt | 15:31 |
| dholbach | great :) | 15:31 |
| DktrKranz | geser: basically I just have to adjust my patch to apply for i386/amd64 only. After that, I'll do some tests on i386 and sparc, but I'll need a hand to test it for amd64 (I've no boxes), util-vserver is good to see if dietlibc works. | 15:32 |
| geser | persia: the buildds are already blocked for weeks during the first autosync, I don't to know how long it would take to get the complete archive rebuild on each release (and how long it would take to get the build order correct) | 15:32 |
| geser | DktrKranz: what kind of tests? | 15:32 |
| * geser has an AMD64 | 15:33 | |
| persia | geser: Nobody knows. It needs someone to plan it. Much as I'd like it, it's not going to happen really soon. Until then, we can only catch what we can. | 15:34 |
| DktrKranz | geser: just rebuild util-vserver or slidentd against new dietlibc. Keep in mind util-vserver has been autosynced, so it works now. | 15:35 |
| persia | For instance, there appear to be 1956 packages that have not been built since we instituted maintainer mangling in pkgbinarymangler. They would be good candidates for rebuild. | 15:35 |
| persia | The list is available from wget -O - http://archive.ubuntu.com/ubuntu/dists/hardy/universe/binary-i386/Packages.gz | gunzip | grep-dctrl -sSource:Package -FMaintainer -v -n ubuntu | sort -u if anyone wants to take a look. | 15:35 |
| DktrKranz | geser: current dietlibc in hardy is fine for all packages on i386 and amd64. | 15:35 |
| DktrKranz | but I should test new candidate | 15:35 |
| dholbach | https://wiki.ubuntu.com/UbuntuDeveloperWeek about to start in 25 minutes in #ubuntu-classroom | 15:35 |
| HighNo | dholbach: will there be transcripts be put on the wiki too? | 15:37 |
| dholbach | HighNo: yes | 15:37 |
| HighNo | dholbach: as i am very interested in hosting code in launchpad but won't make it tomorrow. | 15:37 |
| HighNo | dholbach: just you or will everybody do that? | 15:37 |
| dholbach | HighNo: no problem, we'll get the logs online | 15:37 |
| HighNo | dholbach: cool, I'd really like to have my package at launchpad too so people can use rosetta... | 15:38 |
| geser | DktrKranz: let me know when you have dietlibc ready for testing | 15:38 |
| DktrKranz | geser: sure. Thanks for stepping in. | 15:39 |
| geser | DktrKranz: should I wait with uploading the bglibs fix for the new dietlibc? | 15:39 |
| dholbach | HighNo: the scribes team will take care of it | 15:39 |
| geser | HighNo: the error message about your "corrupt" deb happens also in hardy | 15:40 |
| HighNo | geser: good to know - so there might be a problem with either the package being really broken or gdebi being too picky on details | 15:41 |
| DktrKranz | geser: it should be advisable to wait. Since dietlibc is a minimal toolchain, a new upload could change several aspects of it, so it's better to wait until a (hopefully) working one is landed. | 15:42 |
| HighNo | geser: could you confirm the bug then? https://bugs.launchpad.net/gdebi/+bug/192939 | 15:42 |
| ubotu | Launchpad bug 192939 in gdebi "gdebi rejects a package that dpkg does accept" [Undecided,New] | 15:42 |
| geser | DktrKranz: I will wait at it still time to upload it later | 15:44 |
| === ^Tom is now known as NessieLiberation | ||
| NessieLiberation | May I ask about the case of mpd, am I correct in thinking that it is compiled without aac support to be included in universe rather than multiverse? | 15:47 |
| NessieLiberation | and if so, is it possible to, for example, have a version of mpd in multiverse with fuller support? | 15:48 |
| persia | NessieLiberation: That is a likely justification, although it may be that it was so arranged in Debian to be in main rather than contrib (or at least it looks that way to me) | 15:48 |
| NessieLiberation | persia: unfortunately, I have some songs in aac format, and I would rather not recompile mpd as frequently as I would normally upgrade teh package | 15:49 |
| crimsun_ | hmm, but libfaad{0,2-0,-dev} binaries are in universe | 15:49 |
| persia | main too. Odd. | 15:50 |
| crimsun_ | only the faad binary is in multiverse | 15:50 |
| geser | HighNo: while debugging the problem, I got: SystemError: E:This is not a valid DEB archive, missing 'debian-binary' member | 15:50 |
| NessieLiberation | oh, so what causes it to not have the support then? | 15:50 |
| crimsun_ | NessieLiberation: does hardy's current mpd not support m4as properly? The build-dependency on libfaad-dev is clearly present. | 15:52 |
| NessieLiberation | I'm not running hardy, I was just trying to see what the deal with it was. If it's been fixed in hardy then cool and thanks | 15:54 |
| smarter | geser: I added that to my debian/rules to get rid of the unused libraries: DEB_MAKE_BUILD_TARGET := LIBS="-lm -L/usr/lib -lSDL -lSDL_mixer -lGL -lGLU -ltcl8.5 -lpthread -lieee -lm -lpng12 -lfreetype" | 15:54 |
| smarter | is that the correct way? | 15:54 |
| smarter | it works and the package has a lot less depends | 15:55 |
| kdub | last hardy update put me in dependency hell | 15:57 |
| HighNo | geser: hm, strange - when exactly did you get that message? | 15:57 |
| HighNo | what is the normal status for packages included in hardy in lp? I still have 'in progress' while the package is available via apt-get already | 15:58 |
| crimsun_ | HighNo: if the package has been uploaded with a corresponding bug close entry, the janitor will mark the bug Fix Released | 16:01 |
| crimsun_ | HighNo: so if the main task (current development branch, Hardy) contains that fix, the main task will be Fix Released. It does not, however, automatically follow for attached tasks (e.g., other Ubuntu releases or affected packages) | 16:02 |
| HighNo | crimsun_: hm, I think i could not follow your description - the bug I mean is https://bugs.launchpad.net/ubuntu/+bug/137339 | 16:04 |
| ubotu | Launchpad bug 137339 in ubuntu "[needs-packaging] BlueProximity" [Wishlist,In progress] | 16:04 |
| crimsun_ | HighNo: no one followed up on the bug triaging, that's all. | 16:05 |
| crimsun_ | HighNo: it can be marked Fix Released | 16:05 |
| HighNo | crimsun_: so it's ok that I have set it to 'fix released' now? | 16:06 |
| crimsun_ | HighNo: yes | 16:06 |
| HighNo | crimsun_: I thought there should be the debian/changelog entry which would close this bug automatically? | 16:07 |
| geser | smarter: looks like a good way to fix it | 16:08 |
| * mok0 would like help with the desktop | 16:08 | |
| smarter | geser: thanks, I'll upload the new revision to REVU | 16:08 |
| geser | HighNo: I looked at the python code to understand where and why that message comes from | 16:08 |
| geser | HighNo: I could track it back to "control = apt_inst.debExtractControl(open(file)) | 16:09 |
| HighNo | geser: wow, thanks for all the effort | 16:09 |
| mok0 | I have a "Debian" menu on my K menu. Where does that come from?? | 16:09 |
| ScottK | A package having a Debian Menu entry, but no .desktop. | 16:10 |
| ScottK | I think ... | 16:10 |
| mok0 | ScottK: but many apps appear in both | 16:10 |
| mok0 | ScottK: ... and some have icons in one and not the other etc | 16:11 |
| ScottK | As I (vaguely) understand it, once it's on, you see everything with a Debian Menu entry there. | 16:11 |
| mruiz | hi all . I tried to install five-a-day but it complained: five-a-day: Depends: python-central (>= 0.5.50) but 0.5.15ubuntu3 is to be installed | 16:11 |
| ScottK | mok0: I'd ask in #kubuntu-devel if you want to try and sort it out. | 16:11 |
| mok0 | ScottK: Weird | 16:11 |
| * mok0 goes to #kubuntu-devel | 16:12 | |
| nxvl_work | scottK: did you receive my mail? | 16:12 |
| ScottK | nxvl_work: I did and I support your application. I'm planning on writing on your wiki page to that effect. If I don't make it, you can quote me as saying "Definite +1 for membership." | 16:13 |
| nxvl_work | heh | 16:14 |
| nxvl_work | thanx | 16:14 |
| LucidFox | mok0> why did you migrate from dpatch to quilt for clipper? (not like I object, you're the original maintainer so your choice) | 16:14 |
| nxvl_work | scottK: but i find better if you write on my wiki, than just quoting you | 16:14 |
| ScottK | Sure. It's just that I'm about to head out the door right now... | 16:14 |
| jdong | LucidFox: I object! (kidding) | 16:15 |
| mok0 | LucidFox: Cf. a recent discussion on debian-devel, it seems they want to migrate things to quilt | 16:15 |
| nxvl_work | scottK: we have time, so don worry :D | 16:15 |
| LucidFox | so dpatch is going to be deprecated? | 16:15 |
| mok0 | LucidFox: I think | 16:15 |
| mok0 | LucidFox: I also like to get rid of those annoying 755 modes on patches | 16:15 |
| ScottK | LucidFox: Some time in the next 10 or 15 years. | 16:16 |
| ScottK | There's no consensus. | 16:16 |
| mok0 | It seems quilt has some advantages over dpatch, and it's no more difficult to use, on the contrary | 16:16 |
| ScottK | It just requires thinking about it differently which takes some practice. | 16:17 |
| HighNo | geser: grrr, you also stopped at apt_inst because it is a binary file? binaries are so debugging bad... | 16:19 |
| ScottK | nxvl_work: Commented. | 16:21 |
| nxvl_work | ScottK: thanks :D | 16:21 |
| * nxvl_work HUGS ScottK | 16:21 | |
| ScottK | No problem. You've earned it. | 16:22 |
| HighNo | hm, I seem to not being able to get source packages from de.archive.ubuntu.com - apt-get just sits there and waits. Anybody else has this problem? | 16:22 |
| geser | HighNo: where else should I stop? | 16:22 |
| geser | HighNo: I can't reach de.archive.u.c neither | 16:22 |
| HighNo | geser: :-) I know - I hate it when it gets binary... (that was no offense - it was just if you stopped there) | 16:23 |
| geser | HighNo: I'm just checking if I manage to produce an deb with ar that apt_inst likes | 16:24 |
| LucidFox | mok0> uploaded | 16:24 |
| mok0 | LucidFox: thx | 16:24 |
| mok0 | LucidFox: Hope it builds now :-) | 16:24 |
| HighNo | geser: ok - must go for some minutes now, bbl. Maybe anybody can tell me in the meantime how to change the mirror apt-get wants to download from... | 16:25 |
| geser | HighNo: sudoedit /etc/apt/sources.list | 16:25 |
| HighNo | geser: there's just 'archive.ubuntu.com' no 'de.a.u.c'...?! | 16:26 |
| geser | HighNo: have you some files in /etc/apt/sources.list.d/? | 16:26 |
| crimsun_ | HighNo: there was no corresponding changelog entry to close that bug. It was simply a lax in procedure on the part of the person who uploaded it. | 16:27 |
| LucidFox | hellboy195> commented on ksocrat | 16:38 |
| === mario_limonciell is now known as superm1_ | ||
| hellboy195 | LucidFox: so I should leave it as contrib/text? | 16:40 |
| LucidFox | yes | 16:40 |
| LucidFox | (by the way, thanks for reminding me about this package - I'm planning to take over it in Debian, as I use it and it's orphaned ATM) | 16:41 |
| hellboy195 | LucidFox: ah np ^^ I saw that it's orphaned and because of that I thought a merge would be worth it. As I said, first update since 2005 :) | 16:42 |
| smarter | I've uploaded a new version of extremetuxracer in REVU but it appears in the "New packages" table instead of the "Updated packages" one, why? | 16:42 |
| LucidFox | hellboy195> well, we can merge it now, and sync later | 16:43 |
| LucidFox | switching maintainers will probably take some time | 16:43 |
| hellboy195 | LucidFox: report add_icons back to debian? | 16:43 |
| hellboy195 | *dh_icons | 16:44 |
| LucidFox | hellboy195> If you feel like it :) | 16:44 |
| hellboy195 | LucidFox: but it doesn't make sense if you become the maintainer!? | 16:44 |
| LucidFox | smarter> probably because it's in NEW? | 16:44 |
| LucidFox | and not in the archive yet? | 16:44 |
| smarter | LucidFox: it's in the archive: "extremetuxracer | 0.4-0ubuntu1 | http://archive.ubuntu.com hardy/universe Packages" | 16:45 |
| LucidFox | then it's weird | 16:46 |
| LucidFox | hellboy195> If I become the maintainer, I'll add dh_icons whether or not you file the bug for missing dh_icons :) | 16:47 |
| LucidFox | the only difference is that if you do, I'll add (Closes: #) to debian/changelog | 16:47 |
| hellboy195 | LucidFox: then it's the question WHEN you become the maintainer ;) | 16:47 |
| hellboy195 | LucidFox: well, it doesn't matter to me. It's you decision ;) | 16:47 |
| === danielm_ is now known as danielm | ||
| hellboy195 | LucidFox: nvm. I sent it to debian already ^^ | 16:55 |
| smarter | New extremetuxracer revision awaiting review ;) http://revu.ubuntuwire.com/details.py?package=extremetuxracer | 17:05 |
| === Martinp24 is now known as Martinp23 | ||
| bigon | ScottK: I don't understand your comment about bug #192847 | 17:09 |
| ubotu | Launchpad bug 192847 in telepathy-salut "Please sync telepathty-salut 0.3.1-1 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/192847 | 17:09 |
| dholbach | RainCT: included your POD guide in a couple of places :) | 17:29 |
| dholbach | RainCT: thanks again | 17:30 |
| RainCT | dholbach: cool. no problem :) | 17:33 |
| LucidFox | Stupid CDBS. "rm -rf po/*.pot" in kde.mk's clean can't be disabled. | 17:35 |
| jpatrick | LucidFox: launchpad translations stuff | 17:36 |
| LucidFox | maybe, but it breaks upstream build :( | 17:37 |
| === slicer_ is now known as slicer | ||
| nxvl_work | james_w: around? | 18:02 |
| james_w | nxvl_work: hi. | 18:03 |
| james_w | I got your email thanks. | 18:03 |
| nxvl_work | james_w: so, how would it be? | 18:04 |
| nxvl_work | james_w: you make the talk and i add some ideas? or how? | 18:04 |
| james_w | I don't mind, do you want to take any particular sections? | 18:05 |
| nxvl_work | james_w: i'm more interested on best practices | 18:05 |
| nxvl_work | james_w: so maybe you can talk about the topics and i add a "best practices" part at the end of it | 18:06 |
| james_w | yeah, that suits me. If you could add anything I miss as we go that would be great as well. | 18:06 |
| james_w | nxvl_work: do you think that the draft looked like it would take an hour? | 18:06 |
| nxvl_work | james_w: i think we will need to run to make it fix in an hour | 18:07 |
| nxvl_work | james_w: you need to keep in mind that there are always questions | 18:07 |
| james_w | that was my thought too. I'll try and skim down the first parts. | 18:07 |
| hellboy195 | LucidFox: ping | 18:41 |
| LucidFox | hellboy195> yes? | 18:42 |
| hellboy195 | LucidFox: I got a response for the bug report. (add dh_icons) | 18:42 |
| hellboy195 | LucidFox: Note that dh_icons was only introduced in debhelper 5.0.51, | 18:43 |
| hellboy195 | so the build-dependency should be adapted. | 18:43 |
| LucidFox | yes, I see :) | 18:45 |
| hellboy195 | LucidFox: so, what does this mean? | 18:48 |
| LucidFox | hellboy195> it means that the debhelper build dependency in debian/control should be bumped to (>= 5.0.51) | 18:48 |
| hellboy195 | LucidFox: hmm. you are the debian maintainer soon. so it's task ;) | 18:49 |
| LucidFox | I've already uploaded it to mentors | 18:50 |
| LucidFox | http://mentors.debian.net/debian/pool/contrib/k/ksocrat/ | 18:50 |
| hellboy195 | LucidFox: nice :) | 18:51 |
| hellboy195 | LucidFox: btw, I *still* don't understand why I let contrib/text unchanged. I once did a merge and a remaining change was "Replace contrib with multiverse" | 18:53 |
| hellboy195 | DktrKranz: hoi mate :) | 18:53 |
| LucidFox | hellboy195> that was completely unnecessary, you could have just done a sync :) | 18:53 |
| LucidFox | once an Ubuntu package is assigned to a component, it stays there until the archive-admins explicitly move it out | 18:54 |
| DktrKranz | Guten Abend hellboy195 | 18:54 |
| hellboy195 | DktrKranz: hey, congratulation to perfect german :) | 18:54 |
| LucidFox | (see e.g. freecol: control says contrib, initially uploaded to multiverse, explicitly moved to universe at my request) | 18:54 |
| DktrKranz | hellboy195, my german stops here (as much as many other foreign languages) | 18:55 |
| hellboy195 | DktrKranz: nvm. it was perfect and made me happy :) | 18:55 |
| DktrKranz | heh | 18:56 |
| hellboy195 | LucidFox: so every package with "contrib" automatically moves to multiverse and noch change in debian/control is necessary? | 18:56 |
| LucidFox | hellboy195> archive admins decide where to put each package | 19:01 |
| LucidFox | for one, packages from contrib and non-free don't get autosynced, so it requires a manual sync anyway | 19:02 |
| hellboy195 | LucidFox: so they check every package and don't trust the Section field in debian/control? | 19:02 |
| LucidFox | I think they do look | 19:03 |
| LucidFox | but they're not bound fo follow it | 19:03 |
| hellboy195 | DktrKranz: do you feel bored? | 19:04 |
| DktrKranz | how many? | 19:04 |
| hellboy195 | DktrKranz: just 1 or maybe 2 since LucidFox exited | 19:05 |
| DktrKranz | already in the queue? | 19:05 |
| hellboy195 | DktrKranz: sure ;) | 19:05 |
| DktrKranz | good, then. I'll have a look later | 19:05 |
| hellboy195 | DktrKranz: cool thanks :) but don't feel compelled to do it ;) | 19:06 |
| DktrKranz | np | 19:07 |
| hellboy195 | :) | 19:07 |
| === RainC1 is now known as RainCT | ||
| bddebian | Heya gang | 19:44 |
| hellboy195 | bddebian: hoi :) | 19:44 |
| bddebian | Hello hellboy195 | 19:44 |
| geser | Hi bddebian | 20:06 |
| bddebian | Heya geser | 20:07 |
| RainCT | is anyone familiar with REVU (specificaly the server's configuration) around? | 20:26 |
| siretart | RainCT: perhaps. try it :) | 20:31 |
| nixternal | !5-a-day | 20:31 |
| ubotu | 5-a-day is a community event where each person will take 5 bugs a day and work on them. Everyone is invited to help no matter your abilities! More information available at https://wiki.ubuntu.com/5-A-Day | 20:31 |
| nixternal | :) GET TO WORKING! | 20:31 |
| jpatrick | get to? | 20:32 |
| nixternal | ya, don't know why I added the ING | 20:32 |
| RainCT | siretart: ok.. do files need the .py to be executed by mod_python or are extensionless files also accepted (and, if it doesn't, would it be acceptable to this)? | 20:34 |
| siretart | RainCT: uh, that would be a mod_python question. I suspect you can configure it to not require the extension somehow... | 20:35 |
| * RainCT asks because of bug #192715 | 20:35 | |
| ubotu | Launchpad bug 192715 in revu "Static URL pointing to the latest .dsc file" [Undecided,In progress] https://launchpad.net/bugs/192715 | 20:35 |
| siretart | http://revu.tauware.de/dsc.py&package=foo wouldn't hurt either, imo | 20:36 |
| RainCT | well, I'll give the file a .py for now and annoy sistpoty later :) | 20:36 |
| andresj | hello! I'm not sure if this is the right channel, but is there a tool for making svn snapshot source packages? I want to regularly upload them to Launchpad PPA... I want to use blender as my first test. I have downloaded the latest stable source package already. | 20:36 |
| RainCT | siretart: look at rationale 3 :D | 20:37 |
| siretart | andresj: snapshot source package? what's this? use 'svn export ../foo_version.orig.tar.gz' to create a source tarball, and add your packaging to that | 20:37 |
| siretart | RainCT: that's a matter of taste | 20:38 |
| andresj | siretart: by snapshot source package, I meant a regularly updated package that comes from svn trunk. | 20:38 |
| andresj | siretart: I'll try the command you told me :) | 20:38 |
| siretart | andresj: ah, you mean the holy grail, or having https://wiki.ubuntu.com/NoMoreSourcePackages implemented, no? ;) | 20:39 |
| andresj | siretart: probably not :) "svn trunk" > "svn trunk of upstream/vanilla program" | 20:40 |
| slangasek | mr_pouit: I don't understand why you say in bug #192614 that the Ubuntu delta is "unneeded"; does using xfce.mk instead of debhelper/autotools.mk really not do anything useful? | 20:41 |
| ubotu | Launchpad bug 192614 in ristretto "Please sync ristretto (universe) 0.0.17-1 from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/192614 | 20:41 |
| === \sh is now known as \sh_away | ||
| andresj | siretart: what version should I use? The latest stable version of the program is 2.45. Should I use the date? And how? | 20:50 |
| === tsmithe` is now known as tsmithe | ||
| RainCT | what's the keyboard combination to disable Compiz's advanced zoom? :S | 21:16 |
| pochu | RainCT: where did you get lightyears 1.3a from? latest upstream seems to be 1.2a, and watch file is reporting that (was said to be broken on a mail to debian-devel) | 21:18 |
| * RainC1 blames, curses and hits Compiz and asks hiself why they did even create it argh | 21:24 | |
| RainC1 | :P | 21:24 |
| RainC1 | pochu: upstream (link by e-mail) | 21:25 |
| pochu | RainC1: they didn't release it to the public? that's weird :) | 21:25 |
| === RainC1 is now known as RainCT | ||
| RainCT | pochu: I'll mail him somewhen soon about this :) | 21:26 |
| Nafallo | haha | 21:27 |
| Nafallo | nice server. didn't even see apt-get update run :-P | 21:27 |
| pochu | ScottK: may you have a quick look again to bug 192156? | 21:30 |
| ubotu | Launchpad bug 192156 in amule "[FeatureFreezeException] New upstream svn snapshot" [Undecided,Confirmed] https://launchpad.net/bugs/192156 | 21:30 |
| Ubulette | is bzr broken for anyone here or is it just me ? http://paste.ubuntu.com/4737/ | 21:46 |
| andresj | What should I do to be able to have two different versions of a program? I want to make "weekly snapshot" package of blender, but I want it to be possible to install it alongside the stable blender. I was thinking I could rename the package, but I don't know what should I do. I think there is a number apart from version numbers that allow two different versions of a package to be installed alongside each other, but I don't know | 21:51 |
| andresj | how to use it. | 21:51 |
| crimsun_ | Ubulette: on hardy, it's bug 192992. | 21:52 |
| ubotu | Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [Medium,Confirmed] https://launchpad.net/bugs/192992 | 21:52 |
| RainCT | andresj: rename the package and change the directories where stuff will get installed | 21:52 |
| _MMA_ | andresj: PM | 21:53 |
| crimsun_ | Ubulette: if bzr is critical, downgrade to the previous python-central version, attempt the upgrade, dpkg --configure -a, and then bzr will have upgraded | 21:53 |
| andresj | RainCT: Should I just change the name in the last (first) entry of the changelog and rename the files? | 21:53 |
| crimsun_ | Ubulette: for reference, http://launchpadlibrarian.net/10498055/python-central_0.5.15ubuntu3_all.deb | 21:53 |
| andresj | _MMA_: PM? | 21:53 |
| Ubulette | crimsun_, thanks | 21:54 |
| RainCT | andresj: first changelog entry from the top, debian/control and change installation dir in debian/rules / debian/*install and/or wherever it is set | 21:54 |
| _MMA_ | andresj: You have a "personal message". | 21:55 |
| andresj | _MMA_: oh :) | 21:56 |
| andresj | RainCT: should I change both Source: and Package: or only Package: section in debian/control? | 21:57 |
| RainCT | andresj: Package is enough | 21:57 |
| andresj | RainCT: thanks :) | 21:58 |
| awen_ | should the maintainer field be changed if making a security update to gutsy? (it only has a debian version now) | 21:59 |
| awen_ | the wiki page says "Update the Maintainer field only if working on Feisty or newer." ... but it doesn't say, what it should be updated to? | 22:03 |
| mok0 | ubotu, ! maintainer | awen | 22:03 |
| ubotu | awen: The "Maintainer" field in a package's information (debian/control) should indicate the Ubuntu team responsible for the Ubuntu specific changes to a package (often the !MOTU for !Universe packages). The original maintainer is preserved in the field "XSBC-Original-Maintainer". | 22:03 |
| awen_ | it's a main package - sdl-image1.2 | 22:04 |
| mok0 | awen, then I suppose you put the ubuntu-devel list | 22:08 |
| james_w | devel-discuss I believe | 22:09 |
| awen_ | so "Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>" is a good guess? | 22:10 |
| james_w | apt-cache show <package-in-main> should tell you for sure. | 22:11 |
| awen_ | james_w: that's what I tried :) ... thanks for the help | 22:11 |
| awen_ | when a debdiff has been prepared for a security bug in LP, what do you then do... it should be reviewed by a security team member it says; should I subscribe a team of some sort? | 22:16 |
| awen_ | it's bug 185782 | 22:16 |
| ubotu | Launchpad bug 185782 in sdl-image1.2 "Buffer overflow in GIF handling" [Medium,In progress] https://launchpad.net/bugs/185782 | 22:16 |
| mok0 | awen_: subscribe ubuntu-main-sponsors | 22:20 |
| awen_ | mok0: thanks | 22:20 |
| hellboy195 | DktrKranz: hoi ^^, now looking at my stuff? ^^ | 22:43 |
| hellboy195 | anyway. good night folks :) | 22:44 |
| RainCT | good night | 23:09 |
| === cprov is now known as cprov-out | ||
| slicer | Is there a way to check the target distribution in the rules file? It would make it much easier to use the same rules file for hardy and gutsy. | 23:17 |
| persia | slicer: dpkg-parsechangelog is likely the mechansim you want, although it is unfortunate if the rules must differ depending on the release. | 23:18 |
| nxvl_work | if a bug has been fixed on upstream, how do i mark the bug? as fix commited? | 23:18 |
| slicer | persia: If I understood an earlier discussion here correctly, PulseAudio is now default in hardy. Hence, hardy builds should use PulseAudio as the default audio device, whereas the gutsy one should stick to ALSA. | 23:19 |
| persia | nxvl_work: "Triaged" is good, unless there is already work underway to bring the upstream fix into the release, in which case, "Fix Committed" may be appropriate. On the other hand, don't overuse "Fix Committed", as there have been several bugs found in that status for years because nobody remembered to clean up afterwards. | 23:20 |
| slicer | persia: Thanks for the tip though :) | 23:21 |
| === Ubulette_ is now known as Ubulette | ||
| persia | slicer: Well, if that must be determined at build-time, I suppose you could check, but you likely want to be sure to catch -updates, -security, -backports, and any other -foo strings that may need adding, or you'll make it hard to maintain. I'd recommend different rules files just to make it easier to support, and not require adjustment and mangling each time a new release name is determined. | 23:22 |
| jdong | nxvl_work / persia: I personally think Fix Committed should ONLY be used in the case where the fix is for sure going to be uploaded to Ubuntu very soon, perhaps because the maintainer has another quick thing or two to roll together with it | 23:23 |
| jdong | I find it annoying when people use "fix committed" to mean upstream's VCS has some sort of patch, then not follow up in any way. | 23:23 |
| nxvl_work | jdong: it will be updated, but not for this release | 23:24 |
| * persia agrees with jdong, and further expects the developer to have already completed the change in the working area for the package (personal directory, VCS, etc.) | 23:24 | |
| nxvl_work | jdong: also i don't think they have plans to fix it on this release for the comments | 23:24 |
| persia | nxvl_work: If not for this release, then "Fix Committed" would not be correct. Use "Triaged". | 23:24 |
| nxvl_work | i can't use triaged :S | 23:24 |
| slicer | persia: Ugh. Good point. Ok, thanks. | 23:25 |
| persia | nxvl_work: Talk to bdmurray on #ubuntu-bugs and demonstrate 5 bugs you've helped work on, and you can join the team. For now, use "Confirmed". | 23:25 |
| nxvl_work | persia: ok, thnx | 23:26 |
| crimsun_ | superm1_: multichannel should be fine as long as you don't have ice17xx-based audio hardware. | 23:26 |
| superm1_ | crimsun_, huh? | 23:26 |
| superm1_ | oh you are talking about pulse from yesterday | 23:26 |
| nxvl_work | in progress isn't good enought, doesn't it? | 23:26 |
| superm1_ | that TheMuso and I were discussing | 23:26 |
| crimsun_ | superm1_: yes. Hardy's current PA source package doesn't have the fixes merged. | 23:26 |
| superm1_ | crimsun_, ah okay. | 23:27 |
| persia | crimsun_: Do you need testing from ICE17xx hardware, or is the issue known upstream? | 23:27 |
| crimsun_ | persia: both. | 23:28 |
| TheMuso | crimsun_: I can help test. | 23:28 |
| persia | crimsun_: I'm short on time now, but with a pointer, I'd be happy to help test. | 23:28 |
| crimsun_ | persia: I'll provide an interdiff in a couple hours. | 23:28 |
| persia | crimsun_: OK. I'll be able to grab & test in about 12. Thanks. | 23:29 |
| crimsun_ | currently chasing python-central. | 23:29 |
| persia | TheMuso: Are you 1712 or 1724? (I have 1724) | 23:30 |
| RAOF | \sh_away: You're a wine guy, right? How can I get a useful backtrace from wine? 0.9.55-0ubuntu1 segfaults very early (amd64). | 23:30 |
| TheMuso | persia: 1712 x 3. | 23:30 |
| TheMuso | They don't work either. | 23:30 |
| TheMuso | They don't show up in Pulse's GUI chooser for source/sink options. | 23:30 |
| persia | TheMuso: Excellent. We'll be able to hit them both then. | 23:30 |
| crimsun_ | it's because PA's alsa backend bails attempting to map channels. | 23:31 |
| TheMuso | I'm not surprised. | 23:31 |
| TheMuso | Since these cards have non-stsnadard outputs/channel names. | 23:31 |
| TheMuso | non-standard | 23:31 |
| persia | Not just that, but are typically configured in sets of stereo pairs, rather than n.1 arrangements. | 23:32 |
| cheguevara | RAOF: bug 191575 | 23:32 |
| ubotu | Launchpad bug 191575 in wine "wine segfaults on winecfg" [High,Confirmed] https://launchpad.net/bugs/191575 | 23:32 |
| Flare183 | Bug 1 | 23:48 |
| Flare183 | nevermind | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!