=== funkyHat is now known as funkyHat|off [02:22] Who should I talk to about an issue with lists.ubuntu.com? [02:25] nhandler: Probably #canonical-sysadmin, but probably not this time of day. [02:26] ScottK: What time would you suggest trying? [02:26] European work day. [02:28] Thanks for your help ScottK. I'll try and ask tomorrow before I leave the house for the day. [03:09] anyone feel like doing some ISO testing? [03:26] NCommander: wireshark uploaded. Thank you for your contribution to Ubuntu. Please send the Debian maintainer an appropriate note via BTS. [03:27] ScottK-laptop: it FTBFS on Debian? [03:27] NCommander: Dunno. === ScottK2 is now known as ScottK-laptop [05:08] Good morning. [05:15] Anyone noticed any changes in Launchpad since the updated it? [05:15] I'm still waiting for the promised post on what's new. [05:17] ScottK-laptop: there is already a post [05:17] nxvl: Where? The karma for code reviews one? [05:18] and the where is everyone one [05:18] That's it? [05:18] ScottK-laptop: but, are you using edge? [05:18] Not generally [05:18] i mean, as in now that you don't find anything new [05:19] I do sometimes, but the new fonts and stuff have been leaking onto regular pages for a while. [05:19] I use edge if someone gives me an edge url, but that's it. [05:20] Mind you, I consider the roll out a new version and I don't notice anything good news. [05:20] It's pretty unusual for me to like the changes they do make. [05:22] ScottK-laptop: the fonts are smaller now [05:22] that's all I've noticed :) [05:23] and you have a map on your profile (i have it long ago) [05:23] Yes, the one that they thought it would be a good idea if everyone could move you around. [05:23] heh [05:24] yes [05:24] :D [05:24] it's horrible that other people can add your location [05:24] OK, so we're they day before a significant release milestone and they take our major system development tool down to give us the essential new features of: [05:24] 1. New font [05:24] but it's nice to see a map with the info of the people in each team's page [05:24] 2. Karma for functions rarely used in distro development [05:24] 3. A map. [05:25] Glad to see all the important stuff's already fixed. [05:26] ScottK-laptop: So they'll get more sarcastic remarks from you if they implement other new stuff rather than say, signed PPAs? [05:28] Right. Because we all know having maps in people's profiles is WAY more important than basic security. [05:29] Fortunately parody and criticism are generally protected actions. [05:29] * ScottK-laptop just registered launchpadsucks.net [05:29] So now the question is will I do anything with it. [05:30] Incidentally, https://edge.launchpad.net/launchpad-project/+milestone/2.1.9 might give you a better picture of what's changed in this release. [05:33] Well we have been repeatedly promised better notification of what's planned for Launchpad. It continues not to happen. [05:33] jml: What on that list has actually been implemented? That's milestoned, not done. [05:33] ScottK-laptop: everything with fix-committed was released today. [05:34] jml: "Fix Released" as well? [05:34] How are non-Launchpad people supposed to know that? [05:34] ScottK-laptop: maybe some of the others too (and maybe there were unforeseen problems that mean some fix-committed's weren't released) [05:34] So the page is inaccurate and irrelavant [05:34] ScottK-laptop: we'll be updating them to fix released over the next couple of days. [05:34] ScottK-laptop: ok. I was just trying to help. [05:35] persia: sure, those too. [05:35] jml: I understand that and it's not something personal towards you, but MOTU have been complaining for the two years I've been involved in the project that we are always suprised about what changes. [05:35] persia: "Fix Committed" means 'in trunk' and "Fix Released" means on launchpad.net. [05:36] jml: We get promises of advanced notice so we'll know what's coming, but with very few exceptions, it doesn't happen. [05:36] jml: And the current skew related to release is the lack of automatic hooks to transition states with release? [05:36] persia: partly. [05:36] jml: I don't have enough information to file the bug that would fix that. When you have some time, could you file it and subscribe me? [05:36] persia: also, some of us like to make extra extra sure that a thing actually works before we mark it as 'fix released' [05:37] persia: I think I might have sometime in my first week at Canonical :) [05:37] Which bug? [05:37] * jml looks [05:37] maybe I just complained about it :) [05:37] Also some of those that are marked fix committed have been released for quite some time. [05:37] Also, I think it'd be better to set "Fix Released", and then unset it to show that it was a regression in the Activity log, as a better means of communication. [05:38] Bug 252469 was released last week if not the week before. [05:38] Launchpad bug 252469 in soyuz "PPA delete packages should not require a reason" [Wishlist,Fix committed] https://launchpad.net/bugs/252469 === ssweeny_ is now known as ssweeny [05:40] ScottK-laptop: I find that difficult to believe -- maybe it was released on edge? [05:40] persia: there's bug 41702, 163694 and 163696 [05:40] Launchpad bug 41702 in malone "Allow mass changing of bugs' statuses" [High,Confirmed] https://launchpad.net/bugs/41702 [05:40] Launchpad bug 163694 in malone "Fix Committed/Released distinction is inconsistent and unproductive" [Undecided,New] https://launchpad.net/bugs/163694 [05:40] Launchpad bug 163696 in malone "Launchpad doesn't help in listing bugs fixed in a release" [Undecided,New] https://launchpad.net/bugs/163696 [05:40] jml: I don't use edge except if someone gives me an edge url (not relevant for PPA use) [05:41] ScottK-laptop: sure, but we didn't rollout two weeks ago :) [05:41] Well I did a bunch of PPA test uploads over the weekend and that bug was fixed. [05:42] * jml shrugs [05:43] persia: none of those are quite it. (except maybe 163694) [05:43] jml: I think the distinction in 163694 is useful, but not used well for either LP or Ubuntu. 41702 would help with release, but it's more a need for a hook. 163696 is more about the milestone thing. [05:44] OTOH, only a small fraction of the activity in this release appears to have a significant relationship with distro development anyway. [05:44] jml: In Ubuntu, when someone uploads a patch, there is a means to mark it as fixing a bug. When it is accepted and pushed to the public archives, Malone automatically marks the bug Fix Committed. I'd like to see something similar for LP, but tuned to your workflow in some way. [05:45] Note that the patch doesn't always actually fix the bug, in which case the bug is reopened. [05:45] persia: all, well we have got bug 232429 [05:45] Launchpad bug 232429 in launchpad-bazaar "please close bugs automatcially if commit log contains LP: #123456 magic" [Wishlist,Triaged] https://launchpad.net/bugs/232429 [05:45] s/all/ahh/ [05:46] jml: Hrm. That's close, but wouldn't that close them on VCS-commit, rather than on push to either edge or lpnet? [05:47] persia: well, 'fix committed' when landed on trunk is already what we do, so this would automate it. [05:47] persia: but then there needs to be a 'fix released' transition, probably when the revision appears in a series. [05:47] jml: Which piece of Launchpad is responsible for the map and talking to Google about it? i have a bug I want to make sure I get in the right place. [05:48] ScottK-laptop: couldn't say. filing on 'launchpad' is a safe bet: it'll get triaged swiftly. [05:48] jml: Yep, which is a combination of 163696 and 41702. [05:48] OK. That's what I'll do. [05:49] persia: in general, that sort of stuff (although I would love it so much) is not currently a high priority for the code team. [05:50] jml: Bugs are bugs. Once there are bugs, priorities can be discussed. Let's not dissuade bugs because of previously existing priorities. [05:50] right :) [05:50] persia: just giving you a heads up :) [05:52] Looks like they managed to break the map thing when they released it somehow anyway. [05:53] http://launchpadlibrarian.net/17714878/googleapi.png === TheMuso_ is now known as TheMuso [06:06] Hi. Do I need a FFe if a package sync fix a FTBFS in Intrepid? (Bug #258667) [06:06] Launchpad bug 258667 in kwave "[sync Request] Dependency problem in Intrepid: Kwave" [High,Confirmed] https://launchpad.net/bugs/258667 [06:07] you need a FFe for things that break the freeze on features [06:08] which may or may not be the case for a given sync [06:09] fabrice_sp: How does syncing from Debian fix that problem? [06:09] fabrice_sp: Also does the new upstream release have any new features in it? [06:10] If the answer to the 2nd question is yes, then you need an FFe. [06:10] ScottK: Debian changed the dependencies in control file, so the package now builds successfully [06:10] OK. [06:11] So if it's just a bugfix release, then no, but if it has new features, then yes. [06:11] ScottK: OK: I'll have a look to upstream changelog, to check if there are new features [06:47] I don't need to request a FFe for a release that has only one new feature that only affects BSDs, do I? [06:49] I'm not really sure of the answer to that. I'd lean towards 'yes', but not by much. [06:50] It consists of adding '#if(n)def __FreeBSD__', basically. [06:50] I'd say "no", as it doesn't include any user-visible features. [06:50] The binary change for us will be zero. [06:50] In which case, I'd say "no" :) [06:51] Right, thanks. [06:51] persia: Is FeatureFreeze about user visible features, or about minimising bugs (on the basis that new features are likely to be buggier)? [06:51] RAOF: Yes. [06:52] In this case, we're not even going to compile the code path with the new feature, so I don't see it being relevant. [06:52] Right. But in another case, if there was an extensive new feature which only applied to BSD, a FFe may be appropriate? [06:52] I suppose it depends on the definition of "feature". [06:53] To me, it means something the user is able to do with the software that they were previously unable to do, or did in a significantly different way. [06:53] So, anything that doesn't change the behaviour of the application doesn't count as a feature to me. That said, I'm not one of the people responsible for the official definition. [07:03] Hey, all. I've got a question on versioning. The package was synced from debian (0.5.6-1) then rebuilt due to a lib transition (0.5.6-1build1). What would be the correct version for a new ubuntu specific change. 0.5.6-1ubuntu1? dch -i suggests 0.5.6-1build2, but as it's not just another rebuild, that can't be right [07:06] -1ubuntu1 [07:06] ajmitch: thanks === torkel_ is now known as torkel [07:47] good morning! [07:47] Why is it that dpkg-source on ubuntu includes .git and on debian it does not? How can I get the debian command to include the .git directory? [07:48] Laibsch: Does this apply to the same exact .dsc file? [07:50] persia: no .dsc file [07:50] I am trying to create those [07:51] "dpkg-source -b gnucash.git/" [07:51] On debian gnucash.git/.git/ will not be included in the orig.tar.gz that is being created by dpkg-source [07:51] on ubuntu it is included [07:52] Oh. Probably just a missing patch in Ubuntu then. .git isn't supposed to be in there. [07:52] Try using the -i -I options to make it go away. [07:53] <\sh> crimsun: already in I just need to test [07:55] Hello, I'm almost done with the new version for sl-modem, but I dunno if it fixes all the bugs in Debian/Ubuntu or not [07:56] AnAnt: While fixing *all* the bugs is always a goal, fixing many of the bugs is also good. [07:57] persia: well, I dunno if it fixes any of the bugs or not, I only know that it fixes the bug I encountered and the bugs saying please package the new upstream [07:57] but I think that I put it in good shape, it uses quilt now , making patch management easier [07:58] You might try to get some users with the affected hardware to test the result. [07:59] persia: Actually, in my case, it is the other way round. I want .git to be included [07:59] Although I understand that generally it should be excluded [07:59] great idea [07:59] how do I adopt a package in Debian ? [08:00] Laibsch: Why? Generally, if you want to track a VCS, you want to have a packaging VCS listed in debian/control, and if that is linked to an upstream VCS, that belongs in the packaging VCS, not in the orig.tar.gz. [08:00] AnAnt: File an ITO bug against it. [08:00] Err. ITA. [08:01] persia: OK, let's see if that would work [08:01] do you have an example package config? [08:01] persia: I mean, to file an ITA bug, it should be filed against an existing (orphaning) bug or so, isn't it ? [08:02] AnAnt: I'm not sure if you retitle the orphaning bug or if you file a new bug. You probably want to ask in a Debian channel on OFTC. [08:02] ok [08:02] persia: do you know how I can find the orphaning bug ? [08:03] AnAnt: I don't remember exactly. I think it's a wnpp bug, but I'm not sure. [08:24] morning all. === BugMaN1 is now known as BugMaN [09:18] persia: Unfortunately, I don't think that works [09:18] because of peculiarities in gnucash's build system [09:18] Without a .git or .svn directory, the build system goes into "tarball-mode", but tarball mode presumes a couple of files to present which are only created by "make dist". make dist depends on ./configure having run. ./configure is the file doing the switching between tarball mode and svn mode. a vicious circle. [09:18] * persia has long ago lost any refrent for "that" [09:19] Oh. Can't you just patch that away, or have debian/rules call things in the right order? [09:19] I'd rather not reinvent the wheel [09:19] If all I need is just to get dpkg-source include a simple directory [09:20] This is not so much for release stuff as for regular testing of trunk [09:20] I'd rather have that packaged [09:24] Yeah, but it's considered poor practice to have a VCS directory in the orig.tar.gz. [09:24] You could always generate your orig.tar.gz by hand, with tar. No restrictions there. [09:25] Mind you, you'll probably get complaints about it if you ask anyone for review. [09:34] I'm probably not going to put this up for review [09:34] and yes, I could build the tar by hand [09:34] But I want to eliminate manual steps as much as possible [09:34] Then script the manual tar creation :) [09:34] "git svn fetch;pdebuild" is really what I want to do [09:36] persia: Actually, creating the tar won't help [09:36] Well, you could set debian/rules to work around the upstream broken build system, and then it's just `git svn fetch; debuild -S` [09:36] reason? see above under vicious circle [09:37] Yes. This can be fixed. [09:37] how? please help [09:37] Change ./configure to not do that. [09:38] well, eventually, I'll end up rewriting all of gnucash [09:38] Certainly, but start with the bits that are causing you pain :) [09:38] which is not something I'm skilled enough to do although there are tons of things bothering me [09:38] persia: there is lots of things bothering me [09:39] and believe me, dpkg-source refusing to include a dir I absolutely want is causing me pain [09:39] and it would likely be much faster to fix than messing with gnucash [09:39] Personally, if I just wanted to play with an upstream snapshot, I'd pull upstream VCS, and run make dist, and then build the source package. [09:39] persia: I'll want to do this regularly [09:39] Yes, but you're not supposed to want that directory :p [09:39] Otherwise, I'd just not package stuff at all [09:39] which is also an option [09:39] Sure. ~/bin/update-gnucash: [09:39] #! /bin/sh [09:40] git svn fetch [09:40] make dist [09:40] debuild -S [09:40] nice thought [09:40] ^D [09:40] your are missing something [09:40] that requires all build time deps [09:40] and I don't necessarily want that or can ensure that [09:40] Then patch the build system to be sane. [09:40] on boxes I use for compiling but where I don't have root [09:41] (and apt-get build-dep gnucash ought ensure that) [09:41] if you are root [09:41] Sure, but how can you compile something if you aren't root? For that matter, how can you run pbuilder if you aren't root? [09:41] sudo [09:42] If you just need a chroot in which you have root, and you have access to pbuilder, use pbuilder --login or something. [09:42] Then in the chroot, you can run apt-get build-dep gnucash. [09:42] And do anything else you like. At the end, you have a source package. [09:42] You can even script the whole thing. [09:42] I still think it would be alot easier to get the dir included even if that is not good practice [09:42] and as far as broken is concerned [09:43] I guess ti is [09:43] but I cannot judge [09:43] and I don't think I can fix it [09:43] Perhaps. dpkg-source -b is *not* a recommended way to build source packages anyway. While it sometimes works, it's prone to cause issues with unclean source. [09:43] the reason is to include only the minimal necessary information in the repo and autogenerate stuff [09:44] but quite likely their stuff is just plain weird and broken [09:44] they have too much of an ego and blurred vision to accept it oftentimes [09:44] unfortunately, I am without an alternative mostly [09:45] I have been trying to get this into usable shape for over a year now [09:45] Right. On the other hand, you now have root access to intrepid chroots on your build boxes, so you can work around them. [09:45] which is also the reason I want frequent builds from trunk [09:47] working inside pbuilder chroots is going to be major pain, too, I think [09:47] I don't mean to sound like a dork [09:47] But consider the following scenario [09:47] no root access whatsoever, not even via sudo pbuilder [09:48] * persia works almost exclusively within chroots, so may not be inclined to agree [09:48] but a launchpad account [09:48] if the build system where sane (or dpkg-source could be made to work the way I want it) the following would be possible [09:49] "git svn fetch;debuild -S" [09:49] upload the result to the launchpad autobuilders and be happy [09:49] with the stuff you are suggesting this will not work [09:49] which is why I don't consider it the proper thing [09:50] I guess. You could always abuse a PPA. Create a fake source package that generates the source package you want. [09:50] Essentially, you'd create a source package that contained the tarball from svn export. [09:50] The debian/rules would unpack this source, debuild -S, grab the results, and install it in /usr/src. [09:51] The resulting binary package would contain the source package you wanted, and you could upload that to your PPA. [09:51] Just remember that your helper package needs to build-depend on everything required to build your source package. [09:52] You also add a stanza to your helper package that automates the pull from svn, and creation of the upstream tarball to be put in a source package. [09:52] uff [09:52] sounds complicated [09:52] but possibly a solution [09:52] although I have not yet fully understood it [09:52] * RAOF is coming in late here. [09:52] You want to build git snapshot packages, yes? [09:53] welcome ROAF [09:53] RAOF: sort of, but the situation is a bit complicated [09:53] * RAOF presses his one-button "update the nouveau ppa" script. [09:53] ROAF: I regularly want to package gnucash for personal use [09:53] * persia defers to RAOF, who tends to have better workarounds for this sort of thing [09:54] thanks, persia [09:54] ROAF: Without a .git or .svn directory, the build system goes into "tarball-mode", but tarball mode presumes a couple of files to present which are only created by "make dist". make dist depends on ./configure having run. ./configure is the file doing the switching between tarball mode and svn mode. a vicious circle. [09:54] that is essentially the problem [09:54] Urgh. [09:55] various solutions have been proposed, but they either plain don't work or don't do what I need [09:55] RAOF: exactly [09:55] So, you can just keep the .git directory around. Alternatively, you can work out what it looks for in the git directory, and fake it. [09:55] RAOF: I'd like to keep the git directory [09:55] And possibly complain bitterly to upstream :) [09:56] They're deaf when it comes to complains [09:56] t [09:56] They've heard it for years [09:56] Then keep the git directory. It'll trigger at least one lintian warning, but your objective isn't an archive-ready package. [09:56] They believe it's right [09:56] ROAF: exactly [09:56] The problem is that I have two build machines [09:57] One is VERY slow and running ubuntu ;-) [09:57] dpkg-source apparently keeps the .git directory on that machine [09:57] I have another build machine, very fast and running debian [09:58] dpkg-source will not keep the .git directory, no matter what I do [09:59] on debian [09:59] Laibsch: It's not safe to depend on the Ubuntu behaviour. That will be patched away soon enough. [09:59] yes [10:00] So, that appears to be the behaviour of "dpkg-source -i" - is that being passed? [10:00] which is why I'd be happy if ROAF knew about a way to force inclusion of the .git dir [10:00] RAOF: I tried with and without -i switch, no change [10:00] dpkg-source -iblahdeblah -b gnucash.git [10:01] .git not included [10:01] What version source package is it? 1.0? 3.0? [10:02] there is some mention of 1.0, I believe [10:02] How do I check or change? [10:02] dpkg-source: info: using source format `1.0' [10:03] Right. So... dunno. [10:03] dpkg-source on ubuntu says nothing [10:04] You could always hack around it by moving .git to reallygit and then moving it back at the start of the build. [10:29] hi.. i'm filing a Needs Packaging bug.. how do i answer "in what package did you find this bug?" === Hobbsee` is now known as Hobbsee [10:31] pythonic: Leave it blank. [10:32] k. and just the package description in the "further information" field? [10:33] And license and upstream link, and what not. There's a good example on the wiki. [10:37] \sh: is 271392 fixed for f-nonfree now too? [10:37] <\sh> bug 271392 [10:37] Launchpad bug 271392 in ia32-libs "Unable to install flashplugin-nonfree -- libxcb-render-util.so.0 not found" [High,Fix released] https://launchpad.net/bugs/271392 [10:37] <\sh> Hobbsee: yes... [10:37] <\sh> bah...I missed that [10:37] \sh: cool :) [10:38] <\sh> bah the flashplugin...that wasn't the problem...and now I have to close them manually [10:39] \sh: only some of them are that issue [10:39] * Hobbsee marks one invalid, due to using a non-ubuntu package. [10:40] <\sh> Hobbsee: na... [10:40] <\sh> Hobbsee: if it's the new flashplayer-plugin with the list of libs...just mark them fix released...new flashplayer10 will come in time [10:40] \sh: there's a debconf thing for others. [10:41] * Hobbsee dupes a few. [10:42] Hobbsee, see -devel plzkthx [10:43] ^ was just about to poke Hobbsee about that ^ [10:43] elky: the lawyer questions? [10:43] oh [10:43] no, the idiot [10:43] helps when i scroll down [10:43] yep [10:46] \sh: out of general curiosity, why didn't you use libxcb-render-util0? it contains the library it's whining about. [10:46] <\sh> Hobbsee: I used it [10:46] <\sh> Hobbsee: it's in ubuntu13 now [10:47] \sh: ah right. For some reason, I only checked what I currently had installed. [10:47] * Hobbsee is still trying to delve through this list of bugs, which really should be on the iso tracker. [10:48] <\sh> Hobbsee: ubuntu13 just reached the buildds imho..and should be available soon on the mirrors [10:48] \sh: great :) [10:48] <\sh> it's really a beast [10:50] <\sh> Hobbsee: bug #270358 is a nice one [10:50] Launchpad bug 270358 in ia32-libs "ia32-libs will not install when libcap1 is installed" [Undecided,Invalid] https://launchpad.net/bugs/270358 [10:57] OK, I was actually successful in making the gnucash build system believe it was being compiled from svn [10:57] now I hit the next bug [10:57] http://rafb.net/p/gs728n29.html [10:58] How come pbuilder gets a permission denied for "mkdir -p /usr/share/gnucash"? It should be running inside its chroot with full root privs? [11:01] line 26f [11:02] Laibsch: it shouldn't [11:02] I wonder why gnucash would want to create that directory during configure-stamp [11:02] <\sh> shouldn't be the right dir : $DESTDIR/usr/share/gnucash when building through debian/rules? [11:02] well, the build system of gnucash is strange [11:03] \sh: I thought of that [11:03] <\sh> Laibsch: can you pastebin the debian/rules? [11:03] sure [11:04] it is a variation of the official debian debian/rules [11:04] \sh: http://rafb.net/p/dTngIM26.html [11:06] mkdir -p /usr/share/gnucash [11:06] <\sh> Laibsch: try: mkdir -p `pwd`/debian/temp/usr/share/gnucash :) in line 29 of your paste [11:06] that is wrong [11:06] <\sh> Laibsch: try: mkdir -p `pwd`/debian/tmp/usr/share/gnucash :) in line 29 of your paste [11:06] Laibsch: why did you need to add it at that point anyway? [11:06] <\sh> that's better [11:10] \sh: that's been reopened, too :-\ [11:11] <\sh> Hobbsee: you mean this lib32cap1 thingy? [11:11] \sh: yeah [11:11] actually, that was a left-over from previous troubleshooting :-) [11:11] <\sh> Hobbsee: I set it to invalid yesterday...and I wrote also now something to him, for explanation... [11:12] hi emgent [11:12] i will send you the email ;) === mcasadevall is now known as NCommander [12:44] What the [12:44] Someone is marking needs-packaging bugs as affecting feisty/gutsy-backports [12:44] Laney: ....interesting. [12:47] What's wrong with that? [12:52] While I don't see any issue with having a needs-packaging bug affect backports, I'd think the best path forward was to get the packaging done before trying to test a backport. [12:56] There's nothing to backport - he reported the n-p bugs yesterday and made them affect backports too [12:56] It's spammed me with a lot of bugmail [12:58] Yeah, if there's nothing to backport, it's probably premature. [12:59] http://img168.imageshack.us/img168/6177/bmhp9.png [13:07] Hello, I have recently created an application, its in GTK and its a budgeting program. I was thinking of trying to get it into jaunty as i knew intrepid was frozen. I was told to ask here. [13:11] <\sh> motu-release: please take a peak on ubuntu-devel...pls...and say what you think about a UVE for flashplugin-nonfree :) [13:12] \sh: erk. [13:12] <\sh> Hobbsee: erk=no, erk=I don't care, erk=yes? ,) [13:13] \sh: how much does it fix, vs how much does it break? [13:14] <\sh> Hobbsee: with ia32-libs in place...it works...the new version is rc2 ... so we need to get the final through -updates after intrepid release [13:14] <\sh> Hobbsee: but for now...we should push rc2 to intrepid... [13:15] \sh: i think that would be reasonable + would agree in principle to the final in -updates - although I have little (read: no) control there. [13:21] <\sh> hobbsee: I'll do some UVE magic on LP ;) should -release decide :) [13:48] is there any script to know if any/what dependencies of a package are in multiverse? [13:50] My god, a whole page of emails from that guy === nxvl_ is now known as nxvl [14:01] pochu: You may find the debcheck output useful for some packages, although not all. [14:01] pochu: The other trick is to set up an apt-cache without multiverse, and try to install the package. [14:01] hi, I converted bug #257403 into a FFe request, can someone let me know if I need to provide additional information in the report? [14:01] Launchpad bug 257403 in flashplugin-nonfree "[Intrepid] FFe request for Flash 10 RC2 (10.0.12.10)" [Wishlist,Confirmed] https://launchpad.net/bugs/257403 [14:04] persia: I've done an 'apt-cache madison `list of packages` | grep -v main | grep -v universe. Thanks for your suggestion anyway [14:04] pochu: That works too :) [14:06] pochu: That won't get build-deps. [14:13] ScottK-laptop: It depends on how `list of packages` is generated. [14:13] True. === cody-somerville_ is now known as cody-somerville === ember_ is now known as ember [15:12] ScottK-laptop: unless `list of packages` contains both depends and build-depends ;) [15:13] Right. [15:26] pochu: re. bug 268914: if the whole purpose is to move this (and other stuff) to universe just patch it so, no need to update it [15:26] Launchpad bug 268914 in javassist "[FFE] Please sync javassist 1:3.8.1-1 (multiverse) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/268914 === x-spec-t is now known as Spec [15:31] In what variable is the topdir of the source code to be ompiled stored in pbuilder? [15:32] I need to "cd $topdir;$do_something;cd -" [15:32] looking for the right string for $topdir === Ng_ is now known as Ng [15:34] Laibsch: $(CURDIR) [15:35] (not sure if that's what you mean) [15:35] s/mean/ask for [15:38] thanks [15:40] RainCT: Is $CURDIR exported to called processes such as a batch script? === superm1|away is now known as superm === superm is now known as superm1 [15:47] pochu: Also, we're trying not to have any more Java MoveToMain bugs for intrepid. There's still 10 in the pipeline, and the release team is likely to start having more critical things to chase. [15:54] persia: pochu: norsetto: I will patch the ubuntu version itself. I haven't got enough time in last few days. Should find some time on weekend. [15:55] slytherin: Sorry. Didn't know it was one of the listed bugs (I should check the list next time) [15:56] no issues. [15:57] slytherin: thx [15:58] btw I have no interest in them, I just ACK'd a sync request which changelog entry said it was moved to main in Debian, so I checked if it could be moved in Ubuntu too but it was blocked by 268914, so I left a comment there for completeness [15:59] s/which/whose/ ? [16:01] Laibsch: $(CURDIR) is available in debian/rules, if you call scripts from there then no, unless you pass it to them or include them into the current environment (by prepeding a ". " to the call) [16:06] persia: I've read the Java multiverse -> universe bugs and support them, but have very limited time before I leave on vacation tomorrow. Feel free to copy/paste this into each of them as my motu-release ack for those bugs. [16:06] ScottK: I'll review which of the MoveToMain bugs were also FFe bugs, and paste. Thanks! [16:07] ScottK: Also, as I'll likely be asleep when you go: have a good vacation. [16:08] Thanks. [16:09] where is the correct place to request the motu team look into making a deb of some code ? [16:10] i see there's debs for ebox and 3-4 of its modules, but the ebox cvs has code for several others. one in particular, the soap module, would be handy in the ubuntu repos [16:11] Lamba: For Ebox, #ubuntu-server is probably the best place to discuss it. [16:11] rgr. === ScottK3 is now known as ScottK [17:54] Hmm, why don't you guys delete the revu-uploaders team from launchpad if it's not useful anymore? [17:55] Well, it could conceivably become useful again. Let's wait until LP OpenID is working cleanly for everything before we drop it. [17:58] Yea... that's an idea. [17:58] maybe some of you remember my previous trouble with "mkdir -p /usr/share/gnucash/doc" in pbuilder? I am trying to build gnucash from svn in pbuilder which is a bitch because of some of gnucash's peculiarities in the build system. [17:58] I got a couple of steps further, but now I am back at the point I was trying to troubleshoot before wrt mkdir [17:59] http://rafb.net/p/jsPLbs44.html is the diff for my rules file to the one from the debian maintainer [18:00] http://oss.leggewie.org/wip/pbuilder.log is the output from pbuilder [18:01] And there it is again [18:01] test -z "/usr/share/gnucash/doc" || /bin/mkdir -p "/usr/share/gnucash/doc" /bin/mkdir: cannot create directory `/usr/share/gnucash': Permission denied [18:01] How can that happen? Isn't pbuilder running as root? [18:03] why isn't the released package running into that problem (I tried that one with pbuilder and it completed fine as expected)? [18:04] I grepped through the svn source but found no reference to install-exec-am [18:04] Laibsch: I told you, it isn't running as root [18:04] Oh, it isn't? [18:04] eh [18:04] 19:02 < azeem> Laibsch: I told you, it isn't running as root [18:04] OK, sorry I missed that [18:04] you're not allowed to create any files outside the directory where your source is [18:05] isn't $DESTDIR set? [18:05] I'm not sure [18:05] I'd like to inspect the unpacked and configured source [18:06] for the install rule, it should run "make install DESTDIR=" [18:06] suspend the pbuilder process so you got time to investigate, maybe === asac_ is now known as asac [18:23] http://rafb.net/p/6Ccsjn41.html is the Makefile. line 501 looks OK to me. [18:23] So I wonder if DESTDIR is correctly set [18:23] you have to set it [18:23] Where? [18:23] Laibsch: in debian/rules [18:24] Laibsch: did you read the packaging guide? [18:24]