[00:00] keisangi, this channel is for development *of* ubuntu, not *on* ubuntu [00:00] i tryed other distro, like zenwalk-linux (slackware based distro) and everything seems works [00:01] Seveas, yes, but i wont get any help on #ubuntu channel about this particular problem .. [00:01] keisangi, that doesn't make this a support channel [00:01] i don't know where to ask [00:02] !support | keisangi [00:02] keisangi: the official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org [00:02] Seveas, ok, could you point me to a support channel where i could discuss eclipse , java and ubuntu ? [00:02] #eclipse and #ubuntu come to mind :) [00:02] they will tell me to go to #lwjgl [00:03] #Eclipse will tell me to see with #ubuntu [00:03] everyone try to dodge the stinky problem ;) [00:03] well, #ubuntu it is then :) [00:04] i said two line earlier that #ubuntu ppl are likely to tell me to go to #lwjgl or #eclipse [00:04] (there's #ubuntu-java) [00:04] crimsun, ah nice [00:04] i try this one [00:04] thanks [00:04] crimsun: ooh you appeared! Could I bug you to sponsor another new transmission? [00:05] url? [00:05] bug #185292, [00:05] Launchpad bug 185292 in transmission "Please update to 1.02" [Wishlist,Confirmed] https://launchpad.net/bugs/185292 [00:11] jdong: ACKed. [00:13] crimsun: thanks :) [00:14] if it's in main, it's supported by offical devs right ? [00:14] what are "official devs"? [00:15] people with an @ubuntu.com address [00:15] All Ubuntu members have an @ubuntu.com address; developers are a small subset of this group [00:16] oh what ? [00:16] what is an ubuntu member then ? [00:16] BlackDiamonds: http://www.ubuntu.com/community/ubuntustory/components should answer your question about main vs universe [00:17] And http://www.ubuntu.com/community/processes/ about members, developers, etc [00:30] Why is the ubuntu-devel mailing list moderated? [00:31] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html [00:36] Well, that does not help to explain why my post was discarded, dispite it seeming to match the criteria. [00:37] I will repost to -discuss. [00:38] lamby: I doubt it was discarded, probably just stuck in the moderation queue [00:39] I will repost anyway, I don't have the time to watch the archives to see whether it's accepted or not. [00:41] that reminds me ... [00:42] * LaserJock wanders off to look at the latest fun on -discuss [00:59] does the Developer Sprint is taking place? [00:59] or this development circle there was no one? === nixternal_ is now known as nixternal [03:56] can someone help me with ver 7.1? [04:00] Can someone confirm/explain why sudo seems to forget environment variables? [05:19] can I confirm my own needs-packaging bug (185804) or does it need something else? [05:20] https://bugs.launchpad.net/ubuntu/+bug/185804 [05:20] Launchpad bug 185804 in ubuntu "[needs-packaging] BadRAM Linux Kernel Patch" [Undecided,New] [05:28] gQuigs: Packaging questions in #ubuntu-motu [05:29] oh..oops [08:47] Good morning [08:50] 'morning -.- [08:50] \sh_away: that looks like a gnome-vfs message, not sure where it comes from; maybe check with seb128? === \sh_away is now known as \sh [09:25] <\sh> seb128, the problem from yesterday was a result of nautilius -> preferences -> media_automount_open = True (gconf setting) this happens with all devices which are just mounted but not handled as special devices... [09:26] you told me that this key was set to wrong yesterday? [09:27] mathiaz: your patch in bug 52866 looks ok; can you please upload? [09:27] Launchpad bug 52866 in php5 "SOAP response for associative array is different on ubuntu 6.06" [Undecided,In progress] https://launchpad.net/bugs/52866 [09:27] <\sh> seb128, nope...I never said this...I was thinking something strange happens...and I tracked it down to this setting...set this key to False everything is fine...and only the symbols are on the desktop (despite the fact that some of them are staying on the desktop after unmount) [09:28] I told you to change the key in the preferences and you said you already did that and that didn't change anything [09:29] <\sh> seb128, this was the setting in System -> Preferences -> Removable Media which I disabled...but this didn't help...I think the preferences dialog comes from gnome-volume-manager or whatever we use, but not from nautilus [09:30] <\sh> seb128, the real solution is to set the nautilus gconf key to false... [09:31] slomo: Thanks! [09:32] <\sh> seb128, as far as I could track down the problem (reading gnome-volume-manager source and nautilus-application.c) those two are involved when mounting devices. gvm handles special devices like usb/ipod/cd/dvds but not e.g. /dev/sdb3 when it's mounted manually... [09:33] \sh: the key you describe is the one I told you to change yesterday [09:33] \sh: it's the browse media when inserted in the nautilus preferences, media tab dialog [09:34] \sh: I just verified it does change the gconf key [09:34] <\sh> seb128, well then I didn't understand you correctly...I meant the global preferences for media [09:34] alright [09:35] but I wrote that it was the nautilus dialog [09:36] <\sh> seb128, then I didn't see "nautilus" ... after so many windows popping up [10:02] dholbach: Alter! [10:03] pitti: ALTER! [10:03] dholbach: do you know what p-lp-bugs does when a bug has multiple source packages? [10:03] dholbach: i. e. bug.sourcepackage [10:04] pitti: I find it more accurate to look at all bug tasks and see what their bug status, source packages, etc are [10:04] pitti: bug.infotable [10:04] dholbach: right; can I iterate over all of them? [10:04] aah [10:04] pitti: for task in bug.infotable [10:04] rock'nroll [10:05] pitti: you can branch http://people.ubuntu.com/~dholbach/sponsoring/ for an example [10:05] cool, looking at it right now [10:35] dholbach: rock, it works, I just wrote a pitti-o-matic-sync-bug-bitch script [10:40] pitti: party on [10:41] moin [10:41] pitti: would gvfs cause gnome-mount to have issues? [10:42] davmor2: why should it? [10:42] davmor2: unknown ATM, but it worked fine for me yesterday [10:42] davmor2: --verbose? [10:42] davmor2: gnome-mount doesn't use gvfs yet [10:42] I've updated my main system to hardy as I no longer need a stable system so I can play [10:44] I was putting my favourite cd's back into rhythmbox and gnome mount kept giving me errors bug 185748 [10:44] Launchpad bug 185748 in gnome-mount "gvfs/gnome mount issues with stability" [Undecided,New] https://launchpad.net/bugs/185748 [10:44] I took a screenshot it's on there [10:45] also the cd would lock up about 3 cd's in [10:46] davmor2: how a cd can lock up 3 cds? [10:46] I'm not sure I understand what you describe [10:46] sorry the thirdish cd would lock up [10:47] no idea about that [10:47] is that data or audio CDs? [10:47] rhythmbox converts the cds to ogg on the thirdish cd it would just stop at some point I would have to restart the system to free up the disc again [10:48] davmor2: doesn't seem to be a gnome-mount issue, rather a nautilus one [10:50] seb128: It also happens with my usb pen. so much of the data copied across fine then it just stopped. This didn't happen on my test system when gnome-vfs was inplace. [10:51] locking up that is (sorry not clear again) [10:51] looks like a gvfs or nautilus bug [10:51] do you get the issue using gvfs-copy ? [10:52] I had no issues using sftp in nautilus to copy the files I wanted off my other machine rather than trying from the usb [10:58] seb128: How and I'll try it? [10:59] I'm triaging casper bugs, and I have found one that referrs to xforcevesa. This doesn't appear anywhere in casper, so what package takes note of this kernel command-line flag? [11:00] davmor2: dunno what you are copying, but it's basically "gvfs-copy source destination" [11:00] seb128: np will try now [11:17] \sh: please use standard requestsync in the future, and be more accurate about the source (dcc isn't in unstable, etc.) [11:18] <\sh> pitti, ah well, you commented on it, that it was moved in the past [11:19] seb128: gvfs-copy command not found ? [11:19] <\sh> pitti, and that you wanted to move it into multiverse [11:19] davmor2: sudo apt-get install gvfs-bin [11:20] dialign-t-doc is in Debian non-free because documentation is missing source. It must be synced in multiverse, right? [11:21] \sh: done that, and synced [11:21] warp10: if section on control is non-free, it automatically goes to multiverse :) [11:21] <\sh> pitti, thx :) [11:21] seb128: right installed but it can't recursively copy a directory [11:21] Kmos: ('automatically' is not quite true...) [11:22] warp10: that doesn't sound quite right [11:22] warp10: it would be in non-free because the doc has a non-free license [11:22] warp10: if it was gpl with no source, then it is unredistributable and can't go to non-free/multiverse either [11:23] pitti: the sync script doesn't check for non-free and contrib ? i think it did =) [11:23] pitti: well, according to debian/copyright it is released under LGPL, but source is not available. I check it with debian maintainer too, his answer was: "dialign-t-doc is in non-free because it is missing sources" [11:24] warp10: that's wrong then, and it should be removed from Debian [11:24] seb128: I'm trying the individual tar.gz file it seems to lock up on instead [11:25] what do you mean? [11:25] pitti: wow, too bad! Well, I'll avoid to request a sync in Ubuntu, therefore [11:25] pitti: pdfedit works too :) [11:26] persia: not the prefered form of modification [11:26] pitti: I disagree that that is always the case, having used pdfedit to generate new files in the past, but suspect you are correct in this case (and the vast majority of others). [11:27] seb128: I have a folder full of tar.gz files that I backed up (evolution etc) I can't copy the folder so I'm coping the file where it seems to lock up. [11:29] davmor2: "lock up" = hang? [11:30] yes sorry [11:30] use the --progress option maybe to know if it's copying [11:31] seb128: It's hanging again and I can't access the pen drive now [11:31] looks like a gvfs bug then [11:32] is there any wat I can help find out what? [11:32] ps ax | grep gvfs ? [11:32] UUOps ;-) [11:33] pgrep -l gvfs [11:33] ion_: ? [11:33] ion_: what is your point there? [11:34] Nothing serious. Just repeating the popular UUO* meme. [11:34] 10823 ? D 0:00 gvfs-copy /media/disk/docs-backup.tar.gz /home/davmor2 [11:34] what is UUO? [11:35] cat foo | wc -l UUOC! wc -l foo (Useless Use Of Cat) [11:35] seb128: If I reboot and try the --progress will that tell me where the hold up is? [11:36] http://www.catb.org/jargon/html/U/UUOC.html [11:36] ion_: ah, didn't know about that, learning every day ;-) [11:37] seb128: I noticed too that the trash applet isn't showing trash any more either it is in the folder [11:37] davmor2: not really, no need to reboot, you can likely kill gvfsd [11:37] davmor2: known issue, will be fixed with the new gnome-applets tarball [11:38] okay thought it would be [11:39] the trash location changed, gio is using the freedesktop one [11:42] seb128: Just tried killing 10823 nothing happened. [11:42] Would it be possible to move /lib/udev/watershed to some directory typically in PATH? watershed is useful for many other things than just udev. For instance, i have /lib/udev/watershed a-podcast-fetcher in my crontab. [11:42] davmor2: try using -9? [11:43] seb128: no [11:45] seb128: I just checked system-monitor it says it's uninterruptible === Ubulette_ is now known as Ubulette [11:47] who maintains PHP in ubuntu? [11:47] Mez: server team (soren, dendrobates, keescook, some others) [11:48] Mez: mathiaz, too [11:48] ah, well, we've found an issue here :D [11:48] broken functionality :D [11:48] definately worth a patch for LTS, and hopefully for SRU too :D [11:49] can anybody tell me what /var/lib/dpkg/available is used for? [11:50] Mez: did you file a bug in LP ? [11:50] mathiaz, not yet - [11:50] we're getting it into upstream first (I work with one of the main PHP devs - he's fixing it atm) [11:51] Mez: excellent ! [11:51] mathiaz, :D It's a one line fix - but he's testing it [11:51] Mez: please file a bug in LP, and put a link to the upstream php bug and patch. [11:51] mathiaz, I will do :D though whether he creates a bug ... [11:52] BenC: can you please send me your hal debdiff, so that I can check it into bzr? [11:53] mathiaz - it's pretty rare, and has been there for 2 years at least [11:55] asac_the_2nd: Hmm NM just prompted me for a password it should have known about; perhaps because it couldn't associate and thought this might be because of a password mismtach [12:03] seb128: right rebooted so I can use my system again. How do you want me to file the bug and what against? [12:04] davmor2: open it against gvfs but I doubt we have enough informations to make anything useful from it at right now [12:07] is apt-get update; apitude safe-upgrade the same as aptitude update; apt-get upgrade? [12:09] seb128: no problem [12:09] aquo: No. [12:10] persia: uhhh. that is not good. [12:10] if i want to use aptitude for package management this interferes with the apt-get that is used in periodic scripts ... [12:10] (unattended-updates, cronjobs) [12:13] aquo: The difference isn't with "update", but with "upgrade". For details, check the source, or search for some of the early documentation on why aptitude. This isn't really the forum for longer discussion of the differences. [12:14] persia: so apt-get update and aptitude update produce the same system state? [12:15] i know that there are differences with the recommends on so on with aptitude ... [12:15] aquo: SImilar enough to not be worth discussion. I don't remember if it is the same. [12:15] i am just curious if the use of apt-get update in cronjobs needs to be replaced by aptitude update if i want to use aptitude. [12:16] aquo, in my opinion it is you can use anything you like apt-get, aptitude, dselect, dpkg, synaptic -- they all work on top of APT, and it shouldnt matter what you use [12:16] in apt: /etc/cron.daily/apt [12:16] seb128: bug 185904 is there any thing else you want adding to it? [12:16] Launchpad bug 185904 in gvfs "GVFS: Unable to copy tar.gz backed up data from pen drive" [Undecided,New] https://launchpad.net/bugs/185904 [12:17] so apt-get update; aptitude safe-upgrade is the same to aptitude update; aptitude safe-upgrade? [12:18] dpkg doesn't work on top of apt in my opinion [12:18] davmor2: having backtraces of gvfsd and gvfs-copy would be nice [12:19] aquo, safe-upgrade does not remove packages when situations warrant removing certain packages to upgrade others -- the aptitude manpage has more [12:19] seb128: how or wher do I get them? [12:20] un_op: i am not asking about the upgrade process, i am interrested in the update progress? [12:20] davmor2: https://wiki.ubuntu.com/DebuggingProgramCrash [12:20] unop: i know that [12:20] aquo> so apt-get update; aptitude safe-upgrade is the same to aptitude update; aptitude safe-upgrade? [12:20] aquo, ^^ no [12:20] oops [12:21] sorry misread [12:21] aquo, i'm inclined to say yes here [12:23] seb128: ta [12:23] you are welcome [12:25] unop: yes, apt-get update/aptitude update behave the same [12:25] unop: no problem, i am just curious on how package management works [12:26] mvo: so they are interchangeable, and i don't have to run aptitude update if i have the cronjobs that are included in apt [12:27] aquo, well, i used to think aptitude was a better apt-get (atleast when i was with debian) but with ubuntu, the line that seperates the two is somewhat different, essentially they serve the same purpose and are quite interchangeable [12:27] aquo: yes [12:28] unop: the only real difference left is that aptitude has a nice ui, a different problem resolver (and in ubuntu that it installs recommends-by-default) [12:30] thank you for that information. [12:32] mvo, yes, and autoremoves unneeded depenencies when a package is removed (something like apt-get autoremove ..) [12:32] ScottK2: stepic> hm, what's the purpose of this when the changes are machine detectable? isn't the purpose of steganography to hide data repudiatably? [12:36] thekorn: AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type' (https://launchpad.net/bugs/122396) [12:36] Launchpad bug 122396 in poppler "[apport] evince-thumbnailer crashed with SIGSEGV in CairoFont::create()" [Medium,Confirmed] [12:36] any idea? [12:37] pitti, not right now, but will check in a moment [12:37] thekorn: thanks a lot [12:37] unop: right, but the auto-remove information is unified [12:38] thekorn: ah, seb128 just mentioned that this happens with bugs which have an upstream task [12:38] mbiebl: hi, did you find some time to take a look at my nm 0.7 eni branch yet? [12:38] mbiebl: https://code.edg.launchpad.net/~asac/network-manager/main.eni [12:38] ups [12:38] ;) [12:38] hi, asac_the_2nd [12:38] i think you figure [12:39] pitti, ok, then it might be fixed in the .main branch [12:39] The current checkout doesn't compile... [12:39] I had a missinge eni-private.h something... [12:39] hmm ... let me see [12:39] which revision? [12:39] 2757 [12:40] eniplugin-internal.h that is [12:41] mbiebl: ok ... let me push the revision I used to build the preview package (i didn't include the system settings daemon yet) [12:42] pitti, it is bug 184594 [12:42] Launchpad bug 184594 in python-launchpad-bugs "AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type'" [Undecided,Fix committed] https://launchpad.net/bugs/184594 [12:42] Have you read my email, about getting the Debian and Ubuntu closer in sync again? [12:42] mbiebl: damn ... now i remember why i haven't pushed yet. that branch is locked for 68 hours. apparently that doesn't go away automatically [12:43] thekorn: ah, thanks [12:43] mbiebl: i am currently in uk and my alicedsl connection went down 30 minutes after i left my house ... can read it earliest this weekend [12:43] mbiebl: but yes, i am all for it ... i hope we can submit most patches we need for 0.7 upstream so we should be more in sync [12:43] asac_the_2nd: would be great. [12:43] thekorn: subscribed; I'll roll it out to the retracers once it's fixed in hardy [12:44] especially the sysv init related stuff is already in the Debian NM 0.6 package. [12:44] mbiebl: and we could review what we have and why you don't need it ... if you are interested. [12:44] Yeah, would be cool if we could discuss this. [12:44] mbiebl: https://edge.launchpad.net/~asac/+archive ... there is the 0.7 package we currently use to evaluate it [12:45] asac_the_2nd: Well, as people requested it, I had built 0.7 packages for Debian also, some time ago. [12:45] http://debs.michaelbiebl.de/networ-manager [12:46] mbiebl: https://code.edge.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.7 ... thats the packaging branch we have [12:46] I'll start this weekend to push this version to the pkg-utopia svn in the experimental branch. [12:47] asac_the_2nd: while at it, we had a short discussion on #pkg-utopia, about starting dbus earlier and stopping it later. [12:47] Something around S10/K90. [12:47] i have no problem with that ... we start nm at 26 or something for now ... [12:47] This would make it also possible to stop NM later during shutdown. [12:48] mbiebl: you need to bump soname [12:48] mbiebl: hmm ... now that i think about it ... do we need to stop it at all? [12:49] Well, think for the scripts in if-*.d/ [12:50] They wouldn't be run otherwise. [12:51] Another problem, that is currently nagging me, is how to handle network-manager upgrades. [12:51] mbiebl: will the new NM include features for running user-independent? [12:51] aquo: when its finished ... yes. [12:51] mbiebl: in which regards? restarting the applet? [12:52] No, the problem that the internet connection is dropped when you restart NM. [12:52] mbiebl: yes ... that will change once we have system connection support [12:52] Is a bit unfortunate if you upgrade a system via SSH ;-) [12:52] asac_the_2nd: don't think so. [12:53] NM will still tear down the connection on stop afaik. [12:54] mbiebl: hmm ... i haven't looked into lately, but we should really take care that this is not done anymore for system configured connections ... same for "tearing down at startup" [12:54] mbiebl: have you asked dan williams about his vision for this? fedora must have the same issue [12:54] What do you mean by that? [12:55] asac_the_2nd: fedora never restarts daemons on package upgrades ;-) [12:55] mbiebl: network manager does not only not stop interfaces if you stop it ... it also brings them down and up again if you start it. [12:56] You mean it tears down a connection configured via ifupdown? [12:57] mbiebl: yes it would ... but we don't manage those through nm in ubuntu (to workaround this issue) [12:58] So, you want to have ifupdown establish a connection and then hand it over seamlessly to NM or what? [12:58] mbiebl: but thats independent from ifupdown ... it will always bring all interfaces down it wants to manage on startup. to fix that it should introspect the route and interface state and if that matches the system connnection setting do not bring it down ... anyway, i somehow have the feeling that the multiple device support will make this go away. [12:59] mbiebl: no ... i want ifupdown to conflict network manager ... once it supports multiple devices [12:59] for now its just a workaround so people can still roam even though they have configured their wired connection through /etc/network/interfaces. [13:00] Hm, ok. [13:00] mbiebl: but the problem you want to fix (not down interfaces when stopping) is tightly coupled with the problem that it tears down interfaces at startup [13:00] asac_the_2nd: do you have use cases that describe the update of NM? [13:00] But if you want to conflict with ifupdown anyway, why use the rather hard to manage /e/n/i format for configuring the system-settings daemon? [13:01] mbiebl: for legacy reasons [13:01] people should just seamlessly use their old configuration [13:01] One problem I see is, that the ifupdown format is quite flexible. [13:01] and because its "the debian way" to configure things ... why to chage that? [13:02] aliased interfaces [13:02] pre/post up/down actions. [13:02] mbiebl: yes ... we won't be able to have a perfect mapping ... but covering 90% of the use-cases in the begginning should be enough imo. [13:02] How do you want to map that information to NM? [13:02] he rest is unlikely to use nm anyway [13:03] mbiebl: which information? [13:03] the actions you refered to above? [13:03] Well, just see the proposed configuration for wpa_supplicant roaming? [13:03] which uses virtual devices names. [13:04] and id_str in wpa_supplicant.conf [13:05] or mappings in /e/n/i [13:05] stuff like. [13:05] mbiebl: did you take a look at the eniplugin.c file? ... thats a pretty basic approach still, but we can improve that. you have example config for that use-case? [13:06] asac_the_2nd: here is an example http://pastebin.ca/871988 [13:06] mbiebl: ok i am pushing the latest now to a different branch ... given that the other is still locked [13:06] * asac_the_2nd looking [13:07] mbiebl: do you have the wpasupplicant file as well? [13:07] wpa_supplicant.conf contains different configurations which have an id_str, which matches the virtual device name. [13:08] mbiebl: is that a debian specific thing? [13:08] or upstream wpasupp? [13:08] http://pastebin.ca/871992 [13:09] /usr/share/doc/wpasupplicant/README.modes.gz [13:09] Read roaming mode [13:09] hmmm ... afaict it should map pretty well to the new configuration framework in nm [13:09] Not Debian specific. [13:10] the parse for that probably should be distribution independent though [13:11] asac_the_2nd: lemme check the sources, if id_str is really upstream or a Debian/Ubuntu specific patch [13:11] mbiebl: maybe we should write down the open points somewhere? [13:11] Agreed. [13:12] good [13:13] wpa_supplicant/config_ssid.h [13:13] id_str seems to be upstream supported. I'm not sure if other distros use a similar mechanism though to implement a roaming mode. [13:14] so the name in the iface line in interfaces has to mach that id_str right? [13:14] That's how it's implemented in Debian, yes. [13:16] sorry ... need to eat ... bbl [13:16] Ok, I'll write an email to you this weekend, with all the different points I have in mind. [13:17] Together with your input, we then should add this info to a wiki or something. [13:23] pitti: It's an extreme form of security by obscurity. [13:24] pitti: (stepic) [13:24] I think it's an interesting concept. [13:25] pitti: While you're doing archive stuff (hope you still are), I'd appreciate it if you would binary new libetpan in dapper-backports. [13:26] That's the last manual step in the clamav-0.92 transition in backports for dapper. [13:26] ScottK2: ah, looking [13:27] pitti: Thanks. The rdepens for it are already sitting in depwait for it, so there's no further rebuilding. [13:27] rdepens/rdepends [13:32] what version kernel does hardy use [13:32] 2.6.24 [13:33] the rc based of 2.6.24 or the stable one that got released yeterday [13:33] right now its rc8 but its being rebased to 2.6.24 [13:35] does that mean hardy fiesty edgy and dapper will get 2.6.24 or are there kernels frozen [13:35] i meant gutsy not hardy [13:35] articpenguin3800: Only Hardy gets a 2.6.24 kernel [13:35] ok [13:36] mbiebl: great .... then lets get things going :) [13:37] zul: rc8 is over.. it's now 2.6.24 final :) [13:37] asac_the_2nd: nice talking to you! [13:37] mbiebl: i pushed the latest: https://code.edge.launchpad.net/~asac/network-manager/main.eni1 [13:37] asac_the_2nd: about the soname bump: this should be done upstream imho. [13:38] yes ... thats why i committed it to that branch [13:38] asac_the_2nd: will you contact dcbw about that? [13:38] Kmos: dude, learn to read please. [13:39] yes ... i will send it upstream. we just needed it now to package it decently [13:39] i think this weekend or latest on monday [13:39] Kmos: if you'd actually read the changelog, and read what zul said, you'd know that ubuntu's kernel is currently at rc8. [13:39] asac_the_2nd: great [13:40] pitti: Thank you. [13:40] Hobbsee: i found it :) [13:40] Hobbsee: lagged.. 30 secs [13:40] * Kmos jesus! [13:43] Kmos: how is your lag relevant? you clearly responded to zul said, and the new linux metapackage was published hours ago. [13:48] * Hobbsee checks the email about Kmos [13:50] * Hobbsee notes that adding stuff in here is classed as contributing to ubuntu development, which is one of the things that kmos has been asked not to do. [13:50] * Hobbsee therefore will prohibit him from doing so. [13:52] asac_the_2nd: The debian/ directory in 0.7 still contains a lot of 0.6 cruft (nm-vpn-properties, which is no longer in NM, outdated copyright files) etc. [13:52] asac_the_2nd: I'll work on the debian/ directory during this weekend and will do a thorough cleanup. [13:53] mbiebl: are you talking about the ubuntu package? [13:53] yeah. [13:54] Hobbsee, is that really necessary ? [13:54] What I wanted to propose is, that I'll look after debian/ and you can concentrate on the eni plugin. [13:54] mbiebl: yes, there might be cruft left. it was an initial release for evaluation here [13:55] I'd like to get the contents in debian/ in sync again as best as possible. [13:55] mbiebl: great .... i have two more commits here [13:55] ogra: as far as i know, not contributing to ubuntu development actually meant just that [13:55] which includes talking crap in channel [13:56] * ogra heavily disagrees [13:56] mbiebl: i am fine with sharing workload that way. [13:56] ogra: i can quiet him if you wish [13:56] Hobbsee, obviously you manage to ignore other people that talk crap ... [13:57] asac_the_2nd: are you fine to name the init script /etc/init.d/network-manager and /etc/init.d/network-manager-dispatcher? [13:57] Hobbsee: just relax a little... [13:57] ogra: Other people haven't been told by MOTU Council to desist. [13:57] That's how I had already called them in the Debian 0.6.5-1 package? [13:58] ogra: true, but they don't talk crap for months, and they don't get a mandate from the MOTU council to stop contributing to ubuntu development. [13:58] ScottK, thats not relevant here [13:58] ogra: how is it not relevant? [13:58] ogra: it's entirely based off that decision [13:58] being rude and kicking people *is* relevant though [13:59] mbiebl: i would be fine with that ... however the upstream tree ships NetworkManager (no Dispatcher though) ... anyway, whatever we do, we should submit it upstream [13:59] ogra: sorry, i'm not seeing where i'm being rude - i'm seeing where i'm saying a statement of fact. [13:59] Well, init scripts is a thing I usually don't submit upstream. [13:59] As every distros uses their own anyways. [14:00] yeah .... then we should ask for removal :) [14:00] asac_the_2nd: ;-) [14:01] that kernel comment was probably not right, but it was definitely ignorable [14:02] dholbach: am i wrong in thinking that "being asked not to contribute" and contributing, correctly or not, still should be forbidden? [14:02] we've kicked diots from the channel before [14:02] dholbach: Sure. It's all ignorable, but if the MC decision isn't going to be enforced, what value does it have. [14:03] dholbach: last i checked, doing what you say is actually a good thing [14:03] it's not all black and white, is it? [14:03] he did not file a sync request or anything, just offered a comment to a discussion [14:04] dholbach: The MC's decision seemed to draw a pretty clear line. On this channel you are either contributing to Ubuntu development or off topic. [14:04] dholbach: because its not on malone its not disruptive? That seems to be what you are saying [14:04] sorry, clicked on the wrong button [14:04] [01:03] it's not all black and white, is it? [14:04] [01:03] he did not file a sync request or anything, just offered a comment to a discussion [14:04] [01:04] dholbach: The MC's decision seemed to draw a pretty clear line. On this channel you are either contributing to Ubuntu development or off topic. [14:04] [01:04] dholbach: because its not on malone its not disruptive? That seems to be what you are saying [14:05]