[06:31] <nigelb> tumbleweed: still stuck, yes. Let me get the debdiff. I got past one problem and hit another.
[08:05] <dholbach> good morning
[11:24] <X3lectric> is there anyone who is a expert with debian packaging? I require some help with some packaging that should work on ppa and fails to build yet teh only differnce is the version of the packges being built
[11:24] <X3lectric> https://launchpad.net/~x3lectric/+archive/nvidia-vdpau
[11:25] <X3lectric> the nvidia drivers fail to build yet the packaging is identical to https://launchpad.net/~team-iquik/+archive/nvidia-vpau/+packages
[11:26] <X3lectric> tried variatons of the packging and erros make 0 sense + im not that savvy
[11:26]  * X3lectric n00b
[11:30] <tumbleweed> X3lectric: what are you trying to do? backport drivers?
[11:32] <X3lectric> er no
[11:32] <X3lectric> not backport
[11:33] <X3lectric> its actual debian packages for those distros
[11:33] <X3lectric> https://launchpad.net/~team-iquik/+archive/nvidia-vpau/+packages
[11:33] <X3lectric> see the drivers there were built ok on this ppa https://launchpad.net/~x3lectric/+archive/nvidia-vdpau
[11:33] <tumbleweed> X3lectric: backport means build for an older release
[11:34] <X3lectric> I know
[11:34] <X3lectric> backpost mean using the current debian packaging which is not the case
[11:34] <X3lectric> backport
[11:34] <tumbleweed> the version that's failing to build on lucid and karmic (which is out of support, btw) is the version currently shipping in oneriric
[11:35] <X3lectric> yea but look at the 270 version bilt ok back then
[11:35] <tumbleweed> I'm not suprised it's not building on lucid or karmic, they look like complicated packages and could easily depend on things only available in newer relaeses
[11:35] <X3lectric> now it wont even build those
[11:35] <X3lectric> not a dependency issue
[11:36] <tumbleweed> well, not a stated dependency
[11:36] <X3lectric> ok lemme explain
[11:36] <X3lectric> https://launchpad.net/~team-iquik/+archive/nvidia-vpau/+packages
[11:36] <X3lectric> the packages there for drivers
[11:37] <X3lectric> they built ok
[11:37] <X3lectric> now if I upload ppa7 to superceed the same packages and rebuild with no changes except that it fails
[11:37] <tumbleweed> err no, I see a different version in that PPA
[11:38] <X3lectric> Show details nvidia-graphics-drivers - 270.41.19-0ubuntu1~lucid1~ppa4 	(changes file) 	x3lectric 	2011-05-23 	Published 	Lucid 	Misc 	All builds were built successfully.
[11:38] <tumbleweed> yes. 270.41.19. Your failing build is 275.09.07. Not identical
[11:39] <X3lectric> I tried to uplaod same packages because the 275 were failing and now the 270 also fail
[11:39] <tumbleweed> you can't upload an older version. Version numbers can only go up
[11:39] <X3lectric> yes
[11:40] <X3lectric> i tried it on a differnt ppa
[11:40] <micahg> tumbleweed: well, if the binaries were never published you can (even if they were you still can)
[11:41] <X3lectric> problem is the 270 can no longer be built evn if they suceeded a few weeks ago
[11:41] <X3lectric> they fail with same error as the 275
[11:42] <tumbleweed> micahg: sure
[11:42] <tumbleweed> X3lectric: the exact same source package that built before? Is it not because of something else in the ppa that was updated?
[11:42] <tumbleweed> anyway, let's look at one issue at a time
[11:43] <X3lectric> I didnt do the packaging for lucid or karmic Im reusing previous packaging by other people only modifying the drivers versions on the stated files
[11:43] <X3lectric> ok
[11:43] <X3lectric> pls
[11:44] <X3lectric> if you can help and guide me
[11:51] <X3lectric> tumbleweed: I used dget -xu https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/+files/nvidia-graphics-drivers_270.29-0ubuntu1%7Elucid%7Exup2.dsc
[11:52] <X3lectric> that I modifies for the 270.41.19
[11:53] <X3lectric> so every file that mentioned the 270.29 I updated it to match the newer version
[11:54] <X3lectric> took 6 tries to build on ppa
[11:54]  * tumbleweed is having a quick look, but these packages are big and gnarly. I'd suggest getting more familiar with debian packaging, with simpler packages.
[11:54] <X3lectric> right
[11:55] <X3lectric> since no one guided me at all untill now
[11:55] <tumbleweed> basically, as you can see from the build log, the error is in debian/nvidia_supported
[11:55] <X3lectric> and i dont have problems with smaller packages
[11:56] <X3lectric> ok
[11:56] <X3lectric> so something in nvidia supported wasnt correctly updated?
[11:56] <X3lectric> i dont understand the error
[11:57] <tumbleweed> read the source, and you can see where it came from
[11:59] <tumbleweed> however, in this case I'm guessing the problem is that rules.lucid isn't included any more (and thus presumably the logic that would make it use rules.lucid, so maybe you need to see what that was doing differently
[11:59] <tumbleweed> or you could talk to the guy who maintains it, but I doubt he's that interested in backports to karmic :P
[11:59] <X3lectric> correct me if im worng
[12:00] <X3lectric> but the debian packages as long as their origin is the distro they inteded for they should build any version of drivers or packages as long as the changes point to new versions where applicable
[12:01] <tumbleweed> theoretically yes, assuming the maintainer cares enough to specify all the correct versioned dependancies and all the necessary quirks for older releases
[12:02] <tumbleweed> practically, *well* maintained packages tend to be backportable to supported releases, but may require other backports too, and complicated packages are very likely to require modifications
[12:02] <X3lectric> even if the origin of the packages are based on official releases
[12:02] <tumbleweed> yes
[12:02] <X3lectric> those since are official should already be sorted that way
[12:03] <tumbleweed> no
[12:03] <X3lectric> what you mean no
[12:03] <tumbleweed> just because a package is in an officaial release doesn't mean it can be backported with no changes. There is no such requirement.
[12:03] <X3lectric> but im not backporting
[12:05] <X3lectric> what tells the ppa to build the official version should work and already account for all dependencies
[12:05] <X3lectric> heck the fact that what use to build ok now doesnt tells me the error is somewhere else
[12:06] <X3lectric> but since im not any sort of expert its illogical and i dont have skills to correct what not only doesnt make sense why it fails but its beyond my skills
[12:09] <X3lectric> for e,g thers a erro it says Failed to find the list.... what list?
[12:09] <tumbleweed> read the script that outputs the error. I don't know what list either, it looks like a symbol list, but I'm not about to invest an hour or two in understanding this package
[12:09] <Laney> the source will tell you
[12:10] <X3lectric> if [ "$ret" -eq 0 ]; then
[12:10] <X3lectric>     printf '%s\n' '# List generated by nvidia_supported. Do not edit manually.'
[12:10] <X3lectric>     while read id; do
[12:10] <X3lectric>       printf 'alias pci:v%08Xd%08Xsv*sd*bc03sc*i* %s %s\n' \
[12:10] <X3lectric>         0x10de "0x$id" "$modname" "$pkgname"
[12:12] <X3lectric> ive extracted the driver packages and the output except for the driver verdion is same
[12:12] <X3lectric> heck all files are same
[12:12] <X3lectric> except for in this case driver version numbers
[12:14] <tumbleweed> but what's inside them is different, and this script looks inside them to generate the modaliases
[12:15] <X3lectric> I actually dont need the modaliases since im not using gdm
[12:16] <X3lectric> thers a note on the drivers
[12:16] <X3lectric> # This is a nasty kluge, but it seems to work. Better check the output when
[12:16] <X3lectric> # upgrading to a new release of the nvidia driver, though.
[12:17] <X3lectric> thast on the nvidia_current
[12:17] <tumbleweed> yes, I read that file
[12:18] <X3lectric> i mean nvidia_supported
[12:18] <tumbleweed> if you don't need it, don't call it from debian/rules
[13:33] <X3lectric> ill try and see
[14:07] <c_korn> how can I prevent that quilt edit opens a new instance of gedit? in 10.10 just a new tab was opened
[15:00] <c_korn> how can I prevent that quilt edit opens a new instance of gedit? in 10.10 just a new tab was opened
[15:03] <tumbleweed> c_korn: export a sensible value for $EDITOR ?
[15:04] <c_korn> actually I have an alias for quilt: alias quilt="EDITOR=gedit quilt"
[15:05] <Ampelbein> c_korn: add --new-document to $EDITOR
[15:12] <c_korn> Ampelbein: this has strange effects. if I open a new gedit instance and type something without saving, quilt edit now opens the to be edited file in the same instance as a tab but also creates a new empty tab. if I open a text file in gedit and then quilt edit then the to be edited file is opened in a complete new instance and also a new empty tab is created.
[15:14] <Ampelbein> c_korn: that sounds indeed strange. can you test what happens if you manually open some files with gedit fromt he command line?
[15:16] <c_korn> gedit <file 1> creates the first instance of gedit and opens the file (the gedit process runs in the terminal so I cannot run another command there). I open another terminal and run gedit <file 2>. the file is opened in the same gedit instance as a tab and the gedit process ends there in the terminal so I can type another command
[15:19] <c_korn> Ampelbein: ^
[15:21] <Ampelbein> c_korn: that sounds about right (you can prepend '&' to the command line to continue work in one terminal)
[15:22] <tumbleweed> although quilt will need to have a way of knowing that you've finished editing (normally when the command returns, it's done. I'm a vim user, so I don't know how you are supposed to do that)
[15:23] <c_korn> why does quilt have to know about finished editing? It should just pick the state when I do quilt refresh. If I was still editing there, then it is my fault.
[15:23] <tumbleweed> oh, fair enough
[15:24] <c_korn> quilt edit for me is just a shortcut for me for quilt add and manually opening the file
[15:24] <tumbleweed> yes
[15:24]  * tumbleweed is sufferincg from lack of sleep, which is probably why I'm lurking on IRC
[15:25] <c_korn> heh ;)
[15:25] <Ampelbein> c_korn: after some testing it seems to be a gedit problem. If I do 'gedit doc1 &' and (in the same terminal) do 'gedit --new-document doc2' I get a new empty tab
[15:30] <ScottK> tumbleweed: Sounds like the perfect time for a complex merge.
[15:30] <tumbleweed> heh
[15:43] <c_korn> Ampelbein: what is --new-document supposed to do now? is the new empty tab intentional when opening a file with --new-document?
[15:45] <Ampelbein> c_korn: hmm, maybe I read the man page wrong and it just means to open a new document in a new tab.
[15:45] <Ampelbein> c_korn: I thought it was an option to open the file in a new tab instead of new window.
[15:46] <Ampelbein> c_korn: but testing it further it seems that 'gedit doc1 & gedit doc2' does the right thing and only opens one instance of gedit.
[15:48] <c_korn> Ampelbein: which would mean the problem is in quilt?
[15:50] <Ampelbein> c_korn: fwiw, I can't reproduce the issue in oneiric.
[15:51] <c_korn> hm, ok. which means it is already fixed.
[15:51] <c_korn> now we need to backport the patch
[15:52] <Ampelbein> c_korn: quilt hasn't changed in over a year
[15:53] <c_korn> hm, so it has to be gedit which changed
[18:19] <c_korn> does someone know about a policy for packaging gem applications?
[18:20] <paultag> c_korn: they just changed policy, I got a mail about it
[18:21] <paultag> c_korn: let me see if I can dig it up, I got it a bit ago
[18:21] <paultag> c_korn: http://pastebin.com/2d1Wa1KS
[18:22] <paultag> c_korn: http://wiki.debian.org/Teams/Ruby/RubyInWheezy#Changes_to_rubygems_packaging ← that might be what you're looking for
[18:26] <c_korn> paultag: awesome, thank you very much!
[18:26] <paultag> c_korn: rock on, man
[18:54] <pcpratts> hi.  is there a way to dynamically build a menu for a debconf template?
[18:54] <pcpratts> I tried to modify the appropriate templates file in /var/lib/dpkg/info
[18:55] <pcpratts> is there a tool I need to run to re-sync the modified template?
[19:04] <pcpratts> okay I got it
[19:04] <pcpratts> sorry for bothering