[07:40] <dholbach> good morning
[07:45] <machina> 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] <maco> it has to go to the latest devel first
[07:46] <maco> but you want to make 2 debdiffs. one for each
[07:46] <persia> Well, the *fix* needs to go to the latest development environment first.
[07:46] <persia> The revision needs to be targeted to a specific environment.
[07:47] <persia> (and sometimes, especially when backporting upstream fixes, there is no special upload for the fix to the development release)
[07:47] <maco> persia: er....whats the difference with what i said?
[07:47] <maco> except that i didnt say the part about "devel might not need a special upload" like you did
[07:47] <persia> maco: Precisely the same except I used lots more words :)
[07:48] <maco> of course you did. you're persia.
[07:48] <maco> you have the most flowery speech of anyone i've ever met
[07:48] <dholbach> https://wiki.ubuntu.com/SRU
[07:48] <machina> ah ok thanks!
[08:46] <machina> I'm following the page here on packaging a new revision, https://wiki.ubuntu.com/MOTU/Contributing, and running debuild -S fails
[08:47] <machina> the last line in the output is this, dpkg-buildpackage -rfakeroot -d -us -uc -S failed
[08:47] <persia> Could you pastebin a larger chunk of your output (maybe all of it)?
[08:48] <machina> sure one sec
[08:49] <machina> http://pastebin.com/daf89cae
[08:50] <persia> "debian/control has a duplicate entry for xsensors" is probably the core error.
[08:51] <persia> By my reading, the clean: rule contains dh_testdir which is failing because of issues parsing debian/control.
[08:51] <machina> ha you're right
[08:51] <persia> And that failure stops processing of the clean rule, which stops processing of the build.
[08:52] <machina> turns out there were two repeated paragraphs in the control file, thanks persia
[10:03] <machina> 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:05] <persia> 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] <machina> persia: will do
[11:31] <bee> i can't get my motorola device get working on ubuntu 9.10. what should i do?
[11:32] <bee> anyone here?
[11:33] <maco> 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] <bee> i can't get some peripherals working on ubuntu
[11:33] <maco> oh oh wait
[11:33] <maco> ubuntuforums.org
[11:33] <maco> because the forums dont require that people be online at the same time as you
[11:43] <directhex> what kind of motorola device, though?
[11:43] <maco> directhex: person quit
[11:44] <directhex> oh. poot
[13:03] <azeem> es
[13:03] <azeem> ECHAN
[14:04] <Whoopie> jdong: Hi, how can we proceed with bug #481448?
[14:33] <wrapster> just a doubt.. apt-get upgrade will upgrade only the already installed pkgs to a higer version right
[14:34] <joaopinto> wrapster, right
[14:36] <persia> Well, not precisely.
[14:37] <persia> 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.
[14:43] <joaopinto> persia, is dist-upgrade required for that ?
[14:44] <joaopinto> isn't that the difference between upgrade and dist-upgrade ?
[14:44] <persia> No.
[14:45] <joaopinto> hum, so what's the difference ?
[14:45] <persia> dist-upgrade considers the set of changes differently.
[14:45] <joaopinto> I remember usually getting "package kept" when a package pulls a new package
[14:45] <persia> 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] <persia> 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] <joaopinto> persia, from man apt-get
[14:46] <joaopinto> upgrade
[14:46] <joaopinto> under no
[14:46] <joaopinto>            circumstances are currently installed packages removed, or packages
[14:46] <joaopinto>            not already installed retrieved and installed.
[14:47] <joaopinto> I believe you are wrong
[14:48] <persia> Well, either I'm wrong or the manpage is wrong.
[14:48] <persia> But I was sure that I'd seen the install-extra-dependencies behaviour with just an upgrade.
[14:48] <joaopinto> 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] <persia> Hrm.  Then I'm probably wrong.  I usually use aptitude, which has slightly different semantics and I must be confused.
[14:50] <persia> Thanks for the correction.
[14:50] <joaopinto> :)
[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] <persia> _ruben: Well, not quite.
[14:54] <persia> 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] <bddebian> Heya gang
[14:56] <persia> Well, I could still be wrong  :)
[17:04] <c_korn> will there be apt2 in lucid? http://juliank.wordpress.com/2009/12/13/apt2-progress-report-for-the-1st-half-of-december/
[17:20] <dholbach> any requests for sessions at  https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep  or sessions you'd like to give there?
[17:20] <dholbach> I guess I could wait until after the net split and ask again :-)
[17:25] <dholbach> any requests for sessions at  https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep  or sessions you'd like to give there?
[17:31] <EzraR_> maybe something about working with debian?
[17:54] <highvoltage> http://thechive.com/2009/12/15/daily-morning-randomness-25-photos-14
[18:45] <bjsnider> is mario limonciello in here?
[18:47] <pochu> superm1: ^
[19:00] <superm1> what's up bjsnider ?
[19:01] <bjsnider> well, i was looking at some of the changes you made to the nvidia package in your ppa
[19:01] <bjsnider> and then i was looking at upstream debian
[19:01] <bjsnider> and i wondered which direction this is going to take
[19:02] <bjsnider> debian has created an nvidia-libvdpau-driver package, while you have put the driver into the glx package
[19:02] <bjsnider> same with cuda
[19:02] <bjsnider> i can't for the life of me figure out why debian wants to create separate packages for those two things
[19:04] <superm1> 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] <superm1> glx, vdpau (aside from the stuff in libvdpau), and kernel source
[19:04] <superm1> it makes no sense to decouple them
[19:05] <superm1> and long term trying to push debian to do the same
[19:05] <superm1> 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
[19:06] <bjsnider> but that is how you're doing things in your ppa
[19:06] <superm1> well it's still broken up with kernel source as it's own package
[19:06] <superm1> in my PPA
[19:07] <bjsnider> so you're planning to put the kernel-source files back into the glx package?
[19:07] <superm1> yeah i think that's the best way to go
[19:07] <superm1> and the glx package wont be called nvidia-glx-XYZ, it will be nvidia-XYZ
[19:08] <superm1> 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] <bjsnider> that's amillion miles from upstream debian (right now anyway)
[19:08] <superm1> yeah, so it's gonna be a long term goal to push them in this direction
[19:09] <bjsnider> they're also creating an 1a32 package int he control file
[19:09] <superm1> unless you are closer with them, and you can help maybe?
[19:09] <bjsnider> ia32 i mean
[19:10] <bjsnider> 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] <superm1> right
[19:10] <bjsnider> i think it's fairly safe to just use what you're doing in the ppa
[19:10] <superm1> well tie off with tseliot next time he's online
[19:10] <superm1> in #ubuntu-x usually
[19:11] <superm1> he's the one driving most of these changes
[19:11] <bjsnider> i don't want to have anything to do with all of that stuff they're doing upstream
[19:11] <superm1> we dont really treat debian as an upstream for this package currently
[19:11] <superm1> other than the fact that it was pulled from there once for a basis
[19:11] <bjsnider> well, someone should tell them that
[19:12] <superm1> bjsnider, well hopefully some day we'll all be back on the same page again
[19:12] <bjsnider> it's funny that you're talking about using the version number instead of -glx
[19:12] <superm1> but remember they have different goals and schedules, so sometimes it will take time for that to happen
[19:12] <bjsnider> because they're using -glx and not the version number
[19:13] <bjsnider> i don't think scheduling has anything to do witht his particular issue though
[19:13] <bjsnider> i have no idea what their golas might be
[19:13] <bjsnider> goals i mean
[19:14] <superm1> we're in sync for libvdpau the library at least though
[19:14] <superm1> as soon as launchpad can sync a V3 source package, we'll be pulling in their's
[19:15] <bjsnider> 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] <bjsnider> you're not creating it
[19:18] <superm1> bjsnider, i thought they dropped that http://packages.debian.org/sid/libvdpau1
[19:18] <superm1> it's a suggests
[19:20] <bjsnider> oh right. i was reading it wrong
[19:20] <superm1> yeah i raised a bug complaining about that in their first iteration
[21:07] <ari-tczew> what's doing autoconf patch in any package?
[21:24] <joaopinto> hum, any eclipse maintainer around ?
[22:03] <bjsnider> superm1, ping
[22:03] <superm1> bjsnider, pong
[22:04] <bjsnider> 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] <superm1> that's where it should be
[22:05] <superm1> the libvdpau in ubuntu and debian expect it there
[22:06] <bjsnider> great. that means i can actually subtract some lines from the rules file
[22:06] <superm1> that rules file is hardcoding Way too much
[22:06] <superm1> it needs to evaluate more of this stuff dynamically
[22:06] <superm1> even if that means using stuff like debian/install.in and building a debian/install
[22:07] <bjsnider> well, it seems like it doesn't need the version numbers anywhere
[22:07] <superm1> 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] <bjsnider> yes i know
[22:07] <bjsnider> it's a pain
[22:07] <bjsnider> and all of the other files too
[22:08] <bjsnider> why can't we just use all of the .in files?
[22:12] <superm1> take a look at how fglrx is done nowadays
[22:12] <superm1> its much much cleaner
[22:12] <superm1> i'd like to see our nvidia package looking that good
[22:13] <bjsnider> in karmic? in lucid? in a ppa? where is it?
[22:14] <superm1> karmic and lucid have it
[22:14] <superm1> apt-get source fglrx-installer
[23:43] <lamont> so... where is this REVU thing and how can I fetch source from someones upload to same?
[23:46] <dtchen> lamont: http://revu.ubuntuwire.com/ , pull-revu-source(1) in ubuntu-dev-tools
[23:46] <lamont> ta