[00:18] <Jarvis> Is it valid to advise somone to upgrade from karmic > lucid, for futher updates? The package the users bug report refers to (miro) appears to be a new major revision in lucid and above.
[00:26] <cjwatson> Jarvis: well, karmic is no longer supported ...
[00:26] <Jarvis> kk, i just wanted to make sure before i went ahead and did so :p
[00:30] <directhex> karmic->lucid is a supported move to make, and lucid still receives updates. so "yes"
[00:36] <highvoltage> hey broder
[00:39] <Jarvis> would someone mind tagging 423514 as won't fix for me please? Thanks.
[00:40] <paultag> Jarvis: just because Karmic is EOL does not mean it's WONTFIX
[00:40] <Jarvis> oh ?
[00:40] <paultag> Jarvis: you should have asked to test on the most recent version and verify it's not still present
[00:41] <Jarvis> ok
[00:41] <paultag> Jarvis: bryce marked that high, so it was a bug and an important one at one point
[00:41] <broder> highvoltage: hey, how goes?
[00:49] <Jarvis> thanks paultag
[00:49] <paultag> Jarvis: sure. Keep rock'n.
[00:57] <highvoltage> broder: hey good thanks and you? tomorrow I'll have some time for backports, not 100% sure where to start though but I guess I'll just dive in and get an idea of what seems important right now
[01:00] <broder> highvoltage: lucid-backports is probably the best place to start, just because it's the worst off at the moment
[01:02] <highvoltage> broder: yep I thought so too
[01:02] <broder> highvoltage: certainly a lot of those bugs aren't actually backports bugs
[01:03] <broder> or affect packages too core to legitimately test
[01:03] <broder> (i think someone requested an natty -> lucid openssh-client backport, for instance)
[01:03] <broder> when i've had time, i've mostly focused on trying to keep maverick and natty under control, so i haven't really done much triage on lucid
[01:07] <highvoltage> broder: at work we're planning to upgrade a lot of hardy servers (and vz guests) to lucid so I'll probably look into lucid server backports too if I find ones that are interesting
[01:08] <broder> highvoltage: sounds awesome. feel free to ping me if you find bugs that are ready to go, but don't feel like you need feedback before asking the reporter for additional work
[01:10] <highvoltage> ok great, thanks
[01:33] <highvoltage> broder: https://bugs.launchpad.net/lucid-backports/+bug/795602 requests the backport from natty. would it be better to get it from oneiric instead or should a backport come from a stable release?
[01:34] <broder> backport aptitude> ahhh. that on its own sounds terrifying, but let me take a look
[01:34] <broder> generally we're fine with backports from dev releases
[01:34] <broder> (we do have packages in natty-backports already, for instance)
[01:35] <highvoltage> (ah)
[01:36] <highvoltage> well if it looks like aptitude will be complicated for some reason then I could probably find something simpler to start with
[01:36] <broder> i dont' think it's necessarily complicated, although i do see a bunch of problematic factors in play
[01:37] <broder> so here's what i see when i look at that bug:
[01:37] <broder> (a) i bet aptitude has a fair number of rdepends
[01:37] <broder> (b) an oneiric -> maverick backport would also require a oneiric -> natty backport, with all the testing that entails. natty -> maverick would definitely be easier
[01:37] <broder> (c) "I've just run into this nasty bug in aptitude" immediately says to me "maybe this should be an SRU of some sort"
[01:38] <highvoltage> ah I haven't really considered B much
[01:39] <highvoltage> but yes it does indeed sound more like a candidate for an SRU
[01:39] <broder> looking at the debian bug, the patch to support preferences.d is pretty miniscule. i would probably ping the SRU team and see what they thought of SRU'ing that patch
[01:40] <highvoltage> so what usually happens during upgrades? does update manager remove backports or do you just stay with your backport until a newer one from the archive arrives?
[01:40] <broder> update-manager will leave backports turned on
[01:40] <broder> which is why we require the intermediate upgrades
[01:40] <broder> example:
[01:41] <broder> if maverick has 0.1, natty has 0.2, and oneiric has 0.3
[01:41] <broder> and you want to backport oneiric to maverick
[01:41] <broder> you also have to backport oneiric to natty
[01:41] <highvoltage> ok
[01:42] <broder> there should never be a valid release upgrade path (LTS or normal) that causes the version number of a package to decrease if you have backports turned on on both ends
[01:47] <highvoltage> ok, I don't quite understand why yet but I'll remember that
[01:48] <broder> i think update-manager might treat it as vanished from the archive or something like that
[01:49] <highvoltage> ah yes
[01:50] <highvoltage> is there a tracker for SRUs?
[01:51] <highvoltage> (I guess I should just google for that instead of pesting :p)
[01:54] <broder> there is an sru tracker, but i can't find it at the moment
[01:54] <broder> http://people.canonical.com/~ubuntu-archive/pending-sru
[01:55] <broder> (linked from !sru)
[01:55] <broder> ahem
[01:55] <broder> !sru
[01:56] <highvoltage> yeah I smikked through that just before asking :)
[01:56] <highvoltage> *skimmed
[04:38] <paultag> Hey, MOTU. Anyone know if there's a feed anywhere of uploaded packages?
[04:39] <micahg> paultag: the $RELEASE-changes lists on lists.u.c?
[04:39] <micahg> an actual feed? idk...
[04:39] <ajmitch> there used to be an rss feed from that
[04:39] <paultag> micahg: I'm looking for something easily machine digestable, so I can report stuff back to my Nook
[04:39] <paultag> yeah I remember something like that ajmitch
[04:40] <ajmitch> seveas used to have that somewhere, I don't know what currently exists for it
[04:41] <paultag> hurmm.
[04:44] <micahg> paultag: the archives for lists.ubuntu.com should be machine parseable to some extent
[04:44] <ajmitch> http://feeds.ubuntu-nl.org/UbuntuChanges says they were going away only last month, fwiw
[04:45] <paultag> humm
[04:45] <paultag> I wonder if it's not worth it to integrate into Launchpad, since it parses all this (and has time data) anyway
[04:46] <ajmitch> launchpad already has some feeds, hidden somewhere
[04:46] <ajmitch> but I don't know if there's anything for packages accepted into the archive like -changes is
[04:46] <lifeless> not of uploads
[04:46] <lifeless> patches accepted to add one
[04:46] <lifeless> or you can use the API
[04:46] <paultag> lifeless: I don't want to klobber lp over the api
[04:46] <paultag> I try to be nice :)
[04:46] <ajmitch> polling the API is probably less efficient than adding a rss feed view
[04:47] <paultag> ajmitch: yar, and moreso if it's statically rendered
[04:47] <lifeless> efficiency is very hard to judge without looking at the implementation :)
[04:47] <lifeless> the feeds are not static
[04:47] <paultag> something like ubuntu changes should (and can) be :)
[04:47] <lifeless> paultag: we do 4M API requests a day; we can handle the odd query from you
[04:48] <lifeless> paultag: making it static is only a win if its accessed more often than it changes.
[04:48] <ajmitch> now I remember, it was bugs that had rss feeds that I could see
[04:48] <lifeless> ajmitch: yes, and projects
[04:48] <lifeless> we have a framework to add feeds; its a bit over engineered
[07:53] <dholbach> good morning
[08:06] <tumbleweed> ~
[08:27] <dholbach> hey tumbleweed
[08:27] <dholbach> how are you doing?
[11:04] <c_korn> what could be the reason why dpkg-gensymbols does not output anything for a package which definitely has a shared library in usr/lib ?
[11:06] <Ampelbein> c_korn: libraries not in debian/tmp and wrong -P option?
[11:07] <c_korn> the library has to be in debian/tmp also?
[11:09] <c_korn> the files are here: $ ls debian/libsph1/usr/lib/*.so*
[11:09] <X3lectric> can someone help me fix this https://launchpadlibrarian.net/73961702/buildlog_ubuntu-lucid-i386.nvidia-graphics-drivers_275.09.07-0ubuntu1~lucid1~ppa9_FAILEDTOBUILD.txt.gz
[11:09] <c_korn> and now dpkg-gensymbols -plibsph1 outputs nothing
[11:09] <c_korn> Ampelbein: ^
[11:10] <Ampelbein> c_korn: 'dpkg-gensymbols -plibsph1 -Pdebian/libsph1'
[11:11] <c_korn> Amaranth: oh, ok. did not know I had to give both arguments. thank you!
[11:11] <c_korn> eh, Ampelbein
[11:15] <tumbleweed> dholbach: hi. sorry, busy morning
[11:15] <dholbach> tumbleweed, no worries :)
[11:15] <X3lectric> morning tumbleweed
[11:16] <X3lectric> morning dolbach
[11:16] <X3lectric> tumbleweed I fixed the erros but now I get a really odd one
[11:16] <X3lectric> https://launchpadlibrarian.net/73961702/buildlog_ubuntu-lucid-i386.nvidia-graphics-drivers_275.09.07-0ubuntu1~lucid1~ppa9_FAILEDTOBUILD.txt.gz
[11:16] <dholbach> hi X3lectric
[11:17] <tumbleweed> X3lectric: you know you can build and debug the build locally rather than try an dguess from PPA build logs
[11:18] <tumbleweed> but in this case, the reror seems pretty clear
[11:18] <X3lectric> tubleweed, prolly but like I said I dont know jack about packaging
[11:18] <X3lectric> its all a stab in the dark
[11:19] <X3lectric> yes but the rules file i dont get where its causing that
[11:21] <X3lectric> I the first extraction happens and then a second
[11:21] <X3lectric> http://pastebin.com/hpsEPwmQ
[11:21] <X3lectric> i cant see how that happens
[11:25] <X3lectric> the only way to prevent it is to commnet out the only 86_64 --extract after the driver has been made executable
[11:26] <X3lectric> since I have no clew where the first extract is ocurring
[11:31] <X3lectric> Ive emailed one driver maintainer but hes got 3 emails didnt wanna spam him
[11:48] <X3lectric> tumbleweed: commenting the only extract worked O.o
[11:48] <X3lectric> its built 1386
[11:49] <X3lectric> makes zero sense
[11:55] <X3lectric> danged ISP
[12:39] <X3lectric> its building ok for karmic and lucid just waiting for the amd64 builds
[12:40] <X3lectric> thx for your "help"
[12:40] <X3lectric> definetly thank you for taking the time
[12:41]  * X3lectric thinks tumbleweed is doing exactly what nick suggests
[12:45] <Laney> there's really no need to be rude to people
[12:59] <X3lectric> who was rude
[13:01] <X3lectric> Laney: I hope that wasnt directed at me, since i dont see where any rudeness was implied
[13:35] <cjwatson> X3lectric: making comments about people's nicks and associated inactivity is generally considered rude
[13:36] <dholbach> barry will give a session about porting to dh_python2 in #ubuntu-pyjam in 24 minutes
[13:38] <X3lectric> cjwatson: only if you dont have a sense of humour and thats the first time I ever heard such "unspoken" rules beside if it was rude im sure Tumbleweed can tell me himself.
[13:40] <X3lectric> as I said no rudenss was implied, your guys are suggesting staright away some sort of malice, that is kinda jugdmental which is actually rude...
[13:45] <X3lectric> dholbach: do you have some packaging experince as in starting from source?
[13:46] <dholbach> X3lectric, I would suggest looking at similar packages and how it's done there and also check out http://people.canonical.com/~dholbach/packaging-guide/html/debian-dir-overview.html
[13:46] <dholbach> X3lectric, I need to take my dog for a walk now - best just ask questions in here - I'm sure somebody else can help you find an answer
[13:47] <X3lectric> oh what dog you have? have a nice walk...
[13:48] <X3lectric> im looking for a partner/mentor not necessarily help
[13:48] <dholbach> http://murphy.holba.ch/_IMG_2563.html - thanks - see you later :)
[13:49] <X3lectric> laters :p
[13:49] <X3lectric> oooooohhh cute...
[14:35] <tumbleweed> X3lectric: I chose my nick for a reason, sure :) I'm happy to provide some help, but not going to do all the work for you. (I'm also a full time student who has a thesis to finish, and I can't spend all day playing with linux)
[14:41] <X3lectric> I wouldnt expect anyone do do all work for me.... some people think that because i made a commnet about your nickname that was rude [12:41] * X3lectric thinks tumbleweed is doing exactly what nick suggests
[14:42] <tumbleweed> X3lectric: no problem
[14:42] <X3lectric> Honestly im shocked that peopel are so jugmental since there was no malice intended
[14:44]  * X3lectric actually thinks being jugdmental is actually very rude, more so then making some innocuous/humourous comment
[14:45] <tumbleweed> X3lectric: I have no desire to continue that part of the discussion, don't worry about it. But also, be patient.
[14:45] <X3lectric> tumbleweed: I actually managed to fix the problems with the slew of erros and kicked the ppa backside into gear
[14:46] <X3lectric> tumbleweed: ya I think im patinet after being at this for nealry a week
[14:47] <X3lectric> tumbleweed: good luck with thesis
[14:48] <tumbleweed> X3lectric: it took me months to get my first packages into ubuntu. A week isn't much. And I think everyone has to prioritise their time based on their own idea of what's important.
[14:53] <ScottK> X3lectric: If you're trying to get a package into Ubuntu, you might also consider trying to get it into Debian from where it will be automatically sync'ed into Ubuntu.  See mentors.debian.net.
[14:54] <tumbleweed> ScottK: he's maintaining some backported drivers in a PPA
[14:54] <ScottK> Oh.
[14:54] <ScottK> OK.
[14:54]  * ScottK is busy with $work and not following the details.
[14:56] <X3lectric> its not backported lol
[14:57] <X3lectric> its actually new upstream releases
[15:01] <X3lectric> ScottK: I would release into debian but I already have enough problems to be jusmping through more hoops
[15:02] <ScottK> It may actually be easier for new packages for updates to existing ones though you'd have to work with the existing maintainer.
[15:02] <X3lectric> exactly
[15:04] <X3lectric> the keyowrd being having to work with someone else most likely in another timezone and not intersted in doing what Im doing
[15:05] <X3lectric> current maintainers dont want to do it and stopped doing anything less than natty they no longer intersted
[15:05] <ScottK> Nevermind then.
[15:06] <X3lectric> im neverminding hehe
[15:06] <X3lectric> i wouldnt mid some help and mentoring
[15:07] <X3lectric> thats not likely either ;)
[15:23] <ScottK> If you have specific questions I may be able to answer them.  I can't promise any general help.
[15:23] <X3lectric> notanymore but thx
[17:32] <nigelb> jtaylor: I remember you once told me what the most common fix for the LD change fix was when using autotools.
[17:32] <nigelb> jtaylor: What was it it? I forgot and my grep of logs don't find it :(
[17:32] <jtaylor> wrong use of LDFLAGS instead of LIBS or LDADD
[17:33] <nigelb> so, switching that to LIBS or LDADD should possible fix it?
[17:33] <jtaylor> if autotools orders the commandline wrong, yes
[17:34] <nigelb> awesome, I'll try that. thanks!
[21:44] <Laney> warp10: I am uploading sparkleshare to oneiric now
[22:05] <directhex> realization: i'm not enough people to shepherd the mono 2.10 transition solo, given pressures on my time.
[22:06] <ajmitch> ok, order in some minions
[22:14] <directhex> one of the biggest bits of work needing doing is getting monodevelop working in pure 4.0-only form. i don't have time to work on the little bits
[22:20] <Laney> write an email to the lists calling for help
[22:21] <Laney> (and mention to check with us if unsure)
[22:22]  * ajmitch digs around for a local branch of monodevelop
[22:40] <directhex> Laney, ubuntu-motu@ you reckon?
[22:40] <Laney> directhex: probably too dead. that and devel
[22:41] <micahg> there'e already a nice pretty transition for mono :)
[22:43] <directhex> micahg, needs more warm bodies though. i can only do a handful of packages a day if that
[22:43]  * ajmitch heard that Laney has plenty of spare time for it
[22:43] <Laney> busy writing perl
[22:43] <ajmitch> a likely story
[22:44] <ajmitch> damn alioth
[22:44] <ajmitch> finally able to clone with git+ssh on a new sid VM, had to run ssh-agent & add the other ssh key
[22:45] <micahg> directhex: after I get the stuff I need for the libnotify transition done, I might be able to help, is a no change rebuild usually enough?
[22:45] <ajmitch> http://wiki.debian.org/Teams/DebianMonoGroup/Mono210TransitionTODO is the debian list, there are a bunch of other possible fixes
[22:46] <directhex> micahg, mostly no-change or simplistic changes (e.g. tweaked build-deps). the trick is that *apps* need to be done first. when all apps are done, libs & plugins can be done
[22:47] <directhex> micahg, sadly the apps are more likely to need tweaking than the libs
[22:47] <directhex> anyway, back to monodevelop
[22:47] <micahg> directhex: I assume the transition hierarchy reflects that?
[22:47] <directhex> micahg, nah, ben is stupid and shows pretty much the exactly wrong order.
[22:48] <micahg> :(
[22:48] <micahg> directhex: well, apps first is the exact opposite of everything else
[22:49] <directhex> micahg, basically, a 4.0 app can load 2.0-3.5 libs. the reverse is not true.
[22:49] <micahg> hi xnox` are you still interested in xiphos
[22:50] <micahg> directhex: ah, that's a nice feature, makes sense, but wouldn't the 2.0-3.5 libs be NBS and still around for the apps?
[22:50] <jtaylor> will it does not always work, keepass2 for example does not run with 2.0 libs
[22:54] <micahg> oh, now I remember, mono has a special way of "registering" libs
[22:55] <ajmitch> mono is special in lots of ways
[23:11] <Awsoonn> hi all, I'm wondering if there is a wiki page for debugging unity that you can point me to
[23:12] <Awsoonn> I just upgraded to unity and got myself a blank desktop. :(
[23:18] <micahg> Awsoonn: https://wiki.ubuntu.com/Unity/FilingBugs
[23:19] <Awsoonn> micahg: thax
[23:42] <xnox`> micahg: yes, I'm kinda interested in xiphos. xulrunner is getting killed right?
[23:50] <xnox`> micahg: I'm going to sleep. I have commented on the xiphos bug on lp. I see it's targeted for alpha2. There is similar bug report in debian. I will look into them.
[23:50] <xnox`> I'm off to sleep now. Hopefully will catch you tomorrow (~UTC time)