[00:01] kirkland: thank you [00:06] sponsoring stuff is fun [00:06] :D [00:08] so is guitar hero [00:10] Hm. update-grub seems to have eaten my grub.cfg. Yay. [00:12] to sponsor a sync [00:12] i need to ACK it and suscribe ~ubuntu-archive, don't i? [00:12] Yup. [00:12] and set it to confirmed === Kopfgeldjaeger is now known as Kopfi|offline [00:13] and unsubscribe u-u-s! [00:13] Laney: that's the first thing i did [00:13] Always with the unsubscribing, yes. [00:13] :D [00:21] !!! [00:21] Where did /boot go? [00:21] sorry, i was hungry [00:22] This is probably why grub-probe is somewhat confused. === superm1 is now known as superm1|away [00:25] You know, I should probably merge grub-pc if I'm gonna use it; it seems debian's newer snapshot is full of "please don't die" bugfixes. [00:29] Oh. I think I know what ate my /boot. Stupid parallel fsck! [00:29] * wgrant spits out /boot's bones. [00:30] Nothing says "I love you" more than having a mount point not exist every now and then. [00:42] I have "intltool-update.in -> /usr/share/intltool/intltool-update.in" in a couple of packages, which fail to build in Intrepid as that file is not available, even in the intltool package, has anyone else seen this? [00:43] anyone know where they went? === asac_ is now known as asac [00:46] james_w: I believe that's a change in the new intltool. [00:47] james_w: I hit that packaging Do; I believe intltool would now like to be run as a part of ./configure [00:50] how nice for it [00:50] isn't it a little bit late in the day for intrepid for intltool to break everyones' packages? [00:51] RAOF: thanks, do you know what I need to change? [00:52] it's ./configure where it bombs out [00:52] kirkland: your ecrypfs r0cks. i fixed my system problem [00:52] now work very nice. [00:52] emgent: thanks, dude. what was your problem? [00:52] james_w: From memory, with Do I acually added the intltools stuff to configure.ac and re-autogen'd [00:54] kirkland: in the first step i dont put same password in login and ecryptfs, after that more problem (you know). i removed all an i start new clean setup. now work fine. [00:54] emgent: very good... i wonder if i should improve the documentation/prompts somehow? [00:55] i wish there were an easy way for me to validate that password [00:55] kirkland: documentation is very good, you wrote (add same login system password), It was my mistake [00:55] emgent: okay, thanks [00:55] kirkland: no thanks to you! :) [00:57] kirkland: do you have a launchpad branch for ecryptfs ? [00:58] emgent: no, it's managed in git.kernel.org [00:58] i'm asking about tool [00:58] ecryptfs-setup-private ecc.. [00:59] emgent: i have passed ALL of the code I've written to the upstream ecryptfs-utils project [00:59] okkay great! :) [00:59] emgent: http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=summary [01:00] emgent: i send my patches to the mailing list, and Mike applies them [01:02] http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=blob;f=src/utils/ecryptfs-setup-private;h=1aa6bf56ca5f88a41be8bd68903166b87c63f337;hb=HEAD [01:02] yeah nice work, thanks kirkland ! [01:03] emgent: that's it :-) [01:03] emgent: i think i'm going to add a check, if you've previously run ecryptfs-setup-private, and if so, error out, and tell you that you have to use a "-f" option to force it [01:04] nice i can remove flashusb for .ssh .gnupg .mozilla-thunderbird and .mozilla [01:04] emgent: I also want to add a "--undo" option too [01:04] now i can use this stuff. [01:04] emgent: ;-) [01:04] very good :) [01:05] argh we are in -motu.. i think that we can switch to -server [01:05] we are OT. === superm1|away is now known as superm1 [05:33] moin [06:09] good morning [06:16] morning [06:52] nhandler: just worked thru your lesson. thanks. was great! (you explained the .patch files well. was missing that...) [07:04] moin [07:04] emgent, howdy mate [07:05] bhavi_: moin [07:11] heya gang [07:41] can someone from u-u-s look at the prboom sync request bug 231811 [07:41] Launchpad bug 231811 in prboom "freedom is a dependancy for prboom... but shouldn't" [Low,Triaged] https://launchpad.net/bugs/231811 [07:59] Hew: You should retitle the bug [08:00] Laney: Thanks, will do [08:00] Please sync () from Debian () [08:06] done [08:08] I've gotta head off now so I'll check on it later. Thanks again. === persia changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Intrepid open, go wild! https://merges.ubuntu.com/universe.html | QA targets available from http://qa.ubuntuwire.com | TODAY - Another day!! Keep working. | Next MOTU meeting: Fr, August 22nd 12:00 UTC === wolfger_ is now known as wolfger === kaminix_ is now known as kaminix === dholbach_ is now known as dholbach [12:47] hello I m getting this error please help http://pastebin.com/f25de910 === Kopfi|offline is now known as Kopfgeldjaeger [12:58] coolbhavi, ./dhelp-0.6.12ubuntu1/debian/control at line 27: block lacks a package field <---- [12:58] did you change debian/control and erased the package field? [12:58] effie_jayx, no [12:59] coolbhavi, did you change anything in debian control? [12:59] Looks to me like the upstream makefile doesn't have a clean rule. [13:00] that shouldnt really matter, can you pastebin your debian/control as well ? [13:00] effie_jayx, yes a min please I ll paste it [13:01] effie_jayx, http://pastebin.com/d27eb5a04 <---- control file [13:02] coolbhavi: Remove the blank line 14. [13:02] * persia thinks we'll see a different error now [13:03] a min please [13:05] persia: he hasn't answered yet (almanah) but on debian mentors is a new revision with my manpage in it :\ [13:06] sebner: Progress is being made. [13:06] persia, you are a magician it worked! [13:07] persia: sure but this isn't the collaboration I want to see ;) [13:07] yeah :/ [13:11] persia: btw, nearly forgot to ask. any progress with qmasters? [13:11] uqm ^^ [13:12] sebner: Not at all. Thanks for the poke. I'll push the merge into Ubuntu, as Debian is frozen. [13:12] persia: kk :) [13:13] persia: wait, It needs an update to -8ubuntu1 [13:14] sebner: Indeed it does. Do you want to do that? [13:14] persia: sure ;) [13:14] persia: urgent? [13:28] persia: updated :), I'm off for now. Bad thunderstorm /here [13:28] sebner: Thanks. I've been organising my review queue today, and expect to push it. [13:41] Shouldn't intrepid be available to hardy's debootstrap? [13:42] ... at least in backports [13:45] mok0: It is as of 1.0.9~hardy1. [13:45] jpds: huh? I have 1.0.8 [13:46] jpds: ah, I thought I had backports enabled, bummer! [13:46] mok0: https://edge.launchpad.net/ubuntu/hardy/+source/debootstrap/1.0.9~hardy1 [13:46] thx [13:56] mok0: I saw you were trying to ping me yesterday. [13:56] ScottK: yes, thanks for looking at gamgi [13:56] ScottK: but please see my comment [13:57] mok0: Link please? [13:57] ScottK: http://revu.ubuntuwire.com/details.py?package=gamgi [13:58] Looking [13:58] right. is there any known bug where booting into a red flashing screen will cause your grub to turn into pastebin.ca/1172892 ? [13:59] yes, it is the right pastebin [13:59] mok0: I still thing it needs a man page. I think every executable in /usr/bin is supposed to have one. [13:59] ScottK: But the user should not know about this [14:00] mok0: What does Debian Policy say? [14:00] ScottK: the user will execute the program "gamgi" [14:00] Right. Once you read policy, the answer will be a short man page that says don't excute this. [14:00] I could be wrong. [14:00] ScottK: It says that when a program needs environmental variables, a wrapper script should set them up [14:01] ScottK: So, for the convenience of the user, the wrapper script is called "gamgi" and the binary is called "gamgi.real" [14:02] Right, what about the Policy about man pages? [14:02] ScottK: let me check that [14:03] Should be policy 12.1 [14:04] mok0: Note that you can probably get away with a single manpage for both, with a symlink. [14:04] I don't see anything concerning wrapper scritps [14:05] The environment thing is in 9.9 [14:05] persia: allright, but I think it's silly [14:05] mok0: Well, some user might get clever :) [14:07] persia: heh. Well I see that there are no man pages for "uncompress.real" or "ldconfig.real" [14:07] mok0: Sure: not every package is policy compliant. [14:08] persia: You are right [14:08] ... and there _is_ a manpage for uncompress.real, so that settles it [14:16] persia: otoh, using a link to the manpage is not good, because people should not run the ".real" program, so the manpage should say that [14:17] mok0: No reason the manpage for gamgi can't mention the existence of gamgi.real, and that one should use /usr/bin/gamgi [14:17] alternately, shove it in /usr/lib/gamgi/gamgi.real [14:17] persia: yes... does that change the requirement for a manpage? [14:18] It does: policy requires a manpage for everything in /bin, /sbin, /usr/bin, /usr/sbin, and /usr/games [14:19] persia, I don't see that. I only see "Each program, utility, and function should have an associated manual page included in the same package" [14:20] Hmm.. I guess it depends on one's interpretation of policy. I always felt that everything in the path, and everything not in the path that users were expected to execute should have a manpage. I may be mistaken. [14:20] What do you think, ScottK? [14:21] persia: I agree that putting the exe file in /usr/lib/... is better [14:22] I don't think it's better, it's just an option. [14:22] mok0: I believe that what persia is giving you is the traditional interpretation. This policy requirement is mechanized in Lintian, so for a real anwer, I'd suggest consulting the Lintian source. [14:22] ScottK: good idea [14:23] persia: It is better, because it will prevent users from running the binary without environmental variables set up (unless they are clever) [14:24] mok0: I guess that makes some sense. [14:25] ScottK, persia, thanks for the input! I will go ahead and fix the package [15:09] nxvl: o/ [15:09] emgent: hi! [15:17] Hmm, just created a new sbuilder, but it is missing apt??? [15:17] intrepid sbuilder, that is [15:18] argh another issue on drupal.. [15:22] emgent: what's up with drupal? [15:24] more security issue [15:24] uhuh [15:24] committed intrepid now, i'm working to test backport fix for hardy. [15:29] emgent, what version of drupal is this? [15:29] 5.X and 6.X [15:29] emgent: ah, finally, version 6! :-) [15:29] 6.X it`snt in intrepid yet [15:30] emgent: will be I hope [15:30] i'm waiting for bump it in Ubuntu [15:30] emgent: thanks for the warning. upgraded drupal, and actually subscribed to the rss feed now! [15:31] mok0: dont know.. i will see first to 28 August [15:31] Hobbsee: hehe np, the real problem is that all LoCo Team use it, but not with ubuntu repo.. [15:31] manual installation.. :-| [15:31] mine's manual too [15:31] it took about 2 minutes. [15:32] and not all LoCo upgrade it.. [15:32] (of apply the fix) [15:32] true [15:32] and box dont run mod_security for try to exclude this attack [15:33] Ydrk, getting a compile error in intrepid (but not earlier): 'struct hostent' has no member named 'h_addr' [15:34] Ydrk, it's now wrapped in ifdefs [15:35] i think that we should write a census for CMS used by loco.. and try to send auto-notice when vuln is out. [15:35] (with attached fix) [15:37] anyway i will talk about it in the next security team meeting [15:44] with wich command is that i saw that packages depend on $package? [15:49] apt-rdepends [15:52] I tend to use apt-cache rdepends, as apt-rdepends is a little funny (or at least I can't get it to use --follow right) [15:54] persia: yeah, i'm using rdepends, i have just tried the 2 of them and apt-cache is more what i was looking for [15:54] thank you! [15:54] * nxvl HUGS mok0 and persia [15:55] persia: did you file a bug report? :-D [15:55] heya persia :) [16:00] mok0: Not yet: I've yet to determine it's not me (I keep getting distracted by something else when using apt-rdepends) [16:01] That said, the manpage says it doesn't quite emulate apt-cache, so except where one needs recursion, I think apt-cache is a better tool. === brandon|work is now known as brandonperry === superm1 is now known as superm1|away === superm1|away is now known as superm1 [16:33] bobbo: around? [16:50] dholbach: ping :) [16:52] nxvl: congrats man! [16:52] nxvl: hey [16:53] vorian: thank you [16:53] bobbo: nevermind i just uploaded it [16:53] nxvl: ok :) === bdrung_ is now known as bdrung [17:31] should I register a blueprint for Intrepid on launchpad if I'm not going to assign myself to it ? if they find it as a stupid idea they will remove it right ? [17:34] cherva: There's no good way to remove blueprints, and blueprints for intrepid were discussed in May, so the timing is a little awkward. [17:34] The next round of blueprinting will be for intrepid+1, for discussion in December at UDS. [17:35] persia: so it is too late to proppose to make nautilus edit id3 tags of mp3 via properties->sound tab ? [17:36] cherva: There's only two weeks until FeatureFreeze, and nautius tends to follow upstream very closely. You'd do best to either work to get that into GNOME or put it on brainstorm. [17:37] persia: it is on brainstorm [17:39] cherva: OK. From brainstorm, the next step is to organise the implementation, and get some PoC stuff together. Often a wiki page is used for this, and written in Specification format. Has that been done? [17:42] persia: http://brainstorm.ubuntu.com/idea/3888/ there is no wiki, strage this idea is from 8 Mar '08 where can I see the discussed blueprints for the ibex? [17:43] cherva: I don't know that they are organised in their entirety anywhere. Most of the teams have individual listings of blueprints interesting to them. [17:43] persia: I guess I'll wait for the interpid+1 discussion :) [17:44] persia, do you have a good methodology for how you are tracking down the extras that get added in in the studio stuff? _MMA_ showed me some 300 megs that got added [17:46] superm1: Not really. I've been fiddling with `apt-rdepends --show=Depends,Recommends`. I've yet to figure out how --follow works. Also: https://lists.ubuntu.com/archives/ubuntu-studio-devel/2008-August/000822.html [17:46] cherva: That or get inolved in implementing it yourself: generally those specs that are almost there are more likely to get included than those that are more a description of something someone else should do. [17:47] persia, ah okay fairly similar to how i started to look at some of the mythbuntu stuff that is depending on too much. [17:48] our live cd image is some 200 megs bigger (That includes compression.....) [17:48] and from what i've seen so far, we dont want any of it [17:48] persia: I don't think my code will be good for implementing it ANYWHERE :) [17:49] Well, there's some stuff we want: I just added libpam-ck-connector to -desktop today. On the other hand, we were pulling all of KDE, which is a bit odd for a GNOME-based desktop. [17:49] cherva: Proof-of-concept. Then present that to known nautilus hackers, and watch it change into real, useful, code. [17:51] persia: I don't know gtk :) just a little qt4 I'll just leave it for now [17:51] cherva: OK. If you really want it, maybe you can find someone else who both knows GTK and also wants it? [17:52] no I just wanted to ask what will happen if i register a blueprint and I know now thanks :) [17:53] h [17:53] hi [17:53] if someone have free time please see :http://revu.ubuntuwire.com/details.py?package=dsss [17:57] goshawk: What is dsss? [17:58] persia: it's like python eggs [17:58] but for D programming language [17:58] dsss net install application [17:58] downloads compiles and installs the application [17:59] Ah. Considering how much time we spend patching that out of python apps, I'm unsure how much we want it for other programming languages [17:59] you're right [17:59] but sometimes it could be good [17:59] expecially for not packaged application [17:59] and, now, in the D world [18:00] Well, I don't think it's good for not-packaged applications, as they ought be packaged. It might make things more convenient for D developers though. [18:00] they are a lot (that are not packaged i mean) [18:00] (but not much more convenient for D developers who wanted to have their applications in Ubuntu) [18:00] persia: it's also the "make" equivalent for D applications [18:00] Oughtn't they be packaged then, if they are useful? [18:01] Oh. If it's "make" equivalent, than we do need it. [18:01] I don't suppose you've packaged it in a way that tries to pull libraries from the repositories, rather than the net, have you? [18:01] persia: it's mainly a make equivalent [18:01] the "net" module get sources from net and compile it [18:01] for example [18:01] dsss build [18:01] in a D source tree [18:02] compiles and generate executables [18:02] persia: it's a coded from scratch application [18:02] it uses just C libs [18:02] and D ones [18:02] (using gdc the gnu d compiler that is in the ubuntu repo) [18:03] it does not use the net to build [18:03] itself [18:03] all the libraries are in the repo [18:04] Right. I'm just considering the future popularity of this for D developers, and think that if you haven't, you might want to see if you can stub out the net module to pull libraries from the repositories, pehaps if a certain siwtch is provided. That then makes it easy to package D code that build-depends on dsss [18:05] you can't use the net module while using dsss like "make" [18:05] except you do dirty things in makefiles [18:05] goshawk: OK. Now I'm confused. [18:05] persia: i'll explain better [18:05] D applications have a makefile called dsss.conf [18:06] it's readed by dsss [18:06] to build sources [18:06] dsss has a net module too [18:06] to get and compile sources [18:06] but the net module is not accessible by dsss.conf [18:07] it has no sense for a dsss.conf to get [18:07] the net module [18:07] since [18:07] the net module just get sources from the net [18:07] and open them [18:07] then it goes in the source dir and do "dsss build" [18:07] and dsss install [18:08] is it now more easy to understand? [18:09] OK. So there's no easy way for a developer to configure dsss to pull build-dependencies from the net as part of a call to dsss build ? [18:10] no, dsss does not solve dependencies, it's like make [18:10] dsss net module is able to [18:11] but you can't call it from dsss.conf [18:11] OK, so `dsss build` can't pull from the net? [18:11] yep right [18:11] dsss build just builds [18:11] according to specifications in dsss.conf [18:12] OK. Added to my list of packages to review. [18:12] :) thanks [18:16] persia: after uqm of course :P [18:17] sebner: Indeed. It's a FIFO queue. [18:17] D: [18:17] :D [18:17] persia: nice to hear =) [19:45] Someone can take a look at http://revu.ubuntuwire.com/details.py?package=ircp-tray ? [20:11] evening [20:41] on ubuntu 8.10 alpha 4, the version of miro that ships is 1.2.3, current from miro apt is 1.2.6 [20:41] * ethana2 checks code freeze date [20:43] ok, we haven't even hit feature freeze [20:43] http://www.getmiro.com/download/ [20:44] ethana2: can you open a bug (if it doesn't exists yet)? [20:44] launchpad? [20:45] ethana2: yes [20:46] ethana2, this will help https://help.ubuntu.com/community/ReportingBugs [20:46] ok [20:46] well i report bugs all the time [20:46] a few others this week-- but how do you file a 'package needs to be updated' bug? [20:48] Have a look at the many examples https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=upgrade [20:48] ethana2, make sure you add the tag 'upgrade' [20:48] got it [20:51] ok, how to i add tags? [20:51] is that after submitting? [20:54] ok yes [20:55] https://bugs.launchpad.net/ubuntu/+source/miro/+bug/258401 [20:55] Launchpad bug 258401 in miro "old version of miro in intrepid repositories" [Undecided,New] [21:08] oh hey, while i'm here, i'd like to see this maybe get resolved in a timely manner [21:08] https://bugs.launchpad.net/bugs/258058 [21:08] Launchpad bug 258058 in libprinterconf "Brother DCP 7020 uses wrong drivers" [Undecided,New] [21:08] ... [21:08] particularly because not only is this bug extremely annoying to me, but the solution should be somewhat simple [21:09] ethana2, I look forward to receiving your patch then [21:09] i don't know if i have the ability to help fix this bug myself [21:09] ok, how do i do this? [21:09] Well, you fix it [21:09] then you compare the the old and the fixed version [21:09] right, i have the .deb files for all the right drivers [21:10] is there a driver index file somewhere i can insert this stuff in? [21:10] anyone familiar with the printing subsystem want to help me out? [21:11] i'm expecting the fix to involve maybe a few lines of text, but i don't know where the file is that the text needs to be added to [21:12] ok here, how do i found the launchpad maintainer of a given project? [21:12] Well, you could determine what binary is launched when you plug in your printer [21:12] once i know that i can just ask him [21:12] Then determine which package that belongs to [21:12] i've got that already [21:12] i think [21:12] alright, i should be absolutely sure i guess [21:13] "apt-get source " to get the source code [21:13] how do i see what's being launched as i plug stuff in? [21:13] ah yeah, when i apt-get source, does it just dump it wherever i'm at like svn, or does it put it in some source directory? [21:14] It will download three files to you current working directory [21:14] and extract the source into a sub directory [21:14] ah, ok [21:16] ok, got it, now to figure out where it stores the printer/driver index [21:20] * ethana2 is asking on ##cups [21:33] Ok, this is confusing--what I may do is get a livecd of the latest suse and fedora and add those to the bug report on launchpad if they're affected [21:37] well, thanks for the help-- time to see how the intrepid radeon driver performs in tremulous === superm1 is now known as superm1|away === Kopfgeldjaeger is now known as Kopfi|offline === Kopfgeldjaeger is now known as Kopfi|offline