[00:21] darn it.. just when I thought I'd help out with the bug triage lp goes ro.. [00:24] SpamapS: relax, you caught the tail end of it :) [00:32] micahg: unfortunately I also caught the tail end of my time for today.. :-P [00:34] * SpamapS decides to use ip over avian carrier, which should make his ajax calls take long enough where lp will be rw by the time snowflake and mr. chirpy get there. [00:36] SpamapS: you know there's an RFC for that, right? === Chex changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment === Chex changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs === jjohansen is now known as jj-afk === BUGa_2h2bday is now known as BUGa_BDAY [01:33] hmm. [01:34] ogra_ac: do you need to roll an additional card config into alsa-lib for maverick-proposed? [02:16] when did totem stop making and allowing bookmarks? [02:37] crimsun, From the dicussions I saw ~13 hours ago, I believe that was the expressed desire: to add /usr/share/alsa/init/sdp4430 (or similar), with an appropriate patch to 00main. [03:50] fta: you around? [03:51] mattyb: probably not for another 2-3 hrs [03:52] Thanks. [05:30] persia: hmm, ok. That would be alsa-utils, then. [05:33] OK. I'll add an alsa-utils task to 637947. I think the total solution was some kernel changes, the 652035 SRU, and the alsa-utils file. [05:35] (i was hoping for kernel changes so that the alsa-utils change wasn't required, but it doesn't seem like that will happen) [05:41] ok. [ubuntu/maverick-proposed] alsa-lib 1.0.23-1ubuntu2.1 (Waiting for approval) [05:41] gone for a couple days. [05:48] crimsun, Thanks a lot. === almaisan-away is now known as al-maisan [07:20] Good morning [07:20] jdstrand: ah, thanks for the ping [07:28] Guten Morgen pitti [07:39] pitti: Should I upload a -proposed icoutils then? [07:43] YokoZar: sure [07:43] if it's necessary [07:44] Good morning! [07:45] hey dholbach [07:45] Good morning dholbach [07:47] hey pitti, hey geser [07:50] micahg: I need some more info in bug 625801 [07:50] Launchpad bug 625801 in gnome-web-photo (Ubuntu Lucid) "gnome-web-photo missing required libxul.so" [Medium,Fix committed] https://launchpad.net/bugs/625801 === jj-afk is now known as jjohansen === jussi01_ is now known as jussi [08:38] cjwatson, ok that overnighter also failed to build for a new error, i have a fix for the error it hit, but am flying blind fixing it as i cannot do a full build on the porters due to chroot issues... do we want to hope this fixes it en-toto or wait for the porters to be fixed [08:39] s/fixing it/testing it properly/ [08:41] doko: can you look at bug 660257? [08:41] Launchpad bug 660257 in ghc6 (Ubuntu) "linking fails with binutils 2.20.51.20101009-0ubuntu1: cannot use --sysroot" [Undecided,New] https://launchpad.net/bugs/660257 [09:01] mr_pouit: would you like me to apply the "eject button" thunar patch to the PPA? (http://bugzilla.xfce.org/show_bug.cgi?id=3658) [09:01] bugzilla.xfce.org bug 3658 in core "icon for eject volumes on side pane" [Enhancement,Resolved: fixed] [09:02] oh, it got committed upstream \o/ [09:02] odd, I didn't get a mail about it [09:04] What happened? Where is dholbach? [09:04] mr_pouit: so, not so urgent then, it'll just flow in with new upstream versions then [09:10] c === jjohansen is now known as jj-afk [09:55] So, I'd like to call some python from a postinst: is there a best-practice method for where to put the python script? === hyperair is now known as Guest68417 === buxy_bak is now known as buxy [10:02] Laney: ok, fixing with next upload [10:08] doko: thx, will you reassign? === dapal is now known as hanska === hanska is now known as dapal [10:25] mvo, is it normal that extras.ubuntu.com key is not installed by default? the key missing here is 16126D3A3E5C1192 [10:30] zyga: it should be there, do you have ubuntu-extras-keyring (the package) installed? [10:31] zyga: is that a server install? [10:37] mvo, no it's unity install [10:38] mvo, ubuntu-extras-keyring installed 2010.09.27 [10:38] mvo, any place I could look to understand why the key is not picked up [10:44] http://ubuntuforums.org/showthread.php?t=1588889 mentions it too [10:46] pitti: made that icoutils upload [10:50] zyga: could you please try a apt-get install --reinstall ubuntu-extras-keyring? there was a bug in the package during mav that prevented it from getting applied [10:51] mvo, yup [10:51] mvo, that fixed it [10:51] wow, new django [10:51] (offtopic but important for me) === bilalakhtar_ is now known as bilalakhtar === pedro__ is now known as pedro_ === MacSlow is now known as MacSlow|lunch === carlotolinero is now known as Kaoruchan [12:23] any bug on 10.10? === amitk is now known as amitk-afk [12:33] I have a problem with a daemon written in Python. It depends on a python library package, and like most daemons it starts itself in its postinst. However, the python-support is deferred (using dpkg triggers), so once the daemon tries to start itself, the python module hasn't been python-support'ed, so it's nowhere to be found. [12:33] I can't imagine I'm the first to encounter this. What's the trick? [12:34] I thought there was a way to force a trigger to run [12:34] To trick python-support into running from the daemon's postinst? [12:34] StevenK: There is. update-python-modules -p, iirc. [12:34] I just wasn't sure if that was kosher. [12:36] * soren assumes it is and adds it [12:47] Doesn't dh_python2 fix this by just installing the .pyc files in the .deb in the right places? [12:48] I sure hope not. [12:48] why do you hope not? [12:49] though as it happens I think byte-compilation is still run-time in dh_python2 [12:49] Becuase there's only supposed to be .pyc files for the python version that the end user has installed. [12:49] python version_s_, I mean. [12:50] ...and a bunch of other reasons. [12:50] yeah. [12:50] http://www.python.org/dev/peps/pep-3147/ will help. [12:50] Basically all the reasons why this stuff happens at isntall time. [12:51] I've added a call to "update-python-modules --post-inst" after #DEBHELPER# in my base python package (on which the daemon's package depends). That should take care of business. [12:51] dh_python2 should fix this differently, though; byte-compilation is kind of a red herring [12:51] I've always wondered how much processing time is saved on that account. Do we have any numbres on that? [12:52] relying on a trigger to make the package usable is obviously wrong; it means that the package is lying when it says it's configured [12:52] I thought the way they did it was by putting the .py's in /usr/share/pyshared, and then putting .pyc's in the appropriate /usr/lib/python$ver dirs in the .deb .. I could be wrong.. still wrapping my head around the 3 or 4 ways to build python packages. :-P [12:53] cjwatson: Right. That's what python-support does, though. [12:53] SpamapS: dh_python2 doesn't rely on a trigger [12:53] soren: so don't use it. :) [12:53] cjwatson: It's not (just) me. [12:53] It's /every/ python package in my dependency chain. [12:53] cjwatson: right, which is why it is "the new hotness" .. but I don't recall how it does that. ;) [12:53] If just one of them uses python-support, I'd be screwed. [12:53] ah. unlucky. working around it with update-python-modules is probably fair enough for now, and hopefully it won't be a problem a couple of releases down the line [12:54] SpamapS: um. not using triggers involves *less* effort. :-) [12:54] triggers are a fancy optimisation, wrong in this context [12:55] dh_python2 just does the straightforward thing of pycompile in the postinst instead [12:55] cjwatson: I think we're both saying the same thing, but my snark and your precision is producing a lot of confusion for me. ;) [12:55] (and yes, there's a bunch of stuff about getting the installation paths exactly correct, but in this context that's kind of a side issue IMO) [12:58] cjwatson: I don't think dh_python2 does byte compiling in postinst.. I'm fairly certain the .pyc's are *in the .deb* [12:59] Oughtn't be. [12:59] You simply define the supported versions of python and it byte compiles for all of them. [13:01] I really hope not. [13:01] We'd then need to rebuild the other half the archive when we introduce Python 2.7. [13:02] would that be so bad? Simple maintainer scripts vs. rebuilds every few years? [13:03] SpamapS, Yes. [13:03] SpamapS: Yes, because .pyc files can be different per architecture, and most python packages are arch-indep. [13:03] I mean, we have to rebuild stuff when ABI's change all the time. python's just another ABI, no? [13:03] Because we change something related to supported python versions or default python versions nearly every cycle, and we very much don't rebuild that much of the archive each release. [13:04] Such core libraries rather rarely break ABI. [13:04] For good reason. [13:04] * SpamapS *IS* still talking out his arse on how he thinks dh_python2 works, so please, do not get your torches and pitchforks yet [13:04] And ignoring that problem, it also means you effectively double the size of each python package in the archive [13:06] SpamapS: look at /usr/share/debhelper/autoscripts/postinst-pycompile, which dh_python2 substitutes into postinsts. [13:08] in fact the header of dh_python2(1) says this too: "dh_python2 - calculates Python dependencies, adds maintainer scripts to byte compile files, etc." [13:08] cjwatson: indeed, I was just starting to understand dh_python2's source. I guess I was just confused by POX's presentation saying that dh_python2 had "all files in the package": http://people.debian.org/~piotr/dc10_slides.pdf [13:09] I think he means that it doesn't have a symlink forest for the .py files [13:10] hence the "dpkg friendly" bit - it means that you can look at where you're loading the .py file from, and use 'dpkg -S' without having to follow symlinks around [13:10] Right, thats much better. :) === diwic is now known as diwic_afk [13:12] pitti: could you merge cdbs? [13:13] ari-tczew: I already did [13:13] cdbs | 0.4.89ubuntu1 | natty | source, all [13:13] pitti: ah, nice! [13:14] MoM sucks [13:14] pitti: so cdbs is a part of toolchain? where can I find a fulllist packages related to toolchain? [13:15] ari-tczew: I don't know whether there's a written-down list [13:16] compilers (gcc, g++, gdc, gcj, etc.), perl, python, debhelper, cdbs, kernel (for linux-libc-dev), binutils, glibc [13:16] there isn't, to my knowledge, it's just the stuff that practically everything build-depends on and that tends to have substantial changes which we want in place early [13:16] (e.g. not (say) sed because it hardly ever changes in ways we care about) [13:16] I'm certain there isn't a written down list, and creating one would be tricky except by looking at the set considered "toolchain" just after an archive opens. [13:17] pitti's list above is roughly what I think of [13:17] ari-tczew: MoM sucks> why's that? it doesn't list cdbs, because pitti already merged it. this seems correct. [13:17] cjwatson: it lists quilt, for example [13:18] also annoying bug which shows comments added in the past [13:18] that's odd, and I will have a look. perhaps in future you could phrase this as a bug report rather than a thoroughly unhelpful snark. === amitk-afk is now known as amitk === MacSlow|lunch is now known as MacSlow [13:19] cjwatson: bug 596599 [13:19] Launchpad bug 596599 in Merge-o-Matic "MoM shows previous comments" [Undecided,Confirmed] https://launchpad.net/bugs/596599 [13:19] yes, I meant the quilt bit. I already knew about the comments bug. [13:19] ok I'll report a next bug [13:20] don't bother now, I'm looking at it [13:20] I didn't specifically mean "must be a bug report on launchpad", I meant "must actually contain detail rather than just being rude about it" [13:20] okok [13:20] btw. awesome knowledge [13:21] quilt seems like a stale merge left over from the past. I'm not sure yet whether this is due to a current bug, or an old bug that wasn't cleaned up after properly [13:23] hmm, it's in merge-blacklist.txt [13:23] I think that must be stale, given that it's in sync [13:24] I've removed it from merge-blacklist.txt, so the stale merge should be removed when MoM next runs [13:24] thanks for the report [13:24] pitti: commented on the bug === diwic_afk is now known as diwic === tkamppeter_ is now known as tkamppeter === mathiaz_ is now known as mathiaz === skaet_afk is now known as skaet [14:07] lamont, hey [14:07] lamont, https://edge.launchpad.net/~ubuntu-desktop/+archive/gnome3-builds/+build/1994816 [14:07] seems you didn't stop the build yesterday or that didn't work? [14:07] it's building still for 2 days [14:07] same issue on https://edge.launchpad.net/~ubuntu-desktop/+archive/gnome3-builds/+build/1996029 [14:08] not sure what's going on [14:08] the i386 version built in less than 20 minutes [14:15] stgraber, ping [14:17] huh, linux source exists in queue [14:19] not any more :) [14:25] So, it seems I b0rked php5-pgsql in maverick.. I've prepared an SRU.. https://bugs.launchpad.net/ubuntu/+source/php5/+bug/660227 anybody want to help speed that one in to maverick-updates? [14:25] Launchpad bug 660227 in php5 (Ubuntu) "php5-pgsql crash on getting an error back from postgres" [High,In progress] === Lutin is now known as Guest35464 [14:33] SpamapS: subscribe ubuntu-sponsors [14:38] ari-tczew: I've been told on multiple occasions not to do that if using UDD. [14:39] SpamapS: you can set reviewer as ubuntu-sponsors, then you don't need subscribe sponsors to bug. [14:40] and you can do it inversely: subscribe ubuntu-sponsors to bug, but not assign as reviewer [14:41] ari-tczew: ok. I'll add them to the merge proposal then [14:41] SpamapS: or you could ask me [14:41] does anyone have any idea what could be causing bug #647404? [14:41] Launchpad bug 647404 in udev (Ubuntu) "Udev worker error during boot "worker [XX] did not accept message -1 (Connection refused), kill it" [Undecided,Confirmed] https://launchpad.net/bugs/647404 [14:41] zul: ^^ see above for where I asked you, and anybody else in here. ;) [14:41] it's really annoying [14:42] zul: I was going to wait an hour or so before I started pumping narwhals narwhals into your mumble until you agreed to help me. ;) [14:42] SpamapS: can you make a debdiff for me? [14:43] zul: just download diff from bug. [14:44] SpamapS: ah, bug in debian/changelog. change ubuntu10 to ubuntu 9.1 [14:45] zul: you're so stubborn === xfaf is now known as zul [14:56] cjwatson: could you merge usbmount? [14:58] ari-tczew: I guess, but doesn't coolbhavi have first refusal on it? he touched it last [14:58] it's not a package I remember touching before, so not entirely sure why you're asking me [15:02] Anyone here with lwn.net subsription? [15:05] lucidfox, https://wiki.ubuntu.com/Membership/LWN can get you one quickly enough. [15:05] lucidfox: yes [15:06] Bah, bureaucracy... I just want to look at one article [15:06] nigelb, could you pastebin http://lwn.net/Articles/409033/ for me? [15:06] you can link it in PM [15:07] lucidfox, Up to you, really :) [15:08] cjwatson: dunno, I didn't ask coolbhavi. I've looked into code and it's strange to merge (for me). You're familiar with similiar packages, so I pinged you. [15:08] lucidfox: doesnt hurt to send marianna a mail :) [15:08] lucidfox: I've asked LWN's corbert about this in the past, he's totally ok with sharing links publically: http://lwn.net/SubscriberLink/409813/5ff58cc12efd02fa/ [15:09] ari-tczew: by convention, the person listed as touched-it-last on merges.ubuntu.com gets to merge it first. if you want to merge it, you should ask that person to ensure that you aren't duplicating work. otherwise, it's generally up to them to hand it off to somebody else if they don't want to do it. [15:10] so I'm not going to grab a package I'm unfamiliar with in the first few days of the release cycle unless and until the touched-it-last person says they can't do it (and even then, I have far too many of my own merges to do) [15:11] cjwatson: ok I'll ask with coolbhavi. btw. probably you have to merge a lot of reds packages from main? (MoM UI) [15:12] the installer always shows up as high on that list, since it uses the Priority field differently from everything else [15:13] I've already uploaded 34 merges, it's just that most of them are waiting in the queue until the toolchain's sready [15:13] *ready [15:13] aha === ivoks-af1 is now known as ivoks === ivoks is now known as ivoks-afk === Guest35464 is now known as Lutin [15:53] hi all, is there a plan for process isolation for apps installed from untrusted sources (ie, universe, propietary stuff from the software center)? [15:53] I've seen that iOS and sugar from the olpc already have something like this, using different unix users for each process. [15:55] alecu: I'm not convinced that the "mobile" model (as done by iOS and Android) is something desirable on Desktop systems. But there have been an acknowledgment of this issue in the recent disussion about application review board so it may be discussed at the UDS. [15:56] alecu, how would that work? programs need to able to read and write your files after all [15:56] johanbr, on android, the app has to request permissions to use your SD card, otherwise it has a partitioned off directory it's allowed to write to on the data partition [15:56] right, the main problem is that both iOS and Android were build from base with isolation in mind. [15:58] johanbr, right, they need to read some files, but surely not every file. [15:59] alecu, right, but how could you tell which ones? [15:59] maybe I'm weird and like to use acrobat reader to read pdfs stored in /usr/lib... [16:00] what are pdfs doing in /usr/lib? [16:00] johanbr, then you are an advanced user and may disable this kind of checks :-) [16:00] Chipzz: I only have /usr/lib/pymodules/python2.6/cherrypy/tutorial/pdf_file.pdf [16:00] alecu: then everyone is going to disable it the moment they encounter the first problem. [16:01] pitti: looks like a packaging bug to me ;) [16:01] *nod* [16:01] pitti: that should probably be in /usr/share/doc === jorge is now known as jcastro [16:02] alecu: one way to do it would be to force all applications to be shipped with apparmor profiles. But who's going to write them? It's not exactly an easy thing to do it right :) [16:02] kklimonda, perhaps have a (kinda restrictive) default apparmor profile [16:02] johanbr: but anyway, since pdfs are arch indep, they should go in /usr/share at the very least. a pdf in /usr/lib is a bug [16:03] it would require us to patch GLib and Gtk+ to provide useful error messages when software tries to access something it has no access to. [16:04] kklimonda, also, I would not trust apps from the moment they are being installed. I should not trust even the script that is run as root when the package is installed. [16:04] alecu: I don't know if apparmor has a "default profile" at all and how would that work? Applications have to access dozens of files outside of $HOME to work. [16:05] kklimonda, I don't mind those system files. [16:05] kklimonda, I'm worried about my personal files [16:05] kklimonda, it's the stuff in $HOME I want to protect [16:05] my keyring, my personal files. [16:05] not allowing universe apps to access $HOME sounds pretty useless, though [16:05] kklimonda: read access to /etc/* and /usr/lib/lib*so*, no access otherwise sounds sane I think? [16:06] alecu: right, it can be done already using apparmor (evince doesn't have access to keyring etc.) [16:07] I think there are a lot of small details concerning this, and I don't know enough about this, only that some systems are doing it in a safe(?) way. === james_w` is now known as james_w [16:07] so, I'm only proposing that if enough people is interested we may ask for a slot at uds [16:08] Chipzz: read access to all folders so file dialogs work as expected is also required. And some other things, you can take a look at /etc/apparmor.d/usr.bin.evince to see how could an application be locked in. [16:08] alecu: what systems? if you think about iOS and Android then it's not really the same. [16:09] I don't even know of Fedora have a SELinux in deny (or however it's called) mode by default. [16:09] kklimonda, I'm thinking about iOS, Android, sugar (as used in olpc) and web browsers. [16:10] so, any system that can run apps from an untrusted sources. [16:10] neither Windows nor Mac OS X has such a mechanism in place. [16:11] kklimonda, right, not yet. [16:11] sugar may be worth taking a look at as it's a linux distribution to some extent (isn't it?) [16:11] sugar is a user interface written in python that runs on top of linux [16:12] android also runs on top of linux but is a completely different beast so that description is misleading :) [16:12] kklimonda, btw: the designer of the sugar security mechanism is working at apple now :-) [16:13] kklimonda, right! I'm not saying we should use exactly the same mechanism that any of those uses [16:13] the question is how can it be done when we already have both a huge number of existing applications and full platform. [16:14] I would not worry about "how" yet :-) [16:15] I want to understand if this is really needed. [16:15] it si [16:15] it is even [16:15] My gut feeling being that we will be running more and more apps from untrusted sources. [16:15] indeed [16:15] and that I should only allow a very small set of apps near the more sensitive stuff (my keys) [16:19] right... I guess limiting access to some of the sensitive stuff should be doable (encryption keys, maybe browsing history, ...) [16:22] it's actually pretty complicated stuff - some application store passwords in gconf so you would have to be able to limit access to gsettings, same with desktopcouch.. === zyga is now known as zyga-dinner [16:28] I need to do some more reading on bitfrost and the security model of qubes... :-) [16:34] cjwatson: next case, ffmpeg-php exist in MoM, but package is up-to-date [16:34] smoser: pong [16:34] stgraber, so i'm pinging about a "desktop in the cloud" session [16:35] if you would be interested in helping to host one, and have interest in possibly doing something further with the -desktop images for natty [16:38] smoser: I guess it'd be nice if we can have someone to package properly either x2go or freenx for natty. Then we can make a good desktop image using it. [16:38] yeah. x2go is a mess. i poked around the other day just trying to find source. [16:38] robbiew: rickspencer3: davidm: davidbarth: pgraner: Riddell: jiboumans: ara: we are running the scheduling script today [16:39] smoser: it'd probably be interesting to host a session like that, hoping to find someone with interest and time to do the packaging [16:39] the more blueprints you accept before EOD today the less manual scheduling you will need to do [16:39] and i know you mentioned it not really building from source. [16:39] jcastro, what's the script for? [16:40] it will autoschedule all the sessions you've accepted in the grid [16:40] after that you have to drag them on there yourself [16:40] smoser: yeah, it's a bit of a mess. I guess it builds fine on the developer's machine with all source packages unpacked in the same directory. Trying to build them individually doesn't seem to work at all. [16:40] which isn't hard [16:41] it's just an FYI [16:41] there is just so much potential for coolness there. [16:41] smoser: yep [16:41] especially with the added browser plugin [16:41] alright. [16:41] i'll add a blueprint stgraber [16:41] thanks. === beuno is now known as beuno-lunch === zyga-dinner is now known as zyga [17:02] jcastro: ok; oubiwann is concerned as well ^^ [17:10] cjwatson, do you know if there is any work to port debconf away from libgnome? [17:10] ideally it would use plain gtk only [17:12] cjwatson, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542175 [17:12] Debian bug 542175 in debconf "Port GNOME frontend to GtkAssistant" [Normal,Open] [17:12] cjwatson, https://bugs.edge.launchpad.net/ubuntu/+source/debconf/+bug/415038 [17:12] Launchpad bug 415038 in Baltix "port GNOME frontend to GtkAssistant" [Undecided,New] [17:12] cjwatson, is there any change you could take over this bug in natty? [17:12] or add it to your review list? === sconklin1 is now known as sconklin [17:15] ari-tczew: ffmpeg-php is on the sync-blacklist because of an .orig.tar.gz mismatch. I've removed the merge directory manually [17:15] seb128: nobody's working on it right now, but it probably wouldn't be horribly hard. I'll add it to my list === deryck is now known as deryck[lunch] [17:16] cjwatson, the bug has a patch so with some luck it's only reviewing and commiting [17:16] cjwatson, thanks ;-) [17:16] yeah, janimo's patch looks like a decent start [17:17] jcastro, you might want to hold off another day, but that is up to you. [17:19] seb128: (though just queueing up in the browser for now, as I'm trying to catch up on vast piles of e-mail) [17:20] cjwatson, (no hurry, but I would like to drop libgnome from the CD this cycle if possible and it's one of the remaining users) [17:20] seems we could at least drop the perl bindings easily === al-maisan is now known as almaisan-away === jj-afk is now known as jjohansen === BUGabundo is now known as BUGa_bday === beuno-lunch is now known as beuno === ivoks-afk is now known as ivoks [18:21] mathiaz: hey, I just had an epiphany about your seed cleanup voting/commenting app [18:30] bye guys. bday party === deryck[lunch] is now known as deryck [18:49] slangasek: did you tell me that a tool exists that draws upstart job dependencies? [18:49] kirkland: yes, but it turns out it wasn't very good [18:50] slangasek: bad enough to be useless, or just not very good? [18:52] kirkland, isnt that tool called Keybuk ? [18:52] * ogra_ac wonders about Keybuks drawing capabilities [18:52] SpamapS: shoot! [18:53] kirkland: bad enough that I didn't see any use in it; it doesn't distinguish between AND and OR dependencies, has no information about what generates various events except for the start/stop ones, and only graphs statically based on the files on disk - so isn't useful for analyzing anything that happens during an actual boot [18:53] kirkland: I hinted the author to to improve it along these lines, didn't get a response [18:54] slangasek: do you recall the name of the tool? i'd rather improve something than re-invent it? [18:55] ahs3: honestly, I don't think you'll lose much time re-inventing; but let me see if I can find it [18:56] slangasek: if you can't, no worries. i've sorta hacked something together already (but it ain't pretty) [19:01] does anybody know when $ does anybody know when $UBUNTU_MENUPROXY started showing up in the default user environment, and where it comes from? [19:04] mathiaz: so, the way you approached it was basically "identify which ones need to go" right? [19:05] SpamapS: yes [19:05] mathiaz: what if you turn it around and require everything to get at least one vote to stay? [19:05] SpamapS: well - things are pulled in automatically [19:05] SpamapS: because of dependencies/recommends [19:05] nobody wants to stick their neck out for something that might hurt others by removing, but I'm sure everybody has strong feelings for what they want to keep. [19:06] mathiaz: IIRC, it was mostly about the things that were seeded, not the dependencies that had been pulled in. no? [19:06] SpamapS: right - the thing is that the list of what is *pulled* in is short [19:06] SpamapS: it was mainly about the dependencies/recommends pulled in [19:06] ah [19:07] SpamapS: the goal is to clean up what's in main and really look why things are pulled in [19:07] yeah, same thing then [19:07] SpamapS: the actual list of packages we want is short and available from all the preseed files [19:08] if nothing else, have an up/down vote, and things with 0 points or less would be good candidates for close examination [19:08] also what was the feeling on comparing it to popcon ? [19:08] SpamapS: popcon is not a reliable source of information :/ [19:08] mathiaz: I figured as much. [19:09] SpamapS: the goal is more about identifiying recommends that could be dropped [19:10] mathiaz: ah, by simply moving them to Suggests ? [19:10] SpamapS: yes [19:12] mathiaz: so still.. I think any recommends that don't get votes up would be good to move to suggests. [19:13] SpamapS: agreed [19:13] SpamapS: now the thing is to identify which are recommends [19:13] SpamapS: and that includes going through the whole list of 300+ packages [19:14] mathiaz: rdepended_packages=$(apt-cache rdepends `list of seeded packages` | sort -u) [19:15] if package not in rdepended_packages and not in seeded_packages then recommended = True [19:15] * SpamapS would probably dump it into sqlite just to make it simple. [19:18] SpamapS: http://bazaar.launchpad.net/~mathiaz/+junk/get-server-pkgs/files [19:19] SpamapS: ^^ this is the script I've used to generate the list of srv packages IIRC [19:19] SpamapS: it uses the germinate output which has more info then apt-cache IIRC [19:19] SpamapS: especially to figure out why something has been pulled into main [19:20] SpamapS: http://people.canonical.com/~ubuntu-archive/germinate-output/ [19:20] SpamapS: ^^ has the complete chain for each package [19:31] pitti: My new icoutils SRU got rejected because it's in main, can you upload for me (just a simple backport of the maverick package is all it is) === bjf is now known as bjf[afk] [19:34] mathiaz: ah nice, ok well I just thought if that effort was going to continue in natty that we should look at how to get more data. === dapal is now known as hanska === hanska is now known as dapal === drizztbsd_ is now known as drizztbsd === cjohnston_ is now known as cjohnston === xfaf is now known as zul === almaisan-away is now known as al-maisan === JanC_ is now known as JanC === bjf[afk] is now known as bjf === al-maisan is now known as almaisan-away === ivoks is now known as ivoks-afk [20:51] sabdfl: when did you last spoke in an interview about the importance of a well working IRC Council? === dendrobates is now known as dendro-afk [20:52] sabdfl: it seems like you tend to delegate community related topics to other people and focus on new features instead. but i would be very curious about a few things that affect the _people_ [20:53] who are the underscore people? === dendro-afk is now known as dendrobates === almaisan-away is now known as al-maisan [20:58] sabdfl: mainly german people who use Ubuntu as this group is a tricky, as we have a history like no other country [20:59] * ogra_ac glares at GPenguin and wonders what he talks about [21:00] history is history, we all have it, we all share it, we all come from the same monkey, the same time ago [21:00] sabdfl: i think that i remember, that one of your driving reasons to start Ubuntu as project was, that Debian as a project suffered a lot from social problems. and to me, it seems like we are going there in the german community [21:01] and i am a bit helpless with the IRC Council and the Community Council who seem to underestimate the problem [21:01] no, Ubuntu is not a critique of Debian in any sense, but if I can help avert a social issue in the Ubuntu Germany community, let's talk [21:01] sabdfl: would you prefer a query or can we speak open here on channel? [21:03] I'm not sure what GPenguin's problem(s) is, but he was going on about germans in #ubuntu-irc earlier today too... http://irclogs.ubuntu.com/2010/10/14/%23ubuntu-irc.txt [21:03] highvoltage: i think sabdfl and me are adult enough to manage the conversation without your help [21:08] my main point is, that the english speaking community seems to have somebody in Jono Bacon who inspires them, who keeps them motivated and on track [21:09] and i think such a person is missing for most germans [21:09] somebody who holds up morals and ethics in the most social way [21:10] i think because of our history, we are tricky [21:10] and i observed that many newbies suffer from angry helpers [21:12] i think this is because most self organized channels recruit the wrong people who their access lists [21:12] people who "process" help requests quickly on the one side, but also people who dont understand the social side of everything [21:13] other nationalities dont seem to have this problem as much as we germans do [21:13] * ogra_ac doesnt see that problem as a member of the german community and someone who frequently is in #ubuntu-de [21:14] we dont need to count people for the moment [21:14] sorry, but i fail to see a single of the points which you talk about above in that channel [21:14] we can do that later if thats needed [21:15] ogra_ac: if you dont see a point then why do you join me? [21:15] … [21:16] GPenguin, well, you dont accept other opinions ? [21:16] ogra_ac: "i dont see your point" is not an opinion. is a disturbance [21:17] i just stated that i have a completely different view of the german community [21:17] ogra_ac: i missed that point, sorry [21:17] but we can take a poll later of how many people are happy and how many people are unhappy in the german community [21:18] (and just on a sidenote this conversation doesnt really belong into the ubuntu development channel) [21:18] for a start we can measure how often the term "troll" is used on that channel [21:19] ogra_ac: are you an ubuntu member or just a friend of one of the channel operators from #ubuntu-de? [21:19] ogra_ac: tell them i said hi [21:20] i am an ubuntu member and have several firends who are ... i have no idea if any of them is a channel operator in #ubuntu-de [21:20] i'm usually just lurking there and help out where i cn if i have time [21:20] as most of the other people do there [21:21] ogra_ac: thats nice. [21:21] and i fail to see any different behavior to other ubuntu channels i'm in [21:21] ogra_ac: so you had your point. thanks for sharing it [21:21] its usually friendly and helpful to all people in there [21:22] i know other people who have a different opinion about this. and this opinion spreads across many different IRC networks, that german linux channels are hostile [21:22] and i can prove it later when that is needed [21:23] i worked on this topic since march this year [21:23] GPenguin: either way, this topic doesn't belong on this channel, please take it elsewhere [21:23] ++ [21:23] highvoltage: yes, i am still waiting for feedback from sabdfl [21:23] ogra_ac: no need to donate karma, you can use /ignore === dendrobates is now known as dendro-afk [21:24] GPenguin, no, since i do work in this channel (like everyone else whi is actively speaking here) and i told you above that this conversation is offtopic ... i just expressed my agreement === dendro-afk is now known as dendrobates [21:25] ogra_ac: you can and you will have to use /ignore [21:25] ogra_ac: otherwise i get the impression that you try to troll me while i try to talk to sabdfl [21:26] back, sorry, was on a call [21:27] GPenguin: this is an open channel, about development, in which highvoltage is a leader [21:28] happiness for all is not always the goal in a group that wants to get something done [21:29] because sometimes folks show up that don't have the same direction in mind [21:29] the group then has to choose, between getting what it set out to do, done [21:29] or trying to keep those folks happy [21:30] have you raised your concerns with the irc council in an ameil to their list? [21:30] email, sorry [21:30] and beyond them, have you done the same with the CC? [21:30] that's the process [21:32] i wrote about 6 emails in total during the last 12 months. and the feedback was disappointing. exactly thats why i make some noise now, here and there. until the right people are looking into the problem that does exist. [21:35] everybody tries to ignore the problem [21:35] and thats alright if you guys do not continue to invite more and more people to IRC channels that cant handle the people [21:36] how would you describe the problem? [21:37] its a combination of personality problem ("i want to become a bastard operator from hell") and a burnout problem on the helper side [21:38] its not new people anymore who join the chat room, its somebody who is too stupid to handle linux, its somebody who is aiming to cause trouble (a troll), etc. [21:38] but its still potential contributors after all [21:40] more and more people use Ubuntu who need guidance and not just a quick "do this and that" [21:41] but the helpers on channel are not ready for that [21:43] i am maybe not the right person to suggest this, but i would try a whole different approach. i would make channels like #ubuntu and #ubuntu-de a welcome area only [21:44] people can get in touch with an advisor there and _then_ move on to specialized channels for support questions [21:44] and helpers move from channel to channel aswell to avoid burnout [21:45]