[00:10] How do I actually close a "needs-packaging" bug after the package is included in hardy? [00:12] slicer: After the package is uploaded to the Ubuntu repository, just change it to fix released in LP. [00:12] ScottK: Fix released. Rgr :) === a3p is now known as a7p [00:51] Heya gang [00:52] Howdie bddebian. [00:52] Hi RAOF [00:53] Anybody from the MOTU media team around who works on mplayer? [00:59] TheMuso, i've touched it a lot [00:59] but i'm not on MOTU media... [01:00] 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] TheMuso, it should [01:00] 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] i can verify on my work laptop, give me a few minutes to get it installed there [01:06] 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] superm1: I don't know how mplayer works in this regard. Does it just use pulseaudio if pulseaudio is running? [01:07] well i'd expect so. [01:07] let me force the driver to make sure its pulse then [01:08] TheMuso, yeah it continues to work when I forced it with asoundconf [01:14] superm1: asoundconf? Do you mean using the pulse alsa plugin? [01:14] yeah [01:14] Hrm I'll have to try it here myself. [01:14] asoundconf set-pulse [01:14] I mean pulse natively. [01:14] anyway, I'll test it. [01:14] er asoundconf set-pulseaudio [01:15] TheMuso, oh if you want to test natively [01:15] mplayer -ao pulse [01:15] which also works [01:16] superm1: But it doesn't use pulse by default? [01:16] TheMuso, i dont believe pulse is the default audio output [01:16] superm1: Right, do you think its something worth considering/ [01:16] TheMuso, its set as alsa, [01:16] which means alsa and then anything else [01:17] if that doesn't work [01:17] Oh ok. [01:17] I'll test here anyway. [01:17] well i suppose that priority can be adjusted [01:17] see /etc/mplayer.conf [01:17] it instead its set to [01:17] ao=alsa,pulse, [01:17] er [01:17] ao=pulse,alsa [01:17] ao=pulse,alsa, [01:18] that will do pulse, alsa, and then anything else [01:18] and i just tried it with no pulseaudio running, it just falls back to alsa fine with that setting [01:20] TheMuso, my only worry would be how well does pulse handle multichannel audi [01:20] like more than 2 channels? [01:20] superm1: I hav eben stress testing it bit here lately, and I've not had any issues. [01:21] TheMuso, against more channels? [01:21] Yeah I tried using pulse here, and it decided to try alsa, then used esd. [01:21] do you not have alsa available? [01:21] superm1: Yes, because I've been looking into getting speech using pulse as well. [01:21] I do, but pulseaudio is the default for GNOME. [01:21] And it grabs the ALSA device directly, using hw:number [01:22] TheMuso, I think a commit with it defaulting like that (pulse,alsa,) would be worthwhile [01:22] any systems without pulse don't break as it just skips over it [01:22] Ok, I'll take care of it. [01:22] you have the branch checked out already? (it's a big checkout) [01:23] 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:24] Yep will do. The first thing I do before working on a new src package these days is check for a VCS. [01:25] 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] Grrr! And that is very much the case. [01:25] No I have it checked out. [01:25] okay then carry on :) [01:28] * 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:31] yeah === n3xu|laptop is now known as nexu|laptop [02:04] how do you properly use --logfile in pbuilder? [02:08] sudo pbuilder build --logfile [02:15] thanks zul [02:17] Ok, mplayer change made, will not upload, as I'm sure others have things to do with it. :) [02:38] 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 === zakame_ is now known as zakame === asantoni_ is now known as asantoni [04:05] TheMuso: I think I've solved my premake problems [04:11] rjmyst3: great [04:13] 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] so now, the orig.tar.gz includes Makefiles, and not premake [04:13] that makes the source architecture independent, as it should be [04:13] with no weirdness with building premake [04:15] rjmyst3: Sounds great. [04:15] so, i've got a new orig.tar.gz and a new .diff.gz - would you mind taking a look? [04:17] 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:18] rjmyst3: See https://wiki.ubuntu.com/FreezeExceptionProcess fo more info. [04:18] c [04:18] 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:20] TheMuso, that was something that was talked about i thought, that new versions aren't necessarily needing and exception [04:20] otherwise we are just back at having a UVF [04:20] s/and/an/ [04:20] superm1: Ah yes, this is true. [04:23] superm1, TheMuso: what should I do? [04:23] 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] 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:24] 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:25] ok, i'll create the bug, thank you [05:22] superm1: ping? :) [05:23] boo [05:23] * RAOF is startled. [05:23] * Hobbsee tickles RAOF with a feather [05:23] ...and flies up into the canopy. [05:23] hi slomo__ [05:23] thanks for the upload of totem === zakame__ is now known as zakame [05:31] TheMuso, superm1, ScottK: The bug# is 192818 [05:32] https://bugs.launchpad.net/ubuntu/+source/wxformbuilder/+bug/192818 [05:32] Launchpad bug 192818 in wxformbuilder "FTBFS on all architectures except i386, amd64, and lpia" [Undecided,New] [05:43] email email email... [05:43] it's very overrated [05:53] good morning === asac_ is now known as asac [06:03] superm1: so do you want to maintain gmyth in debian too? if so, please give me a package for review :) [06:04] slomo__, yes that would be most ideal [06:04] changes shouldn't be too much to put it in debian, give me a little bit [06:04] superm1: great :) did you contact the debian multimedia team if they're interested in it too? whatever, i'll be back in 30 minutes ;) === slangase` is now known as slangasek [06:57] Good morning [07:03] slomo__, okay i've got it all together and an ITP all ready. [07:05] superm1: great :) [07:06] slomo__, let me get an account at mentors.debian.net made, and i'll throw it up there [07:10] slomo__, http://mentors.debian.net/debian/pool/main/g/gmyth/ [07:11] superm1: thanks, will take a look now [07:11] thanks [07:12] superm1: you repacked the tarball? then please name it 0.7.debian1-1 or similar [07:12] slomo__, yeah i had to repack it because of upstream including a broken debian directory :( [07:13] ok [07:14] superm1: libmysqlclient-dev | libmysqlclient15-dev | libmysqlclient14-dev please... the first is a new version in debian [07:14] ok [07:15] superm1: what about the UPNP stuff from configure.ac? [07:15] slomo__, afaik the upnp stuff isn't complete yet [07:15] ok :) [07:15] 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:16] i dont think its that useful yet - later it will be [07:16] when the project matures more [07:16] 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] ok [07:17] yeah i've seen those gnome packages, that does make it a lot easier to read diffs indeed [07:17] superm1: the -dev package needs to depend on libglib2.0-dev (pkg-config file requires it) [07:18] yeah that was probably missed because every app it is compiled with has already had it [07:18] i'll add that in [07:18] 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:20] 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] k [07:21] wooh, manpages :) [07:21] kinda boring manpages though :) [07:21] they exist, that's better than for most packages ;) [07:22] 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] 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:23] every time they've done public releases its been with the indt1 [07:23] ok [07:23] superm1: DEB_CONFIGURE_EXTRA_FLAGS := --includedir=/usr/include/gmyth <--- why is this encessary? seems weird [07:24] it was missing files when I didn't have it in before [07:24] ok :) [07:24] if i can try to remember back a week ago [07:24] 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:25] those rules will need some big mods at this point still too, with adding a .debian1 to the version [07:25] :) [07:26] superm1: in debian/copyright... the file is GPL-2 (as you need GPL version 2 or higher) [07:26] ah, now i finally know what indt is ;) [07:26] :) [07:27] superm1: the copyright is 2006-2007, not 2007 only [07:27] well actually 2006-2008 now I suppose. they've modified code this year [07:27] ok [07:28] good that you link to libcurl-gnutls :) [07:28] i'm relieved it worked with it :) [07:28] would have been hell getting this into main otherwise [07:29] 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:30] superm1: uh oh... you need some patching :) [07:30] in what? [07:30] superm1: libgmyth.so is not linked against libglib but should [07:31] superm1: it's only linked indirectly... so better get this fixed, otherwise dpkg-shlibdeps gives many warnings [07:31] ooh yay. [07:31] superm1: in src/Makefile.am [07:31] libgmyth_la_LDFLAGS [07:31] contanis some _CFLAGS variables [07:31] should be _LIBS instead [07:31] and needs patching in the Makefile.in too then [07:32] this already fixes it i guess [07:33] 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] and then everything is good :) [07:33] sorry if i'm a bit picky [07:33] slomo__, okay :). you sure caught a lot of stuff there [07:34] i'll get those cleaned up in the morning and shoot you an email once they're in [07:34] it's a little past bed time :) [07:34] ok, one thing left though :) [07:34] sure [07:34] superm1: what about the other source releases from the gmyth sourceforge project page? [07:35] they're not necessary for gmyth's functionality [07:35] but eventually will get those in too [07:35] gmyth is the more urgent one [07:35] ok :) [07:35] superm1: could you write me a mail when you're done with the package? [07:35] slomo__, yeah i'll do that [07:35] thanks :) [07:35] good work btw [07:35] okay night night, and thanks for helping me get this in [07:36] np :) good night [08:10] 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] also, he told me he wants to schedule piuparts for universe soon :) [08:39] Er, is PulseAudio installed (and used) by default now? === \sh_away is now known as \sh [08:58] <\sh> moins [08:58] Is Hardy universe freezed now or is there a chance that a package is accepted? [08:59] verb3k: which one? [08:59] Hardy [08:59] I mean which package [09:00] DktrKranz, The "Gens" Genesis emulator, I can't find it in the repositories [09:01] DktrKranz, https://bugs.launchpad.net/ubuntu/+bug/107927 [09:01] Launchpad bug 107927 in ubuntu "[needs-packaging] gens" [Wishlist,Confirmed] [09:02] verb3k: if it is not into hardy archives, you need to request a Feature Freeze exception (https://wiki.ubuntu.com/FreezeExceptionProcess) [09:02] DktrKranz, do you think it's worth it ? :) [09:04] DktrKranz, and it's not a feature it's a package in the universe(not supported) [09:05] Personally, I don't think so, but I'm not a ~motu-release member, so my words might be false. [09:05] verb3k: Feature Freeze exceptions apply to new packages too. [09:06] DktrKranz, someone already prepared nice packages and sources for ubuntu http://ubuntuforums.org/showthread.php?t=290008 [09:08] DktrKranz, whom do you think I should talk to in this channel about this? [09:09] <\sh> grmpf..brb [09:09] verb3k: someone from ~motu-release (https://launchpad.net/~motu-release/+members) === \sh is now known as \sh_away [09:11] DktrKranz, anyone you know from them is a gamer? that's a bigger chance to include this package :) how about Daniel Holbach? [09:12] verb3k: sorry, I'm not much of a gamer and quite busy right now === \sh_away is now known as \sh [09:13] dholbach, ok, but do you think the package can be accepted? if yes, who do you think I should talk to? [09:13] verb3k: I think none of them, but I may be wrong. [09:15] verb3k: http://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for how to get it submitted for review [09:16] 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:17] dholbach, I see, it's already been requested in LP: https://bugs.launchpad.net/ubuntu/+bug/107927 [09:17] Launchpad bug 107927 in ubuntu "[needs-packaging] gens" [Wishlist,Confirmed] [09:18] then best to get the package uploaded to REVU an link it in the bug report [09:22] I see, then I will try my best to get it before release, thanks for your time dholbach DktrKranz [09:22] anytime [09:23] verb3k: you're welcome [09:24] good morning [09:43] is this the correct channel for the dev week? or is that ubuntu meeting? [09:47] TuxCrafter: #ubuntu-classroom and #ubuntu-classroom-chat are the channels used for it [09:48] https://wiki.ubuntu.com/UbuntuDeveloperWeek/JoiningIn === man-di_ is now known as man-di [10:04] Unksi: thanks [10:05] youre welcome :) === man-di_ is now known as man-di [10:12] 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:14] persia: http://pastebin.ubuntu.com/4708/ [10:14] from 65k to this :) [10:15] of course it lacks changelog entries, but that's the most important part [10:18] DktrKranz: Is that against current, or against Debian? [10:18] persia: current, but there aren't main changes from 0.30 in Debian. [10:20] 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] Were you changing dpkg, it would be a different story :) [10:21] me too, I think 0.30 was uploaded saturday [10:22] persia: ok, then. I'll gather material required for a FFe, do some tests and submit the whole stuff. [10:22] we should have it in shape soon :) [10:24] 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:26] I hope so. I'd like to do something for {dapper,gutsy} -> hardy upgrade tests, I'll ask mvo about them [10:30] 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:32] mok0: does the first -dev package use headers from the other -dev packages? [10:33] geser: I can't remember, probably [10:33] 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] if it uses them, then the -dev package should depend on the other headers/-dev package [10:34] geser: so if headers are used -> Depends, otherwise Recommends?' [10:35] mok0: why would you want to recommend them? [10:35] geser: because the library calls the lower libraries [10:35] geser: and you can't link without them [10:35] mok0: That should be handled by the dependencies of the library package, no? [10:36] geser: that's what I am asking [10:36] persia: -"- [10:36] mok0: If I use libA-dev in a package it shouldn't matter to me which package libA depends on [10:37] geser: right, but if libA-dev calls functions in libB-dev [10:37] libA should link to the libs it needs and not the app [10:37] 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:38] * mok0 ponders... [10:38] Got it [10:39] A lot of that is handled by dh_shlibdepends I guess [10:40] dh_shlibdepends add the dependency on libbar to libfoo during its build [10:40] However, I need to do gcc prog.c -lA -lB [10:40] and if libB is not there... boom [10:40] does prog.c use both libs or only A? [10:41] functions from libB are called from libA [10:41] is libA linked with libB? [10:41] geser: no [10:42] please fix libA, it will it make easier when libB needs a transition [10:42] geser: right [10:42] Thanks === pochu_ is now known as pochu [11:36] Hi all! [12:02] hello [12:05] hiya === czessi_ is now known as Czessi [12:40] howdy all [12:41] hi norsetto [12:41] heya geser [13:07] So let's get a party going (let's get a party going) [13:07] Now it's time to party and we'll party hard (party hard) [13:11] Weird guy. === ogra_ is now known as ogra [13:34] hi all [13:44] Hey mruiz [13:44] hey Iulian [13:53] hi [13:53] Could someone explain me what to do with that(dpkg-shlibdeps complains)? http://pastebin.com/m7b68f3bf [13:54] smarter: Looks like an overzealous LDFLAGS in the build system [13:55] I didn't change the LDFLAGS [13:55] dpkg-buildpackage says: "dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions" [13:55] smarter: Check your buildlog: maybe upstream set LDFLAGS? [13:57] persia: dpkg-buildpackage from the recent dpkg sets now LDFLAGS, CFLAGS and others [13:57] persia: nothing special in the logs [13:58] geser: Yes, but upstream can still break that, depending on how it is defined. [13:58] maybe if I recreate the automake/autoconf stuff [13:58] smarter: In the buildlogs, is there not a line that has -lfoo -lbar, etc. [13:58] smarter: check in the build logs the linking stage [13:59] geser: where is the linking stage? [14:00] smarter: can you make the complete build log available? [14:00] 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] geser: ok [14:01] 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] persia: what should I do? [14:02] 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] geser: build log: http://launchpadlibrarian.net/11945971/buildlog_ubuntu-hardy-i386.extremetuxracer_0.4-0ubuntu1_FULLYBUILT.txt.gz === _emgent is now known as emgent [14:11] 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] 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] 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] 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] make[3]: Leaving directory `/build/buildd/extremetuxracer-0.4/src' [14:11] Making all in data [14:11] oops, a little bit long [14:11] smarter: that the linking stage [14:11] smarter, did you receive my email about qdevelop? [14:11] -lXXX means link with libXXX.so [14:12] LucidFox: yes, didn't have time to answer, sorry [14:12] ah [14:12] LucidFox: I think we should try to integrate this with upstream [14:12] But isn't -qt4 Ubuntu-specific? [14:12] Debian use it also [14:13] but upstream could first check for qmake-qt4, then qmake, ... [14:13] well, Debian-based-specific [14:13] ah, that makes sense [14:13] LucidFox: I'll try to speak with the upstream author [14:13] good, thanks [14:13] he's very responsive [14:13] 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:14] LucidFox: he provided a tar.gz package instead of the .zip the day after I asked [14:14] I like responsive upstreams. [14:17] geser: and how can I remove the unused -l libs ? [14:17] force LDFLAGS? [14:18] 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:20] smarter: check in the build system where they are added [14:21] l1unatic: did it say whey clearsignig failed? [14:21] l1unatic: Afaik, you'll need an entry in ~/.bashrc also. [14:23] geser: Secret key not available. [14:23] l1unatic: set the DEBEMAIL variable to the mail address of your key [14:24] 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] Debian bug 374349 in dietlibc-dev "Causes bglibs to FTBFS: undefined reference to `main'" [Serious,Fixed] http://bugs.debian.org/374349 [14:25] l1unatic: check if Changed-By in the changes file contains your complete key id (incl. all comments) [14:25] norsetto: ping [14:25] mok0: pong [14:25] norsetto: Hey! do you have time to look at xtide? [14:26] mok0: no, but when did I ever say no .... [14:26] norsetto: :-) [14:26] l1unatic: and just to be sure, set the DEBFULLNAME variable to that value too (the full name used for the key) [14:26] 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:27] norsetto: just to clear up the comments on LP. We need to get xtide-data and the merged xtide uploaded [14:27] anyone got an idea on my hand-edited .deb file? Maybe a hint where I should look, other channels to ask? [14:27] DktrKranz: so we have the choice between breaking other apps or bglibs? [14:28] mok0: so far so good [14:28] norsetto: you had some comments on xtide [14:28] geser: we have the choice to revert dietlibc and uploading fifteen packages with --fno-stack-protector [14:28] mok0: yes, there seems to be some unneeded changes [14:29] or waiting for a better solution, but I don't think it will come before release [14:29] HighNo: what "strage results" did you have? "dpkg installs it nicely - the software is completely installed and runs perfectly" sounds good. [14:29] 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] geser: Ya. The entry is complete. [14:29] mok0: but that is not a carried over change [14:29] HighNo: Ok. I'll just check. === lamalex_2 is now known as lamalex [14:30] 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] 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] norsetto: no it's a change I made for the new wvs1 stuff [14:30] DktrKranz: I looked at bglibs and I don't understand why it complains it can't find main. [14:30] mok0: right, now we have it in the repos and it makes sense to use it, thats what you are saying [14:31] persia: ok, that's what I've done to xtide-data (except that "Revert..." comment) [14:31] mok0: so just prepare a new debdiff where you sync xtide from debian and add this new change [14:31] 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] mok0: It's the except that was part of what was confusing :) [14:31] norsetto: I have, it's that old patch [14:32] mok0: which old patch? [14:32] norsetto: from 2008-02-01 [14:32] mok0: yeah, but where is that, in a comment in the bug report? [14:32] DktrKranz: do you know more about it? what the exact problem? [14:32] norsetto: It's in bug 188086 [14:32] Launchpad bug 188086 in xtide "[needs-merge] xtide-2.9.5-2 from sid" [Wishlist,In progress] https://launchpad.net/bugs/188086 [14:33] mok0: I see quite a lot more than that in that debdiff [14:34] norsetto: I did it as a standard merge, so the old changelog entries have been carried over [14:34] geser: the problem is GDebi doesn't even open the new .deb file - telling me it's corrupt [14:35] mok0: its not a merge, its a sync with a new change (the addition of xtide-vws1-data) as we just discussed [14:35] norsetto: so, you want me to make a new debdiff that only includes that? [14:36] mok0: I'm all for minimise the delta wrt debian, unless justified (which in this case I don't think it is) [14:36] HighNo: ah, your first message got cut of at "...runs perfectly. GD" [14:36] norsetto: that's fine, I'll fix that. Now, what about xtide-data? [14:36] HighNo: is the same version of the deb also in the archive? [14:37] Hi [14:37] mok0: wait a sec, what about the dirs change? Thats not even in the changelog [14:37] norsetto: that's reverting to debian [14:37] geser: ? do you mean the cache? it's not in universe - at least not for feisty [14:38] mok0: well, if we sync you don't need to do that, its a dropped change [14:38] 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. === dholbach_ is now known as dholbach [14:38] norsetto: afai understood persia just before, we can not go down in version number [14:39] mok0: ah, you mean the version you want to sync its an older version!? [14:39] geser: I asked upstream if there's something I can do, but never received a reply. [14:39] norsetto: It ought be a sync, except that first requires a Debian update :) [14:39] mok0: then yes, we need to do as you did (...what a mess....) [14:39] norsetto: it has release -1 instead of -1ubuntu1 [14:40] persia: yes :-( [14:40] norsetto: yes, a mess. [14:40] (and Debian is not of aid, since it's not its business) [14:40] 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] 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:41] persia: it is 1ubuntu2 in the patch on LP [14:41] mok0: Ah, good. Last time I looked, there status was perhaps a bit more confusing (that being the 14th). [14:42] 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] persia: it's been on my list for a while and I want to get rid of it [14:42] norsetto: what cosmetic changes do you mean? [14:43] mok0: for instance the lintian warnings [14:43]