[00:01] where would be the appropreate place to document this sort of decision? [00:02] (that last question is open to all) [00:03] rexbron: probably first ubuntu-motu/ubuntu-devel ML [00:03] LaserJock, this package is not in the repos yet, but I will do so [00:08] rexbron: I'm not really here, but my concern is that while openlibraries uses rpath entirely internally within itself, open libraries is intended to be used for building other applications, and I'm not convinced that there won't be odd follow-on behaviour once other packages dynamically load the libraries, possibly with RPATH set, nor am I sure those packages won't run against policy. I may be completely mistaken, and expect your research to hav [00:10] ouch buffered [00:11] I would think that any libraries that use openlibs would not use rparth, hense preserving upgrade sanity [00:11] * rexbron will definately take it to the ML [00:20] rexbron: But if the openlibraries itself uses rpath, then anything using it... [00:21] RAOF, if only internally? [00:22] rexbron: But the OL libraries are installed into a non-ld-config-known path, right? Anything linking against them will need to do annoying stuff. [00:22] Basically, openlibraries is a collection (five main ones, with in each there is a C++ lib and a python binding) and a bunch of compiled plugins for those libs [00:23] RAOF, by nonstandard I mean /usr/lib/openlibraries- [00:23] which is how upstream is installing it [00:23] Ok. So the libraries themselves are in /usr/lib, and the plugins are in /usr/lib/openlibraries type thing? [00:23] no, [00:23] currently everything is in /usr/lib/openlibraries-0.5.0 [00:24] That sounds like a really annoying idea. [00:24] RAOF, I was striping the rpath out of the libs that had it (not all of them do) [00:24] but that completely broke the python bindings [00:24] due to the non-standard location [00:25] it is possible though that I mangle it in the .install files [00:25] This non-standard location isn't build-time configurable? [00:25] afaict, no [00:25] beyond a prefix [00:25] rexbron: For details of why installing libraries in /usr/lib/foo is really annoying, see *anything* which embeds gecko. [00:25] :P [00:25] That's annoying. [00:26] Whine upstream :P [00:26] nenolod: pong [00:26] RAOF: pong [00:26] RAOF, upstream just revived itself [00:26] RAOF, it might have to do with the devs being Mac and Windows peps [00:27] crimsun: Hi. Trying to hack in multiarch _sucks_ :( [00:27] heh, it's nice and comfy down here in hell, isn't it? [00:27] I wonder if I strip rpath and install everything to /usr/lib if the problems would allivate themselves [00:28] rexbron: Worth a try :) [00:28] I am unsure if ld.so.conf is getting updated by debhelper... [00:29] crimsun: My final problem is trying to make the bi-arch build not build plugins that it can't, but pkg-config thinks it can. [00:30] RAOF, the dir structure is like this: usr/lib/openlibraries-0.5.0/openeffectslib/plugins/ [00:30] or usr/lib/openlibraries-0.5.0/openeffectslib/lib [00:31] rexbron: Hit upstream with a big "what the hell are you doing" stick. [00:31] "Bash upstream with the libtool handbook.." [00:32] It makes sense to have the plugins in /usr/lib/, but that looks mad. [00:37] RAOF: did you mean to follow up that last one? [00:48] crimsun: By "last one" did you mean the "stopping it building the plugins it can't, but pkg-config makes it think it can"? [00:48] RAOF: yes [00:48] Ah. [00:49] I can explain the problem: configure checks pkg-config for libpulse, jack, ald dbus-1, and sets "HAVE_foo". [00:50] However, pkg-config is returning results for the native bitness libraries. So it tries to build all of these plugins. [00:51] I can partially work around this by telling pkg-config to look in /usr/lib$)bi)/pkgconfig (which is empty) and manually specifying the right libs & cflags. [00:52] That builds the basic plugins, with no external dependencies. However, since they use a [if found] and a [if not found] custom action for their PKG_CHECK_MODULE configure calls, libpulse & dbus-1 (which exist in ia32-libs) don't get built. [00:53] anyone have program that needs packaging that they've been saving for a newbie :-)? [00:53] crimsun: Given that what *I* want out of lib32asound2-plugins is a 32bit pulse plugin, this isn't very useful behaviour for me :( [00:53] crimsun: Any ideas? [00:55] RAOF: do your basic debian/rules modifications follow alsa-lib's? [00:56] crimsun: Yes, they do. I can post them, if you like. [00:57] sure, though my attention is diverted to a PA security issue ATM, so I'll be slow in responding. [00:58] crimsun: That's fine. It's at http://www.cooperteam.net/rules [01:11] anybody know how to tell tracker what to index? [01:13] <_MMA_> LaserJock: Isnt there a place where to tell it what *not* to index? [01:13] bah [01:13] I killed it [01:13] I want it to index my pdfs [01:13] That isn't hard [01:13] and it doesn't seem to do it [01:13] does it not index .pdf files? [01:13] * _MMA_ only thought there was a blacklist. [01:13] LaserJock: It'll index your ISO images too. [01:14] ScottK: hah, that's smart [01:14] I saw it also indexes vmware images [01:14] <_MMA_> :) [01:14] but they're gonna blacklist that [01:14] so far the only thing I found it *can* do is index my email [01:14] Well I think Tracker is one of the best advertisements Kubuntu has has in a long time. [01:15] which I can already do from evo [01:15] ScottK: you use strigi? [01:15] LaserJock: Actually not, but I understand it's better behaved. [01:15] My main desktop (where it'd be useful) is still Dapper. [01:16] I know there's been some cool work with strigi and chemistry indexing [01:18] crimsun, would ALSA plugin chains cause problems with DMA writes in libalsa? [01:18] LaserJock: BTW, so far so good the mass clamav backport. Thanks again. [01:19] ScottK: great [01:21] nenolod: quite probably, particularly if dmix and/or dsnoop are in the mix. [01:26] bah, I give up >:( [01:28] heya people [01:50] Heya gang [02:38] ScottK: I think you have been hanging around Debian too much already.. ;-P [02:44] bddebian: Not yet. I didn't curse at you. [02:52] crimsun, fantastic. thanks (: [02:55] ScottK2: Heh, touche :-) [03:37] * emgent night. [03:37] ScottK2: Wanna help with a bug instead? :-) [03:38] What bug? [03:38] testresources FTBFS [03:39] And? [03:39] And I don't know how to fix it :-) [03:40] Point me at a build log? [03:40] I read that as "testosterone FTBFS" :/ [03:41] ScottK2: http://paste.debian.net/47576 [03:41] LucidFox: :) [03:43] bddebian: Is the the Debian package or the Ubuntu one? [03:44] I just updated the debian one so they are pretty similar but same issue [03:45] I'll have a look. [03:46] You ROCK :) [03:46] I need to improve my python.. :-( [03:47] Well, and everything else.. :) [03:47] Cue bddebian suckage rant? [03:47] :) [03:50] Yeah, he does suck doesn't he.. [03:51] Well the ubuntu package doesn't even get that far right now. [03:52] Ah, I used python support [03:53] doko would kill me if I changed it in Ubuntu. [03:53] heh [04:01] bddebian: I got it to build in Ubuntu. [04:01] I made two changes. I'm not sure which it was. Testing. [04:01] What did you change... Oh :) [04:04] The problem in Ubuntu was that python2.4 wasn't present [04:04] So I changed python-dev to python-all-dev [04:04] Also moved it from build-dep-indep to build-dep since it's needed in clean according to Lintian. [04:05] So it'll build now and the current Ubuntu package that hasn't been built since python2.4 was default (I think) will now built. [04:05] built/build [04:06] Hmm I have both of those.. weird [04:06] Do you have a sid pbuilder? [04:07] I do. [04:08] I just uploaded to Ubuntu so it'll at least build. [04:08] I've got to run here in a minute. [04:08] I kicked off my sid pbuilder and we'll see what happens [04:08] OK, thanks [04:10] bddebian: Builds fine in my sid pbuilder. Feel free to steal it for Debian. ;-) [04:11] It could use more work. Lintian is happier, but not satisfied. [04:11] Grr, wtf [04:22] Hey, would anyone be willing to throw together a _very_ simple package for me? My personal life has taken a turn for the insane and I'm becoming unsure of whether I can get it done before freeze, although an experienced person could probably do it in a matter of minutes. [04:23] I just fixed bddebian's bug for him, so he's got free time. [04:24] I find it hard to believe that it's actually fixed with that :) [04:24] tonyyarusso: What/where is it? [04:24] It has been proposed that a package with the name of 'nvu' be added to the Hardy repos in the same vein as the 'mozilla-thunderbird' package, just as a transitionary package depending on 'kompozer' (already in the archives), so that Dapper users have a clean LTS->LTS upgrade path. [04:24] bddebian: ^ [04:24] tonyyarusso: Make it an additional binary package of your kompozer package. Not a whole new package. [04:25] Aye, can't you even just make it Provides: ? [04:25] ScottK2: That makes sense... [04:25] bddebian: I'm not sure? Probably? [04:25] bddebian: We'll see. [04:26] bddebian: So I just add a Provides: line much like Depends:, and if a user has nvu installed on Dapper, and upgrades to Hardy, they'll get the new kompozer package installed? [04:26] You could just ask mvo to add an hint to update-manager [04:27] a hint? [04:27] * tonyyarusso looks for documentation on Provides [04:27] tonyyarusso: Should. You might also need a conflicts/replaces if you do that?? [04:27] tonyyarusso, bddebian: Does provides: work properly accross package renames & upgrades? I remember being asked to provide a proper package for Miro. [04:27] RAOF: It may not [04:27] tonyyarusso: I'd suggest asking pitti when he turns up [04:28] ScottK2: Can you throw a source package up somewhere or are you leaving? [04:28] "For some types of packages where there are multiple alternatives virtual names have been defined. You can get the full list in the /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz file. Use this if your program provides a function of an existing virtual package." [04:28] tonyyarusso: Ignore that [04:28] StevenK: heh, all right. Didn't know what it meant anyway! [04:28] * Hobbsee would just use conflicts and replaces nvu [04:29] It has no reason to Conflict [04:29] Hobbsee: I know that would properly replace nvu if they did it manually, but I'm confused about upgrade-specific behavior. [04:29] Replaces and Provides, sure. [04:29] StevenK: ah right, is that it. [04:29] StevenK: assuming none of the files wer ethe same [04:30] Wait, no reason to Replaces either [04:30] It is possible to have both packages installed simultaneously. It would just be a tad silly, and not what an upgrader would expect. [04:31] AFAIK they have different paths for all files. [04:31] I think this should documented [04:31] Sigh [04:31] I think I need a clone. [04:32] (Full time student and managed to find myself doing three jobs too - stupid, but they're good jobs, so hey - just a wee bit busy between now and June) [04:33] So pitti or mvo eh? I forget; what times are they usually around? [04:34] tonyyarusso: European work day. [04:34] ScottK: 'k [04:34] Damn Europeons [04:34] * bddebian ducks [04:35] tonyyarusso: Any chance you could look into making the publish function work with SFTP and not just FTP. [04:35] That's be really handy. [04:35] ScottK: Make it work, no. Mention the desire to the guy who could, yes. (I just put it in the archives; someone else wrote the code.) [04:36] ScottK: Meanwhile, you wanna add scp as an option to sbackup? :P [04:36] (Just while we're talking about transfer methods in random packages on our wishlist) [04:36] tonyyarusso: Mentioning would be great. [04:37] ScottK2: on the todo list [04:38] Great. [04:40] Good night all. [04:40] Gnight ScottK, thanks for looking at that [04:42] Even if it does fail on sid for me... ;-) [06:06] keescook: I've filed and attached the appropriate info to bug 185534. [06:06] Launchpad bug 185534 in pulseaudio "[SECURITY] Fix unchecked setuid() return values (feisty-security, gutsy)" [High,Fix released] https://launchpad.net/bugs/185534 [06:39] heya all === boomer` is now known as boomer [07:32] how do i build tarballs to create source packages from? like a source package to install wallpapers === bigon` is now known as bigon [07:41] Aloha: By taking a directory with all the stuff you want in it and going "tar czvf wallpapers_0.1.orig.tar.gz" [07:41] RAOF, i want to make a bonary package though [07:41] binary [07:42] Which will be built from a source package, which will start with a .orig.tar.gz? [07:43] RAOF, how do i get it to install the files? [07:43] Any way you like. dh_install is probably a good way. [07:44] * Aloha needs to grok dh_install [07:45] It's pretty easy; you have a 2 column list. The first column is the file you want to work on, the second is where it should go. [07:46] RAOF, then i put dh_install in debian/rules? [07:46] Yup. Probably in the install-indep target. [07:46] * Aloha needs to grok install-indep [07:46] RAOF, thnx for the help [07:47] Heh. debian/rules is just a makefile with a bunch of specified targets :) [07:47] gotcha [07:47] It helps to have a basic understanding of Makefile syntax. Which is also pretty easy :). [07:47] * Aloha needs to grok Makefile ;) [07:48] only Makefile work I usually do is typing make heh === \sh_away is now known as \sh [07:55] what targets does the installer call in the Makefile when the package is installed? [08:05] Aloha: You'd want to check Debian policy; there's a list of all the targets there. [08:05] RAOF, thnx [08:05] In particular: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules [08:07] RAOF, whats the advantage of using dh_install over a simple cp? [08:08] It's more debianic, for a start. [08:09] If you weren't going to use dh_install you'd probably want to use install anyway, so you can control the permissions, for a start. [08:09] And if you're installing a bunch of wallpapers it can be more obvious to have them listed in debian/foo.install rather than having a bunch of cp lines. [08:10] RAOF, gotcha, how does dh_install how which .install file to look in? [08:10] or do i dh_install file.install? [08:10] It either looks for debian/install, or debian/.install [08:11] This is common behaviour for debhelper programs [08:11] where dh_name looks for debian/name? [08:12] Or debian/.name, yes. [08:12] RAOF, thnx you're a BIG help [08:29] dpkg-buildpackage --rfakeroot doesn't execute binary-arch? [08:36] g'morning all! === civija_ is now known as civija [08:39] wallyweek, morning [08:42] <\sh> hmm..how can I stop gnome/nautilus/whatever to show dynamically mounted lvm devices? [08:45] morning everyone [08:51] morning folks [08:51] norsetto: ue'. [08:51] ué gaspa - ron [08:51] ue' == "tipical american greeting" :D [08:52] gaspa: gasparon = typical american nickname [08:53] :D [08:53] norsetto: how are you? [08:53] gaspa: surviving, and you? [08:55] norsetto: very good!! [08:55] when i do dpkg -c packagename.deb it lists /usr/bin and /usr/sbin how do i get rid of that? [08:56] norsetto: i've a little monst... ehm... daughter that makes hard to sleep well. :D [08:56] gaspa: he, the pleasures of parenthood .... you going to Pisa this week-end btw? [08:56] siena, you mean... [08:57] Aloha: most probably you used dh_make and that automatically includes those in debian/dirs I guess [08:57] gaspa: yes, somewhere in Tuscany anyhow ;-) [08:57] lol [08:57] norsetto, oh gotcha. is there a better way to build non compile source packages? [08:58] aloha: to build not compile!? Sorry, don't follow you ... you mean to make a tarball and attach it a deb label? [08:58] norsetto: i don't know, there's not so much developers, and i don't like 'organization meetings' [08:59] norsetto, i just have dh_install in my package and not anything else. no software gets compiled [08:59] gaspa: yeah, I can undersatnd, its a good excuse to have fun together though [09:00] aloha: well, just make a very simple rules then, but you still need copyright, control and changelog [09:00] of course. and you? what will you do? [09:00] * wallyweek welcomes norsetto in non-sleeping fathers club :p [09:00] aloha: also, some target needs to be there (don't remember the list by heart) even though they are used, you should check the debian policy for that [09:01] aloha: read that "even though they are not used" [09:01] norsetto, ok thnx alot :) [09:01] wallyweek: hey, its gaspa the lucky parent ;-) [09:02] wallyweek: yes, i'm the one [09:02] Hey folks. [09:02] Hey, TheMuso [09:02] aloha: you could also check some similar package to give you an idea, there are few which only ships bash scripts for instance [09:02] oh I see... this online client is a nightmare :) [09:02] ué TheMuso [09:03] ops, morning TheMuso [09:03] norsetto: so, will you go to siena? [09:03] gaspa: nope [09:03] i see. [09:04] norsetto: well, i think i'll go to fosdem, anyhow... [09:05] gaspa: siena?! why? [09:07] wallyweek: there's the ubuntu-it meeting, this weekend. [09:09] gaspa: I can't go either but it's nice to know, thanx! :) [09:10] wallyweek: uh. are you italian? or in italy? [09:11] gaspa: yes to both [09:11] i see. === \sh is now known as \sh_away === \sh_away is now known as \sh === \sh is now known as \sh_away === \sh_away is now known as \sh === gouki_ is now known as gouki === \sh is now known as \sh_away === \sh_away is now known as \sh [10:27] Hey there, would anybody like to review http://revu.tauware.de/details.py?package=speed-game ? It's a very simple package and I've addressed all previously reported issues. It's been 10 days since the last review. [10:32] ScottK: r u around? === Aloha is now known as tjgillies === lifeless_ is now known as lifeless [11:01] Can anyone please review this debdiff before I actually attach it to a bug. http://paste.ubuntu.com/3827/ [11:02] slytherin: What level of review do you seek? [11:03] slytherin: BTW: have you had time to look into that axis bug? [11:04] persia: I was not sure how to set a variable's value with command substitution in rules file and then use that variable. So I have used command substitution twice where needed. [11:05] man-di: Nope. Couldn't find what exactly the reason was. I will have to take a detailed look in the error. [11:05] slytherin: from what I saw the bug was filed because GCJ ICEd on building [11:06] slytherin: At a base level, I think you want $(shell ) rather than `` in a makefile, and I don't believe in minor standard version bumps when updating Debian packages: this is only worthwhile if you get the ancient-standards-version report, and feel like cleaning all the cruft. 3.7.2 -> 3.7.3 just adds noise to the patch and confuses MoM. [11:06] slytherin: when you can build the package that is fixed already [11:06] man-di: I will try today [11:06] slytherin: For setting a variable, just use $(shell ...). Whether to use = or := depends on whether the result changes during the interpretation. [11:07] slytherin: thanks, I think that bug can just get closed [11:07] persia: Ok. Will remove version bump. And also use $(shell command). But then how to use that variable? $(var)? [11:09] slytherin: OK. Assuming you want to set the variable once at parse time (to avoid multiple calls), you'd use MY_VAR := $(shell ). You can also use curly braces if you find that less confusing. [11:09] persia: Done that. And then how to use that variable where the value needs to be substituted? [11:10] Then, you can use $(MY_VAR) later in the makefile to call it. If you use :=, be sure to define before using. If you use =, it is less strict (but produces multiple calls). [11:10] slytherin: Sorry. I'm not the fastest typist :) [11:10] persia: oops, sorry. I thought you didn't understand my question [11:12] <\sh> soren, any clue why bochs ftbfs at configure stage with checking for default gui on this platform... x11 [11:12] <\sh> ERROR: X windows gui was selected, but X windows libraries were not found. [11:13] slytherin: I just tend to be wordy, and there's this annoying 256 character limit imposed by freenode that often keeps me from using paragraphs properly. [11:13] (or maybe it's 255 characters: I never actually counted) [11:14] persia: By the way, I am not sure if the patch actually fixed the bug. It just installed extension at proper place. I have not actually tried the package to check if there are any ABI compatibility problems. [11:15] slytherin: Good to test things before uploading :) Also, please shift to $(shell). Using escape characters to convince make to run shell scripts is less than ideal. [11:15] persia: Do you have hardy running at this point of time? I am in office and can't test the package. :-( [11:16] I was looking at http://packages.qa.debian.org/d/dialign-t-doc.html . This package is not in Ubuntu and I would like to request a sync. It is in non-free, but I don't understand why, since it is under LGPL. Any idea? === Nightrose2 is now known as Nightrose [11:16] slytherin: Yes, but I've a larger queue that I am confident I can process before I next sleep. You'll have better luck with another tester. [11:18] persia: Ok. If I don't find anyone I will test it tonight at home and then submit the fix tomorrow. [11:19] * pochu wonders whether Hobbsee plans to write something regarding her application to the MC... [11:21] Is anyone willing to test a fix for nautilus-open-terminal? I don't have access to a hardy system at present. [11:23] * DaveMorris asks persia nicely if he'd have time to review his OpenSG package again some time soon [11:24] DaveMorris: I'll start a build overnight, and try to take a look tomorrow. Has nobody else reviewed it? [11:25] no [11:25] people tend to pick the smaller packages [11:25] * persia encourages someone else to review opensg, as only one reviewer doesn't tend to make the best quality package [11:27] warp10: I didn't check it but it could [build-]depend on something in non-free [11:27] DaveMorris: You've not the biggest. Take a look at the urbanterror candidate :) [11:27] \sh: Just a wild guess: Because you don't have x11 development packages installed? [11:28] persia: that looks like it has a sane build system though :) [11:28] <\sh> soren, libx11-dev is in b-d :) [11:28] norsetto: I checked it before asking here: it just build-depends on debhelper, depends on ${misc:Depends} and suggests dialign-t (in main and universe). [11:28] <\sh> soren, well, it's the new debian upstream package...where your changes are applied :) [11:29] \sh: Ah, nice. [11:30] <\sh> soren, but the problem occured now.. [11:30] * soren is looking [11:31] <\sh> soren, cool thx [11:32] warp10: I'd guess it's considered non-free because there doesn't appear to be any source file for the PDF/ps/html docs. Just a wild guess, though. [11:33] \sh: Builds fine in my sbuild. [11:33] \sh: Are you on amd64 or i386? [11:33] persia: mmm... maybe that's the issue. I'll try to contact the maintainer, he should know about that [11:33] * soren high-fives dholbach [11:34] <\sh> soren, amd64 [11:34] \sh: Me too. [11:35] warp10: Check the changelog. I suspect that it would make sense to drop the package, and restore the upstream tarball in dialign-t, rather than just moving to universe. Of course, this is only worthwhile if you plan to maintain the fork. If you just want to be a user, bests to leave in multiverse. [11:35] <\sh> soren, oh fun...what could that be [11:35] soren: what about? :) [11:35] dholbach: Because everything is *awesome*! [11:36] \sh: Are you building in pbuilder or sbuild? [11:36] <\sh> soren, sbuild [11:36] soren: OK, I think I can agree with you :)) [11:36] hi [11:36] <\sh> soren, I can check against pbuilder [11:36] To be fair, my sbuild is slightly out of date. [11:36] Well, my chroots are. [11:37] Dear TeX-maintainers. Please use triggers. kthxbye [11:38] persia: well, I don't like to increase our delta with debian, but that could be a good idea, since I am greatly interested in having that package in good shape in Ubuntu. [11:38] <\sh> soren, update ;) [11:39] It's running, it's running, I've just got... erm... let's just say "a few" schroots. [11:39] <\sh> soren, are you using local archive mirrors, just as I do? [11:40] \sh: apt-cacher [11:40] warp10: Keeping close to Debian is largely a way to reduce the amount of work that MOTU needs to do. If you want to commit coordination for that package, you might split it. On the other hand, I don't think we allow non-built-from-source docs in universe either: check with an archive admin. [11:41] \sh: rebuilding with fresh chroot. [11:42] <\sh> ah [11:43] <\sh> well libx11-dev should be enough for with-x11 [11:44] persia: I'll surely do that, but I would like to ask to debian first, maybe there are additional reasons for putting that package in non-free. [11:44] \sh: It still builds fine here. [11:45] <\sh> hmmm [11:45] <\sh> I just recreated the chroot this morning [11:47] <\sh> soren, can you send me your build log please? [11:47] <\sh> I wonder what's wrong here [11:50] hey proppy! [11:50] heya dholbach ... [11:50] hey norsetto [11:51] * proppy hugs norsetto [11:51] * proppy hugs dholbach [11:51] whats up dholbach? You seem unusually depressed!? [11:51] proppy: any new spec in preparation? Any linux-unfriendly software being packed? :-) [11:52] norsetto: errrrr? :) [11:52] norsetto: not really :-) [11:52] * dholbach hugs norsetto and proppy [11:52] dholbach: good ... you had me worried [11:52] norsetto: was in a big hole that poped up just today :) [11:52] norsetto: why? what happened? [11:53] dholbach: I mean, that you seemeed not ok [11:53] norsetto: I'm happy our spec got implemented :) [11:53] norsetto: and juce packaging still waiting for upstream feedback [11:53] proppy: a hole? ok, your company discovered you and got rid of you even before it disapperead? [11:55] * Kmos hugs norsetto & dholbach [11:55] norsetto: kinda like that, we've setup specifications and meetings for a no budget response in the end :) [11:55] \sh: I kind of killed it before it finished. You said it died during configure.. [11:55] hey Kmos [11:55] <\sh> soren, yepp [11:55] hi kmos [11:56] norsetto: won't you candidate to motu council member? [11:56] kmos: nope [11:57] <\sh> soren, trying with an i386 chroot now [11:57] norsetto: i think you have a good place there :) [11:58] kmos: there are much better people than me for that, believe me ;-) [11:58] norsetto: and one is you :) hehe [11:59] <\sh> soren, the same...checking for X ... no and then failing at checking for default gui on this platform... x11 [11:59] <\sh> ERROR: X windows gui was selected, but X windows libraries were not found. [12:01] \sh: Have you tried using debuild under schroot -c foo? You may find that you can more easily understand the issue when you are exploring the existing build. There's also the --purge=never argument to sbuild if you like. [12:02] <\sh> persia, I'm checking against pbuilder now, and push a testpackage to my ppa... [12:03] \sh: You can get a pretty close simulation of the PPA if you download the buildd chroot tarball from launchpad, and use that to prep your schroot. [12:04] \sh: What version of bochs are you building? [12:04] 2.3.6-2 ? [12:04] <\sh> persia, -1 [12:05] <\sh> soren, the last one which is in sids Sources.gz [12:05] \sh: ? [12:05] 2.3.6-2 ? [12:05] (!) [12:05] <\sh> nope 2.3.6-2 [12:05] <\sh> aehm [12:05] <\sh> nope 2.3.6-1 [12:05] That's not the last on in sids Sources.gz. [12:05] <\sh> it's sids Sources.gz from this morning actually [12:06] quit living in the past already! :) [12:06] <\sh> getsid.sh --update ;() [12:08] <\sh> * Try to use pkg-config before AC_PATH_XTRA (fixes a FTBFS). Add pkg-config [12:08] <\sh> to Build-Depends. [12:08] <\sh> - debian/patches/patches/20_use_pkg-config.patch: New file. [12:09] <\sh> soren, YAY [12:09] morning [12:10] <\sh> those buggers [12:11] <\sh> moins zul [12:14] <\sh> ifneq ($(DEB_HOST_ARCH_CPU),i386) [12:14] <\sh> $(error "build-indep will only succeed on any-i386") [12:14] <\sh> endif [12:14] <\sh> [12:15] <\sh> WAAA? [12:18] That's not really unexpected. [12:19] <\sh> soren, sure... [12:19] <\sh> soren, I wonder what's the magic in our buildds to build at least the main bochs package [12:20] * persia points at bug #183495 for one way to deal with building bios packages sanely [12:20] Launchpad bug 183495 in openbios-sparc "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [Medium,New] https://launchpad.net/bugs/183495 [12:23] <\sh> persia, I like infinities idea... [12:24] \sh: You might want to also hit openbios then, as the person who was chasing that issue is no longer encouraged to follow up... [12:25] * norsetto --> lunch [12:27] <\sh> persia, it means to introduce more packages [12:28] \sh: Only has to be a binary package: you can leverage the existing source package. As they are mostly dummy packages, not so much pain, no? [12:28] Of course, how one gets an arch-all package to build-dep on a package only built on an architecture different than that of the buildd is a more interesting question... [12:29] <\sh> persia, actually right now I'm trying to understand what it involves to get this hack ready ;) [12:30] <\sh> persia, infinity mentions to use another (new) source package which build-dep on the resulted binary arch dep package [12:30] \sh: Worst case you can do something like ia32-libs, but that's non-ideal. [12:30] \sh: Oh right. I managed to ignore the fact that packages build-depending on themselves was bad :) [12:32] <\sh> persia, na...what adam means is this: Package: -sparcbios Arch: sparc ... build the package on the needed archs...and introduce a new source package which generates an arch:all package . the Arch:all can actually only be generated on the sparc arch because of the build-dep on the arch dep bianry package [12:32] <\sh> now I need some crack [12:32] \sh: That doesn't solve the problem. The arch:all package needs to be able to be generated on an arbitraty arch, or else it still needs handholding. [12:33] I suspect that's the same sort of issue you're encountering with bochsbios, that you're not using the same architecture for building the arch:all package as Soyuz, but that shouldn't break the build. [12:33] <\sh> persia, so how can a i386 buildd include a _sparc.deb [12:33] \sh: Without internet access? That's the hackish bit... [12:34] ia32-libs chose to do this with internet access at packaging time, but I'm not convinced that's really a source package. I don't know the right solution. [12:34] <\sh> persia, I mean more, that the i386 arch needs to overwrite the behaviour apt of pulling in .deb packages for the build arch [12:35] \sh: That's not so hard. The hard part is getting the sparc apt-cache on i386. [12:35] <\sh> persia, that's what I mean...or you switch for this special occasion the -A switch of sbuild on ;) [12:36] You might check in #launchpad to see what "no internet access" really means. There might be a way to access an archive via the network, even if not the normal archive. You could try archive.ubuntu.com, and if that failed, fall back to the internal archive. [12:36] <\sh> persia, and let the sparc buildd create the Arch: all package at all...it means just cp the binary of _sparc.deb build-dep to the Arch: all package [12:36] \sh: That's significantly less trivial within wanna-build, and I suspect even more so within Soyuz. [12:36] Hobbsee: will you write something regarding your MC application? [12:37] pochu: probably, when i get inspired. if getting inspired doesn't become before the end of the voting, then no :P [12:37] * persia suspects Hobbsee of having a secret alien agenda, which is hard to describe in mere human languages [12:38] <\sh> persia, I think I'll talk to adam because he knows a lot about his buildd ... well I could also ask lamont... [12:39] persia: or involving a lot of beeping [12:39] \sh: That works too. I suggest #launchpad, as I believe in teams, and someone else might know too. [12:39] Hobbsee: heh === DrKranz is now known as DktrKranz [12:42] hello! [12:43] <\sh> persia, see #launchpad ;) [12:43] I'v tried to compile glib2.0 2.15.3 for gutsy in using PPA, everything worked fine and I was able to install but now I have this weird situation: [12:43] gabriele@nicholas:/var/cache/apt$ apt-cache policy libglib2.0-0 [12:43] libglib2.0-0: [12:43] Installato: 2.15.3-0ubuntu1~psicus2 [12:43] Candidato: 2.15.3-0ubuntu1~psicus2 [12:43] Tabella versione: [12:43] 2.15.3-0ubuntu1~psicus2 0 [12:43] 500 http://ppa.launchpad.net gutsy/main Packages [12:43] *** 2.15.3-0ubuntu1~psicus2 0 [12:43] 100 /var/lib/dpkg/status [12:43] !pastebin [12:43] pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [12:43] 2.14.1-1ubuntu1 0 [12:43] 500 http://it.archive.ubuntu.com gutsy/main Packages [12:44] and the update manager keeps asking me to update it! [12:44] ops, sorry about that [12:45] http://paste.ubuntu-nl.org/53299/ [12:45] psicus78: Usually indicates an issue with keys or repos. Since you signed it, check to make sure you trust your PPA. If not, ask in #launchpad (we don't really handle either glib or PPAs here) [12:46] ok, thanks [12:46] Hobbsee: if your write-up has a lot of click sounds like the bushmen do then I would vote for you [12:46] persia: Just FYI ... I tested the package with the help of another user and attached the debdiff to bug 185435 [12:46] \sh: Maybe lunchtime? [12:46] Launchpad bug 185435 in nautilus-open-terminal "nautilus-open-terminal no longer works in Hardy" [Low,Confirmed] https://launchpad.net/bugs/185435 [12:46] slytherin: Excellent. [12:47]