[00:00] tumbleweed: the previous autotools based approach catered for that, too [00:00] is there any way to pass to backportpackage when it tries to extract the source package of to ignore the gpg key checks during extraction? [00:00] tumbleweed: oops, another copy&paste incident [00:00] because i'm doing backportpackage -s precise -d oneiric -w php5, and it won't extract the source [00:02] Ah, apparently the publisher's about to come back on [00:02] EvilResistance: it should be ignoring the gpg signature [00:02] ah yeah, there it is [00:02] * EvilResistance misread the error [00:02] cjwatson: eta? [00:02] (assumign they told you) [00:02] tumbleweed: ok, fixed the import * part. is there any way I can take care of /etc in setup.py? [00:03] EvilResistance: the publisher runs at *:03 [00:03] ockham_: I wouldn't try to. setup.py is normally for installing a python module, its data, and possibly, at a push some manpages. [00:03] EvilResistance: it currently takes around half an hour [00:04] tumbleweed: docs are ok, too? [00:04] although I expect it will have a bit more to do this time round [00:04] cjwatson: i'd assume so there were TONS of builds afaict :P [00:04] ockham_: if it's trying to put them in /usr/share/doc/$packagename, that's probably too debian-specific for setup.py [00:04] Not radically more so than usual, I'd expect :-) [00:05] cjwatson: the backlog of it, though... :P [00:05] Oh, BTW, this is the distro publisher, I don't know about the PPA publisher [00:05] yeah the PPA publisher is my focus [00:05] EvilResistance: have you seen the armhf backlockg? [00:05] tumbleweed: uhm, what then? [00:05] May well be coming back soon as well but it's on a different schedule. [00:05] They were both disabled at the same time. [00:06] I think the PPA publisher runs every five minutes rather than every hour. [00:06] ockham_: what then? bed time for me. [00:06] now on an entirely unrelated question, a company i work with wants to set up an apt repository for ubuntu, but doesnt want it to be an apt mirror. i said i'd research getting it done, but not actually do it. any of you know how i'd attack that problem? [00:06] or should I just go post on the ubuntuforums or whatnot [00:06] tumbleweed: ok. [00:06] They should specify what they mean: a repository of add-ons to Ubuntu, or a private mirror of Ubuntu itself that isn't exposed to the world [00:07] well the way i understood their request is they dont want a mirror of Ubuntu at all [00:07] they want a repo that acts similar to what a PPA does: hold *additional* packages [00:07] stuff not already in the ubuntu main repos. [00:09] OK. There's a variety of packages for managing that kind of thing. Names that come to mind are reprepro and mini-dinstall. [00:09] reprepro seems the most popular at the moment, from what I've gathered. [00:10] for the sake of the actual server admins at this company, got any links to documentation/instructions for setting up and configuring? [00:10] (Or it's possible to roll your own around apt-ftparchive, or try to set up something industrial-scale like dak or Launchpad - but I wouldn't advise either of those two) [00:10] I do not, sorry. [00:10] not a problem [00:11] i assume google will turn up something :P [00:11] reprepro seems to come with documentation in the package. [00:13] after a quick google i'm glad i'm just researching it, not the one actually *doing* the setup and config xD [00:13] although it would be JUST MY LUCK if I get told to set it up >.> [00:15] Oh, I just found mini-buildd-rep as well, which is another option. [00:15] They may also need to attach build servers to it. sbuild/buildd is probably a sane choice, but there's mini-buildd-bld too. (I have no idea of the latter's quality.) [00:16] isnt sbuild/buildd what lp builders use? [00:16] or something... [00:16] LP builders use sbuild [00:16] (Albeit currently a rather old fork) [00:16] buildd is more or less what Debian builders run; Launchpad has its own build farm [00:18] sbuild builds a single source package; since you're familiar with pbuilder already, pbuilder is more or less analogous to sbuild [00:20] pbuilder and sbuild are only slightly different, no? the end result is a built package. [00:27] EvilResistance: Right. [00:28] pbuilder is slower for doing lots of builds, though, as it wants to unpack a tarball every time. sbuild is more flexible. [00:29] could a private apt repository with addons be configured to use pbuilder over sbuild if they arent producing tons of packages/addons? [00:30] (see, if i explore every angle, then the company won't feel the need to say "Go Do More Research!" :P) [00:31] I wouldn't see why you'd want to bother; but it's no doubt possible. Whether any of them actually have a config knob for that I wouldn't know. [00:32] I just upload to Debian or Ubuntu where somebody else manages this for me ;-) [00:32] :P [00:32] yeah, but you're a MOTU, you have that right xD [00:32] standard users dont get that [00:32] and corporations/companies that want private repositories dont either :P [00:32] sure, I wasn't being serious [00:32] I'm told that publishers and builds are all back up [00:32] :P [00:33] *all* publishers? [00:33] so I'm told [00:33] yeah wgrant just changed the topic in #launchpad [00:33] :P [00:33] cjwatson: in that case, I'll go poke about why the buildds aren't picking up builds :) [00:33] There's still some build database trouble. [00:34] ah, just saw comments in another channel [00:34] Let wgrant work on it :-) [00:34] I think they'll resolve themselves in 15-20 minutes. [00:34] micahg: They're all security builds, I guess? [00:34] In a private PPA? [00:34] wgrant: oh, that could be [00:34] wgrant: I have no idea, didn't look, just saw the backlog on +builders [00:34] Ah. [00:35] Private builds don't start until they're published, and there's a massive publisher backlog. [00:35] heh [00:35] so if i were to upload to a PPA a package, then its likely it wouldnt get published until sometime next year? [00:35] (figuratively speaking) [00:36] Hopefully it'll all clear up in about 20 minutes. [00:36] * EvilResistance points at the word "hopefully" [00:36] ;P [00:36] The build queues might take another 6-7 hours. === EvilJackyAlcine is now known as JackyAlcine [00:39] ah, I'm not in a rush for anything, was just curious === keffie_jayx is now known as effie_jayx [00:43] wgrant: heh, i'm not in a rush either :P [00:47] alpha or actual release? ;o on precise === JackyAlcine is now known as how === how is now known as when === when is now known as because === because is now known as JackyAlcine === almaisan-away is now known as al-maisan [07:54] good morning === Guest30213 is now known as Zic === Zic is now known as Guest96253 === Guest96253 is now known as Zic [10:46] morning [10:48] hey guys.. can we take a look at bug 896695 ? [10:48] Launchpad bug 792146 in clang (Ubuntu) "duplicate for #896695 clang can’t link any programs: cannot find crt1.o, crti.o, crtn.o" [Medium,Confirmed] https://launchpad.net/bugs/792146 [10:49] it's solved, but set as duplicated of a discussion that doesn't see the end in the immediate future [10:51] this is the url of bug → https://bugs.launchpad.net/ubuntu/+source/clang/+bug/896695 [10:51] Launchpad bug 792146 in clang (Ubuntu) "duplicate for #896695 clang can’t link any programs: cannot find crt1.o, crti.o, crtn.o" [Medium,Confirmed] [11:10] Hi, will there be a REVU-day in this month, or is there some rough schedule about when the next REVU day will be? === al-maisan is now known as almaisan-away [11:19] handschuh: probably never, REVU is on the way to get deprecated [11:21] geser: ok so whats the new way of getting packages into ubuntu? (or is it not decided yet?) [11:28] handschuh: the currently preferred way is to go through Debian and sync it to Ubuntu [11:29] * ogra_ never saw revu as a tool to get packages into ubuntu ... its simply a easy tool to review packages, nothing more [11:29] geser: thank you for the information [11:29] it's still possible to get a package directly into Ubuntu if you find someone willing to do the review (e.g. from a team which is interested to get this package into Ubuntu) [11:31] so, https://wiki.ubuntu.com/MOTU/Contributing#Preparing_New_Packages should be changed then [11:33] wendar: are you working on adding the deprecation notice to revu? [11:33] p.s. hi! [12:53] can someone help me? I'm getting the following error on a python package using dh_python: [12:53] /usr/bin/fakeroot debian/rules clean [12:53] dh clean --with python2 [12:53] dh: unable to load addon python2: Can't locate Debian/Debhelper/Sequence/python2.pm in @INC [12:53] targetting lucid [12:57] mhall119: I may be wrong but I think it requires debhelper 8 [12:58] it doesn't; but dh_python2 isn't in lucid yet [12:58] no, it needs python 2.6.something from debian or whenever you introduced it [12:59] for now I'm afraid you have to fall back to python-{central,support} for lucid [12:59] even though those are now deprecated [13:00] oh, ok [13:02] when I tried python-central and cdbs, it was putting my code in /usr/lib/python2.7/site-packages [13:03] instead of /usr/share/pyshared/ [13:03] and while dist-packages is on my path, site-packages is not [13:03] it should do links on install though [13:10] Ive always used apt-pinning for "version blendings" and now this appear to do not work very well or concise. Ive tryed to ask in #ubuntu about this but the awnser i got is "precise isnt suported", but im blending versions for backporting development. Anyways, where i can find a information about how apt-pinning works for ubuntu? [13:11] since even pinning using apt.conf/preferences.conf dont appear in apt policies and install packages using apt-get install xpto/precise marks for update from precise, but mantain higher priority for oineric [13:11] (If a paste helps with my question: http://pastebin.com/ks0jz4L2) [13:12] mhall119: python setup.py install --install-layout=deb [13:12] although dh_auto_install should do that for you [13:12] (dunno about cdbs, I avoid it) === jibel_ is now known as jibel [14:56] Laney: it's on my list for this week, yeah. But no worries if someone beats me to it. :) [15:58] is there any way to use the bash exclusion operator in debian/rules? [15:59] as in [15:59] cp source/!(not_this_file) target [16:01] i'm using the above in a loop, and get [16:02] /bin/sh: 3: Syntax error: "(" unexpected (expecting "done") [16:02] same stuff works when directly entered into a terminal [16:04] no [16:04] dont asume bash functionality [16:07] aww, to bad [16:07] sh != bash [16:08] and you want your package to build on machines w/o bash [16:08] is there any textbook example of excluding files in shell commands in debian/rules then? === Quintasan_ is now known as Quintasan [16:14] tumbleweed: i'm finding your reverse-depends script/service to be incredibly useful, by the way [16:14] broder: glad to hear that :) [16:33] Has anyone had difficulty with cowbuilder-dist installing the wrong apt lines into the image? It always installs the host's distros lines [16:34] Kiall: hrm, that's the exact opposite of pbuilder-dist, which was always using archive.ubuntu.com [16:34] Well, it uses archive.ubuntu.com .. but always "oneiric" and never lucid or precise :) [16:34] that sounds problematic :P [16:35] Yea .. I've been scratching my head (on and off!) for a day or two ;) [16:35] * tumbleweed has never used cowbuilder, but I'd appreciate a bug report (and even better, a patch) [16:36] cowbuilder is basically pbuilder, but with cow rather than tgz images [16:36] right, but people are reporting bugs on it that we don't see with pbuilder [16:36] (cowbuilder basically just wraps pbuilder) [16:36] and cowbuilder-dist wraps cowbuilder :P [16:37] Yea ;) [16:37] in fact, investigation on any of these bugs would be welcome https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools?field.searchtext=cowbuilder-dist [16:42] tumbleweed: well, I've spotted why it always uses http://archive.ubuntu.com/ubuntu/ … Its hardcoded ;) [16:43] Kiall: we fixed that recently [16:43] ah, I guess that hasnt landed in oneiric yet so... [16:43] no, it won't [16:43] grab a daily build / the bzr branch if you want to fix bugs in it [16:44] Normally I'm up for that, but right now I need to get the CI server building packages right ;) [16:45] * tumbleweed suggests sbuild for production use [16:45] may I ask why? (Other than personal preferences :P) [16:46] partly that, it's also what the buildds use [16:46] The LP builders? [16:46] it does a great job of building packages, out of the box [16:47] the LP builders run an ancient fork of sbuild, but that's hopefully going to be resolved soon [16:48] I'll have a look, any suggested docs/wiki pages etc? Looking at the debian wiki page for it now... [16:49] mk-sbuild makes it easy to set up [16:50] Thanks, Will have a look [16:50] here's something a little more manual: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment [16:51] like cowbuilder, it doesn't use a tarball for each chroot [16:51] but it uses schroot, which is really handy for other things [17:18] tumbleweed: I think I'm onto something with the cowbuilder-dist issue [17:19] the command ran by (p|cow)builder-dist is something along these lines: [17:19] "... ARCH=amd64 DIST=precise cowbuilder ... --distribution precise .." [17:19] --distribution makes it work with pbuilder [17:20] but cowbuilder wants "DISTRIBUTION=.." rather than "DIST=" [17:20] right, DISTRIBUTION is the variable pbuilder is actually going to use [17:21] DIST is what many people use to drive their .pbuilderrcs (but that's normally people not using pbuilder-dist) [17:21] e.g. https://wiki.ubuntu.com/PbuilderHowto [17:21] yea - but pbuilder/cowbuilder-dist use DIST, rather than DISTRIBUTION [17:21] and hence it gets ignored by cowbuilder [17:21] Kiall: what I'm saying is that that's partially intentional [17:22] but it works with pbuilder since pbuilder also understands the --distribution precise [17:22] Sure, I get that.. [17:22] right, I'm sure there's no harm in setting DISTRIBUTION, but we may need to set DIST too, for people with existing pbuilderrcs [17:23] But - Currently, cowbuilder-dist does not provide the dist to cowbuilder using any method it understands, hence it is defaulting the the host's dist [17:23] yup, that I can understand [17:27] Humm - maybe I'm wrong, adding that aint helping [18:38] so MOM says auto merge of a package failed... the instructions say you fix the merges, build the source package, then upload it ( with dput? )... how does bzr fit into this picture? Are the MOM instructions just outdated and you should now do this with bzr? [18:39] most of the time, it's a lot easier to do a merge with MOM output than bzr [18:40] applied quilt patches make merging with bzr branches less fun than it should be [18:41] indeed [18:41] so if I do it the mom way, how won't that leave the lp bzr branch out of date? [18:42] the bzr branch will be updated by the importer, just like it would be for any other upload [18:53] hrm... I thought the importer updated the debian branch, but the ubuntu one you just push to and the archive auto imports from that? [18:54] it does both [18:54] if there's a commit on the Ubuntu branch with a tag matching the upload it wants to import then it leaves it alone [18:55] if there's a commit after the last tag on the Ubuntu branch then it imports the new upload but moves the commit aside to a new branch and files a merge proposal for it [18:55] otherwise it imports the new upload [18:56] cool.. so if I use grab-merge and fix it up... I can't dput it, so... what do I do then? [18:58] attach a debdiff to a bug; current Debian -> your merge is probably the best one although some people also attach current Ubuntu -> your merge [19:00] i like to look at current ubuntu -> merge | filterdiff -i '*/debian/*', but i consider that sufficiently advanced technique that i don't expect it from sponsorees [19:00] You can construct either one from the other anyway, so :) [19:01] (well, from the other plus archives) [19:20] hey everyone. my config script is being executed twice during an apt-get install [19:20] any ideas why? [19:21] what the heck is with the php source package in precise being dependent on a precise-only version of mysql-client :/ [19:21] pcpratts: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html [19:21] tumbleweed: again, you saved the day! thanks! [19:22] thanksssssssssssssss! [19:22] there's a graphical version somewhere... [19:22] there http://wiki.debian.org/MaintainerScripts [19:23] ooo. even easier! [19:25] hrm... actually, just doing the bzr merge works like a charm [19:25] psusi: please use bzr merge-package not merge [19:26] otherwise it can miss out metadata that'll confuse the importer (and other users) later [19:26] what's that do? [19:26] otherwise it works the same way? [19:26] yes [19:26] hrm... ok [19:27] thank god for packages that don't already have the quilt patches applied in bzr ;) [19:32] I love open source === JackyAlcine is now known as webjadmin === webjadmin is now known as JackyAlcine [19:49] my config script to prompt the user with debconf is called twice: once when the screen says: Preconfiguring packages and again when the screen says Setting up package [19:50] yes, that's intended [19:50] your config script must be idempotent - that is, if called twice it must behave as if it were called once, and it must not re-ask questions (which generally means you shouldn't force questions to the unseen state) [19:50] cjwatson: I am prompting the user twice. my config says: [19:50] case "$1" in [19:50] configure) [19:50] oh okay [19:51] yeah, I see now [19:51] where should I reset the dbconf variables? [19:51] anywhere? [19:51] debconf* [19:51] the reason it is this way is to allow preconfiguration without actually requiring it [19:51] as a general rule, you shouldn't [19:52] okay [19:52] thanks [19:52] why do you want to? there are sometimes exceptions, but you must be careful [19:54] eh, when I was debugging I wanted to make sure I could type it in everytime I did dpkg -i [19:54] but it probably doesn't matter now [19:54] use debconf-communicate [19:54] echo RESET your/question/name | sudo debconf-communicate your-package-name [19:55] (NOT in your maintainer script, but from a terminal while debugging) [19:55] so yeah, it sounds like you should just omit the reset in your config script and then you'll be good [19:55] :) thanks. yep, just read not in your maintainer script [19:55] yeah I think so [20:18] how often is harvest supposed to update? [20:29] much more frequently than it is [20:29] (which appears to currently be never) [20:29] i keep meaning to bug dholbach to get him to bug canonical IS about it [20:31] yea, I just found an entry that should have been removed back in july... === l3on__ is now known as l3on [20:46] how do you get bzr bd to pass options like -us -uc to builddeb? [20:46] -- -us -uc [20:46] bzr bd -- -us -uc [20:46] ahh [20:52] wait a second... why does bzr bd leave me with a .tar.bz2 instead of a .diff.bz2? [20:55] the ubuntu/debian changes relative to the orig tarball should be in a diff shouldn't they? [20:55] debian.tar.bz2? [20:55] yea [20:55] thats how the diff is called with 3.0 pacakges [20:55] ugh [20:55] damn... seems to break debdiff [20:56] in what way? [20:56] it claims there are no differences [20:57] ohh, wait, works when I give it the .dsc files instead of the .changes ;) [21:07] Who would I talk to about an outdated package? [21:08] depends on the package [21:09] jtaylor, kismet. Its like 4 years old in the repos and the dev's are hoping this can be fixed [21:12] hm looks like it needs a new maintainer in debian [21:12] exactly. Is there anything that we can do here? [21:13] also the kismet dev makes a deb for you to add to the repos but its not debian rules friendly [21:15] http://www.kismetwireless.net/download.shtml [21:19] interested in taking of the package maintenance yourself? [21:19] I can, I am really crappy at packaging however. but I am trying to learn all that. I downloaded and am going to be reading the ubuntu packaging guide soon [21:20] over christmas break I can learn packaging [21:22] well I already know how to package. I just need to make myself more comfortable with advanced packages [21:23] thats good, best you get involved in debian and try to find a sponsor there, ubuntu will automatically get the new package [21:23] philipballew: I queried the maintainers status in the MIA database. The MIA team is aware that he's inactive [21:23] I think it's fairly NMUable [21:24] jtaylor, whats the best way to do that? [21:25] tumbleweed, Thank you. i think I will try to see if I can get this in by lts [21:25] #debian-mentors and mentors mailing list are good places for information if you have any technical issues just ask there or in #ubuntu-packaging [21:26] if you can get the package in a team it usually makes sponsoring easier [21:26] I took out db_fset variable seen false in most places from my config. now installation works on the first time. after a remove and install again, things fail with exit status 30. the way I can revert back to it working again is to do: dpkg --purge --force-remove-reinstreq [21:27] how do i figure out what source package provides certain binaries? [21:27] a search on LP? [21:27] jtaylor, thats in irc.debian.net right? [21:27] jtaylor: right, but hijacking a package into a team is probably going a little far for an NMU :P (and I can't think of any relevant teams) [21:27] EvilResistance: apt-cache show package | grep Source [21:27] EvilResistance: packages.ubuntu.com ? [21:27] EvilResistance: apt-cache show will report the source package name [21:28] lifeless: thanks [21:28] tumbleweed: no upload in 3 years known mia isn't that enough for an hijack? [21:28] regarding my previous question: I solved it. thanks. [21:29] I think I had an infinite loop if the password confirmation was not right [21:30] jtaylor: the hijack process is to announce that you are planning on hijacking before you hijack: http://wiki.debian.org/qa.debian.org/removals (if someone wants to file such a bug, that'd be awesome) [21:45] should i be worried about these broken pipe errors being thrown whilst using backportpackage ? http://pastebin.com/feqRTmS6 [23:08] someone said earlier I should use bzr merge-package instead of merge, but it doesn't seem to be smart enough to deapply quilt patches before the merge, and won't take --force to do the merge after I manually deapply them... how can I work around this? [23:12] psusi: I know there are scripts out there to make it less painful, but don't know where offhand [23:12] bug 845860 says barry was going ot write something... [23:12] Launchpad bug 845860 in Ubuntu Packaging Guide "merge-package discussion doesn't discuss coping with quilt" [Medium,Triaged] https://launchpad.net/bugs/845860 [23:17] hrm.. so there's no way to avoid the bogus deapply/reapply commits in the history? [23:18] yah, that seems like a horrible solution [23:18] I recall a better one [23:25] * psusi wonders why --lca isn't the default