=== asac_ is now known as asac === tgm4883_laptop_ is now known as tgm4883_laptop [01:41] <_2> can someone point me at my problem here http://ubuntu.pastebin.us/?show=d308f1395 ? [01:45] hello everybody [01:46] _2: I'm not sure what you're actually asking. What are you trying to do? [01:47] <_2> RAOF just get the package manager un hung [01:47] <_2> RAOF can't install xorg because of that dependancy [01:49] _2: Oh, right. Well, that's probably a question for #ubuntu (or a question on launchpad.net, or a bug), not here. How did the libgl1-mesa package get installed? Also, is your root partition writeable? [01:49] <_2> RAOF heh in #ubuntu i was sent here :) [01:50] _2: #ubuntu was wrong, this is a development channel :) [01:50] RAOF: maybe it's a bug [01:50] let me chech [01:50] check [01:50] nxvl: Yeah, possibly. [01:50] wow [01:50] dapper [01:50] Indeed. Oldschool. [01:51] If it's a bug, it's an infrequently triggered one :) [01:51] _2: can you please include your sources.list? [01:51] <_2> sure what it here ? only three lines [01:51] nop [01:52] on pastebin please [01:52] <_2> well more than three anyway http://ubuntu.pastebin.us/?show=d3a3294ee [01:53] <_2> i had forgotten adding src [01:54] condor? Look at my pm [01:56] <_2> oh crap that shell is not chrooted in that system. this is the sources list for that system http://ubuntu.pastebin.us/?show=d28980f52 [01:56] <_2> sorry nxvl my bad. [01:58] * Hobbsee waves [01:59] <_2> Hobbsee :) [01:59] Yo! Hobbsee! [01:59] * Hobbsee apparently has a USB stick of doom. [01:59] <_2> you too ? [02:00] <_2> nxvl apt-cache policy on that package http://ubuntu.pastebin.us/?show=d34abe004 if you want it too [02:01] yeah. it keeps shutting down the machine whenever i plug it in, anywhere in the lab. [02:01] i'm not sure why. [02:01] <_2> oh my. mines not that bad... ;/ [02:02] _2: i'm creating a dapper chroot to check :D [02:02] which is odd, as it doesn't shut down the machines in the first year labs. yet it does the third. [02:02] go figure... [02:03] <_2> nxvl k. [02:03] I would appreciate it if someone could take a look at my package for revu: http://revu.ubuntuwire.com/details.py?package=mythbuntu-log-grabber [02:15] HAH! [02:15] ! [02:15] the problem is SP3 of XP. [02:16] is it wrong of me to have to: touch config.status; $(MAKE) clean; rm -f config.status; [02:17] to have a dependable` fakeroot debian/rules clean` system? [02:20] Doesn't autotools-dev recommend that you copy their config.* on clean? [02:21] RAOF: I've never heard of that before. [02:21] RAOF: my rules file does do checking for config.sub and config.guess files. [02:22] When lintian checking in the past I've gotten errors about there being a config.{status,cache} file in my source. So I've had to delete it... then trying to make clean freaks out because there is no config.status file [02:22] Is there a proper procedure for this that you can point me at? [02:26] I think, by default, dh-make will produce something which copies the config.{sub,guess} from the autotools-dev package. [02:26] But I'm not aware of a canonical source for this info. [02:26] RAOF: You are correct [02:26] Just do that :) [02:27] RAOF: test ! -f config.status && touch config.status [02:27] :) [02:28] <_2> ummm touch is safe without testing. it only sets the timestamp [02:28] _2: i don't have any problems here, so it's not a bug [02:28] _2: I've had good results so far. THe upstream makefile seems to just hate makeing clean without config.status existing [02:28] <_2> i mean it wont blank an existing file [02:29] <_2> nxvl hmmm ok. thanks. that means something other than that package is borked causing it... ;/ [02:30] <_2> nxvl i do apreicate that. although it means more work for me... ;/ so thank you. [02:31] _2: try to reinstall the package which ships that library [02:32] <_2> nxvl that is the package. [02:32] _2: than why is it already in your system? [02:32] then* [02:33] (i'm talking about libGL.so.1.2) [02:33] <_2> and yes i know. i copied the files out of the archive testing to see if there was a problem with the package in that respect. [02:34] <_2> the files copy ok but the package when installing blanks one of them. and errors out. [02:34] <_2> http://ubuntu.pastebin.us/?show=d308f1395 [02:36] <_2> see that pastebin was after i had already "given up" on being able to find it myself. and yes i tried removinf the files contained in the package from the system and installing, same results. [02:37] <_2> but if it installs cleanly for you. then it's something on my system. and not the package. which makes me pull hair and screem... 0.o [02:38] <_2> i.e. i can copy /usr out of the package just fine. but dpkg can't [02:38] :( [02:38] I've got a question [02:39] Upstream for a package is adding a linking exception to allow adeone and openssl to be linked [02:39] Is it sufficient to just having this in the COPYING/LICENSE file, or does something more need to be done? [02:40] debian/copyright as well at the least I would say [02:41] Yeah [02:41] Upstream doesn't get the problem linking with OpenSSL -_-; [02:41] If they've got copyright headers on each file, I think they may want to add the exception to each header. [02:42] I've never seen linking exceptions in the headers [02:42] I certainly have, but I'm not sure whether they're necessary. [02:43] Yay licensing! [02:43] *rolls eyes* [02:43] debian-legal has _surely_ had to answer this at some point; maybe search the archives? [02:43] They just said add a linking exception [02:44] I can't find anything stating if it has to go in the headers [02:44] (and I've seen headers that just say "Licensed under the GPL", which flew with arch admins) [02:44] Wow. [02:45] <_2> nxvl are you done with me ? or am i waiting on something, cause i'll go if i'm just taking up space here... [02:46] sorry i get distracted [02:47] <_2> not a problem. i just don't want to become a nusense in here. [02:47] <_2> and i type a lot... [02:50] persia, ping? [02:56] _2: sorry, i can't find where the problem is [02:57] <_2> nxvl ok. again. my "thank you!" and i hate that i have spent both yours and my time in vain here. peace man. [02:58] <_2> i'll work it out somehow. ... [02:58] _2: it's never a waste of time [02:58] :D [02:59] Argh, he was IRCing as root? [02:59] ! [03:09] Cartman: "I've got a a golden ticket..." === superm1|away is now known as superm1 [03:28] NCommander: As long as it's in the upstream license file, I think it's fine (per file would be better). I've seen packages accepted that had no per file copyright statements at all as long as the verbatim copy of the license was in the tarball. [03:33] 4 hugs to anyone who will give me a revu (and hopefully ACK) of lucidlife: http://revu.ubuntuwire.com/details.py?upid=3308 [03:33] I have a package that I'm working on that contains a single perl script, but mostly C code compiled binary. Should I have an 'indep' section in my control file for the Perl script? [03:36] Are you building an arch: all package as well as the arch: any from this source? [03:37] Wasn't planning on it. The perl script probably wouldn't be that useful on it's own [03:37] How big is it? [03:38] 1.2k [03:38] I think I wouldn't bother. [03:39] Great. Didn't seem worth while at this time [03:39] The only point in splitting it out would be to save archive space and if it's that small, I don't know that you'd actually save any. [03:39] Right, but we do lots of stuff that doesn't seem worth the trouble. [03:40] Which is why I asked [03:40] I'd rather do the right thing now than be asked to fix it later [03:45] so I am trying to upload a translated .PO I made for xulrunner but there's no upload option; what do I do? [03:46] (in Launchpad) === foka_ is now known as foka [05:01] Are you a MOTU that has no time to REVU http://revu.ubuntuwire.com/details.py?package=mythstream-parser-google ? Take some Ambien and REVU it while you sleep ;) [05:12] tgm4883_laptop: commented [05:13] thanks nxvl [05:27] Fixed, thanks again nxvl [05:35] good morning [05:36] good evening dholbach [05:37] hi tgm4883_laptop [05:37] how are you? [05:38] good, just waking up - how are you? [05:39] pretty good. Tired (2138 here). Have a bunch of packages i'm trying to get REVUed [05:39] so if you are ever bored, let me know [05:39] tgm4883_laptop: I'm still a bit in catching up mode after nearly 3 weeks of holidays, so I'm likely not to be bored [05:39] tgm4883_laptop: which of the packages in the best shape you think? [05:40] best shape? [05:40] sec [05:40] give me the URL and I might check it out later [05:40] http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube [05:40] this one is best shape [05:40] all are pretty similar, but this one has been revued the most and has 1 ack [05:41] alrighty [05:41] thanks [05:42] I'm trying to come up with alternative ways of asking for a REVU [05:42] dholbach: good morning! you are early today! [05:42] hiya nxvl [05:42] nxvl: Mimi had to get up earlier today, so I decided to get up as well [05:42] oh ok [05:48] dholbach: btw, have already uploaded the pictures of india? [05:48] no, f-spot and friends have all been letting me down for flickr [05:48] so I uploaded just a few to picasa to try picasa out [05:49] but it sucks somewhat [05:49] yes it does [05:49] and I really want a tool that scales images for me, uploads them, etc [05:49] dholbach: have you tried with igal? [05:51] ah, no I didn't [05:52] igal scales all the images in a folder (with some options) and creates a plain html gallery [05:52] you can always drop the html [05:53] I'd need to select images before I do that [05:53] I did like 1100 pictures in India [05:53] igal can handle it [05:53] :D [05:54] maybe I don't want to upload them all ;-) [05:54] and IIRC it's python [05:54] * dholbach hugs nxvl [05:54] heh [05:54] * nxvl HUGS dholbach back [05:54] * dholbach is a tricky customer today [05:54] ah no igal is perl [05:54] * nxvl remembers his perl coder days [05:55] it's good that the nightmares are finished [05:55] :P [05:55] What's wrong with coding in Perl? [05:56] StevenK: the problem is not coding, is the code! [05:56] nxvl: Oh? [05:57] StevenK: try to remember 2 months later what the hell did you do on a script [05:59] nxvl: Meh. If I wrote the script, that usually isn't a problem. [05:59] * StevenK tries to find some Perl he wrote [05:59] StevenK: actually it is some times [06:00] $self->{IP_MAPPING}{$self->{ID_MAPPING}{$_}} = [$name, $_]; [06:00] See! Perfectly understandable. [06:02] * nxvl runs [06:02] screeming! [06:05] dholbach: oh, btw, your fanclub is growing [06:05] dholbach: we have 9 members [06:05] ~we-love-dholbach ? [06:06] ~dholbach-huggers [06:06] https://edge.launchpad.net/~dholbach-huggers [06:06] yooohooo! :) [06:09] dholbach: can you please confirm if the versioning thing is right [06:09] dholbach: http://revu.ubuntuwire.com/details.py?package=mythstream-parser-google [06:09] dholbach: i find it odd [06:10] nxvl: best to ask the archive admin [06:14] nxvl, i believe sistpoty recommended that type of versioning [06:14] nxvl, to point out the changed orig.tar.gz [06:14] superm1: yep, it's on the response, but i still find it odd [06:15] superm1: in that case why do we have the extra -0ubuntu1 [06:15] because the debian directory is'nt in the changed orig.tar.gz [06:19] but yeah nxvl i agree it does seem a bit out of place [06:20] yeah [06:20] since it's 1ubuntu1-0ubuntu1 [06:20] on the second part of it i see that it's not in debian but it is on ubuntu [06:21] but how did you read the first one? [06:21] it is in debian and it the 1st ubuntu revision? [06:27] heya gang [06:27] dholbach: oh, btw some guy ping me some days ago, he posted the spanish video on his blog -> http://www.blogubuntu.com/379/video-como-ser-un-motu-de-ubuntu/ [06:31] heh, my CPU is at 99% building in experimental and sid [06:31] :D [06:31] i love making my CPU work [06:37] What is a "watch file" in relation to packaging? [06:37] A file which describes how to get the upstream source and work out its version. [06:38] it helps you when you need to update your package (as in package the new upstream version) and knowing when you have to update it [06:38] I'm having trouble finding documentation which describes what this should look like [06:38] "man uscan" describes the format. [06:38] take a look at one package that ships with a watch file [06:39] nxvl: NICE :) [06:40] foxxtrot: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch [06:42] dholbach: we have almost 3K of pontential spanish contributor that saw the video [06:42] nxvl: I hope they'll all show up here! :) [06:43] me too [06:43] so we need 1) more videos and 2) more spanish videos, right? :) [06:43] foxxtrot: http://cypherm0x.blogspot.com/2008/08/more-packaging-fun.html this might help too [06:43] please add videos (and suggestions too) to https://wiki.ubuntu.com/MOTU/Videos [06:43] nxvl, RAOF: thanks [06:43] and 3) TIME! [06:43] tuxmaniac: I'll bookmark that [07:02] time to sleep [07:02] have a nice day [07:03] sleep tight nxvl! [07:03] or sleep tight, or whatever applies to your timezone [07:03] :D [07:03] dholbach: thank you, have a nice day! [07:03] gracias... === superm1 is now known as superm1|away === apachelogger_ is now known as apachelogger [08:34] morning [08:34] dholbach: thanks a lot for the acks [08:37] tuxmaniac: np [08:52] Good morning. [09:03] good morning [09:05] What are "hardy", "hardy-updates", hardy-security, hardy-backports, and hardy-proposed called? not components (those are main, universe, etc, yes?) [09:07] technically a distribution, afaik [09:08] hi all [09:09] I'm not sure if they have a name. [09:09] Hello csrealized7. [09:09] hi lulian [09:10] i have gone thru the packaging guide for motu beginners [09:10] and have achieved packaging for the software on my machine [09:10] That's great. [09:10] I want to know how should i package the new software on launchpad bug list [09:10] ? [09:10] i have an acount with launch pad [09:11] I want to have a start for contributing in ubuntu [09:12] csrealized7: Look for needs-packaging bugs - https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging [09:13] csrealized7: Those are programs requested by users to be packaged. [09:13] thnks lulian... [09:16] csrealized7: You might want to have a look at https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize too. Those bugs must be easy to fix. If you encounter any issues, don't hesitate to ask here. [09:16] good morning [09:16] Morning [09:16] lulian : thanks a lot... [09:17] No problem. [09:17] I have gone thru the documentation and will try my best..to package some software [09:18] csrealized7: Ok, it is your choice. [09:18] csrealized7, I am not sure packaging software is the best activity at this time, judging from the lack of activity on REVU [09:19] actually, i want to have a hands on packaging ........ [09:19] and also if I am not mistaken the UVF is getting close [09:20] This time next week, I believe. [09:20] so that i can fix the bugs for the packages [09:20] csrealized7, sure, but I would not expect to get those packages still available on Intrepid :P [09:21] fixing bugs and creating packages are different activities, to fix a bug you usually only need to provide the diff for the bug, you don't need to understand how to create a package (except maybe for the build command) [09:21] Fixing bugs you'll learn most of the things you need to create a package from scratch, just not all at once. [09:22] RAOF, I do not agree, you are not expect to understand what is a debian/copyright or a debian/rules or even debian/control for fixing a bug... [09:23] joaopinto: You should certainly start developing a working knowledge of some of them. [09:23] joaopinto, you're not fixing the right bugs then! [09:23] and debian/rules and debian/control are hotbeds for bugs [09:23] joaopinto: NOt debian/copyright, perhaps, but you'll need to be touching the other files! [09:23] directhex, those are packaging related bugs, not application bugs :) [09:23] thnks guys....i have learnt the packaging.....and i could understand most of it debian/...so would be very happy to have a hands on fixing bugs :)... [09:24] joaopinto, and equally valuable to the project [09:24] directhex, that was not the subject, he was mentioning that he wanted to learn package, and at the same time fix application bugs :P [09:25] joaopinto, look at it this way, if he fixes an application bug, he needs to know about debian/patches and possibly hack debian/rules too [09:25] directhex, assuming he will use debian/patches :P [09:26] joaopinto, if not, it's slappin' time! [09:27] csrealized7: Reading the documentation is not exactly ... learning the packaging. There is lot more under the hood. :-) [09:27] i believe it.... [09:28] so i tried to some practical also...but i trully believe commiting to ubuntu would tell me much more.... [09:33] just a small question.... [09:33] what is triaged status ???? [09:36] Ready to go. [09:36] As in: all the needed information is there, the priority is set correctly, and all that remains is for a dev to swoop in and fix whatever the well-identified problem is. [09:37] cool [09:37] csrealized7: https://wiki.ubuntu.com/Bugs/Status [09:38] csrealized7: And see /Importance too if you're interested. [09:39] k [09:41] Well, that's convenient. gnome-main-menu is libslab's only rdepend. [10:16] Can there be anything more fun than updating debian/copyright? [10:16] <\sh> RAOF: yes...changing licensing and then updating debian/copyright [10:17] \sh, even better, DFSGing a package by deleting things. then updating debian/copyright to mention it [10:20] Translations should be mentioned in copyright, shouldn't they. WOOOOOOOOO! [10:28] Does anyone have any idea if elisa 0.5.x is going to land in intrepid? [10:29] It'd probably be kinda cool, but elisa's in main, right? [10:30] RAOF: yes. Let me see if there is already a bug for update [10:30] Asking in #ubuntu-devel would be a better bet; but when is 0.5 out? [10:30] RAOF: It has been out for a while. Current version is 0.5.5 [10:30] Oh. Go package it up, then~! [10:30] :) [10:30] RAOF: Nah, no python expertise here. [10:31] Python's _easy_. GO! [10:34] ehm... why is elisa in main? [10:34] I have _no_ idea. [10:34] Because we want to support it with security fixes for 3 years? [10:37] * wgrant likes it when insecure things enter main. [10:37] i propose moving it to restricted, since it's utterly broken with Free 3d drivers ;) [10:40] directhex: Not so! Nouveau runs it! [10:40] * NCommander lurks in [10:40] morning [10:40] I'm bootstrapping kfreebsd-i386 for lenny [10:40] .... [10:40] Perhaps with an unusually generous definition of "run", however :) [10:41] RAOF, okay. runs it without showing white rectangles or red dots instead of labels [10:41] Intel cards are too bad? [10:43] directhex: It does pass that definition of 'run', yes. [10:43] It might accidentally segfault in mesa when playing stuff, but the _interface_ certainly works :) [10:43] morning RainCT, you have new commits \o/ [10:44] jpds: don't flood my inbox too much while I'm away ;P [10:44] RAOF, better than ati, intel, or via then! [10:44] wgrant, intel cards are fine. elisa is not [10:44] directhex: Really? Score one for gallium, then! [10:45] RainCT: Why, I would never do such a thing! [10:45] RAOF, cell-based driver? O_o === k0p is now known as trinity === trinity is now known as k0p [11:05] hi all. [11:05] why my package is yet in the queue? https://edge.launchpad.net/ubuntu/intrepid/+queue?queue_state=0&queue_text= :( [11:05] I'm concern with it. [11:06] RainCT, do you know something about that? [11:06] k0p: because every package that is new to ubuntu goes in there? [11:07] Hobbsee, yes. But is it a queue? [11:08] yes [11:08] Yesterday I have 48 packages in the queue. Today I see 23. [11:08] what's priority of this queue? do you know? [11:08] some of them come from different places, so get thru quicker. [11:08] ie, new stuff to ubuntu, from debian, is quicker, so might get done faster. [11:09] main stuff tends to get done faster, too [11:09] Hobbsee, sure :) [11:09] I don't know about this priority. [11:10] Hobbsee, is it added manually? [11:10] define "it"? [11:10] packages [11:11] I only have a sources on the archive. [11:11] soren, is the pacakges added manually to archive? [11:11] s/soren/so [11:12] once the sources get built into binaries, they go into another queue, then get added [11:14] Hobbsee, https://edge.launchpad.net/ubuntu/+builds?build_text=umit&build_state=all [11:14] I think it is already built [11:14] so now it's on the queue :) [11:16] probably :) [11:23] http://tinyurl.com/5dan4f \o/ [11:32] directhex: Cell-based driver? Gallium isn't cell-specific, although there is a cell driver, I believe. [11:35] directhex: Gallium is the swanky new GPU abstraction layer in mesa; driven, as always, by Intel. [11:37] can't they finish their hardware video decoding lib first? O_o [11:37] directhex: It's the same thing. [11:38] The deal is: you write the gallium driver, which is meant to map fairly cleanly to modern GPUs, and then there are a bunch of "state trackers" on top of it; OpenGL is one, there's a xvmc tracker being done as a part of GSoC, etc. [11:39] Intel have a DirectX state tracker, although I don't think it's open-source. [11:39] hm, the description of gallium looks all 3d related. i'm unconvinced that it's related to vaapi [11:43] Possibly they have special video acceleration hardware, although the trend seems to be against such hardware. [11:44] directhex: But the problem with vaapi is that not only do you have to write the library, and implement it in the drivers, but you also need applications to _use_ it. [11:45] well, yes [11:47] Although that's probably more likely than using xvmc, since it actually accelerates something people care about.. [11:49] if you build it, they will come [11:49] anyway, i'd rather see a mature vaapi used by multiple vendors than rubbish like VeMP [11:52] directhex: They build xvmc. Who came? :) [11:53] RAOF, epia users, snice they still don't have enough mhz to play SD MPEG2 convincingly? [11:54] really, that's the XvMC problem. it helps with mpeg2. whoop. a $50 cpu can eat HD mpeg2 for breakfast [11:54] vaapi? What's that? [11:54] You mean lpia? Ok. But no player that I use supports xvmc :) [11:54] RAOF, mythtv! also things like mplayer [11:55] jorgenpt, xvmc, but for all the "current gen" codecs instead of just mpeg2 [11:55] Right. No player I use :) [11:55] It relies on hwacc with a sw fallback? [11:55] Or is it a spec for a type of hwacc? [11:55] RAOF, vaapi should be more embeddable into other things. gstreamer sinks, that'd be nice [11:56] jorgenpt, i don't think it'll have software fallback, but it should allow any card with vaapi drivers (and appropriate back-end hardware) to accelerate playback in a way they aren't currently [11:57] Ah, okay. Anything support it yet? [11:57] No. [11:57] is it aimed at motherboards or at gpus? [11:57] GPUs. [11:58] Because motherboards generally don't have video decoding hardware on them ;) [11:58] The problem with hw accelleration is that "no-one" ever supports it. :| [11:58] My VIA Epia has, I think? (mpeg2) [11:58] Not totally true; Xv is well supported. [11:58] jorgenpt: But that's going to be on the GPU, the integrated video. [11:59] xv takes care of one or two of the major steps in decoding video. colorspace conversion and scaling, iirc [11:59] Right? [11:59] RAOF, right. [11:59] directhex: Correct, yes. [11:59] I mean, you need to first define a good API/library that people can use to get backend-ignorant decoding of formats, and then you need to find all the types of hardware that supports hw acc and use it to decode, and then you need to get hw producers to add hw acc, _and_ release specs so you can port your lib to support it. [12:00] Like, it's going to use the actual GPU to do the decoding, not specialized hardware? [12:00] (using shaders or whatnot) [12:00] jorgenpt: With the nice caveat that modern graphics cards _don't_ generally have hardware to accelerate specific codecs. They have stomping great parallel cores. [12:00] Using shaders can be done already, at least experimentally, in GStreamer. I believe there's a shader-implemented dirac decoder. [12:00] realtime dirac playback? [12:01] Yeah. [12:01] You'd need to implement the "big" codecs like xvid and h264, though. Those that're used for high-res video and people can have problems decoding. [12:01] and that's _gotta_ be a lot of work to do efficiently. [12:02] I'm pretty sure a reasonably powerful CPU can decode 720p dirac at the moment, with the schrodinger elements. [12:02] once again, we're gonna have cpus comfortably decoding these things before we get the drivers to do it in hardware [12:02] Not that I've tried it, myself. [12:02] ffmpeg's frame-level parallelism should help enormously with h264 [12:02] But what's vaapi about? Using GPUs with shading language? [12:02] Or using the display drivers to decode? [12:03] http://en.wikipedia.org/wiki/Video_Acceleration_API [12:03] jorgenpt: No. It's basically extending xvmc to handle modern codecs. How drivers implement it is up to them. [12:03] directhex: Is that already in place? (Frame-level parallelism?) [12:03] jorgenpt, in trunk, in unfinished form, yes [12:04] Can't wait, that'll be pretty neat. [12:04] Man, it'd be awesome if the ffmpeg devs considered ffmpeg a library. [12:04] What do they consider it? [12:04] My media center has 2 cores on ubuntu, so frame-level parallelism would rock. :) [12:04] I'm not entirely sure. :) [12:04] RAOF, never heard of libavcodec? [12:05] (and libavformat) [12:05] directhex: Care to point me to a release? :P [12:05] apt-cache policy libavcodec1d? [12:06] So, not so much a release as Debian finally saying "no, all ffmpeg apps can _not_ have their own private copy of ffmpeg. Link against this svn snapshot we've taken" [12:06] ffmpeg apps usually link statically against the ffmpeg source 'library'? [12:07] erm, yeah. generally they still have their own private copy [12:07] jorgenpt: Right. Because there's no guarantee that the next svn revision doesn't break your app. [12:07] partly because the symbols change weekly [12:07] perhaps daily [12:07] haha :p [12:07] Indeed. They don't treat it like a _library_. [12:07] That's a strange dev model. Isn't ffmpeg a few years old? [12:07] If they thought of it as a library, they'd make it possible for other apps to use it. [12:08] ffmpeg is a melting pot for development. making it useful for real use is other peoples' problems [12:08] jorgenpt: If you ask the ffmpeg devs, releases are an unnecessary waste of time, and are boring. Plus, static linking is, like, 0.001% faster. Also, a stable API would mean we'd need to design ahead of time. [12:09] How to write a detailed changelog? its confusing me [12:09] Also, a stable API would mean we couldn't have different APIs for different codecs, and that would reduce efficiency! [12:09] So they mostly run gentoo? [12:09] ;) [12:09] hi folks [12:09] sistpoty|work: Howdie. [12:09] hello sistpoty|work [12:09] API _additions_ aren't that much of a problem, are they, RAOF? And they could still maintain different APIs for different codecs? ;) [12:09] hi RAOF and bhavi_ [12:10] sistpoty|work, Can you please guide me in writing a changelog? [12:10] bhavi_: dch -i, write all stuff you changed there. enjoy :) [12:11] or was that too short? *g* [12:11] sistpoty|work, yes but most bugs are marked incomplete coz of the same reason [12:12] hm? [12:12]