[00:18] 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] Jarvis: well, karmic is no longer supported ... [00:26] kk, i just wanted to make sure before i went ahead and did so :p [00:30] karmic->lucid is a supported move to make, and lucid still receives updates. so "yes" [00:36] hey broder [00:39] would someone mind tagging 423514 as won't fix for me please? Thanks. [00:40] Jarvis: just because Karmic is EOL does not mean it's WONTFIX [00:40] oh ? [00:40] Jarvis: you should have asked to test on the most recent version and verify it's not still present [00:41] ok [00:41] Jarvis: bryce marked that high, so it was a bug and an important one at one point [00:41] highvoltage: hey, how goes? [00:49] thanks paultag [00:49] Jarvis: sure. Keep rock'n. [00:57] 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] highvoltage: lucid-backports is probably the best place to start, just because it's the worst off at the moment [01:02] broder: yep I thought so too [01:02] highvoltage: certainly a lot of those bugs aren't actually backports bugs [01:03] or affect packages too core to legitimately test [01:03] (i think someone requested an natty -> lucid openssh-client backport, for instance) [01:03] 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] 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] 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] ok great, thanks [01:33] 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:33] Ubuntu bug 795602 in lucid-backports "Please backport aptitude 0.6.3-3.2" [Undecided,New] [01:34] backport aptitude> ahhh. that on its own sounds terrifying, but let me take a look [01:34] generally we're fine with backports from dev releases [01:34] (we do have packages in natty-backports already, for instance) [01:35] (ah) [01:36] well if it looks like aptitude will be complicated for some reason then I could probably find something simpler to start with [01:36] i dont' think it's necessarily complicated, although i do see a bunch of problematic factors in play [01:37] so here's what i see when i look at that bug: [01:37] (a) i bet aptitude has a fair number of rdepends [01:37] (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] (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] ah I haven't really considered B much [01:39] but yes it does indeed sound more like a candidate for an SRU [01:39] 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] 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] update-manager will leave backports turned on [01:40] which is why we require the intermediate upgrades [01:40] example: [01:41] if maverick has 0.1, natty has 0.2, and oneiric has 0.3 [01:41] and you want to backport oneiric to maverick [01:41] you also have to backport oneiric to natty [01:41] ok [01:42] 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] ok, I don't quite understand why yet but I'll remember that [01:48] i think update-manager might treat it as vanished from the archive or something like that [01:49] ah yes [01:50] is there a tracker for SRUs? [01:51] (I guess I should just google for that instead of pesting :p) [01:54] there is an sru tracker, but i can't find it at the moment [01:54] http://people.canonical.com/~ubuntu-archive/pending-sru [01:55] (linked from !sru) [01:55] ahem [01:55] !sru [01:55] Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [01:56] yeah I smikked through that just before asking :) [01:56] *skimmed === lifeless_ is now known as lifeless [04:38] Hey, MOTU. Anyone know if there's a feed anywhere of uploaded packages? [04:39] paultag: the $RELEASE-changes lists on lists.u.c? [04:39] an actual feed? idk... [04:39] there used to be an rss feed from that [04:39] micahg: I'm looking for something easily machine digestable, so I can report stuff back to my Nook [04:39] yeah I remember something like that ajmitch [04:40] seveas used to have that somewhere, I don't know what currently exists for it [04:41] hurmm. [04:44] paultag: the archives for lists.ubuntu.com should be machine parseable to some extent [04:44] http://feeds.ubuntu-nl.org/UbuntuChanges says they were going away only last month, fwiw [04:45] humm [04:45] I wonder if it's not worth it to integrate into Launchpad, since it parses all this (and has time data) anyway [04:46] launchpad already has some feeds, hidden somewhere [04:46] but I don't know if there's anything for packages accepted into the archive like -changes is [04:46] not of uploads [04:46] patches accepted to add one [04:46] or you can use the API [04:46] lifeless: I don't want to klobber lp over the api [04:46] I try to be nice :) [04:46] polling the API is probably less efficient than adding a rss feed view [04:47] ajmitch: yar, and moreso if it's statically rendered [04:47] efficiency is very hard to judge without looking at the implementation :) [04:47] the feeds are not static [04:47] something like ubuntu changes should (and can) be :) [04:47] paultag: we do 4M API requests a day; we can handle the odd query from you [04:48] paultag: making it static is only a win if its accessed more often than it changes. [04:48] now I remember, it was bugs that had rss feeds that I could see [04:48] ajmitch: yes, and projects [04:48] we have a framework to add feeds; its a bit over engineered === medberry is now known as med_out [07:53] good morning [08:06] ~ [08:27] hey tumbleweed [08:27] how are you doing? === korn_ is now known as c_korn [11:04] 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] c_korn: libraries not in debian/tmp and wrong -P option? [11:07] the library has to be in debian/tmp also? [11:09] the files are here: $ ls debian/libsph1/usr/lib/*.so* [11:09] 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] and now dpkg-gensymbols -plibsph1 outputs nothing [11:09] Ampelbein: ^ [11:10] c_korn: 'dpkg-gensymbols -plibsph1 -Pdebian/libsph1' [11:11] Amaranth: oh, ok. did not know I had to give both arguments. thank you! [11:11] eh, Ampelbein [11:15] dholbach: hi. sorry, busy morning [11:15] tumbleweed, no worries :) [11:15] morning tumbleweed [11:16] morning dolbach [11:16] tumbleweed I fixed the erros but now I get a really odd one [11:16] https://launchpadlibrarian.net/73961702/buildlog_ubuntu-lucid-i386.nvidia-graphics-drivers_275.09.07-0ubuntu1~lucid1~ppa9_FAILEDTOBUILD.txt.gz [11:16] hi X3lectric [11:17] X3lectric: you know you can build and debug the build locally rather than try an dguess from PPA build logs [11:18] but in this case, the reror seems pretty clear [11:18] tubleweed, prolly but like I said I dont know jack about packaging [11:18] its all a stab in the dark [11:19] yes but the rules file i dont get where its causing that [11:21] I the first extraction happens and then a second [11:21] http://pastebin.com/hpsEPwmQ [11:21] i cant see how that happens [11:25] the only way to prevent it is to commnet out the only 86_64 --extract after the driver has been made executable [11:26] since I have no clew where the first extract is ocurring [11:31] Ive emailed one driver maintainer but hes got 3 emails didnt wanna spam him [11:48] tumbleweed: commenting the only extract worked O.o [11:48] its built 1386 [11:49] makes zero sense [11:55] danged ISP [12:39] its building ok for karmic and lucid just waiting for the amd64 builds [12:40] thx for your "help" [12:40] definetly thank you for taking the time [12:41] * X3lectric thinks tumbleweed is doing exactly what nick suggests [12:45] there's really no need to be rude to people [12:59] who was rude [13:01] Laney: I hope that wasnt directed at me, since i dont see where any rudeness was implied [13:35] X3lectric: making comments about people's nicks and associated inactivity is generally considered rude [13:36] barry will give a session about porting to dh_python2 in #ubuntu-pyjam in 24 minutes [13:38] 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] 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] dholbach: do you have some packaging experince as in starting from source? [13:46] 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] 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] oh what dog you have? have a nice walk... [13:48] im looking for a partner/mentor not necessarily help [13:48] http://murphy.holba.ch/_IMG_2563.html - thanks - see you later :) [13:49] laters :p [13:49] oooooohhh cute... [14:35] 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] 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] X3lectric: no problem [14:42] 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] X3lectric: I have no desire to continue that part of the discussion, don't worry about it. But also, be patient. [14:45] tumbleweed: I actually managed to fix the problems with the slew of erros and kicked the ppa backside into gear [14:46] tumbleweed: ya I think im patinet after being at this for nealry a week [14:47] tumbleweed: good luck with thesis [14:48] 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] 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] ScottK: he's maintaining some backported drivers in a PPA [14:54] Oh. [14:54] OK. [14:54] * ScottK is busy with $work and not following the details. [14:56] its not backported lol [14:57] its actually new upstream releases [15:01] ScottK: I would release into debian but I already have enough problems to be jusmping through more hoops [15:02] 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] exactly [15:04] the keyowrd being having to work with someone else most likely in another timezone and not intersted in doing what Im doing [15:05] current maintainers dont want to do it and stopped doing anything less than natty they no longer intersted [15:05] Nevermind then. [15:06] im neverminding hehe [15:06] i wouldnt mid some help and mentoring [15:07] thats not likely either ;) [15:23] If you have specific questions I may be able to answer them. I can't promise any general help. [15:23] notanymore but thx === med_out is now known as med === med is now known as medberry === jdong- is now known as jdong_ === jdong_ is now known as jdong [17:32] jtaylor: I remember you once told me what the most common fix for the LD change fix was when using autotools. [17:32] jtaylor: What was it it? I forgot and my grep of logs don't find it :( [17:32] wrong use of LDFLAGS instead of LIBS or LDADD [17:33] so, switching that to LIBS or LDADD should possible fix it? [17:33] if autotools orders the commandline wrong, yes [17:34] awesome, I'll try that. thanks! === Quintasan_ is now known as Quintasan === yofel_ is now known as yofel [21:44] warp10: I am uploading sparkleshare to oneiric now [22:05] realization: i'm not enough people to shepherd the mono 2.10 transition solo, given pressures on my time. [22:06] ok, order in some minions [22:14] 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] write an email to the lists calling for help [22:21] (and mention to check with us if unsure) [22:22] * ajmitch digs around for a local branch of monodevelop [22:40] Laney, ubuntu-motu@ you reckon? [22:40] directhex: probably too dead. that and devel [22:41] there'e already a nice pretty transition for mono :) [22:43] 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] busy writing perl [22:43] a likely story [22:44] damn alioth [22:44] finally able to clone with git+ssh on a new sid VM, had to run ssh-agent & add the other ssh key [22:45] 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] http://wiki.debian.org/Teams/DebianMonoGroup/Mono210TransitionTODO is the debian list, there are a bunch of other possible fixes [22:46] 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] micahg, sadly the apps are more likely to need tweaking than the libs [22:47] anyway, back to monodevelop [22:47] directhex: I assume the transition hierarchy reflects that? [22:47] micahg, nah, ben is stupid and shows pretty much the exactly wrong order. [22:48] :( [22:48] directhex: well, apps first is the exact opposite of everything else [22:49] micahg, basically, a 4.0 app can load 2.0-3.5 libs. the reverse is not true. [22:49] hi xnox` are you still interested in xiphos [22:50] 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] will it does not always work, keepass2 for example does not run with 2.0 libs [22:54] oh, now I remember, mono has a special way of "registering" libs [22:55] mono is special in lots of ways [23:11] hi all, I'm wondering if there is a wiki page for debugging unity that you can point me to [23:12] I just upgraded to unity and got myself a blank desktop. :( [23:18] Awsoonn: https://wiki.ubuntu.com/Unity/FilingBugs [23:19] micahg: thax [23:42] micahg: yes, I'm kinda interested in xiphos. xulrunner is getting killed right? [23:50] 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] I'm off to sleep now. Hopefully will catch you tomorrow (~UTC time)