[00:10] Fujitsu: The leader of the EeeXubuntu thing seems to a a mysterious person: http://forum.eeeuser.com/profile.php?id=2298 [00:11] * Fujitsu grumbles at lucas. [00:12] Fujitsu: Why? I think Lucas has a point. [00:12] He does, but he made it sound like this was an officially sanctioned derivative. [00:12] Akin to Kubuntu, Xubuntu, etc. [00:13] * minghua has seen {,K,X}Ubuntu spin-offs in Chinese Ubuntu-related forums as well. "A new derivative" seems a very common attitude among Ubuntu user communities. [00:14] Fujitsu: Agreed on your point. Lucas should have made that more clear. [00:15] Don't forget the soon-to-be-announced {Eee}{k,x,ed,}ubuntu-Xmas-Edition ;-) [00:16] pochu: And then eeeXubuntu Xmas Edition CE. [00:17] Do we get a New-Year version as well? [00:17] minghua: why not? The more, the better ;-) [00:17] * pochu hides === cheguevara_ is now known as CheGuevara [00:39] * minghua starts gutsy->hardy upgrade. [00:39] * Fujitsu applauds minghua [00:39] * Fujitsu upgrades. [00:39] * StevenK doesn't. [00:39] Fujitsu: Already running gutsy? [00:40] I haven't upgraded for a couple of days. [00:40] "You have to download a total of 474M." Hmm. [00:41] Hm, is this another Flash security update that I see, or is it the same one? [00:42] Fujitsu: Ahh, I meant "already running hardy", but since you are talking about security updates, I assume you are running gutsy. [00:44] No, Hardy. [00:45] I see an Flash security announcement from Adobe on the 18th. [00:55] Fujitsu: same one iirc [00:59] imbrandon: nice specs! [00:59] * pochu envies your ram ;-) [01:00] UserInterfaceFreeze <- whoever thought of that, kudos to you! [01:01] when is universe freeze? [01:03] A couple of days before FinalRelease, probably. [01:05] heh [01:09] killer, did yall see this ? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457371 [01:09] Debian bug 457371 in dpkg "dpkg: please add the DEB_VARIANT build environment variable" [Wishlist,Open] [01:09] pochu: thanks [01:14] * persia wants "edit comment" in launchpad [01:17] persia: Would bug #80895 describe what you want? [01:17] Launchpad bug 80895 in malone "Give people five minutes to edit/delete their comment" [Undecided,Confirmed] https://launchpad.net/bugs/80895 [01:17] * jonnymind is away: sleeping [01:18] imbrandon: Nice! [01:18] Fujitsu: Yes. Preceisely. Thanks for the bug number (and for generally knowing all the Malone bugs off the top of your head). [01:18] * Fujitsu only knows a couple of bug numbers, but remembers the keywords in the summaries of most malone/soyuz bugs. [01:19] heh yea like the digg.com 2 minutes to edit the comment thing === cheguevara is now known as CheGuevara [01:21] * pochu was angry while he replied to a bug report and typoed FYI with YFI, which in fact made sense as he was angry... :-) [01:21] Luckily the reported didn't take it seriously but interpreted it as FYI... [01:27] Heya gang [01:28] Night bddebian [01:28] Hi pochu [01:28] Err gnight pochu :) [01:28] Hey bddebian. [01:28] Heya Fujitsu [01:39] * Hobbsee waves [01:39] Heya Hobbsee [01:43] ello Hobbsee and bddebian [01:43] mmm time for food [01:43] brb [01:43] Heya imbrandon [01:44] * persia cheers blueyed for fixing debdiff for native packages [01:45] You're welcome persia :) [01:45] hello Hobbsee [01:46] ...yay, motu ML [01:46] heya bddebian, imbrandon, minghua [01:46] Hobbsee: What on MOTU ML? I only see MC bother. [01:46] sorry, MC [01:46] they all go to the same filter on my inbox [01:47] Ah. Good. Two would have been too many :) [01:48] yeah well. [01:49] * Hobbsee should just resign or something. [01:54] Hobbsee: Why? Because of the MC decision? [01:56] My gutsy->hardy upgrade claims firefox and openoffice.org as obsolete after the upgrade and offers to remove them. Curious. [01:56] What'd I miss now? [01:57] bddebian: A spat about specific vs. general in terms of mechanisms to ask someone disruptive to stop, and what to do when they don't. [01:58] Ah, I can guess who that was about [01:59] bddebian: That was the seed, but the discussion has moved into other, more pointless areas. That's the problem with multiple threads. [02:00] (not that Robert's Rules of order would work in email anyway :) ) [02:00] persia, I just checked the runghc bug and I hadn't received any notifications on email.. I am buiding with the changes... [02:00] should have a patch shortly [02:01] effie_jayx: Strange. Are you not subscribed to the bug? [02:01] persia, yesm I am . I found t odd myself [02:01] persia: :) [02:04] minghua: that, and wider issues related to that. [02:04] minghua: and the fact that i'm not doing uploads, etc, anyway [02:07] Hobbsee: It would be sad if you resign. But to be honest, I personally just care if you are still going to hang around on IRC or not. :-) [02:08] minghua: well, yeah. as for that, i don't know. [02:09] minghua: i can ignore all of MOTU if i don't hang out here, and unsubscribe from teh lists [02:25] wow intels new moble device looks alot like a ipod only bigger [02:25] http://images.appleinsider.com/silverthorne-071221-3.jpg [02:29] Good, nothing big seems broken after upgrading to hardy. [02:36] I did a small module for linux, I would like, when "make install" is called, that the module insert itself into "/etc/modprobe.d". What is the best way to do this ? (cp foo /etc/modprobe.d?) [02:38] Larose: dh_installmodules(1), perhaps. You can also ask in #ubuntu-kernel channel. [02:39] minghua: Thanks [02:40] No problem. [02:57] ok anyone semi familiar with licensing ( GPL ) , i'm not wanting legal advice but if someone knows about a link in lamens terms explaining the diffrences in GPL2 and 3 [02:57] * bluefoxicy stabs the 7.04 livecd [02:58] failsafe terminal [02:58] i have some new code i'm writing and would like to stick with GPL just not familiar with v3 at all [02:58] LOADING GNOME [02:58] stupid. [02:59] imbrandon: http://www.fsf.org/licensing/licenses/rms-why-gplv3.html might be part of what you seek. [02:59] cool /me looks [03:00] imbrandon: http://www.fsf.org/licensing/licenses/quick-guide-gplv3.html is likely some of the rest of it. Details are best left to careful inspection. [03:01] right, basicly i want to avoid the situation that if someoen is using gplv2 only code cant use mine, i would like them to be able to [03:01] infact in htis instance i might be better off with BSD or something [03:01] imbrandon: Then you have to license under "GPLv2 or any later version". GPLv3 code cannot be pushed into GPLv2. [03:02] imbrandon: For permissive, ISC is really nice. Gives more protection than PD, but doesn't block anyone. Don't use BSD unless you've had a discussion with the Regents. [03:02] ok v2 or later it is then, that was my major question [03:02] unix systems are awesome [03:02] the system is retarded [03:02] ISC and PD ? [03:03] imbrandon: http://en.wikipedia.org/wiki/ISC_license, Public Domain [03:03] i rarely write my own code so i'm not well versed in licenses :) [03:03] while true; do killall -9 $(ps -e | grep "$gnome|nautilus$" | awk '{print $1}'); done & [03:03] so much for I can't kill anything because something revives it. [03:03] bluefoxicy: Better to make it not be revived, no? That path leads to thrashing. [03:03] bluefoxicy: just kill all of X [03:04] imbrandon: i did that [03:04] then I logged in in failsafe Xterm session and it started Gnome [03:04] heh [03:08] * bluefoxicy also disables hal [03:10] ok persia quick question i think i understand but just makin sure, so if i ( or anyone but using *i* here to make the question easy ) release say a single c file program ( just to be the simplest as possible ) under gplv2 or later , only *i* can redistribute that as v3 or can anyone ? [03:10] * imbrandon thinks the latter but makin sure [03:10] imbrandon: Anyone. [03:11] imbrandon: Stepping back, what do you want from your license? [03:11] cool, ok , but at that point its effectively forked as the new code cant go into the v2 version [03:11] correct ? [03:11] imbrandon: Right. [03:11] imbrandon: I presume you want open source, and credit due. Do you want copyleft? If so, how strong? [03:12] really i want it to be as permissive as possible without theft [03:12] heh [03:12] bsd? [03:12] that's pretty open [03:13] imbrandon: For permissive, use ISC. For copyleft, GPLv2 is good if you don't mind someone selling a device with DRM to prevent using the modified code, or GPLv3 in most cases. In special cases, LGPL is appropriate (infrastructure code, deep libraries, etc.) [03:13] bderrly: BSD requires discussion with the Regents of the University of California. ISC gets all the same benefits, but avoids the discussion. [03:14] wha?! [03:15] what is ISC? haven't heard of that... [03:15] well since i'll likely at some point want to pull in others gplv2 stuff i'll stick with v2 or later [03:15] and i didn't know anything about discussing with the regents of ucb [03:15] bderrly: Basically, a cleaned up BSD without the specific references to the Regents of the University of California and a couple minor language changes to better match the Berne convention. [03:16] bderrly: Take a look at /usr/share/common-licenses/BSD to see why it matters. [03:16] there. Swap partition ELIMINATED [03:16] * bluefoxicy swapd [03:17] awesome, i didn't know about /usr/share/common-licenses/ [03:17] :) [03:19] ok last quickie for the night, is there a list of "current" ( being the opertive word ) Source: section fields for debian/control as of 3.7.3 ? [03:20] i'm guessing on the debian wiki somewhere [03:20] imbrandon: /usr/share/doc/debian-policy/policy.html/ch-controlfields.html [03:21] (assuming you have debian-policy 3.7.3 installed) [03:21] you rock' [03:21] yea [03:21] * persia thinks people should look in /usr/share/ more often. Lots of good stuff there. [03:23] * bddebian rm -rf'd /usr/share to save space ;-P [03:24] heh [03:24] * persia finally understands so much :) [03:24] Oh ouch.. :'-( [03:24] Good one though :-) [03:24] bddebian: Sorry. I couldn't resist that :) [03:27] s'ok, it was well deserved ;-) [03:50] persia: mind adding to this list http://paste.ubuntu.com/2918/plain/ on the -dev metapackage [03:51] can someone take a look at bug 150036 and sponsor it :D [03:51] Launchpad bug 150036 in dillo "Dillo menu item should be in Internet category" [Low,Confirmed] https://launchpad.net/bugs/150036 [03:55] nxvl_work: i'll sponsor it [03:55] imbrandon: thnx :D [03:56] * nxvl_work *HUGS* imbrandon [04:01] nxvl_work: done [04:03] * nxvl_work *HUGS* imbrandon again === elkbuntu_ is now known as elkbuntu [04:18] imbrandon: On which list does that belong? [04:19] ? [04:20] imbrandon: persia: mind adding to this list http://paste.ubuntu.com/2918/plain/ on the -dev metapackage [04:20] no i mean sugestions for the depends [04:20] tot he -dev pacakge [04:21] how goeth those kde4bindings? [04:21] having issues with qyoto yet? [04:21] nah qyoto was fine [04:21] its the ruby mess thats killing me [04:21] ahh ya [04:22] you would dep on ruby, and it would tell you ruby wasn't installed? [04:22] yea lol [04:22] ya, same crap building from svn with amarok [04:22] i got it fixed i think [04:22] I think I had to go with 1.8 [04:22] yup [04:23] I need to make tty1-6 buffer a few thousand lines [04:23] btw who uploaded amarok last ,Rid*dell and apache*logger_ ask me to then like 20 minutes later someone else already had done it [04:23] I hate scrolling up to find an issue, and it doesn't make it all the way up [04:23] I don't know who did it, I seen apache&laggers name on it though [04:24] apachelogger_: who served you homey? :p [04:24] yea but he isnt core so couldnt have :) [04:24] speak up, or imbrandon and I go gangstah on ya [04:24] oh well no biggie, just was curious [04:24] when it happened, JR was zzZzzZzZzzzZ [04:25] this is sad, i can't remember families birthdays, but I can remember uploads and versions [04:25] I need a life [04:25] imbrandon: 1) s/Pre-Depends/Depends/, 2) s/(= ${binary:Version})//, 3), s/devscripts//, 4) s/pbuilder//, 5) s/subversion/subversion, \n cvs, desktop-file-utils, debian-policy, lintian, linda [04:26] k [04:27] pbuilder is Recommends: and devscripts is Depends: of ubuntu-dev-tools. [04:27] right [04:28] desktop-file-utils ? [04:28] i'm guessing for .desktops [04:28] imbrandon: Right. It's default for Ubuntu/Xubuntu, but not for Kubuntu. Maybe Recommends: [04:29] Also, for meta-packages, consider doing everything as Recommends: so that people can push things if they don't like them. Even apt-get does Recommends-by-default for metapackages. [04:29] ahh i dident know that [04:29] the -by-default [04:30] * persia may be mistaken: last review of apt source was > 6 months back [04:36] * Fujitsu wonders why the Janitor now does changelog-closes-bugs messages. [04:37] * minghua noticed that too. === bigon is now known as bigon` [04:46] i have a doubt on Bug 178046 [04:46] Launchpad bug 178046 in dillo "dillo failed to unpatch" [Undecided,New] https://launchpad.net/bugs/178046 [04:47] is better to change the patch or the rules? [04:47] nxvl_work: Likely the patch. [04:47] its a weird patch [04:47] The rules appears to be trying to unpatch, but the patch doesn't unpatch cleanly. Something is odd. [04:47] it removes some files [04:48] --- dillo-0.8.6/ABOUT-NLS 1970-01-01 09:00:00.000000000 +0900 [04:48] +++ dillo-0.8.6-i18n-misc-20070916/ABOUT-NLS 2006-05-16 01:21:07.000000000 +0900 [04:48] nxvl_work: Not just set to zero bytes, but remove? [04:48] and under this there are only + sentences not even one - [04:49] nxvl_work: That appears to be creating a file. [04:49] and isn't it deleting ABOUT-NLS? [04:50] mmm, that file doesn't exist [04:50] persia: is there any way to check in what point is it failing? [04:51] nxvl_work: Yes. Run the build manually (debuild -b), and check to see the status of the files at failure. I recommend running that in a chroot to not affect the rest of your system. [04:51] can it affect my system? [04:51] same output as on the report [04:52] nxvl_work: If you run debuild not in a chroot, the commands in debian/rules run against your current system, and you must have all build-dependencies installed. Once you've run debuild, go look at the status of things: maybe there will be some .rej files to help you understand how the patch failed. [04:53] yep [04:53] there is many .ref files [04:56] what am i looking for on this rej files? [04:58] nxvl_work: The .rej files show you what hunks of the patches couldn't deapply. This may help you to understand the issue. In the worst case, you might need to repack the patch. [04:58] mmmm [04:58] there are many + and - sentences [04:59] so, those can't be applied? [04:59] nxvl_work: looks like they cannot be de-applied from the report. [05:00] mmm === rob1 is now known as rob [05:00] im not understanding i will google for rej files to understand them better [05:00] thnx for pointing me to them :D [05:05] maintainer notified [05:11] nxvl_work: Huh? We don't really have maintainers. Better to patch the package to not have the bug, no? [05:11] persia: the Debian one [05:11] Pbuilder's command line is really fragile. A leading space in the --mirror option gives cryptic error messages. [05:12] nxvl_work: We've passed DIF, so pushing the work to Debian doesn't help as much anymore. Much better to fix it, and send the patch to Debian for later reference. [05:19] yep [05:19] i think so too [05:19] but maybe he can help :D [05:19] i will give a look tomorrow, now i'm to tired [05:19] O_o [05:19] What at packages.qa.d.o? [05:19] *ate [05:20] Fujitsu: huh? [05:20] nxvl_work: Maybe. In these cases, best to try to duplicate in a debian chroot, adn if you can, just file a bug in the BTS rather than emailing a maintainer. [05:20] Fujitsu: New look for a new age? [05:20] It's so bright and LP-like. [05:20] persia: i have a debian system on a VM and it's there too [05:20] IIRC [05:21] nxvl_work: Great. Did you file a bug in the BTS? [05:21] let me recheck [05:21] i'm unsure [05:22] why it shows me that error the 2nd time i run it, is there any difference between the 1rs and the 2nd? [05:22] nxvl_work: The clean rule doesn't properly restore state. [05:23] More generally, running debian/rules clean should return the package to the same state as it was when it was originally unpacked, assuming no manual adjustment of files. [05:24] yep, exactly same error, reporting [05:24] oh! so it is patching it, but no unpatching at the end? [05:25] nxvl_work: OK. Please note that using the BTS to report bugs in Debian is the best way to tell the maintainer about an issue. A fix may benefit Ubuntu, but a Debian maintainer generally prefers to get information about Debian in the BTS, rather than direct email, and usually prefers to only get BTS reports for things that would improve the package in Debian. [05:28] unless you're sneaky like me and bundle some Ubuntu-specific changes in with some other patches [05:28] * Fujitsu wants some of the crack that the first responder to Debian bug #453620 is on. [05:28] Debian bug 453620 in qmail-src "qmail under public domain" [Important,Open] http://bugs.debian.org/453620 [05:28] * persia thinks slangasek gets a special pass [05:30] Fujitsu: Perhaps having a package in non-free has a special feeling for some people? [05:30] Hah. [05:31] * Fujitsu notes we should probably push qmail to universe, though with 44 Debian revisions there could be something nasty there. [05:31] persia: I don't think it's a special pass, I'm just Cunning :) [05:31] 44? I thought qmail was previously under a "do not modify" license. [05:32] I find it strange too. [05:32] slangasek: Maybe. I still think you have a special "yes, that is the way to do it" certificate that makes it easy. Anyway, wouldn't you prefer a BTS entry asking you to be sneaky than private email? === ubiq__ is now known as lucid === rob1 is now known as rob [05:35] persia: oh, yes, absolutely it should go via the BTS [05:35] persia: even if the package maintainer is willing to accept patches by other means [05:35] nxvl_work: That'd be the Voice of Authority speaking on the matter :) [05:38] persia: Ahhh, I see. Debian can modify it because they only distribute source. [05:40] Fujitsu: Ah. That might make the maintainer correct that it doesn't apply to the qmail-src package then. On the other hand, a qmail package might be nice. [05:41] The qmail source package only builds the qmail-src binary, but could probably now build qmail, right. [05:42] Fujitsu: Well, maybe. It depends on the patches. It might need a fresh download of the PD stuff, and then cherrypicking of the acceptable patches into the tree (perhaps involving license verification). [05:43] Still, it's not as trivial as just moving it to main (and thereby syncing to universe). [06:00] * Fujitsu wonders what Kubuntu's lack of LTSness means to upgrades. [06:04] So not only do we have Dapper's Canonical-sponsored-LTS main and the community-driven-LTS universe, but also non-LTS subset of main... Yay. [06:06] Does that also mean the only supported upgrade path for Kubuntu dapper will be dapper -> edgy -> feisty -> gutsy -> hardy -> ... ? [06:07] :-D [06:07] That is what I was asking with my first question. [06:07] And are we supporting Dapper->L* for Kubuntu? [06:08] Fujitsu: yes. But there is also hardy -> next LTS upgrade. [06:09] One could presumably upgrade Dapper->Hardy, as upgrades are tested. [06:09] But once on Hardy, you can't safely get to L* [06:09] As that will be released after support ends. [06:09] L* being the next LTS? [06:09] Assuming a 2-year gap as seems to be the standard. [06:10] h -> j -> k -> l -> m, shouldn't that be M*? === LifeHacker is now known as tuxmaniac [06:10] Ah, I missed I. [06:10] Heh. [06:10] * minghua can't recite alphabet. :-( [06:11] * minghua blame physics' convention of skipping vowels when choosing letters as super/subscripts. [06:12] Haha. [06:12] * Fujitsu thinks that any LTS deployments of Kubuntu are going to be in a bit of trouble. [06:16] * persia wonders where the "official no LTS for Kubuntu" announcement can be found. [06:16] persia: I found it linked from Planet, with a reference to the kubuntu-devel ML. [06:17] * Fujitsu digs up a link [06:17] https://lists.ubuntu.com/archives/kubuntu-devel/2007-December/002066.html [06:20] Hmm. I read that differently. Looks to me like 8.04 dual KDE3.5 & KDE4, with KDE4 being normal LTS, and 6.06 users being encouraged to upgrade to KDE3.5. I'd think it could be solved by providing a KDE3.5 -> KDE4 migration wizard to be applied at some point prior to the 8.04 -> 10.04 upgrade. [06:20] No, read the followups. [06:22] nixternal: Why is there an unfinished merge .changes in your latest sync bug? [06:22] cuz I forgot to dch -e when I was teaching....bad teacher ey? [06:22] hey, at least I taught him to dch -e though, but I didn't listen [06:23] The unfinished bit was extra - why is there a merge .changes at all? It's a bit odd... [06:24] * persia is vaguely unhappy about the marketing efforts of a single sponsor having an influence, but doesn't do LTS deployments anyway, so stops worrying about it. [06:24] hrmm, ya...I copied changes..just noticed that [06:31] * Fujitsu is thoroughly confused on how this will all be handled. main is defined by support from the Canonical security team, but after 18 months much of it won't be... upgrades are problematic... [06:32] Hi all! [06:33] Fujitsu: From what I read on the list, it's just a matter of branding for Kubuntu, from the marketing team, and a complete lack of upgrade testing 8.04 -> 10.04. Security should still be about the same, I'd think, especially as Ubuntu LTS users may well install kdebase for whatever reason. [06:34] persia: So it's LTS in some ways, but not others. These are yet to be properly defined. Great. [06:34] Fujitsu: It's LTS except that it's not called LTS, and the kubuntu-devel team doesn't expect to be chasing non-security SRUs after 18 months would be my gloss. [06:35] * persia is not a Kubuntu developer, and so any statements are necessarily interpretive, and may not reflect any known reality [06:36] * Fujitsu pities people who accidentally install KDE packages on LTS releases, and get themselves broken systems on upgrades that look to be supported. [06:36] Argh... REVU still down? [06:36] warp10: I believe so; the server it is on seems to have died. [06:37] warp10: Looks that way :( The admins have been notified. [06:37] And I'm not sure anybody has physical access at the moment. [06:37] * persia suspects the hosting university is closed for the holidays [06:37] It seems a bunch of things are uninstallable, care of libgif/libungif fun. [06:38] Too bad... ok, let's wait! [06:39] RAOF: Yep, the transition is partly done, and they conflict. [06:39] warp10: In the meantime, there's lots of packaging bugs available for consideration from https://bugs.launchpad.net/ubuntu/+bugs?field.tag=packaging :) [06:39] Since libungif is unmaintained, and libgif replaces it, should there be a nice mass-bug filed?_ [06:40] RAOF: Already done. [06:40] RAOF: There likely is. Which packages are left? [06:40] I think it has caught most of them. [06:40] Aaaah, there it is. At the bottom of the emacs22 bug list. [06:40] * persia only sees icedtea-java7-bin left for hardy AMD64 [06:41] persia: You obviously don't have emacs installed. Heretic! [06:41] persia: ty, bugs.launchpad.net/ubuntu is always in a firefox tag :) [06:42] RAOF: My data comes from `apt-cache rdepends libgif4` and is not related to the presence or absence of any specific packages. Anyway, I gave up on emacs years ago, in preference of telepathically adjusting the electrons. [06:42] * Fujitsu binds his vi into a nice arrow, and kills off RAOF. [06:42] persia: Wrong way. [06:42] We're going *to* libgif, aren't we? [06:42] Fujitsu: Ah. Right. [06:42] * persia goes off to play with grep-dctrl [06:42] bug #174252 [06:42] Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252 [06:43] Right. There we have it. It's just a build-dep swap? [06:44] * persia notes that the "affects" list in the bug report is rather short, considering... [06:44] persia: That should be all that is necessary. [06:44] * Fujitsu gets a list of sources. [06:45] Fujitsu: Explain why we don't need to do paul or mgp or mtpaint please :) [06:45] persia: I meant that to you `It's just a build-dep swap?' question. [06:45] s/you/your. [06:45] Fujitsu: OK. Sorry then :) [06:49] Has the library dependencies abolition effort gone far enough down-stack that it's worth updating these before imlib, etc. have been updated? [06:58] Quick question: Is there a way to refresh my group information after "addgroup minghua foo" without logging out? [06:59] minghua: start a new shell? [06:59] RAOF: Doesn't seem to work under hardy. I tried "bash -l" [07:00] You should have the right group information inside that shell, thoug? [07:01] Doesn't seem so: [07:01] minghua: Try a new terminal emulator with a new login session, or ssh to your bok. [07:01] $ grep "^src" /etc/group [07:01] src:x:40:minghua [07:01] $ id [07:01] uid=1000(minghua) gid=100(users) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),104(scanner),108(lpadmin),114(netdev),116(powerdev),118(admin),1000(minghua) [07:03] persia: Checked "run command as a login shell" in gnome-terminal's profile, quit gnome-terminal, relaunch gnome-terminal, nothing changed. [07:03] I swear the same thing worked in Debian before... [07:03] * persia tries [07:06] minghua: Odd indeed. I can replicate here. ssh works. [07:06] Aha. Thanks persia. [07:06] * minghua heads to malone. [07:07] Hmm, what package should the bug be against, though? [07:07] minghua: The very odd bit is that `groups` is supposed to be `id -Gn`, but `groups` provides the right data, even without reloading the terminal session (which is different than in the past). perhaps something related to PolicyKit or ConsoleKit? [07:08] Sup Peeps? [07:08] Any1 here? [07:08] persia: "groups" doesn't work here, gives the same output as "id -Gn". [07:08] !ask | BiG_ALLen [07:08] BiG_ALLen: Don't ask to ask a question. Just ask your question :) [07:09] minghua: Interestingly, running `id -Gn persia` provides the updated output. [07:09] Ah. [07:09] What do u do 1st when u start this game? [07:09] persia: Yes, yes, "groups minghua" works here, too. [07:09] BiG_ALLen: find a bug you like, and fix it. [07:10] * minghua straces id. [07:10] minghua: But that doesn't help the entitlements of the current shell :( [07:10] what does that meen...? [07:14] persia: I don't see anything related to consolekit in strace. [07:14] minghua: I was just guessing wildly. [07:18] * minghua is attempted to just report it against Ubuntu in general... [07:18] * persia suspects it may get lost in that case, or someone may tell you it's not a bug report. [07:19] minghua: Perhaps start with coreutils: anyone triaging bugs there ought to know better than we where it really belongs. [07:23] persia: Okay, since both id and groups are in coreutils... [07:23] minghua: That was my thinking [07:23] * minghua is skeptical that coreutils bugs gets more attention than general Ubuntu bugs, though. Let's see... [07:24] minghua: Likely less attention, but more likely to get attention by the right people. [07:24] BTW Debian's "general" bug is cc:ed to debian-devel list, therefore has a high visibility. [07:24] persia: Fair enough. [07:24] minghua: There used to be something like that in Ubuntu, but it was rejected as too much traffic before the migration away from bugzilla. [07:26] persia: Yes, it's just too easy to file general bugs in LP. [07:26] minghua: True. I realise I don't even know how to do that properly in the BTS (and no, don't explain, I'll likely never need to do it). [07:28] Heh. [07:36] Yeah, coreutils has two bugmail contacts. :-) [07:36] persia: bug 178059 if you are interested. [07:36] Launchpad bug 178059 in coreutils "Strange behavior after adding a user to a certain group" [Undecided,New] https://launchpad.net/bugs/178059 [07:37] Feel free to suggest a better description. :-) [07:40] minghua: That seems to sum it up. Let's hope one of the bug contacts has a better idea :) [07:51] nixternal: imbrandon: I actually thought Riddell did it ;-) [07:51] wasn't me, for sure [07:51] about time you spoke up [07:51] imbrandon is getting the bats right now, just for you :) [07:52] hahaha nixternal shush [07:52] Oo [07:52] I thought he crashed though before you get it finished or what not [07:52] oh well, imbrandon he admitted to it, so lets get um! [07:52] i was just curious, if i was *that* curious i could check hte sig on the changes file [07:52] :) [07:52] brb [07:53] arrr [07:53] <-- needs a coffee [07:53] it isn't "speak like a pirate day" [07:53] I will too, looks like I am pulling an all nighter [07:53] nixternal: @amarok it's always talk like a prite day [07:54] or 'use as many unknown words as possible' day [07:54] also, amarok2 isn't building in svn for me, fix it! :) [07:54] honestly [07:54] I wouldn't doubt if there is an issue with the deps on my desktop though [07:54] I didn't have time to build for the last week ;-) [07:56] nixternal: what error message do you get? [07:56] I can't remember...I will tweak it up a bit tomorrow [07:56] I guess I am staying up for this kubuntu meeting [07:56] 3 more hours until the meeting [07:57] Good, at least logout-and-relogin works... === \sh_away is now known as \sh [08:57] <\sh> moins [08:58] hi \sh [09:02] <\sh> now it's the best time of the year...no need to go to the office anymore...until 1st of Feb no need to do something for a living...and 5 Eizo FlexScan M1700 are waiting to be tested... === cassidy_ is now known as cassidy === minghua changed the topic of #ubuntu-motu to: Ubuntu Masters of the Universe: https://wiki.ubuntu.com/MOTU | Hardy Alpha 2 released. | REVU is offline | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com [09:51] My understanding is that REVU is offline because the machine is down. So I added that to topic. [09:52] It would be nice if someone sends an notice to the mailing list as well. [09:52] Are we firmly expecting to stay that way for a long time? I don't remember anyone saying it couldn't be fixed soon. [09:52] Well, it's still down. And it's been about how many hours? 8? [09:53] persia: Feel free to remove it if you like. :-) [09:54] minghua: I've no issues with it being there, just curious if there was any firm feedback from those with local access. [09:54] persia: ... or change it to something like "REVU is temporarily offline". [09:55] Personally, I'm not expecting much, given that it's housed in Germany, and this weekend is likely to be long and most people busy there. [09:56] persia / minghua : siretart is hte only one with physical access and he is aware its down but not sure on an eta for fixing it [09:56] s/hte/the [09:56] imbrandon: sistpoty doesn't have physical access? [09:56] <\sh> persia, siretart has [09:56] persia: He said he didn't. [09:56] persia: no they are at diffrent campusus iirc [09:57] imbrandon: yes, but I'm atm rather ill in bed, and I don't know when I make it next to the server room. sorry :( [09:57] Ah. Different campus. That makes sense. [09:57] siretart: no worries, i was just updating them on the situation [09:57] siretart: Please get better soon (and not for REVU). [09:57] it's the same campus, but sistpoty doesn't have access to the door for the server room [09:57] siretart: Sorry to hear that. Hope you can recover soon. [09:57] thanks! [09:57] :) [09:59] wow i' [09:59] m actualy able to run a vm [09:59]