[00:01] lfaraone, that's the weird. There is no diff.gz [00:01] Legendario: did you run "debuild -S"? (upper case S) [00:01] And did you get a message about trouble finding the orig.tar.gz? [00:01] lfaraone, yes. debuild -S -sa [00:01] Legendario: like persia said, could dpkg find the orig.tar.gz? [00:03] lfaraone, no. because it program is released as a simple bash script. It offered me the option to create a tar.gz file, which I accepted [00:04] what is "It" which offered this to you? [00:04] azeem, debuild i guess [00:05] I never saw debuild offering options to accept [00:05] maybe it was dh_make? [00:05] Um, for packaging a bash script, one needs to create one's own tarball. === jmarsden_ is now known as jmarsden [00:06] https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling is a bit out of date, but not a bad outline. [00:06] If doing it now, I'd be recommending DEP3, DEP5, and dh(1) [00:07] persia, the tarball was created, but not the diff.gz [00:07] Legendario: because there was no .orig.tar.gz, it created a native package [00:07] i.e. just .tar.gz and .dsc [00:07] I know. But creating the tarball with debuild isn't the preferred method. See the notes from my class. [00:11] persia, ok. I'll give it a try. thanks [00:49] persia: is there a problem with using standards-version 3.8.4? REVU lintian complains. [00:52] lfaraone: spooky only has lintian 2.2.17ubuntu1.1 : you could backport a newer one if it's easy, and we can request that it be installed. [00:53] * persia doesn't have permission to install stuff [01:08] In what cases is update-notifier's "you must restart foo" triggered? Groundcontrol's postinst copies /usr/share/groundcontrol/groundcontrol-restart-required.update-notifier to /var/lib/update-notifier/user.d but I don't get a popup. [01:08] (the app specifically to restart is nautilus) [01:10] I remember being very confused by that before, although I don't remember the results of my research. I believe I had to look at the update-notifier source to figure it out. [01:11] IIRC you also need to actually trigger update-notifier in some way; simply dropping a file there doesn't trigger it. [01:13] That sounds like something that would benefit from dpkg trigger support. [01:13] It does, yes. [01:13] RAOF: I'm looking at firefox's packaging right now. it's a very very very complicated debian/ directory, but I don't *think* they are triggering anything. [01:13] check the postinst. [01:14] hyperair: that's what I'm looking at. [01:14] ah [01:15] Firefox vs groundcontrol [01:16] hyperair, RAOF, persia, am I missing something? [01:17] That part of the postinst is actually getting triggered, right? IE: you're seeing the updatenotifier file being copied? [01:17] lfaraone: check the [ -d $UPDATENOTIFIERDIR ] block [01:17] Both of those are horrible. They should have case wrappers to handle the different sorts of arguments. [01:17] it looks like it's copying a file into /var/lib/update-notifier/user.d [01:18] is there any page that show's packages up for adoptions? === aaron is now known as TiMiDo [01:18] aaron: No, we don't have maintainers in Ubuntu. [01:18] oh ic. [01:18] TiMiDo: But, there's lots of work needs doing. What sort of stuff would you like to do? [01:19] persia, possible packaging and i do a lot of translations also [01:20] hyperair: yep. our file their file [01:20] TiMiDo: Well, I can't tell you anything about translations (I think there's an #ubuntu-translators or some such for that, but I could be wrong). [01:21] lfaraone: does it work? [01:21] true. perhaps now i want to do packages now =) [01:21] For packaging, most of the work is bugfixing, but there's also some package updates pending. Which of those sound more interesting? [01:21] hyperair: firefox's does, I think. [01:21] i will ove to do the updates pending =) [01:21] that wi'll be cool [01:21] lfaraone: read update-notifier's source then =p [01:21] TiMiDo: Take a look at http://qa.ubuntuwire.com/uehs [01:22] Packages not in sync with upstream is the most accessible list, but the other lists may be interesting to investigate as well. [01:22] is html2ps already updated it? [01:22] * hyperair notices that lots of ubuntu-specific stuff seem to either be poorly documented, or written badly. [01:22] hyperair: patches welcome :) [01:22] usplash is one example of poor documentation [01:22] notify-osd has endless leaks [01:23] and this update-notifier is yet another example of poor documentation [01:23] not to mention update-manager and its grinding of the CPU using Xorg [01:23] persia, so i could update the package and after the update to where do i upload it? [01:24] hyperair, is usplash even actively developed anymore? I was under the impression that it was dropped in favor of the plymouth [01:24] persia: it's easier to rewrite the whole thing than patch it up. notify-osd felt like hack upon hack while being implemented. [01:24] AHA. I need to "touch /var/lib/update-notifier/dpkg-run-stamp"! [01:24] kklimonda: i'm not sure, but while i was trying to write up usplash support for uswsusp, i couldn't *any* documentation. [01:24] TiMiDo: Attach the new diff.gz to a bug requesting the upgrade, and subscribe one of ubuntu-main-sponsors or ubuntu-universe-sponsors, and someone will review. [01:24] I have no idea where firefox is doing that, but as soon as I did that update-notifier started working! [01:24] oh okey that's cool [01:25] TiMiDo: rmadison can help you figure out which sponsor group to subscribe. [01:25] rmadison? [01:25] who is that? [01:25] hyperair: Sure, but even rewrites tend to be accepted, if they are good. [01:25] TiMiDo: rmadison is a command. [01:25] oh [01:26] persia: well, i'll look into it sometime, regarding notify-osd. [01:26] heh. Best of luck :) [01:26] maybe i'll name it notify-osd++ or something lol [01:26] hyperair: tradition is to call it notify-osd-ng :) [01:27] lfaraone: ah yes. of course. =p [01:27] hyperair: I'm personally planning on writing purity-ng when I get a Round Tuit. [01:27] lfaraone: putty is awesome on windows. on linux it's just.. useless. redundant. [01:28] hyperair: purity, not putty. Purity is an interactive CLI test application. [01:28] hyperair: currently orphaned on Debian. [01:28] oh whoops [01:28] interactive CLI test eh [01:28] interesting. [01:29] hyperair: it's really more of a game. see http://en.wikipedia.org/wiki/Purity_test [01:29] basically to test interactive CLI apps non-interactively? [01:29] hyperair: no, it tests *you*. [01:29] huh [01:29] oh lol [01:34] persia: would it be a bad idea to try to run groundcontrol through NEW if I have any hope of meeting the Feature Freeze? [01:34] Debian NEW or Ubuntu NEW? [01:34] persia: personally I prefer doing fixes/packaging through Debian when I can, and then backporting changes to Ubuntu releases / wait for them to sync. [01:34] persia: Debian, that is. [01:35] I'm not sure of current Debian NEW latencies, but I think you'd be pushing it. [01:35] For the new package I did last week, I uploaded to Ubuntu, and expect to send to Debian sometime this week. [01:36] (I'm waiting for two people who said they would be users to install it and confirm it works) [01:56] persia: if you have a moment, I'd appreciate it if you could glance at http://revu.ubuntuwire.com/details.py?upid=7616 [01:57] * persia sucks at python packaging, and hopes that someone else will jump up and offer to review before this is compelte [01:57] lfaraone: maintainer should be "Ubuntu Developers [01:58] Upstream should grow some StartupNotify support :) [01:58] Name, and Generic Name should be translated the same way that Comment is in the .desktop file. [01:58] s/seemlessly/seamlessly/ in Comment[en] in the .desktop file [01:59] X-Ubuntu-Gettext-Domain doesn't mean anything for stuff not in the langpacks [01:59] Categories should be restricted to those in http://standards.freedesktop.org/menu-spec/latest/apa.html [01:59] The .desktop file ought be upstream anyway, rather than in the diff.gz [02:00] I prefer ([\d\.]+) to (.*) in watch files, just in case. [02:00] Maintainer scripts should check arguments : see http://women.debian.org/wiki/English/MaintainerScripts [02:01] persia: odd, it is upstream, I wonder why .desktop is in the diff.gz... [02:02] I'd prefer a get-orig-source that pulled released tarballs, rather than alternately pulling from bzr. [02:02] I tend to prefer DEB5 copyright, but it's fine as-is. [02:02] persia: it only does that if you have bzr(revno) in changelog. [02:02] I also prefer to use Name consistently, rather than Name (email) (in debian/copyright) [02:03] debian/copyright fails to specify where the upstream source lives. [02:03] lfaraone: Yeah, well. It also fails the works-from-any-directory test. [02:04] Requiring both CDBS and debhelper (>=7.0.0) strikes me as odd. Most CDBS packages are compat level 6 compliant, unless there is something fancy I don't see. [02:05] Extra trailing comma in Build-Depends [02:06] Changelog entry for "Misc packaging Fixes" seems pointless for an initial release. nice to give credit, but I'm unsure if this is the best way. [02:06] persia: well, I don't know how else to give doctormo credit for doing 90% of the work :) [02:06] Odd to see a polish translation for restart-required, but not the .desktop file, and no English translation for restart-required. [02:07] lfaraone: Re-check the first line of debian/copyright :) [02:07] And I'd probably set debian/compat to 6 unless there was some special reason to use 7. [02:08] Obviously, check lintian -iIEV and --pedantic on source and binary changes :) Fix all the rest, and I'll run builds and check that. [02:08] persia, after the update i upload the package in launchpad? [02:08] I've also not yet reviewed upstream licensing, although I suspect it's likely clean, given the identity of upstream. [02:08] persia: would you rather I remove the polish translations? I don't speak it :) [02:09] TiMiDo: Not quite. Once you get a working updated package, attach the diff.gz of the updated version to a bug in launchpad. Make sure that you have a working watch file or get-orig-source rule. [02:09] okey [02:10] lfaraone: No, I just find it odd to have only that one bit available in polish, and not in english, the more so when the .desktop file is partially translated in English, and not Polish. [02:10] persia: what I really don't understand is why the desktop file ends up in the diff. It's part of upstream source! [02:11] lfaraone: Maybe it's duplicated somewhere, or generated on clean somehow? [02:11] persia: if so, I'll stab the CDBS maintainers. [02:12] Or switch to dh(1) :) Mind you, you'd also have to switch to python-support. [02:12] I do intend to fix python-distutils-extra at some point, as it gives me an excuse to learn python packaging, but that's not happening in the next couple days, and probably not for FF> [02:15] persia: does pysupport handle XS-Python-Versions: fields? [02:15] No idea. That's on my list of stuff to investigate :) [02:23] persia, how soon would be too soon to ask? =p [02:23] About 5 minutes ago :) [02:23] perfect timing [02:24] So, I don't recommend packaging new stuff until one has a fair bit of experience working with other people's packages, as this gives one a better feel for all the different ways to do things, and lets one develop a personal style. [02:24] persia: aha! "Found cached translation database" seems to be the culprit. It still happens when I'm using dh(1) however... [02:24] That said, if one has something one *really* wants to package for some reason, the following process is what I use: [02:24] Merging translations into groundcontrol.desktop. [02:25] * "Found cached translation database\nMerging translations into groundcontrol.desktop." [02:25] lfaraone: Hrm. I'm not sure about that. Might want to turn on DH_VERBOSE to find the culprit. [02:25] No idea what that means... [02:25] ddecator: make a directory with the package name, and create a debian directory. [02:25] ddecator: In that directory, create a watch file (man uscan can help). [02:26] ddecator: run dch --create to create a debian/changelog, and use uscan to get the upstream source [02:26] ddecator: unpack the upstream source, and move your debian directory into the unpacked directory. [02:26] ddecator: absolutely no change in the output. (this was on a source upload) [02:26] persia: you mean when DH_VERBOSE=1, right? [02:26] ddecator: `echo 7 > debian/compat` and `cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules` [02:26] lfaraone: Yep. [02:26] s/ ddecator / persia / [02:27] It *should* make it more verbose. [02:27] lfaraone, haha, i wondered about that [02:27] persia: so yeah, no change. See bzr branch lp:~groundcontrollers/groundcontrol/debianfiles :) [02:28] ddecator: use `licensecheck -r --copyright .` and `suspicious-source` to create and verify debian/copyright : I tend to use the format described at http://dep.debian.net/deps/dep5 [02:28] ddecator: Create a debian/control file based on http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ch-controlfields.html [02:29] Build the source, and you've created a buggy package. That's it. [02:29] Fixing the bugs is the fun bit :) lintian -iIEV and --pedantic can help find some issues to think about. [02:30] thanks persia, i'm trying to work my way into getting into some debugging, but i'm a little lost on where to start so i'm learning basic python so i can recognize code. and suggestions as to some files i can use to practice packaging? [02:31] python-mkdebian automates it for most python programs. Not into my favorite style, but it tends to mostly work. [02:32] i wanna figure out how to do it manually though [02:33] ddecator: Um, OK. I think that you'd do much better to explore other existing packages for that, rather than trying to do it from scratch. [02:34] any suggestions? [02:35] Go find some bugs, and investigate them. Pull the relevant sources. Explore. If they look like they can be fixed with packaging (fail to upgrade are common cases for this), try changing stuff. [02:35] alright...thanks persia =) [02:38] persia: aha. upstream only ships a desktop.in file! [02:40] lfaraone: Aha! That's fine, but the upstream build system shouldn't be updating it on clean, which seems like the candidate culprit. [02:40] Unless something else is happening deep within CDBS. [02:40] persia: well, now it's dh7 :) [02:40] persia: same problem. [02:41] Well, same issue. Either upstream is updating it on clean, or something else is happening deep within dh. [02:41] pastebin the source build log with DH_VERBOSE=1? [02:41] persia: you're right, it happens on clean. [02:43] lfaraone: So, it probably ought happen on build. Having clean make it less clean just seems wrong somehow. [02:43] persia: right again. it's a python package, so there's something wrong with setup.py [02:43] looks like they run it regardless of what command is run. [02:45] persia: code in question: http://sprunge.us/EeZG?python lines 39 to 45 [02:46] Um, and this gets back to my plan to learn how python works :) [02:47] persia: setup.py is widely regarded as black magic. [02:47] if you consider wide to be {lfaraone} [02:48] Well, some people say that about make, which I find trivial. I think it depends on your background. [03:03] * ScottK finds setup.py generally pretty accessible. [03:04] ScottK: Any idea why the .desktop file is reconstructed on clean for groundcontrol on REVU? [03:04] persia: Nope. Haven't looked. [04:59] jdong: ping [06:26] how to create man page? [06:29] Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok [06:33] geser: FYI ... libpdfbox-java merge is done. [07:39] good morning [07:39] morning [07:40] hey ivoks [07:40] what's up daniel? [07:40] Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok [07:41] ivoks: how are you doing? [07:41] dholbach: fine, trying to implement two blueprints :) [07:41] dholbach: you? [07:42] ivoks: still a bit jetlagged, but I'm OK - and my luggage is supposed to arrive later today - YAY! :) [07:43] dholbach: good luck with those; in dallas, i had to pick up my luaggage and i did that 2 days before departure :) [07:43] ivoks: in Berlin it usually arrives the day later and they call you in advance to tell you they bring it - worked for me the last 3 times :) [07:43] nice :) [07:44] yeah, I'm grateful it always happened to me on the way back and not when I was going somewhere :) [07:44] hehe [07:45] heh, good thing I didn't do the corosync merge ;) [07:46] crimsun: yeah, don't touch it :D [07:47] ivoks: it would have been done at least a month ago, but I pinged chuck about it first. good thing. [07:56] do we have a revu hacker here? http://revu.ubuntuwire.com/p/zope.index gets redirected to http://revu.ubuntuwire.com/p/zope. which makes reviewing the package a bit hard! [08:14] hey i have a question i was wondering if i can port up BitchX [08:16] meaning take on maintainership of it? The best place to do it is probably in Debian; see Debian #451373 [08:16] Debian bug 451373 in ftp.debian.org "RM: ircii-pana -- RoQA; security issues, abandoned upstream, unmainted" [Normal,Open] http://bugs.debian.org/451373 [08:18] well bx is back up and i'm one of there Developers [08:19] again, the best place to take it up again is in Debian [08:20] all those bugs are Fixed. [08:20] =) [08:21] great. Makes sense to prepare an upload to Sid, then. [08:21] it's almost there = [08:34] hi [08:34] I'm having some trouble with my debian files [08:34] (trying to package a .deb) [08:35] Can I have a copy of your 'rules' file, please? [08:47] Linux-CLI: Instead tell us what the problem is and we will try to solve it. [08:48] Linux-CLI, lol why would you need another packages rules? [08:48] that's seems odd. [08:49] slytherin & TiMiDo: I'll try one last time... [08:49] last time of? [08:52] TiMiDo: Attempting without help :P [08:52] :p [08:53] * Linux-CLI is installing devscripts [08:55] * Linux-CLI is [still] installing devscripts (1min & 40secs) [08:56] (took 5min, installing now) [08:59] cool [08:59] did it .... finish? [08:59] with 0 errors? [09:04] Nope [09:04] Could you please help me? - Here is my Terminal output: http://pastebin.com/d3b20a4ff [09:07] * Linux-CLI is uploading his /debian/ folder [09:07] Linux-CLI: Upstream doesn't appear to provide a clean rule in the makefile. Either another rule needs to be called, upstream needs to be fixed, another build system used, or cleanup done manually. [09:08] How do I do cleanup manually? [09:08] Also, do you know of a good free hosting site where I can put my tar.gz? [09:08] (just the /debian/ folder) [09:09] http://www.mediafire.com/?tjni1zzm2mj [09:10] ^There is the copy of my /debian/ folder [09:10] (Within the program directory) [09:10] You can do whatever clean needs to do in the clean rule in debian/rules. [09:10] What type of clean is required? [09:10] Ideally, it should put the source back into the state it was in prior to the build. [09:11] I don't understand [09:11] Can you show me an example of that type of rules file? [09:14] I don't know of one offhand, but it's usually a number of -rm calls. [09:14] persia: I understand that the rules file needs to clean the source, reverting the source back to its prior state. Could you please take a look at my /debian/ subdirectory, and tell me what else needs to be changed? [09:15] persia: So it's just to install [09:15] What? [09:15] persia: So it's just to uninstall [09:15] apparently I can't look: attempting to see your debian/ folder shows me a poker advertisement. [09:16] No, it's clean. Has almost nothing to do with install. Local stuff created during build. [09:17] persia: How about an xdcc? [09:18] 2KB btw [09:20] http://uploading.com/files/f6666e9e/debian.tar.gz/ [09:20] I'm not sure that works through the chain of bots and proxies I use to interact with communication services. [09:21] That one takes me to a picture of an underdressed woman and a heap of text in a language I don't read. [09:22] I'm not going to click on any more of your URLs. [09:24] Well it sounds like you're not recommending anyway for me to give you the files. [09:24] Goodbye. [09:25] Bother. I don't mean to be rude, I'm just tired and insufficiently motivated to do a review of a known broken package right now. [09:25] persia, bah, it doesnt take me to a naked woman ! [09:25] ogra: I didn't say "naked": she was in her underwear. But I'm not surprised, as it seems to have extensive geolocation logic. [09:26] indeed, the ad changed for me [09:26] So different places probably get different images, depending on local tolerances. [09:26] i can buy an iphone instead :) [09:27] its an upload service that keeps the upload for 30sec btw ... [09:27] err, "keeps you from getting the upload" [09:28] So you can look at the advertisements? Aha! [09:28] right, it puts up an ad that stays for 30sec before you can download the referred file [09:29] The first one might have been the same thing. I'm not sure I waited long enough. [09:31] * persia goes back to figuring out how to use a mandonline and lets backscroll accumulate [09:32] <\sh> persia: "use a mandonline" you mean "mandoline"? [09:44] hello I just reinstalled my system and i m getting a secret key not found error http://paste.ubuntu.com/371550/ [09:44] I made a new key and uploaded it to lp [09:45] http://paste.ubuntu.com/371551/ <-- my .bashrc [09:47] i sourced .bashrc too [09:47] any ideas? [10:03] rsajdok: I just write what it says on the labeling. It's for cutting stuff. Nifty, but the conclusion was to not cut stuff for this next meal :) [10:18] hi i'm creating man page for my package, here also any restriction for description like control file. [10:19] Could you rephrase the question? [10:21] ya, in control file in description each line should be less than 75 characters, like that the man page description also each line should be less than 75 characters or any other condtions? [10:22] I tend to prefer that all text files in source be less than 75 characters, as it makes it easier to quote chunks of stuff in email, etc. [10:23] I don't think it's a firm rule though. Just make sure you can parse it cleanly with nroff -man in a regular terminal. [10:24] ok [10:39] james_w: Would you please have another look at 517161. At least if I'm reading Launchpad right the "and move it to Multiverse" part of the bug doesn't seem to have been done. [10:42] ScottK: it hasn't, I missed that as it was requesting something that had already happened [10:45] done now [11:05] james_w: Thanks. [11:56] hey [11:57] i'm wondering how to submit a bugfix to a package [11:57] i generated the source deb, should i just attach the .diff.gz to the bug report? [11:58] corecode: Generally we prefer the output of the debdiff between the current version in the archive and your new candidate version. [11:58] The exception would be for upstream version upgrades, where this gets extremely noisy. [11:58] okay [12:00] i just realized it is a main package, but the process will be the same [12:01] Yeah, except you would have asked in #ubuntu-devel, and I would have answered the same way :) [12:01] Remember to subscribe ubuntu-main-sponsors to the bug once you've attached the patch. We7re always looking for better ways to track that, but haven't found a clean one yet. [12:02] corecode: please read this guide https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff [12:06] doing so, thanks [12:19] so what do i do to get this processed? should i just wait or contact somebody? [12:23] Once you subscribe the appropriate sponsorship team to the bug, then you just wait. [12:24] i see [12:26] reading the wiki page, i'm not sure how to submit it for sponsorship [12:35] corecode: in launchpad bug, click 'subscribe someone else' and then search for ubuntu-main-sponsors [12:35] ah [12:35] thanks! [12:35] because the wiki page says "don't subscribe anybody if the bug needs sponsorship" [12:36] that is surely wrong [12:36] great, thanks [12:37] the workflow in ubuntu is so easy to use, it is a real joy [12:37] coming from bsd's packaging... [12:37] "Do not assign a bug to anyone if it needs sponsorship. " [12:37] is the wording [12:42] corecode: Assign is different than subscribe. [12:42] Subscribe is the right thing to do. [13:04] ah [13:27] could anyone with core-dev upload priviledges please act on bug #493628 ? [13:27] Launchpad bug 493628 in mozvoikko "Please merge mozvoikko-1.0-4 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/493628 [13:27] this one goes to main, so I cannot do anthing about it myself. [13:38] What's the proper way to record copyright status of a PD work in DEP5? [13:38] Copyright: none? [13:40] Q-FUNK: You might want to ask in -devel for stuff that needs main, as many folk here also don't have that access. [13:41] ok, will do [13:41] Laney: License: PD, etc. [13:41] Laney: But note that PD isn't valid in all jurisdictions, and has different requirements in different jurisdictions. It can be quite hard to properly document and demonstrate that something is truly PD. [13:42] I'd drop the Copyright: header for that license, but, again, this isn't valid in some places: better to identify the copyright holder, if possible, and document that copyright has expired or is explicitly not claimed, or similar. [13:42] persia: This is just a simple shell script that I took from another source package (from the debian/ directory, even). I don't expect it to be contentious. [13:42] "If the work is truly public domain, this should be stated in the copyright field." from DEP5 [13:43] * Laney will just explain a little [13:43] It's unlikely that anything in a debian/ directory is in the public domain, unless the authors are from specific locations that still permit it (public domain requires lots more time than Debian has had in any jurisdiction where the Berne convention applies). [13:44] Doesn't mean the authors don't think it is, of course :) [13:44] :) [13:52] any revu hackers here? [13:53] What do you need? I'm not a REVU hacker, but I'm a REVU admin, so can do some stuff. [13:53] http://revu.ubuntuwire.com/p/zope.index gets redirected to http://revu.ubuntuwire.com/p/zope. [13:53] which doesn't help reviewing it :) [13:54] pull-revu-source might work. [13:54] you should file a bug on lp/revu [13:54] But yeah, file a bug. [13:54] * persia can't fix that: requires coding hackery, or at least webserver config hackery [13:55] can you see what the httpd logs say about the request? [13:56] bug 518827 [13:56] Launchpad bug 518827 in revu "http://revu.ubuntuwire.com/p/zope.index unreviewable ("index" removed from URL)" [Undecided,New] https://launchpad.net/bugs/518827 [13:56] * persia tries [13:57] * Laney has access to that box, but no permissions to view logs [13:57] Laney: I don't have sufficient permission to view the logs either. [13:57] I suspect we're hitting some URL rewriting rule though, from the observed behaviour. [13:57] hi persia ;) [13:58] htaccess.tmpl:#Get rid of "index" in directories: <-- maybe? [13:58] sounds suspicious [13:59] anyway, I managed to get the source which helped :) [14:00] Submitted patches tend to get applied fairly smoothly. I don't remember if there is a current staging server running though. [14:00] I'm sorry, I don't have time for setting up a REVU instance and patching it now [14:01] Heh. Understood :) [14:12] hello [14:13] where is the current Standards-Version defined? [14:13] I'm getting lintian warnings on debian packages that want Standards-Version: 3.8.4, but my lucid stuff seems to want to be at 3.8.3 [14:14] statik: That's hard to say precisely. I tend to believe that the current version of the ubuntu-policy package represents the current standards version, but you may do as well with the current version of the debian-policy package, in case ubuntu-policy hasn't been updated recently. [14:14] persia, thanks! i'll dig into those packages [14:14] statik: Where do you see the warnings? [14:14] persia, lintian I think [14:14] statik: dpkg -l or apt-cache show ... | Version is likely a good way to check, rather than heavier digging. [14:15] Which lintian? [14:15] on mentors.debian.net it wants 3.8.4. when I build locally on lucid, lintian wants 3.8.3 [14:16] Well then :) That tells you the versions of policy supported by lintian on mentors and lucid :) [14:16] persia, yep, I already knew that. my question was where/how is it defined :) [14:16] I doubt that many 3.8.4 compliant packages won't be 3.8.3 compliant in sufficiently significant ways to break lucid though :) [14:18] yeah, i hope so [14:19] Well, ask yourself a different question: Are you able to construct a package that is both 3.8.2 and 3.8.4 compliant? [14:19] so this is weird, http://packages.debian.org/search?keywords=debian-policy is at 3.8.3 also. I wonder where 3.8.4 comes from [14:19] It's in sid. [14:20] statik: Standards version is as known to the lintian version on your machine. Usually lintian is updated after policy is updated. [14:20] More than usually. Always. It's not possible to check compliance against unspecified policy. [14:20] sid has policy version 3.8.4 and also lintian that knows about this policy. [14:21] ah, so this page is outdated? http://packages.debian.org/sid/debian-policy it shows 3.8.3 [14:21] checking [14:21] * persia generally finds packages.${distro} to be out-of-date in all cases [14:22] statik: There is issues with the harddisk on packages.debian.org, currently worked on. [14:22] statik: yes it is outdated. there seems to be problem for last few days. A more updated information is available here - http://packages.qa.debian.org/d/debian-policy.html [14:22] persia: It's even in testing already. :) [14:22] thanks! i have learned a lot in just 5 minutes, I'm glad I asked [14:22] Rhonda: See, this is why I should be using rmadison rather than apt-cache show :) [14:23] ;) [14:23] And this problem is causing issues with requestsync tool when trying to request sync against package form unstable (instead of squeeze). [14:23] requestsync detects version but can not retrieve changelog of latest version. [14:33] damnit. How many time do I have to fix 518829 for lucid? [14:41] Does anyone have access to an {hppa,kfreebsd-i386,ppc,s390} box with a sid environment, and the inclination to run a test build for me? :) [14:42] * persia can do sid/ppc, but will have some latency reporting results if the build takes longer than 20 minutes. [14:42] I just want to know if it starts really [14:42] OK. Where is it? [14:42] persia: git://git.debian.org/git/collab-maint/agda-stdlib.git (or I can sort out the source package if you want it) [14:42] If you give me something to dget, I don't have to think about it, which I like :) [14:43] ok === dholbach_ is now known as dholbach [14:45] persia: http://orangesquash.org.uk/~laney/agda-stdlib/agda-stdlib_0.3-2.dsc [14:46] as long as it gets past https://buildd.debian.org/fetch.cgi?pkg=agda-stdlib&arch=powerpc&ver=0.3-1&stamp=1265532637&file=log&as=raw and starts typechecking then I'll be happy [14:52] Laney: http://paste.ubuntu.com/371732/ [14:52] erm [14:53] I think I'd call that an external problem :) [14:53] thanks persia [14:54] Laney: Yeah. Doesn't really look like your script, but I built my chroot with debootstrap --variant=buildd and would expect a simiar model for other folk. [14:54] Laney: Do you really need whatever pulls exim to build? [14:55]