=== sikon is now known as lucidfox [07:02] good morning === almaisan` is now known as al-maisan [08:20] Morning dholbach. [08:20] hi iulian === Kiall is now known as zz_Kiall === zz_Kiall is now known as Kiall === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [12:19] hi Rhonda, I'm told you're maintaining either packages.debian.org or the Ubuntu counterpart. If so, quick question about the info about the content of packages. How does that work at a high level? Is the archive scanned for all files that packages contained and then all that info put into a database? [12:20] Contents.gz is already there :) [12:20] or all the packages downloaded, extracted and then the info put into a DB?... [12:20] so no need to scan [12:21] Zhenech, ah, so there is a Contents.gz file that contains info about all the files contained packages from an archive? (I'm not familiar with the structure of the archives) [12:21] yes [12:22] http://ftp.de.debian.org/debian/dists/stable/ Contents-*.gz :) [12:23] dpm: There are Contents files in the archive which gets used. :) [12:23] apt-file uses the same information, btw [12:24] cool, thanks Zhenech and Rhonda. So packages.ubuntu.com then just reads Contents.gz and dumps the info in a DB? [12:25] … yes, "DB" [12:25] bdb files %-/ [12:25] … and this is on my agenda to get fixed, to use a real db. [12:27] Rhonda, gotcha. Out of interest, do you know roughly how long it takes to scan the Contents.gz file and put it into the bdb file? [12:28] Way too long. But that's not the only bottle neck, the Packages and Sources files are just as bad. [12:29] is "way too long" in the range of minutes, hours, days... ? [12:32] Hours, in total. [12:34] ok, thanks [12:38] dpm: If you're talking about scanning that when ARB packages are submitted, it won't work. The archive will not check against ARB, so you could get a collision at any future moment. [12:40] sorry but the spec was too long for me to read, so I don't know what you're proposing here. I only know what ScottK said on the list. [12:40] Laney, I was thinking of scanning both the main archive and extras [12:40] then you have to yank the package from extras as soon as a conflict appears in the archive [12:41] actually it's maybe not so much of a problem on stable releases [12:41] yeah, I think that's the advantage, as extras packages would only come for stable releases [12:42] but what happens when you want to roll it on to the next release? [12:42] * xnox wishes for dpkg to auto-notice colisions and auto-convert them into alternatives. [12:42] then you might have to rename your files [12:42] I want git, chromium, node to point to the things I have installed..... not to something that happened to be first. [12:43] no collision on my machine -> collision doesn't affect me =) [12:43] grim [12:44] it's impossible to install every single package simultaneously. and the overlap, even when it happens by accident, is by accident small. [12:44] * xnox just have not wait for a life simulation game 'init' [12:45] as a cool way to spell "Ain't it?" [12:47] That's a stupid London slang for "isn't it". :) [12:49] "isn't it" is kinda weird in and of itself. Noone says "is not it", so it's a rather peculiar abbreviation. [12:50] I'm sure there are historical reasons why it makes sense, but still. [12:50] * _ruben votes for "is itn't" as the new alternative [12:50] soren: "init" is just a lazy way of saying "isn't it". Some Londoners can't be bothered saying it correctly. [12:51] iulian: I know. [12:51] I've heard it a lot in east London. [12:51] soren: language is kinda weird in itself. [12:51] Laney, yeah, we'll have to think this through, for now I was just trying to gather some info about the current options and caveats [12:51] * iulian nods. [12:51] iulian: I'm just pointing out that oddity of "isn't it" being the "correct" abbreviation of "is it not". [12:52] The trouble with spoken language is that it's an interpreted language, and every person has their own interpreter for it. [12:52] That's bound to fail and result in incompatibilities. [12:52] Rhonda: Speaking is overrated. [12:52] s/spoken/written/ if that pleases you better, same difference. [12:52] _ruben: Heh :) === medberry is now known as med_ [15:33] How do you save the output of pbuilder-dist to a file, seeing how --logfile isn't passed along to pbuilder? Wouldh you just have to redirect in bash? [15:35] I always use --pkgname-logfile [15:35] arand: it writes to a file in ~/pbuilder by default [15:36] Yes, but if I run two simultaneously, the last with overwrite this last_operation.log, right? [15:37] sounds right [15:37] we'll take a patch to make last_operation.log a symlink to the most recent log file, named after the package built :) [15:46] The right thing would be to support the --pkgname-logfile switch in *builder-dist [15:46] Laney, RainCT, ^^ :) [15:47] hello, is there any design guideline to create icon for indicators? [15:48] alucardn1: no idea, I'd ask the #ubuntu-unity people [15:50] where can one find a list of packages that were removed from the repos? [15:50] and reasoning thereof :P [15:51] tumbleweed: thanks [15:52] TheLordOfTime: I don't think we have a list, but for each package, you can find it in its publishing history page [15:52] tumbleweed: which would be where? (general link structure) [15:52] ...you can find *the reason* in... [15:53] TheLordOfTime: https://launchpad.net/ubuntu/+source/PACKAGE/+publishinghistory [15:53] you can find everything about a package at /ubuntu/+source/PACKAGE [15:53] :P [15:54] the publishing history page... that's a new one, didnt know that existed [15:54] the link is in the top right corner of the package's page [15:54] don't see it here. *shrugs* [15:54] might have old cruft in my cache [15:54] if you want to find all package removals, you can get them from the API, but it's a slow painful process... [15:54] i'll check later, net's going down for maintenance here. [18:14] hm ruby-vmc has a json<1.7.0 dependency in its gem file [18:14] so it should conflict with ruby-json [18:14] (or that dependency is just nonsense) === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === yofel_ is now known as yofel [19:16] gna ruby vmc never seemed to ahve worked in the first place [19:16] it needs some interact module which isn't even packaged === chrisccoulson_ is now known as chrisccoulson [20:55] tumbleweed, Logan_, micahg: I think I changed my mind, objections to removing ruby-vmc? [20:55] from what I can tell large parts of it never worked [20:55] no objections here [20:56] jtaylor: fine with me [20:56] but sooner rather than later [20:57] jtaylor: would just like to know if there's anyone in Canonical that needs it for something (which would obligate them to fix this mess at that point), otherwise, no objections [20:58] * micahg pings someone for that info [20:59] jtaylor: re mpmath. It the tests *currently* fail and are ignored, so it's not any worse, but this seemed like a useful moment to deal with it (as you'd claimed that they passed :P ) [21:00] tumbleweed: yes that was a mistake [21:00] sort of copy paste from my other ffe's [21:00] there are a couple other issues in the log I overlooked too [21:00] s/It t/T/ [21:01] pinged morph about it [21:01] and there I thought accepting FFes from you was safe :) [21:01] yeah, I saw [21:03] oh man [21:03] the psutil testsuite also failed [21:03] I really wasn't to attentive when I filed these [21:03] hehe [21:03] well it didn't fail it never ran [21:04] jtaylor: go for it :) [21:10] at least networkx realls passes its tests [21:10] 1 out of 3 ._. [21:10] * tumbleweed shall in future require build logs from jtaylor :) [21:14] it also teaches, let your builds fail on failing tests [21:15] yeah. fortunately it's an RC bug if you fail to do that :) [21:15] really? [21:16] then you could file rc bugs against all of morphs packages oO [21:16] policy § 4.6 [21:18] hm that looks more like advice than requirement [21:18] if its ignored intentionally its certainly not a severe policy violation [21:18] yeah, for ignoring test failures, RC would be a bit hash. But for something that might fail and build an incorrect package... === almaisan-away is now known as al-maisan [21:23] howdy motu's. I have a couple FFe for multiverse that I filed this morning for sync's from debian. The packages were held up on debian sponsorship, but they are now in Debian. Are MOTU's the archive admins that need to sign off on the FFe? [21:23] utlemming: -release peoples === al-maisan is now known as almaisan-away [21:24] some are lurking here though [21:24] micahg: I thought it might go that way, but thought I'd ask here first [21:25] pure MOTU and archive admin are mutually exclusive ATM as well :) [21:25] michahg: that's good to know === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === med_ is now known as DaveM_ === DaveM_ is now known as med_ [22:18] Laney: Archive scans won't solve the problem. [22:18] what problem? [22:18] File conflicts. [22:18] wh [22:18] Even in the stable release, backports can cause an conflict. [22:18] * micahg thinks namespacing is the best option there [22:18] oh, you're referring to that old conversation [22:19] Laney: Yes. Been offline most of the day. [22:19] * ScottK thinks /opt is a namespace. [22:19] it is [22:19] * ajmitch wants to suggest namespacing using an overlayfs, extending what arkose does [22:19] it doesn't solve all problems but it's less work for upstream developers [22:20] stow ftw [22:20] * xnox hides [22:20] xnox: similar enough, but done without symlinks :) [22:21] * ScottK thinks it's an essential predicate to a proper solution that stuff that's built on top of Ubuntu can't interfere with Ubuntu proper. [22:21] * micahg would think using some of these apps in an lxc container only might be the best way to go [22:21] ScottK: +1 [22:22] micahg: lxc+apparmour is what arkose uses [22:22] I think something along those lines would be better. [22:23] TBH the policy was so long that I didn't get much past the introduction [22:23] Laney: it was detailed :) [22:23] & I have doubts that people will understand the permissions asked for when installing a package from the software centre [22:24] since retrofitting sandboxing onto these apps will be so much fun [22:25] If you do it right, they shouldn't know they are sandboxed. [22:25] no, but the users installing it are prompted to allow permissions, aiui [22:25] I haven't read the latest drafts of the spec to see what will be presented to users [22:25] Permissions will be displayed apparently. [22:26] any MOTU around? got a question regarding a package that is pretty much unmaintained [22:26] !ask | TheLordOfTime [22:26] TheLordOfTime: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience [22:28] ScottK: was about something in Universe, the supybot package. Its pretty much unmaintained, hasnt been updated since Karmic. as well, in Debian, the package is also unmaintained (last update in 2009). Is this possibly removable? iirc, such an old supybot is technically buggy and at risk for overflows and stuff [22:28] (its just been copied from karmic according to the LP page) [22:28] If you can confirm it's got security issues, I'd say definitely. [22:29] You should also suggest the same in Debian if it's appropriate. [22:29] i'll email the upstream maintainer, see if they are even still alive [22:32] TheLordOfTime: people use supybot [22:32] there hasn't been an usptream release in years [22:32] do we have *known* security issues? [22:33] tumbleweed: correction: people use Limnoria [22:33] which is a patched and improved fork [22:33] never heard of it [22:33] https://bugs.launchpad.net/ubuntu/+source/supybot/+bug/234629 looks like a security bug [22:33] Launchpad bug 234629 in supybot (Ubuntu) "supybot !web title leaks LAN HTTP servers to the channel" [Undecided,Confirmed] [22:33] never been "fixed" per se. [22:34] I suggest you propose the debian maintainer switch to limnoria [22:34] the "debian maintainer" according to the supybot project channel here *is* a dev of "supybot" [22:34] i'm going to email them shortly as soon as my email client stops freezing [22:36] then he should be aware of limnoria, but it's still worth prodding him [22:36] i'm prodding him for an update log, to see whether he's aware of bugs existing [22:36] the guy has an @debian.org address, so if he's not checking bugs, well... [22:37] jamessan is very active in debian [22:37] indeed. kinda surprised he hasnt picked up on this. [22:37] * TheLordOfTime did just email him [22:38] tumbleweed: also... http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=supybot&repeatmerged=no [22:38] read the "Important" bugs [22:38] there's risks in there as well, filed against the Debian version and not the Ubuntu version [22:39] its not too far fetched to assume those bugs exist in the Ubuntu version as well. [22:39] * TheLordOfTime would have to confirm, but already uses Limnoria on production environments [22:42] hi l3on, was wondering if you plan on working on your open merges (/me has some uncompleted as well, but is planning on doing them) [22:44] tumbleweed: oh, you know what... [22:44] tumbleweed: according to these bugs that can put a system at risk, there's been *zero* activity on the bugs [22:44] and statements to the effect that upstream is pretty much dead [22:44] it's not like anyone provided any ptaches either [22:45] they're all patched in limnoria, according to bug comments... [22:45] they just told him to switch to a different upstream. which isn't something one does lightly [22:45] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672214, for instance. and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672215 [22:45] Debian bug 672214 in supybot "[supybot] misc.last command can be used to crash the computer where the bot is running" [Important,Open] [22:45] Debian bug 672215 in supybot "[supybot] math.calc can be used to crash the computer where the bot is running" [Important,Open] [22:46] TheLordOfTime: we (and debian) fix security issues by applying minimal patches. only the development releases are fixed with new upstream versions [22:47] tumbleweed: limnoria doesn't keep their patches around afaict [22:47] i'm reading up on suggesting a package's removal now, so... [22:47] they sound lie a pleasure to work with :/ [22:48] why aren't those bugs RC? [22:48] seriously, though. they use git. the commits fixing those bugs can be found [22:50] ... okay, now i'm seriously annoyed [22:50] and that's not a good thing [22:50] because of getting banned? [22:51] no, because that guy has banned me in two places [22:51] because i brought up (1) the fact the package shoudl be removed, and (2) he's taking my opinions a bit too seriously [22:51] * TheLordOfTime goes off to a private channel to rant. [22:54] aww did I miss out on some fun? :) [22:55] apparantly [22:55] you've missed out on my rage/annoyance levels going from 500 (low) to 8000 (very high) very quickly. [22:55] just because i happen to be wanting to suggest the removal of the supybot package because of security bugs [22:55] * TheLordOfTime returns to private ranting, to prevent a mess from /dev/chaos leaking to Ubuntu channels [22:56] if you can be civil then I suggest you post links to the commits on the bugs and make them RC [22:58] the civility will improve after a little while of ranting in private. [22:58] hence the ranting in private.