[00:03] can we use non-english characters in URLs, description or name in debian/control ? [00:09] k0p, yes. advocates are resetted when pushing a new upload. [00:09] DktrKranz, xiii [00:09] DktrKranz, I don't know about that. [00:10] DktrKranz, so I need to talk with norsetto again. After that can you put the advocate again? sorry [00:10] sure [00:10] ping me when ready [00:10] DktrKranz, ok. [00:11] another question. do you test in intrepid right? [00:11] i built in intrepid, yes [00:11] yeap. [00:11] And I test in hardy. [00:12] it works fine. But not with norsetto. [00:12] I don't discover what's happen [00:13] k0p, I haven't tested it properly, just sure it installs and removes cleanly, are there issues with program itself? [00:14] well ... I don't know. [00:14] norsetto tell me that in hardy [00:14] nothing appears after run umit [00:15] DktrKranz, do you run umit? [00:16] just a sec, I'll install it [00:17] ok :) [00:17] done [00:18] launched [00:18] yeap [00:18] now launched with sudo to avoid warning message [00:18] DktrKranz, lot of people runs it in hardy and intrepid. [00:19] me too [00:19] noones reports errors [00:20] I did a couple of scans, no issues here [00:20] yeah [00:20] the only issue with norsetto was lauching [00:20] launched from menus now [00:20] it works. [00:20] yeap works. [00:21] ha! missing su-to-root [00:21] this needs fixing [00:21] DktrKranz, how I do that? [00:22] I don't remember which is the common behaviour... let's see [00:23] in GNOME, gksu is common [00:23] yeap. [00:23] but people tells to put su-to-root. [00:24] IIRC, that's not the good one, though [00:24] if you want to use su-to-root, you have to add menu in Depends field [00:25] I do it. [00:25] ah... I got older version ;) [00:28] k0p, it's quite late here, I think it's good to talk with norsetto to see issues he faced in Hardy [00:28] and I'm moving to bed too :) [00:28] DktrKranz, ok. [00:28] i'll do the same [00:28] DktrKranz, thanks. I'll talk to advocate when it's ready ;) [00:28] good night ;) [00:29] thanks [00:46] someone could review my package? I already have a ack. http://revu.ubuntuwire.com/details.py?package=umit [01:26] hola folks [01:27] heya! [01:37] hey Hobbsee [01:37] * NCommander just got a new part for his laptop to fix it [01:37] \o/ [01:38] Woot [01:48] * NCommander double clicks RAOF randomly [02:06] where is the debian standards located? e.g. if i wanted to actually read whatever the Standards-Version: 3.8.0 is, where would I look? [02:07] debian-policy [02:07] thanks [02:07] sorry, that's the package name [02:07] http://www.debian.org/doc/debian-policy/ is the URL [02:30] Oh. It seems that upstream has put Xgl out of its misery. [02:31] So now we get to work out whether _we_ want to remove it from Intrepid. [02:34] how did they do it ? did they finish it off finally ? [02:35] git rm xgl/* [02:35] yay [02:35] Well, kinda. [02:36] There's a group of users who'll no longer be able to get Compiz if we drop Xgl. [02:37] unless nvidia reacts on their mails ;) [02:37] And adds features to a driver that's been superceded by _three_ newer drivers? [02:37] Colour me skeptical. [02:38] well, xgl broke tons and tons of ltsp setups ... and caused us major headdaces in the support channel ... [02:38] Oh, yeah. Xgl was _crap_ and full of unfixed bugs. [02:39] if admins thought they are cool and installed xgl ... and suddenly 200 VIA based thin clients dont work anymore [02:39] I implemented a blacklist to prevent that from happening. It didn't work? [02:39] (the admins indeed worked on the server directly with the nvidia onboard card :P ) [02:39] Oh. Craziness. [02:39] not if your display is remote [02:39] Right. [02:40] ltsp uses ssh -x user@server /etc/X11/Xsession [02:40] so if xgl starts as part of the session ... boom ... [02:40] your X is already up on the client before thats run [02:41] Urgh. [02:41] and finding out that the admin simply didnt tell you he had xgl installed ... after a week of debugging ... well ... [02:41] :) [02:42] TheMuso: norsetto's fixes have been in my branch since early june... [02:42] TheMuso: (for pulseaudio) === ApOgEE- is now known as apogee-x [02:43] crimsun, while i got you here, do you see any reason to keep libflashsupport in intrepid with flash 10 ? [02:43] crimsun: Ahj right, sorry I forgot about your branch. [02:43] i'd like to drop it asap === macd_ is now known as macd [02:44] ogra: I see no reason [02:44] great :) [02:45] ogra: Was that re: Xgl? [02:45] RAOF, nope thats was just a question to the master of sounds :) [02:45] Right. [02:56] is something wrong with revu? i kinda uploaded a new package a while ago and it's not showing [03:08] hmm i was sending to the old .de . anyone willing to review http://revu.ubuntuwire.com/details.py?package=hamster-applet [03:44] what buildsystem should I use (I'm a deb newbie, and I'm making a new package, a _very_ small one) [03:57] =In order to get a package into the archive, is it really a requirement that each source file contain that useless copyright junk? [03:59] TomJaeger: not a hard requirement, no. Of course, not following it means that you make the reviewers' and archive admins' lives more difficult. And when you make their lives difficult, you make it less probable they'll accept it. [03:59] TomJaeger: and no, that "useless copyright junk" is NOT "useless..junk". [04:02] well, I don't really see an advantage over a single LICENSE file, but okay. It'd just be a major pita for me to include it right now, rather than with the next upstream release. [04:05] TomJaeger: whatever works for you, as long is it's easy for the archive admins to tick off. [04:05] as long as* [04:05] ("tick off" == verify appropriate licences) [04:06] okay, I'll add a comment to the REVU page [04:08] any one what to do when you need to divert a file when its already being diverted by another package? [04:08] Btw, for the ISC license, would one reproduce the whole license in each header or would the "Permission to use..." part be enough? [04:11] see what the bind9 source does. [04:12] thanks, already checking [04:13] They reproduce the whole license, so I'm going to do the same [04:15] you'll never go wrong reproducing the entire licence(s) === mdomsch_ols is now known as mdomsch [04:29] but I don't need to add a license to a glade file, right? [04:31] yay, my laptop works again [04:34] god, this is such a waste of time. Now all my files contain the text "ISC DISCLAIMS ALL WARRANTIES". [04:36] TomJaeger:? [04:38] copied the license from the bind source because they already had the correct * formatting. However, I'm not ISC and now I have to replace all occurrences of ISC with THE AUTHOR. [04:38] A sed oneliner. [04:39] if you don't care that lines be less than 80 characters long [04:40] A quick vim macro, then. [04:46] RAOF: in your gnome-do development, do you think it'd be possible to get the standard 'open' for a text document to open in something other than less? [05:03] why does that every-source-file-must-have-a-license-header rule not apply to the debian/ directory? [05:08] Anyway, could someone please have a look at my package: http://revu.ubuntuwire.com/details.py?package=easystroke [05:08] Hobbsee: You should fix xdg-open; that's what we use. [05:08] RAOF: yes, but i could voluntell you to fix it.. [05:10] Right. xdg-open is just plain stuffed. [05:12] Ah. The GNOME detection has been b0rked by new gnome-session. [05:13] Hobbsee: You've got a kubuntu desktop handy, right? [05:13] RAOF: er, no? [05:13] actually, i might have a really old edgy version... [05:13] Am I crazy? [05:13] no? [05:13] I was sure you did kubuntu stuff. [05:14] i used to [05:14] i haven't run kubuntu since hardy. [05:14] Ah. I'm merely out of date. [05:14] i switched over a copule of days before hardy release [05:14] * Hobbsee has been slowly stepping out of kubuntu stuff [05:15] Ok. So: to anyone with a kubuntu desktop - does your environment contain DESKTOP_SESSION=kde? [06:07] TomJaeger: again, it's not a rule but a recommendation. [06:08] good morning [06:08] 'morning [06:09] crimsun, well anyway, I've added the license boilerplate now. [06:10] hiya crimsun [06:10] (the diff's 36k now) [06:11] TomJaeger: You can't actually add license information for upstream. [06:11] I am upstream [06:11] (unless he's upstream) [06:11] Aha :) [06:21] So does anyone want to review it? I've already looked through a few other submissions in order to anticipate common problems: I removed commented lines, added a man page, improved the .desktop file and added license information to the source files, so hopefully this will be rather painless. [06:25] TomJaeger: if you are upstream, why not updating the orig file? This way, in the ubuntu diff file, we would only have the 'debian' directory stuff [06:27] Is that really such a big deal? I'd rather not modify files I've already released. [06:27] By the way, could someone review my mountmanage packaging? It's at http://revu.ubuntuwire.com/details.py?package=mountmanager. Thanks. [06:29] TomJaeger: For licensing, it's a big deal. For nearly everything else, less so, especially if you commit the patches to your trunk for inclusion in the next release. [06:30] TomJaeger: the rule is not to modify anything outside debian directory inside a diff file. In the worst case, you should include patches in you debian directory to modify sources, but as it's about licensing, I think that nobody will ack that package... [06:31] Remember that the orig.tar.gz must be independently redistributable. [06:32] I uploaded http://revu.ubuntuwire.com/details.py?package=compcache-setup which should have fixed the problems pointed out in the previous review. Anyone up for reviewing? [06:36] persia, why would the orig.tar.gz not be independently redistributable? [06:37] fabrice_sp, so you're telling me that there must not be any synergy effects if the packager and the upstream maintainer are the same person? [06:38] TomJaeger: From backscroll, I thought you were patching licensing in the diff.gz. That is usually not ideal, because if the licensing needs patching for redistribution, the unpatched orig.tar.gz would then not be redistributable. [06:38] fabrice_sp: There's no rule about that. There's no good reason *not* to modify things outside debian/ as long as the differences are well tracked. [06:38] Indeed [06:39] Personally, I find that anyone who does this without a well-kept VCS is exceedingly annoying, but that's just me. [06:39] Such as in VCS commits [06:42] persia, my current diff is not under revision control because I've made some changes in the development tree that preclude patches from applying to the released version. [06:42] I actually created a patch by hand and then applied it to the packaging tree [06:42] tomjaeger: That’s what branches are for. [06:43] persia: that's what I've been told by apachelogger: for mountmanager package (sponsored by apachelogger), I spend a lot of time using quilt, to patch correctly the configure file (and some sources) [06:43] TomJaeger: If you're diverging, I'd suggest either branches or debian/patches [06:43] * persia develops a strong distaste for pam_mount [06:44] (or maybe just sbuild remounting /home 10 times during a build) [06:44] ion_, darcs has trouble moving patches between branches when things are diverging, plus it's not like adding that license junk is in any way non-trivial. [06:45] and why on earth would I spend half an hour or more to figure out how debian's patch system works? [06:46] TomJaeger: So that if you later get distracted and someone else takes over maintenance, they don't need to spend several hours with you detangling the applied patches. [06:46] Of course, if you're sure that won't happen until you're more in sync, it doesn't matter so much. [06:46] all the patches are in the next version anyway, so that's a non-issue [06:46] Well, uupdate will still show patch conflicts, but there are ways around that. [06:48] TomJaeger: why not just updating the easystroke-0.2.1.tar.gz file in sourceforge with the license changes? Maybe, it's a non sense, but it would be easier, as the changes are already in the next version. [06:50] fabrice_sp, that is out of the question. What I could do is release a new version just for this purpose, but I won't do that unless it's absolutely necessary [06:51] TomJaeger: You could ask an archive-admin (on #ubuntu-devel), but historically, packages that patch licensing in diff.gz have been rejected. [06:52] persia, okay, thanks, so I'll have to do it. [06:53] TomJaeger: I suspect as much, unfortunately. You can try without it, but I don't know that it will work. [06:54] I'm not going to take any chances. I'm sick of all the bureaucracy already. [06:54] Yeah. licensing is a lot of fuss :( [06:55] I'm not actually changing licensing, though. I'm just adding redundancy. [06:58] TomJaeger: Yeah, well, unfortunately despite the efforts of many, copyright law isn't the same everywhere. I live in one of the few places where the Berne Convention was adopted into law directly rather than laws being changed to match, and even that doesn't seem to work well for most people. [07:02] What's going on here? easystroke: remote site does not even have current version [07:04] TomJaeger: What is the output of uscan --report-status ? [07:04] Newest version on remote site is 0.2.1, local version is 0.2.1.1 [07:04] easystroke: remote site does not even have current version [07:04] OK. What is first line of debian/changelog ? [07:05] easystroke (0.2.1.1-0ubuntu1) intrepid; urgency=low [07:06] OK. Why 0.2.1.1 rather than 0.2.1 ? [07:06] Because I don't change files once they're released. That's shady. [07:06] Essentially, either you need 0.2.1.1 on the remote site, or you need to just list 0.2.1 for the packaging. [07:07] I just uploaded 0.2.1.1 [07:07] Yeah, that is shady. Maybe release 0.2.1.1 on the main site, with a note that it's just licensing changes? [07:07] http://sourceforge.net/project/showfiles.php?group_id=229797 [07:07] Oh, so it is there? What is the match line in debian/watch? [07:07] http://sf.net/easystroke/easystroke-(.*)\.tar\.gz [07:08] maybe it takes some time to be available on the server? [07:08] Might just be an issue with the debian sourceforge mirror management system used by the watch file. [07:09] okay, that was it, it worked now [07:09] Could take a bit to update. Oh good :) [07:12] Okay, the package should appear on REVU in just a few minutes [07:26] okay, it's up now and my pbuilder^H^H^H^H PPA was able to build it. [07:27] (Ended up having to change a file outside of debian/ anyway: The man page was still mentioned version 0.2.1) [07:31] TomJaeger: Correcting a manpage is the sort of change to diff.gz that is considered good maintenance, rather than being risky. Thanks for your flexibility. [08:03] <\sh> moins [08:04] howdy [08:19] Hi \sh [08:24] * persia is a little disturbed to read the REVU statistics, and encourages more people to comment on packages: there shouldn't be such concentration in the top 10. [08:48] moin [09:40] hi all [09:41] back in home again! [09:41] Hola [09:47] hi nxvl [09:48] hi! [10:02] hi nxvl [10:02] ! [10:02] huats: hi! === dholbach__ is now known as dholbach === DrKranz is now known as DktrKranz [10:31] darn, even more people leaving motu-sru :( [10:42] laga, yep :( [10:59] DktrKranz: if you have a minute: what's still missing from bug #241402? i wrote that email to the MOTU mailing list.. do we need martin's ACK for the translations to be tested in hardy-proposed? [10:59] Launchpad bug 241402 in mythbuntu/8.10 "Mythbuntu control center VNC setup freezes if & in password" [Medium,Fix committed] https://launchpad.net/bugs/241402 [10:59] hum, let me check if my mail went through [11:00] no, it didn't go through. resending.. [11:01] it would probably help if i didn't reply to ubuntu-motu-bounces@.. [11:01] laga, pitti replied back. he's happy with update translations in universe SRUs (since he manages langpacks updates for main), so your debdiff should be ok. Do you have some mythbuntu guy to sponsor package in -proposed? [11:02] yes, i saw his reply. i was just referring to his "assuming they're tested" bit. [11:02] yes, i have a sponsor [11:02] i just need the ACK ;) [11:03] laga, good... I'll review it soon, then. thanks :) [11:03] thank you [11:04] are there some mechanism to test translations? [11:05] setting $LANG accordingly and making sure the app doesn't crash? ;) seriosly though, i guess we'll have to find people who speak these (new) languages and hae them try it.. although that could be a painful process [11:06] if Italian is one of these new languages, you've found a tester :) [11:07] we do have an italian translation, not sure if it's new ;) [11:08] i believe people need to be in a special team to be able to translate apps - so there should be some quality control regarding applicants. [11:08] if they follow italian translation team rules, I trust them a lot [11:10] laga, I see Intrepid tasks are not marked as Fix Released, is it fixed now? [11:12] umm. i've committed all fixes, but not all of them are in intrepid yet === Syntux__ is now known as Syntux [11:12] can we use non-english characters in URLs, description or name in debian/control ? [11:13] plans to release for intrepid soon? [11:13] DktrKranz: we can do that if it's needed by the SRU policy. on the other hand, i'm currently rewriting mythbuntu-control-centre and that's what I planned to have uploaded next to intrepid [11:15] laga, it's recommended to have intrepid tasks fixed, but if you plan to release fixes for intrepid before the release and keep track of status progress, I think it's safe enough to have a package in -proposed now. [11:18] * DktrKranz goes to lunch [11:18] i should really try & get an updated merge of mono into intrepid, but given the usual delays on u-m-s, it might only be out in time for 9.04 [11:39] directhex, try asking latest sponsor [11:42] Could somebody take a look at monkeystudio (http://revu.ubuntuwire.com/details.py?package=monkeystudio)? It's already had two advocations, but it was rejected by the archive admins for embedding libraries that were already available in the repos. That's fixed now, so it should be okay. [11:46] laga, ACKed. [11:51] thanks [11:55] hi all [12:11] DktrKranz, are you there? [12:16] I test my package in hardy x86, 64bits and works fine. [12:16] I can't reproduce norsetto error :/ [12:25] hi folks [12:26] hi sistpoty|work [12:27] hi k0p [12:29] someone could review my package? http://revu.ubuntuwire.com/details.py?package=umit I already have a ack but I need another. [12:32] I've uploaded a new package for Webstrict (http://revu.ubuntuwire.com/details.py?package=webstrict) but I don't see it... can someone help me? [12:33] jmehdi, it takes five or so minutes to show up. [12:33] i've uploaded it several days ago... :( [12:34] is the version number taken into account? [12:34] jmehdi, did you login to revu using your launchpad account first? [12:34] you need to do that to get your keys synced to the new system [12:34] I don't think I did that [12:35] ok, I'll login, then should I have to upload it again ? [12:36] jmehdi, i don't know if you need to upload again. You should ask NCommander or RainCT. After logging in, you probably want to merge your old revu account with your launchpad one using the link at the top. [12:37] drebellion: ok I've merged my accounts [12:37] k0p, I'm here now [12:38] jmehdi: I only see binary uploads of webstrect in the rejected queue, so please reupload (a source package) [12:38] \sh: would you mind looking at the emacs21 merge ? the debdiff seeems to contain more than what's actually listed as retained changes [12:40] <\sh> lucas: emacs21 or xemacs21? [12:40] sistpoty: I've uploaded that: "Uploading to revu (via ftp to revu.tauware.de): [12:40] webstrict_1.0-0ubuntu1.dsc: done. [12:40] webstrict_1.0.orig.tar.gz: done. [12:40] webstrict_1.0-0ubuntu1.diff.gz: done. [12:40] webstrict_1.0-0ubuntu1_all.deb: done. [12:40] webstrict_1.0-0ubuntu1_i386.changes: done. [12:40] Successfully uploaded packages." is it ok? [12:41] jmehdi: nope, that's a binary upload [12:41] jmehdi: No. You should only dput *_source.changes. [12:41] jmehdi: the _i386 from the changes file [12:41] DktrKranz, I test my package on hardy with amd64 and x86. It is systems clean. No bugs there. [12:41] jmehdi: please build your package/changes file with parameter -S (for source upload) and -sa (to include the orig.tar.gz) as parameters to dpkg-buildpackage/debuild [12:42] <\sh> Lutin: do you have somehow the link to the merge report? [12:42] k0p, I tested it on Intrepid, it seems good too [12:42] I'll have another review now [12:43] mh... no, not really now... later today [12:43] DktrKranz, ok :) [12:43] <\sh> argl..it's my own merge ,-> [12:44] sistpoty: thanks, I've uploaded it again [12:44] np [12:44] jmehdi: now it's a native package (is your .orig.tar.gz named correctly? [12:44] +) [12:45] DktrKranz, but I think the possible error on norsetto in hardy doesn't prohibits umit enter on intrepid. is it true? [12:45] k0p, it can be fixed later, if it will show up === otwr is now known as otwr|sleep [12:46] sistpoty: arf... is it because I changed the version? (I have a webstrict_1.0.orig.tar.gz and webstrict_1.0.0-0ubuntu1... files) [12:47] jmehdi: yep, looks like it. would be webstrict_1.0.0.orig.tar.gz then [12:47] jmehdi: but the good new is that the package should be on revu now :) [12:48] sistpoty: yep :) [12:49] <\sh> Lutin: you can sync it... [12:49] <\sh> Lutin: the only change was the libungif4-dev to libgif-dev change, which can go now, since we have this transitional package [12:50] sistpoty: ok, new package with 1.0 version, so it is clean... [12:50] <\sh> Lutin: anyways..fileing sync req [12:55] <\sh> Lutin: bug #255302 [12:55] Launchpad bug 255302 in emacs21 "Please sync emacs21 21.4a+1-5.5 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/255302 [12:59] thanks sistpoty, all is fine ; now if someone could review my new package (http://revu.ubuntuwire.com/details.py?package=webstrict) :) [13:10] * ScottK thought we packaged emacs separately from Debian, but maybe that's just 22. [13:23] wireshark has a pretty bad rules file [13:24] can someone have a look at http://revu.ubuntuwire.com/details.py?package=hamster-applet === thekorn_ is now known as thekorn === kduboi1 is now known as kdu1 === kdu1 is now known as kdub [14:09] Anyone willing to review sphinxbase and pocketsphinx in REVU :)? It has already been reviewed by RainCT, so current uploads correct what RainCT suggested. Thanks :). The links are and [14:24] tseliot: hi [14:25] BUGabundo_work1: hi [14:25] did the nvidia change from yesterday [14:25] got any regression reports? [14:25] I just rebooted and can't seem to use my nvidia card [14:26] actually I can't even open jokey to select the driver [14:26] BUGabundo_work1: yes, a new driver was uploaded [14:28] can this be the cause why I'm at 800x600 ? [14:29] what does this command say? sudo aptitude show nvidia-glx-173 | grep Version [14:29] and of course I will also need your /var/log/Xorg.0.log and xorg.conf [14:30] tseliot: Version: 173.14.12-0ubuntu2 [14:30] I'll upload to pastebin [14:31] everything is "slugish" [14:31] the mouse is moving really slowly [14:31] metacity looks awfull [14:33] <\sh> emgent: ping moin merge 1.7.1-1 from debian [14:33] kdub: just found a binary upload to revu (tv-grab) from you in the rejected queue... I'm removing it. please upload only source packages, thanks [14:33] tv-grab-dvd even [14:34] BUGabundo_work1: oh, and make sure that the linux-headers for your kernel are installed [14:34] http://paste.ubuntu.com/34760/ [14:35] tseliot: and http://paste.ubuntu.com/34762/ [14:35] looking for headers now [14:36] tseliot: headers are installed [14:37] BUGabundo: add this line to the Device section of your xorg.conf:Driver "nvidia" [14:37] BUGabundo: I mean, Driver "nvidia" [14:37] <\sh> emgent: I filed a sync req of moin 1.7.1 because it fixes your security issue and some other problems like attachments [14:37] humm getting DBUS erros while trying to lunch jockye-gtk [14:37] sistpoty|work: any idea what i did wrong? [14:38] i thought i did only upload source [14:38] kdub: well, only my standard line for this: when building a package, please use -S (to create a source package) and -sa (to include the .orig.tar.gz) as parameters for dpkg-buildpackage/debuild [14:38] BUGabundo: you're using the "nv" driver. As regards Jockey you might want to contact pitti in #ubuntu-devel or (even better) file a bugreport against jockey [14:39] yeah [14:39] something with the lastest updates mess the system again [14:39] sistpoty|work: so using the -S flag will only make source then? [14:39] kdub: exactly [14:39] ok, sorry for doing the wrong thing [14:39] after that I had to run dpkg-recinfigure xserver -phigh just to get 1024 [14:40] no problem kdub... was just a rm command on revu's server ;) [14:40] tseliot: so that's why it lost the nvidia driver [14:40] restarting X [14:41] tseliot: it fails... it just ask me to configure, because I'm left on a low-graphics mode [14:42] if i get an error, something like "no appropriate .orig in the parent dir", is that ignorable? [14:42] when doing debuild -S [14:42] BUGabundo_work1: what does this command say? sudo modprobe nvidia [14:44] kdub: it usually means that you've got the name of the .orig.tar.gz wrong [14:44] someone can review my package? DktrKranz have already advocate it. http://revu.ubuntuwire.com/details.py?package=umit [14:44] tseliot: nothinh [14:44] tseliot: *nothing [14:45] BUGabundo: ok, try to set the driver to "nvidia" then log out, log in and show me your /var/log/Xorg.0.log and /var/log/Xorg.0.log.old [14:45] tseliot: do I set by hand like I did last time, on xorg.conf? [14:46] BUGabundo: yes, by hand [14:49] tseliot: can is use:; [14:49] Driver "nvidia" [14:50] Option "NoLogo" "True" [14:50] BUGabundo: what do you mean? [14:51] if I can just add those lines to xorg [14:53] BUGabundo_work1: yes, you can add them to the Device section [14:54] ok [14:54] pastebining the logs [14:56] tseliot: http://pastebin.ubuntu.com/34769/ xorg.0.log [14:56] tseliot: http://pastebin.ubuntu.com/34770/ xorg.0.log.old [15:01] BUGabundo: both logs show that the vesa driver is in use. Type: "sudo updatedb && locate nvidia.ko" and show me the output [15:02] just a sec tseliot [15:02] pitti may have found another thing [15:03] Heya gang === cprov-out is now known as cprov [15:04] Hi bddebian [15:04] Heya geser [15:05] tseliot: see private im, please [15:13] hi bddebian [15:13] Heya sistpoty|work [15:21] emgent: I can approve your mailing list today, just ping me when you resubmit it (check your mail) - thanks! [15:26] tseliot: all fine now [15:27] BUGabundo_work1: great [15:30] now its bug 51054 [15:30] Launchpad bug 51054 in linux "MS IntelliMouse Optical 1.1A USB stops responding" [Medium,New] https://launchpad.net/bugs/51054 [15:50] \sh: i'm here :) [15:51] \sh: moin bug opened? [15:51] <\sh> http://hg.moinmo.in/moin/1.7/rev/c4cf4327c96e [15:52] <\sh> emgent: but after installing the debian package and checking that this patch is in 1.7.1 ... I wonder if I did something wrong or the patch actually doesn't work [15:53] uhm ok thanks \sh i go to take a look [15:53] <\sh> emgent: anyways..I requested a sync.. [15:53] ok nice [15:54] <\sh> well, the error is not anymore with uploading but with displaying the stuff [15:54] \sh: debian fixed the bug that I found ? [15:54] <\sh> emgent: upstream fixed the bug in 1.7.1 [15:54] <\sh> emgent: and debian has now 1.7.1 [15:55] oh ok [15:57] uhm.. [15:58] Thomas Waldmann had told me that upgrade to version 1.7 was not easy and automatic and that it was necessary to follow the documentation, but I did not detail [15:59] anyway this night i will try to install debian package in my devbox for see it [16:00] <\sh> emgent: it works out of the box from 1.7.0 to 1.7.1...the migration is easy. [16:00] <\sh> emgent: even the migration from 1.5.x (hardy) to 1.7.0 was quite easy... [16:03] \sh: ok [16:06] <\sh> uh wow...new zend-framework 1.5.3. === brandonperry is now known as brandon|work [16:26] sistpoty|work: thanks for taking over! :) [16:26] sistpoty|work: I've just wrote the email to ubuntu-motu [16:26] siretart: no problem [16:26] siretart: great [16:27] siretart: have a nice holiday ;) === doko_ is now known as doko [16:30] A lot of people are leaving MOTU posts [16:33] DktrKranz or any other sru member: bug #243722 needs ack for gutsy (already got one for hardy) [16:33] Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,In progress] https://launchpad.net/bugs/243722 [16:34] Adri2000, is your patch almost identical to hardy's one, isn't it? [16:35] DktrKranz: it's the same, but applied inline because there is no patch system in this version [16:35] lukehasnoname, minimum wage, no holidays and bad badges on LP personal page, it's really a pain :) [16:35] Adri2000, cumulative ACK :) [16:36] please go ahead [16:36]