=== yofel_ is now known as yofel === Pici` is now known as Pici === jussio1 is now known as Guest88592 === jtechidna is now known as JontheEchidna === matti_ is now known as matti === yofel_ is now known as yofel === Adri2000 is now known as Guest25225 === Hobbsee is now known as Guest78837 === yofel is now known as Guest7105 === Pici is now known as Guest66795 === rmcbride_ is now known as rmcbride === dous_ is now known as dous === wgrant_ is now known as wgrant === nixternal_ is now known as nixternal === dous_ is now known as dous === itnet7_ is now known as itnet7 === asac_ is now known as asac === Guest25225 is now known as Adri2000 === RoAk is now known as RoAkSoax === Adri2000 is now known as Guest438 === Guest438 is now known as Adri2000 === Adri2000 is now known as Guest14290 === Guest14290 is now known as Adri2000 === Adri2000 is now known as Adri2000` === yofel_ is now known as yofel === lifeless_ is now known as lifeless === Guest88592 is now known as jussi01 === fabo_ is now known as fabo === nigel_nb__ is now known as nigel_nb [07:40] good morning [07:45] I have a question about packaging a new revision. Are you always supposed to put the latest development environment in the changelog even if you want the revision to be considered for SRU? [07:46] it has to go to the latest devel first [07:46] but you want to make 2 debdiffs. one for each [07:46] Well, the *fix* needs to go to the latest development environment first. [07:46] The revision needs to be targeted to a specific environment. [07:47] (and sometimes, especially when backporting upstream fixes, there is no special upload for the fix to the development release) [07:47] persia: er....whats the difference with what i said? [07:47] except that i didnt say the part about "devel might not need a special upload" like you did [07:47] maco: Precisely the same except I used lots more words :) [07:48] of course you did. you're persia. [07:48] you have the most flowery speech of anyone i've ever met [07:48] https://wiki.ubuntu.com/SRU [07:48] ah ok thanks! [08:46] I'm following the page here on packaging a new revision, https://wiki.ubuntu.com/MOTU/Contributing, and running debuild -S fails [08:47] the last line in the output is this, dpkg-buildpackage -rfakeroot -d -us -uc -S failed [08:47] Could you pastebin a larger chunk of your output (maybe all of it)? [08:48] sure one sec [08:49] http://pastebin.com/daf89cae [08:50] "debian/control has a duplicate entry for xsensors" is probably the core error. [08:51] By my reading, the clean: rule contains dh_testdir which is failing because of issues parsing debian/control. [08:51] ha you're right [08:51] And that failure stops processing of the clean rule, which stops processing of the build. [08:52] turns out there were two repeated paragraphs in the control file, thanks persia [10:03] hi, I created a debdiff for a new revision that should close Bug #183330 and Bug #73405 , should I just go ahead and post it as a patch to the bug reports? [10:03] Launchpad bug 183330 in xsensors "xsensors lacks support for coretemp module" [Undecided,In progress] https://launchpad.net/bugs/183330 [10:03] Launchpad bug 73405 in xsensors "xsensors displays nothing and then crashes when closed." [Undecided,In progress] https://launchpad.net/bugs/73405 [10:05] machina: Just check to make sure the debdiff works cleanly and solves the issue (as described on the wiki page you've been following), and subscribe the sponsors. [10:07] persia: will do === freeflyi1g is now known as freeflying === Guest78837 is now known as Hobbsee [11:31] i can't get my motorola device get working on ubuntu 9.10. what should i do? [11:32] anyone here? [11:33] this isnt a support channel, but i know you've been asking in #ubuntu for a while. since thats not working, i think google's all i can suggest :-/ [11:33] i can't get some peripherals working on ubuntu [11:33] oh oh wait [11:33] ubuntuforums.org [11:33] because the forums dont require that people be online at the same time as you [11:43] what kind of motorola device, though? [11:43] directhex: person quit === Lutin_ is now known as Lutin [11:44] oh. poot [13:03] es [13:03] ECHAN [14:04] jdong: Hi, how can we proceed with bug #481448? [14:04] Launchpad bug 481448 in vlc "VLC lacks build-dep on libupnp3-dev" [Undecided,New] https://launchpad.net/bugs/481448 === jrib1 is now known as jrib [14:33] just a doubt.. apt-get upgrade will upgrade only the already installed pkgs to a higer version right [14:34] wrapster, right [14:36] Well, not precisely. [14:37] If the dependencies of a package change between versions, and that package is upgraded, new packages may be installed, and depending on your apt configuration, old packages may be removed. === menesis1 is now known as menesis [14:43] persia, is dist-upgrade required for that ? [14:44] isn't that the difference between upgrade and dist-upgrade ? [14:44] No. [14:45] hum, so what's the difference ? [14:45] dist-upgrade considers the set of changes differently. [14:45] I remember usually getting "package kept" when a package pulls a new package [14:45] For a real answer, you'd do best to check the docs, but my understanding is that when you do dist-upgrade, it's more forgiving about removing stuff that other stuff depends upon if that other stuff is also being upgraded and the upgraded version depends on something different. [14:46] Whereas an upgrade will happily install new stuff (as long as it doesn't conflict with other stuff) or, depending on apt config, remove stuff that nothing depends upon anymore. [14:46] persia, from man apt-get [14:46] upgrade [14:46] under no [14:46] circumstances are currently installed packages removed, or packages [14:46] not already installed retrieved and installed. [14:47] I believe you are wrong [14:48] Well, either I'm wrong or the manpage is wrong. [14:48] But I was sure that I'd seen the install-extra-dependencies behaviour with just an upgrade. [14:48] I believe you are wrong, because when I need to get a new kernel, which is a new package set as dependency from the kernel metapackage, I need to dist-upgrade [14:49] Hrm. Then I'm probably wrong. I usually use aptitude, which has slightly different semantics and I must be confused. [14:50] Thanks for the correction. [14:50] :) [14:51] <_ruben> iirc, aptitude safe-upgrade matches apt-get upgrade .. and aptitude upgrade matches apt-get dist-upgrade .. then again, i never use(d) aptitude :) [14:53] _ruben: Well, not quite. [14:54] If the man pages are entirely accurage, `aptitude --no-new-installs safe-upgrade` matches `apt-get upgrade`. [14:55] <_ruben> persia: ah ok .. could be something "new" as well .. my previous line was based on comments i picked up ages ago .. and i might even have misinterpreted those, hence the "iirc" ;) [14:55] Heya gang [14:56] Well, I could still be wrong :) === solarion_ is now known as Solarion === elky is now known as Guest10403 === tseliot1 is now known as tseliot === yofel_ is now known as yofel [17:04] will there be apt2 in lucid? http://juliank.wordpress.com/2009/12/13/apt2-progress-report-for-the-1st-half-of-december/ [17:20] any requests for sessions at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep or sessions you'd like to give there? [17:20] I guess I could wait until after the net split and ask again :-) [17:25] any requests for sessions at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep or sessions you'd like to give there? [17:31] maybe something about working with debian? [17:54] http://thechive.com/2009/12/15/daily-morning-randomness-25-photos-14 === yofel_ is now known as yofel [18:45] is mario limonciello in here? [18:47] superm1: ^ [19:00] what's up bjsnider ? [19:01] well, i was looking at some of the changes you made to the nvidia package in your ppa [19:01] and then i was looking at upstream debian [19:01] and i wondered which direction this is going to take [19:02] debian has created an nvidia-libvdpau-driver package, while you have put the driver into the glx package [19:02] same with cuda [19:02] i can't for the life of me figure out why debian wants to create separate packages for those two things [19:04] bjsnider, so actually tseliot is going to be driving the changes for ubuntu, and when me and him last talked we're leaning on everything in an nvidia-XYZ package [19:04] glx, vdpau (aside from the stuff in libvdpau), and kernel source [19:04] it makes no sense to decouple them [19:05] and long term trying to push debian to do the same [19:05] the stuff in my PPA is just for karmic so people have a way to use vdpau with myth and nvidia-190, i wouldn't treat it as the long term way of doing things === FlannelKing is now known as Flannel [19:06] but that is how you're doing things in your ppa [19:06] well it's still broken up with kernel source as it's own package [19:06] in my PPA [19:07] so you're planning to put the kernel-source files back into the glx package? [19:07] yeah i think that's the best way to go [19:07] and the glx package wont be called nvidia-glx-XYZ, it will be nvidia-XYZ [19:08] so if people want to switch between free<->nonfree, it's literally just one package to add or remove then, and the conflicts/replaces hopefully wont get messed up [19:08] that's amillion miles from upstream debian (right now anyway) [19:08] yeah, so it's gonna be a long term goal to push them in this direction [19:09] they're also creating an 1a32 package int he control file [19:09] unless you are closer with them, and you can help maybe? [19:09] ia32 i mean [19:10] no, i'm not close with them or anything but i don't want all of the stuff in my ppa to be very far away from what's un ubuntu, or it could cause upgrade issues in the future [19:10] right [19:10] i think it's fairly safe to just use what you're doing in the ppa [19:10] well tie off with tseliot next time he's online [19:10] in #ubuntu-x usually [19:11] he's the one driving most of these changes [19:11] i don't want to have anything to do with all of that stuff they're doing upstream [19:11] we dont really treat debian as an upstream for this package currently [19:11] other than the fact that it was pulled from there once for a basis [19:11] well, someone should tell them that [19:12] bjsnider, well hopefully some day we'll all be back on the same page again [19:12] it's funny that you're talking about using the version number instead of -glx [19:12] but remember they have different goals and schedules, so sometimes it will take time for that to happen [19:12] because they're using -glx and not the version number [19:13] i don't think scheduling has anything to do witht his particular issue though [19:13] i have no idea what their golas might be [19:13] goals i mean [19:14] we're in sync for libvdpau the library at least though [19:14] as soon as launchpad can sync a V3 source package, we'll be pulling in their's [19:15] i'm going to do that right now, but they added a dependency on their nvidia-libvdpau-driver virtual package, which you'll have to remove [19:15] you're not creating it [19:18] bjsnider, i thought they dropped that http://packages.debian.org/sid/libvdpau1 [19:18] it's a suggests [19:20] oh right. i was reading it wrong [19:20] yeah i raised a bug complaining about that in their first iteration === cyphermo1 is now known as cyphermox === Rhonda is now known as Gerfried === Gerfried is now known as Rhonda [21:07] what's doing autoconf patch in any package? [21:24] hum, any eclipse maintainer around ? === ikonia_ is now known as ikonia === asac_ is now known as asac [22:03] superm1, ping [22:03] bjsnider, pong [22:04] with the .53 driver, nvidia has moved its vdpau driver to /usr/lib/vdpau. is it ok to leave it there in the installation or should i move it or link it to something in /usr/lib? [22:05] that's where it should be [22:05] the libvdpau in ubuntu and debian expect it there [22:06] great. that means i can actually subtract some lines from the rules file [22:06] that rules file is hardcoding Way too much [22:06] it needs to evaluate more of this stuff dynamically [22:06] even if that means using stuff like debian/install.in and building a debian/install [22:07] well, it seems like it doesn't need the version numbers anywhere [22:07] but because it's calling out all the stuff to be installed explicitly like that, it's really hard to update when new releases come out [22:07] yes i know [22:07] it's a pain [22:07] and all of the other files too [22:08] why can't we just use all of the .in files? [22:12] take a look at how fglrx is done nowadays [22:12] its much much cleaner [22:12] i'd like to see our nvidia package looking that good [22:13] in karmic? in lucid? in a ppa? where is it? [22:14] karmic and lucid have it [22:14] apt-get source fglrx-installer === quadrispro__ is now known as quadrispro [23:43] so... where is this REVU thing and how can I fetch source from someones upload to same? [23:46] lamont: http://revu.ubuntuwire.com/ , pull-revu-source(1) in ubuntu-dev-tools [23:46] ta