[00:00] I am still reading about maintainer scripts (following links etc) . On another topic I would like to get a package into universe is there some form of guide/details on what requrements it needs to meet? [00:00] No. [00:01] Basic guidelines are: lintian-clean, nicely packaged, of interest to some Ubuntu developer. [00:01] Depending on the relative cycles, it's often easier to get into Debian, and it's almost always easier to continue to maintain it in Debian. [00:02] ok its not much use to debian as it would be for the ubuntu-manual project but what does "interest to some Ubuntu developer." mean? The program is only really usefull to new users would it get in? It would basically retrive the manual in their langauage [00:03] also where should i send it? === zul_ is now known as zul [00:22] ubuntujenkins: What is this program, and waht does it do? [00:27] persia: It basically provides a way for the user to get the latest version of the manual (pdf) in their language and view it, keeping it up to date. [00:29] I say "view" but htey will just see it in their pdf reader [00:31] This really doesn't sound like more than a .desktop file. [00:32] Is there another package in which it could be sensibly included? [00:33] * persia is imagining a .desktop file and a script that checks a file location, and if absent, downloads something to make it present, and then opens a PDF viewer [00:37] persia: It does have a gui as the manual might not be avalible in their language, so we ask them to choose one and suggest the could help translate. (Thats the idea). It is a glorified .desktop file . I [00:38] I am not aware of a package we could add it to off the top of my head [00:38] I'm not sure it's enough to have meaningful value as it's own package if it's a glorified .desktop file. [00:39] You could upload it to REVU, but I believe the backlog is larger than will be processed during the maverick cycle, which makes it awkward. [00:39] And I agree there's no point trying to get it in Debian: it doesn't belong there. [00:40] ok thanks i will have a go at making it thanks for your help persia [00:41] I think our project lead will be very pleased if we get it in [00:41] persia: so since REVU queue is backlogged, if I want a new package in Ubuntu for Maverick, I should push it through Debian? [00:42] That's usually best practice anyway, unless it's a package that's interesting to have Ubuntu-local, or needs to be (e.g. for trademark reasons). [00:45] ubuntujenkins: you should read something about what debhelper is or how it works in general and then read the man page of dh_installtex [00:45] carstenh: thanks I like your script its very helpful. I think i will look in the morning its gettting late now [00:46] ubuntujenkins: dh_installtex is not used by default because it is not standard debhelper module (it's in another packge) and it should take care of the changes you need to make to the maintainer script [00:47] ok, got it I did not think i would be doing all this 4 months ago all so much fun :) [00:50] you're welcome :) http://stateful.de/~carsten/tmp/100507UsG9s93sBD8/dir2deb includes a fix for a typo, fixes displaying the error message if a required variable is not set and adds the possibility to overwrite the short and loond description using environment variables. you can check the differences using diff -u oldfile newfile [00:52] ubuntujenkins: the only change that is visible in a generated package is the typo in debian/copyright (unless you substituted it with something useful). so there is not need to rerun it for an existing package [00:52] ok thanks carstenh [00:53] s/loo../long/ === nobawk is now known as nobawk|away === nobawk|away is now known as nobawk [03:44] ScottK: I can't see any reason not to get it applied in Debian. The pkg-perl team (the real maintainer) are very responsive to applying patches that we need in Ubuntu [03:44] nhandler: Thanks. Would you please push it up to their svn? [03:45] I'll be glad to if your rather merge boost1.42. [03:45] ScottK: I can take care of it, but it will need to wait until at least the weekend. [03:46] nhandler: That's fine. It's been unmerged for almost two years, another two days won't hurt. [03:46] :) [06:55] people, what is the process for a contrib to update a package in universe [06:56] hello? [06:57] bilalakhtar: version update or patch? [06:57] micahg: version update [07:00] <\sh> moins [07:01] micahg: yes? [07:01] * micahg is looking, it's late for me :) [07:01] * bilalakhtar understands why micahg is busy [07:01] <\sh> micahg, it's never too late...;) [07:02] bilalakhtar: not only that it can be alot of things because the packaging may need updating too [07:02] <\sh> micahg, btw...are you attending the upcoming UDS? [07:02] bilalakhtar: and it may also be actively maintained in debian, and would be better to be updated there in some cases [07:02] s/some/most [07:02] imbrandon: maybe you can take over this Q [07:02] \sh: yes :) [07:02] micahg: :) [07:02] imbrandon: yeah, it requires a test build, test run, and, dch! [07:03] bilalakhtar: yes, but quite a bit before that [07:03] <\sh> micahg,nice...so we can meet in person :) [07:03] imbrandon: INCASE it doesn't work [07:03] \sh: indeed, that will be nice [07:03] imbrandon: otherwise, its simple to package, and upload [07:03] bilalakhtar: first you need to dertimine if it should actualy be updated in Ubuntu, or should it be updated in debian and synced [07:04] imbrandon: yes that is also there, but my question is, what is the process for a non-motu to do that? [07:04] bilalakhtar: THEN you download the new tar, and update the conrtol/rules/*.install as needed [07:04] bilalakhtar: here's the link I was looking for: https://wiki.ubuntu.com/MOTU/#MOTU%20Processes [07:04] bilalakhtar: the same as a MOTU the only diffrence is you need to get a sponsor to upload it once completed [07:04] imbrandon: yes, but, should I upload the package to revu or what? [07:05] \sh: night [07:05] bilalakhtar: depends on what your sponsor wishes, but normaly no [07:05] bilalakhtar: most of the time you put a diff on an LP bug or Debian BTS attachment [07:05] <\sh> micahg have a good one :) /me just starts to work :( [07:05] * micahg needs to be up in 6 hrs :( [07:06] imbrandon: thanks. using pbuilder to do some stuff right now :) [07:06] imbrandon: but one cannot update a universe package in a stable release like karmic or lucid, right? but we can do it for maverick? [07:07] right , well you can but it must follow SRU policys [07:08] imbrandon: if its just a small update, like from 3.1.2 to 3.1.5 [07:08] then what? [07:08] bilalakhtar: again though if your updating to a new version please make sure you shouldent be doing it in debian first [07:08] bilalakhtar: dosent matter how small or big , still folows same steps [07:08] bilalakhtar: and thats 3 revisions so its a larger update :) not a small one [07:10] imbrandon: fine, now I am getting training on how to pakage well :) [07:10] bilalakhtar: :) its a long processes with alot of variables [07:11] thats why its hard to give a solid awnser, almost every package needs individual attention [07:11] imbrandon: yes, and you people, as motus, may be getting a lot of needs-packaging bugs and all the stuff! [07:12] sure, but most needs-packaging should be filed as ITP's in debian [07:12] only the rare case does it nned to be in ubuntu first [07:13] imbrandon: yes, its *better* to upload to debian and then sync [07:15] bilalakhtar: not only better but damn near a requirement depending on your sponsor [07:15] imbrandon: yeah [07:17] This is a debian question: Where can I find info on how to get packages into debian on wiki.debian.org? [07:18] bilalakhtar: http://www.debian.org/devel/wnpp [07:19] and mentors.debian.net [07:19] imbrandon: thanks [07:21] bilalakhtar: np [07:22] bilalakhtar: its alot to take in, if you have more specific questions be sure to ask :) [07:22] ( i'm sure you will ) [07:22] imbrandon: these are the reasons why windoze stinks. no community support. no way to add packages to the windows repo (there isn't one) ! [07:36] imbrandon: so I should target debian squeeze and ubuntu maverick? [07:36] Debian unstable. uploading towards squeeze is almost never right. [07:37] persia: isn't squeeze the debian unstable right now? [07:37] sorry I am new to debian packaging, though I know about ubuntu packaging [07:37] No. [07:38] what is unstable? [07:38] sid [07:38] what is squeeze then? [07:38] its called "unstable" though, they dont use the names in the changelog as ubuntu does [07:38] Debian has a permanent "unstable" repository. Packages that are in that repository and unbuggy for a configured amount of time are copied into the "testing" repository, which happens to currently be "squeeze". [07:38] sqeeze is testing [07:39] oh, I got confused when I came to debian. feeling at home with ubuntu [07:39] moins persia [07:39] hey imbrandon [07:39] bilalakhtar: they are very similar and very diffrent at the same time ;) [07:39] * bilalakhtar creates a chroot for maverick [07:39] bilalakhtar: If Debian confuses you, stick to bugfixing in Ubuntu for a while, rather than packaging/updating new stuff. [07:40] bilalakhtar: yea i second what persia just stated [07:40] After you've become familiar with the tools, etc. Debian may make a lot more sense. [07:40] * persia doesn't think new packaging or updating is a good place to start *at all*: it's like jumping in the deep end of the pool when one is learning to swim [07:40] persia, imbrandon: thanks for your lecture :) [07:41] heh yea, or an ocean [07:41] if your comming form windows [07:41] * bilalakhtar has been fixing bugs for a while now [07:41] i tend to think that reviewing patches and turning them into candidate uploads is a good place to start [07:41] maco: agreed [07:41] imbrandon: no, I switched to ubuntu when gutsy came [07:42] have used hardy, intrepid, jaunty, karmic and now lucid [07:42] bilalakhtar: :) [07:42] not to forget the GUTSY! [07:42] great [07:42] I took up app development in ubuntu a year ago [07:42] bilalakhtar: We don't mean to imply you're not active: we just haven't seen you around that much yet, and like to suggest easy stuff at first :) [07:43] (at least not around in *this* channel: I've certainly seen you lots of other places) [07:43] persia: maybe in #ubuntu-offtopic [07:43] bilalakhtar: definately but it is ALOT to take in, i started somewhere arround breezy's release and still have alot to learn ;) [07:44] imbrandon: wow, you have been here since the BREEZY BADGER? [07:44] i ahve be developing since then, i was using before that, yes [07:45] as has persia and ajm*itch and Scot*tK and TONS of other ubuntu-dev's ;) some of us are quite old-ish [07:45] imbrandon: you develop in which languages? [07:45] bilalakhtar: mono,php and c++ mostly , although the last year or so i've been picking up some python [07:46] imbrandon: I develop in php, c++, gave up python just a month ago [07:46] I didn't get any major libraries to have a python bin ding [07:46] *binding [07:46] huh? [07:47] like, you can see a media player I am currently developing, https://launchpad.net/gnome-media-player [07:47] python has a binding for almost everything ;) [07:47] imbrandon: does python have a libvlc binding? gstreamer binding? [07:47] yes and yes [07:47] and its trivial to wrap other things like mplayer [07:47] but python can never match the vast library support of c [07:49] infact i just wrote a proof of concept python qt app that used gstreamer to play some rtsp streamd mkv videos 2 days ago, in like ~100 loc [07:49] :) [07:49] even had pretty qt overlayed controls on the video surface :P [07:50] oh, just found python bindings for libvlc and gst :) [07:50] hehe yea , youb be suprised at the vastness of python binding and libs [07:51] imbrandon: ok, find a way to create a kernel module in python :) [07:52] hahaha right tool for the job, when you only know one language everything looks like a nail [07:52] imbrandon: but c is the only language in which you could make a kernel module [07:53] c/c++ is about perfect for kmods, cuz its not too low level like asm to where its proc specific, but still can be compiled standalone [07:53] static* [07:54] praise gcc, the gnu compiler collection! the app without which gnu/linux wouldn't be like what its now ! [07:55] and rapid app dev is done well in python or ruby or gambas , everything has its place ( then you can always optimize parts that need c++ or asm later ) :P [07:55] imbrandon: agreed. php would be my language of choice of it had better support for cli and many people had it installed by default [07:55] php-gtk should become official [07:56] Please, no. [07:56] bilalakhtar: heh if you only knew hahahahah i love php, but then again i feel the right tool for the job is applicable there too, but dont get me wrong where most people here would write a bash or python script i write php-cli apps :) i have a few dozen on my hdd i've written for various things over the years [07:57] but most ( /me looks at persia ) would kill me for it ;) [07:57] imbrandon: yeah, I also prefer php and love it, for many reasons [07:58] * bilalakhtar has his maverick shroot ready [07:58] *chroot [07:58] 99% of the time php is my "fallback" if i need something done *NOW* i do it in php, then i find the best tool for it after [07:58] I've just never seen a "best coding guidelines" doc for PHP. [07:58] And most of the PHP stuff I've seen can be broken with a bit of effort. [07:58] one more thing where php is the best is its manual [07:59] persia: there really isnt one, there are alot of best practices but its like perl, its chnaged so much over the years [07:59] But I wouldn't kiil anyone: I tend to grab make when I want something done quick-like, and I know most folks don't prefer it. [07:59] the *best* and *most documented* manual. every function has a page [07:59] bilalakhtar: i have to agree, the php docs are BY FAR the best i have ever had to use [08:00] that and its hard to find a webserver that dosent support PHP and thats where i make my $$ ( i re-brand websites for people/companys ) [08:01] ;) [08:03] but i also use it for many things most would cringe at, like i have a 34k+ file mp3 collection that i backup,index, and manipulate nightly on cron via php, and then serve up a frontend to access it while i'm away form $HOME [08:04] i wasent happy with any of the available solutions at the time ( arround 2001 ) so i made my own, it has grown form a simple ~30 line script to a fill blown suiet of php scripts even with their own conffiles and debian package [08:04] ;) [08:06] i should really re-write it in c# or c++ someday, but i never seem to have the tuits and i put a ton of hours into the php already [08:06] :) [08:07] what would be really nice is if rhythmbox started using something like couchdb , then i could replicate the db from rhythmbox nightly and use that as a backend for my frontend [08:08] but that dident exist ~8.5 years ago [08:08] and i would be tied to one gui [08:08] <\sh> imbrandon, shouldn't be a rpoblem to integrate couchdb into rhythmbox [08:09] Does it really make sense to replicate the metadata but not the data? [08:10] <\sh> RAOF, just attach your mp3s to the couchdb database documents...there you go ;) but I wonder if it's really a good idea to replicate 10G of mp3s ;) [08:10] good morning [08:10] <\sh> hey dholbach [08:10] Or ~40GiB of assorted mp3, wavpack, flac and aac :) [08:10] hi \sh [08:10] RAOF: the data is replicated via rsync nightly anyhow, i want the metadata for my front end [08:11] my php script spends about ~60 minnutes a night reindexing the meta data [08:11] to put into a mysqldb [08:11] for my frontend [08:11] <\sh> But what would be nice to tell rhythmbox to sync some of the music files via desktopcouch to ubuntu one (or an eventually opensourced compatible service) and have your data also synced to other computers you have hands on ;) [08:12] <\sh> imbrandon, I have ampache running at home :) [08:12] \sh: yea i've looked at Ampache, its close to what i have, but i did my first and long before that one [08:13] It would be nice to have Banshee play from my U1 account on all my computers… [08:13] one sec lemme see if i can add a .htaccess entry for ya for a moment to look at it [08:15] \sh RAOF : http://bobsmusic.sytes.net/ user:temp pass:brandon [08:15] thats the "front end" [08:16] ( be kind to it, its on my cable modem ) [08:17] <\sh> garry glitter ... I see that we have a very similar taste of music ;) [08:18] \sh: lol, i have a littel bit of everything [08:18] little* [08:18] imbrandon: how do I force pbuilder to use maverick archive? [08:18] <\sh> ok...it looks like ampache without the shinyness ;) [08:19] I added that line in .pbuilderrc, in my package dch, what else? [08:19] \sh: yup exactly, but arround way way before ampache ;) [08:19] <\sh> imbrandon, :) [08:19] bilalakhtar: depends on your pbulder setup, first you must have a maverik base.tgz [08:20] bilalakhtar: something like "DIST=maverick sudo pbuilder create" should work [08:20] imbrandon: I added the line in .pbuilderrc, then ran build, do I need to do something else also? [08:21] bilalakhtar: something like "DIST=maverick sudo pbuilder build some.dsc" should work [08:21] its DISTRIBUTION=maverick [08:21] ok, then, I will run update --override-config [08:21] bilalakhtar: like i said depends on your pbuilder setup ;) mine i have the DIST varible [08:22] create seemed to recognise the distribution variable, but not build [08:22] when I ran create, it said "Distribution is maverick" [08:23] does that mean I have a maverick base? [08:23] should , but as i said it all depends on the .pbuilderrc and the rest of the setup, pbuilder is very very custom per person/setup [08:24] basicly just go through the same steps you did to make a lucid one [08:29] bilalakhtar: http://paste.debian.net/72368/ [08:29] bilalakhtar: thats my pbuilderrc for refrence [08:29] got it. I am updating base.tgz [08:30] good [08:33] \sh: imbrandon@enterprise:/storage/websites/bobsmusic.sytes.net$ du -sh /storage/users/imbrandon/Music [08:33] 83G /storage/users/imbrandon/Music [08:33] a little more than 10g :) [08:35] <\sh> imbrandon, hehe [08:39] * imbrandon turns off access since this channel is logged , dont want everyone eating up my bandwidth === lifeless_ is now known as lifeless [09:04] lifeless: Why is your mugshot an upside-down person? [09:05] because he's upside down? [09:08] kiko's sense of humour [09:08] then I decided I liked it [09:08] heh or hes downunder [09:12] lifeless: Why is your mugshot an upside-down person? [09:12] and again... [09:12] ajmitch: I went offline [09:12] so missed the answer *probably* [09:12] blame my connection [09:16] 03:05:29 < ajmitch> because he's upside down? [09:16] 03:08:25 < lifeless> kiko's sense of humour [09:16] 03:08:29 < lifeless> then I decided I liked it [09:16] 03:08:30 < imbrandon> heh or hes downunder [09:29] ajmitch: i updated the packages on p.u.c to include the rythmbox-ubuntuone-music-store now too, and filed an ITP for it today [09:37] though it'll only work when rb uses python 2.6 [09:38] nah i made it work with 2.5 [09:39] it works on my sqweeze laptop now [09:39] the packages a a mess of mix between 2.5 and 2.6 though lol [09:40] everything is forced 2.6 except for the musicstore which is forced 2.5 to work with rb [09:40] but it "works" just not clean as i'd like [09:42] i'd really like to hear from jak soon, so i can poke him to atlease update aptdaemon and software-center, and possible give us the ITP's === traveller__ is now known as traveller [11:01] People, I have uploaded a new version of the package "clamtk" to revu on http://revu.ubuntuwire.com/p/clamtk . I have run a test build using pbuilder, checked for errors using lintian, filed bug #576902 [11:01] Launchpad bug 576902 in ubuntu "New upstream version of ClamTk" [Undecided,New] https://launchpad.net/bugs/576902 [11:17] People, I have uploaded a new version of the package "clamtk" to revu on http://revu.ubuntuwire.com/p/clamtk . I have run a test build using pbuilder, checked for errors using lintian, filed bug #576902 [11:17] Launchpad bug 576902 in ubuntu "New upstream version of ClamTk" [Undecided,New] https://launchpad.net/bugs/576902 [11:19] Why are people joining and leaving this channel so much? [11:20] That's what happens [11:20] you can ignore them if you like (I have) [11:21] Laney: Are you a motu? === nobawk is now known as nobawk|away === nobawk|away is now known as nobawk [11:32] * Laney goes suspiciously quiet [11:33] * bilalakhtar searches for a sponser for an updated package [11:34] you should just use the sponsor queue [11:34] Laney: what sponsor queue? [11:34] where is it? [11:34] I have subscribed the bug to the ubuntu-sponsors team [11:36] that's it [11:37] james_w: According to the schedule on https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews , you are reasy to sponsor packages now [11:38] bug number? [11:38] 1 sec [11:38] bug #576902 [11:38] Launchpad bug 576902 in clamtk "New upstream version of ClamTk" [Undecided,Invalid] https://launchpad.net/bugs/576902 [11:39] james_w: oh didn't see the recent comment. sorry. no need to review === nobawk is now known as nobawk|away === nobawk|away is now known as nobawk === nobawk is now known as nobawk|away === lifeless_ is now known as lifeless === nobawk|away is now known as nobawk [14:01] * stefanlsd makes my people i need to buy a beer list for uds [14:25] stefanlsd: It might be easier to grab a keg [14:26] azop: hehe. yeah. def :) [14:27] stefanlsd: with that in mind, what can I do to help you so I get added to the list? [14:37] azop: haha. i'll buy u one anyways. just find me [14:52] Hello :) [14:52] Could you have a look to the last two revisions of php5-mcrypt ? https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/php-mcrypt/lucid [14:53] It looks like patches were applied in the wrong order [14:53] (on lucid) [14:54] zul, ping [14:54] pong [14:54] ah, great [14:54] zul, cf. my last messages =) [14:55] mirsal: k...ill hhave a look when i get a chance [14:55] zul, Thanks [14:56] (it should be trivial) [14:58] Could an ubuntu-sru person take a peek at bug 576660 please? [14:58] Launchpad bug 576660 in soprano "soprano crashes on multiple simultaneous queries" [Medium,In progress] https://launchpad.net/bugs/576660 [14:58] The reporter happens to be upstream of an affected app, so I'd like for this to not get lost in the morass [15:03] JontheEchidna: jdong is probably your best bet. He's got a ton of projects to get done before the semester ends so he's probably procrastinating. [15:03] ScottK: procrastinattion 101 :D [15:11] <\sh> ./mirror_lucid --to-laptop && echo "done" [15:24] JontheEchidna, Can you attach a debdiff or link to bzr branch revision? [15:25] cody-somerville: debdiff attatched [15:27] why do you guys prepend kubuntu_ to your patch filenames? [15:27] To distinguish from patches that come from Debian. [15:29] Conincidentally, there's a spec to make things a bit more sane in that regard: https://wiki.kubuntu.org/Kubuntu/Specs/MaverickPatchPolicy [15:30] The naming scheme, and patch policy in general for kubuntu [15:30] * jpds wishes we had ubuntu_* patches. [15:33] <\sh> jpds, wasn't that somewhere documented, that we should use "ubuntu_" prefix for ubuntu patches? [15:33] I thought we were going to use patch tags or something for that. [15:35] <\sh> cody-somerville, inside the patch file...but it would be nice to see before what is "upstream" patch (means: debian patches) and what is ubuntu only [15:38] \sh, Can you give a use case? [15:39] if I'm working with the files locally, executing grep is almost as easy as executing ls. [15:39] Last day of https://wiki.ubuntu.com/UbuntuOpenWeek starts in 21m in #ubuntu-classroom with "Introduction to Ubuntu Development" [15:40] plus, patch tags or just good ol' revision control would give greater flexibility to see who did what since a patch could easily start upstream but then by modified by Debian and then be modified by Ubuntu. are you going to have upstream_debian_ubuntu_01_blah.patch? [15:43] wow. I actually really don't like that spec. Adds way too much confusion/bureaucracy, especially for new contributors or contributors not familiar with Kubuntu policies, for very little benefit when a good comment in the patch could be so much more helpful and accurate. [15:47] JontheEchidna, Your SRU request needs a bit of improvement. Please describe the change that is actually being made (ie. the commit message is pretty descriptive). Also although the patch being done upstream and upstream history can be a factor in your regression analysis, the meat and potatoes should be based on the actual change your proposing. [15:56] *you're [16:07] <\sh> cody-somerville, I can't right now without searching....but in general...even when someone only changes some sources which are "ubuntu specific" (e.g. launchpad integration in the help menu)... [16:08] <\sh> anyways...I think we have enough time next week to discuss some of those little things ;) [16:08] * \sh still needs to setup something for next week [16:15] dholbach: what are tasks of day-to-day maintenance ? [16:16] ari-tczew: I'm giving a open week session right now [16:16] ari-tczew: can you mail me? [16:16] dholbach: sure [16:17] thanks [16:34] cody-somerville: fixed [16:43] JontheEchidna, have you tested the patch yourself? [16:43] cody-somerville: yes, it fixes the crash with the given testcase === jcastro_ is now known as jcastro [16:45] JontheEchidna, I'm not really sure you provided the information I requested. The commit message says "Instead of checking for the connection state in the current thread, actually try to connect.". I'm curious as to the affect that will have and if it could potential cause other crashes or maybe memory/descriptor leaks. [16:46] All I know, is that upstream made a point to release a bugfix release for this patch, and upstream is going to get pissy with us if we don't include it. [16:50] temugen: say, maybe your python skills could help me some more... so far I have been doing this by hand with grep and sed... could you whip something up that can take the ureadahead --dump output and translate it into a file that lists their inode numbers, one per line? [17:35] JontheEchidna, Although I appreciate the delicacy of maintaining healthy relationships with upstream developers, === nobawk is now known as nobawk|away [17:37] JontheEchidna, the objective here is to protect our users from regressions while providing a critical fix to a stable release. [17:38] cody-somerville: If there's s clear test case and the diff is reasonable, I think that's what the procedure requires. [17:39] the rest will be taken care of during the verification-needed bit [17:44] I don't like the idea of blindly applying patches from upstream SVN which is why I want to see some level of understanding of the change being made. [17:46] This is not blindly taking a patch from upstream svn. It is isolating the major fix of a point release of the software, as is SRU protocol, in order to solve a regression that makes an application very unstable. [17:47] JontheEchidna, Thats why if you link to say a changelog then it'll help me get that. [17:47] http://soprano.sourceforge.net/node/46 [17:47] as I suspected, the fix is "quick and ugly". [17:48] obviously clean enough to warrant a point release from upstream,though [17:51] JontheEchidna, So, I'm curious if when soprano tries to connect, does it have to explicatively close the connection? What are the ramifications of it trying to connect every time isConnected() is called? [17:55] JontheEchidna, I can understand why you want to provide this fix to users. However, from my perspective I think a little extra care here is warranted since this is a "quick and ugly fix" (sic). [17:56] Hi all... I've some doubts about quilt use: I created patch as described in this tutorial: [17:56] http://www.debian.org/doc/maint-guide/ch-modify.en.html [17:57] now, have I to add some lines in debian/rules to make sure build operation calls quilt patches? [17:59] cody-somerville: if there is already a connection, connectInCurrentThread() will return the existing socket [18:00] so it will not result in creating connections that will never be closed [18:00] psusi: yea, no problem [18:14] From what I've seen in the comments, the whole socket architecture needs redone, which is likely why the fix was called "quick and ugly" [18:14] a stopgap measure for a class that really just needs redone [18:16] JontheEchidna: what's the testing scope of the upstream fix? e.g. how many distros/users have adopted that solution? [18:17] JontheEchidna: I totally sympathize with the motivation to adopt upstream's workaround, but I've been-there-done-that with KTorrent's "trade one race condition for another" approach, and I'd hate to go through a SRU verification cycle just to get a new batch of slightly different versions of this bug [18:19] jdong: Fedora has pushed the entire 2.4.3 (this fix plus what looks like some apidocs updates) to Fedora 11, one of their stable releases [18:19] JontheEchidna: fedora's also pushed iptables packages with the binary missing, alsa packages that can't even install due to nonexistent dependencies.... more importantly than them pushing, what have their users reported? [18:20] (oh yeah, they also had a bind9 update that shipped a conf file with mismatched braces.) [18:23] Right. They would be the ones who did so great with KDE that Linus switched to Gnome. [18:24] they also switched over to 4.0 the first release they could [18:24] temugen: a few caveats about it though... 1) symbolic links need followed and their destination looked up instead, and 2) could you separate the directories from normal files? it seems that normal files don't share the buffer cache of the block device, so I need to read directories through the block device, and normal files the normal way, so I'd like to keep them separate on the disk [18:24] Same thong [18:24] thong/thing [18:25] psusi: do you want it to print JUST the inodes? [18:26] temugen: basically... defrag wants a list of inodes to prioritize... one inode number per line... it also takes a priority number though, so basically I want a line that says "=-2" then all of the directory inode numbers, then a line that says "=-1" followed by all of the normal file inode numbers [18:26] ok [18:27] that should pack the directories first, where they can be read quickly through the block device, then the files, which can be read normally... all without seeking [18:27] JontheEchidna: I mean don't get me wrong, Fedora's awesome, but good judgement in pushing out updates is not their claim to fame. The information I'd like to hear from Fedora is "1000 users installed and there's concensus it fixed the bug" type feedback from the users [18:28] I'm unable to upload a package on revu. The last upload was for lucid the 15th feb 2010 but it was signed with another pgp key, however the currently key I'm using to sign the package is imported in launchpad. Any idea? [18:29] temugen: eventually I'd like to have the package build an alternate initrd for you to choose from your grub menu that will parse the pack file, delete it, then defrag using that information to optimize, and reboot [18:33] <\sh> ok...guys...I'll see you at UDS...(arrival: sunday around 1700 GMT+2) [18:33] psusi: hmmm.... does ureadahead list any directories in the dump? [18:34] psusi: I stat'd every realpath and check S_ISDIR, but came up with no directories [18:35] JontheEchidna: anyway, bottom line is, cody-somerville and I are not trying to be bureaucratic jerks making your life harder... We'd just like to make sure you're filing this SRU because you believe it'll fix the bug, not because upstream committed a hackish fix and we're being puppets and following along for the fun of it [18:35] if you have that confidence in the fix, I'm willing to give you the SRU approval [18:37] temugen: it does in my version ;) [18:38] temugen: ohh, and probably going to need --root parameter so you can run it on a fs mounted in /mnt for example [18:39] or a --pack parameter in general. [18:40] think --root... because you will need to prepend that to each path when stating it [18:40] I just pushed a script with fragraph (that relies on fragraph) [18:40] but what about --root/--pack now? :) [18:41] ok, so you want a prefix added? [18:41] temugen: if I mount the fs in /mnt from say, a livecd, there needs to be a way for that to work... normally ureadahead --dump looks for the dump on the current root, which won't work from a livecd [18:41] ok [18:42] jdong: it does fix the bug. I've confirmed that [18:42] JontheEchidna: If an SRU is too hard, I'll approve a backport. [18:42] so need to point ureadahead to the pack file in /mnt, and then the file names it spits out will be relative to /mnt, so need to add /mnt when stat()ing [18:42] do you have /sys /dev to work with too? (since this script just uses Ureadahead from fragraph, it needlessly reads in the block device too) [18:42] though actually I think ureadahead does not support --dumping a pack file from another system either... [18:42] hrm... [18:43] JontheEchidna: ok, I'll give an ACK for the bug to continue testing then :) sorry for the hassle [18:43] psusi: I can allow you to pass in a dump of a packfile and you specify a prefix? [18:43] temugen: do you run ureadahead --dump, or do you parse the pack file yourself? [18:43] psusi: I can do either [18:43] Thank you. I will be perfectly fine to let it go if the verification process catches regressions in -proposed [18:44] how does it work now? [18:44] psusi: I do ureadahead --dump, but I can make it so you pass in a filename of --dump output [18:45] temugen: yea, then to work from another system either ureadahead needs fixed, or you have to run ureadahead in a chroot... hrm.. [18:45] psusi: right now it does ureadahead --dump, needlessly reads /sys /dev stuff like it does for fragraph, and then goes through stat'ing realpaths and checking if they're directories or not [18:45] JontheEchidna: thanks. I've commented on your bug report. [18:45] what does it look in /sys and /dev for? [18:46] psusi: it finds the device from the dump and uses it to pass into blockdev to get sizes [18:47] ohh, to know how big to make the graph? [18:47] psusi: for various things, yes [18:47] hrm... actually, I guess nevermind on the --root parameter... will just need to run it after chrooting into the mounted fs [18:47] for now... [18:48] psusi: alright, just ping me if you want something modified [18:49] cool, thanks [18:49] I'll give it a try tonight... must.... break... 10 second barrier... [18:50] psusi: that would be awesome :) [18:51] psusi: and you did point out in needs to follow symbolic links before grabbing the inode, doesn't that mean some of the symlink names are too long to fit in the inode? [18:51] I had it down to 13 or 14 seconds last night [18:51] it needs* [18:51] temugen: dunno... don't care really... I just want to make sure the REAL file is packed in the proper place ;) [18:52] though actually I guess stat() will follow the symlink to the real file won't it? it's lstat that doesn't [18:52] psusi: does ureadahead seek to read the symlink first to find the realpath, though? [18:52] psusi: and yea, you're right. [18:52] all I know is that when I was running ls -i at first, it gave me the inode number of the symlink instead of the file it points to, hehe... [18:53] it will if the link is too long to fit in the inode, but I don;t think a typical system has any of those [18:54] psusi: ok, that's fine, I wasn't sure. 13 seconds is awesome :) [18:54] I think I can get it down to 8 ;) [18:54] maybe 7 [18:55] O_O [18:55] my ssd boots in 5 ;) === mok0_ is now known as mok0 [19:01] ohh, actually I just scanned for non fast symlinks with find / -mount -type l | xargs du and it did find a few [19:02] hrm.. quite a few actually... [19:03] psusi: possibly prioritize those inodes as well? :) [19:03] * psusi wonders wtf there are font files in /var/lib for on a server [19:03] temugen: no need if they aren't used by ureadhead ;) [19:04] psusi: no no, of course. just wondering if you want me to list any if they exist in the dump with the python script [19:04] I wouldn't worry about it for now... [19:04] ok [19:06] I seem to have a bunch of symlinks in /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType that point way over to /usr/share/fonts/some/retardedly/long/name... which is odd seeing as this is a server install [19:06] headless [19:22] LOTs of long symlinks in /usr/lib/python2.6/dist-packages... hrm... [19:22] Please don't break the Python symlinks. [19:23] hoho... not breaking any symlinks... was just checking to see if there are many that could benefit from being moved by the defragger [19:23] I'm surprised to find so many long ones [19:24] what are all these needed for? [19:24] Just be glad we don't also have python2.5 anymore or there'd be a lot of similar symlinks for /usr/lib/python2.5/site-packages [19:24] what are they all for and could they not use hard links instead? [19:26] when we have a package with delta from debian, its not autosynced next cycle? [19:26]