[00:47] <vadi2> What is the proper way to associate a program with a file extension?
[00:57] <wgrant> vadi2: It's best to associate with a MIME type instead.
[00:58] <vadi2> ﻿wgrant: Okay, sure. But I don't really know where to even start and can't find much on it. Do you have a resource on this handy?
[00:59] <wgrant> I'm not sure of one, and I've not done it myself before, sorry.
[01:19] <crimsun_> vadi2: http://www.debian.org/doc/packaging-manuals/mime-policy/
[01:22] <crimsun_> vadi2: additionally, there are many packages that provide mime files.  Two examples are in the evince source package.
[01:26] <vadi2> ﻿crimsun_: thanks for that.
[03:05] <Hobbsee> ScottK: i have confidence that close to no one will actually follow, nor enforce, such a concept.
[03:05] <Hobbsee> at least, none of the MOTU's.
[03:05] <Hobbsee> or, very few of them
[03:06] <persia> Hobbsee: referant?
[03:06] <cody-somerville> Whats going on?
[03:06] <Hobbsee> [11:35] <sebner> 06:47:21> ScottK: about merging. I followed the mail discussion. What sense does it make to request a Exeption for a merge? We now that since import freeze we want "important" merges but exeptions ...
[03:07] <Hobbsee> (and replies)
[03:07] <persia> Oh.  Yeah.
[03:07] <persia> For hardy we did https://lists.ubuntu.com/archives/ubuntu-motu/2007-December/thread.html#2888
[03:08] <persia> I'm not sure it's ideal, as noted in the discussion ScottK referenced previously, but it's probably a reasonable place to start.
[03:08] <persia> With that model, enforcement is done by LP permissions.
[03:13]  * ScottK disagrees it's a reasonable place to start.
[03:13] <ScottK> It's nothing more than doing what one would normally do and calling it an 'exception'.
[03:13] <Hobbsee> ScottK: why?  the MOTU's can just behave as normal, with extra thought on suitableness, and the contributors have to already file a bug with a rationale.
[03:13] <ScottK> No point in that.
[03:14] <Hobbsee> there is that.
[03:14]  * ScottK doesn't think DIF is a magical day where everything changes.
[03:14] <ScottK> The only thing that changes is that the archive no longer changes automatically.
[03:14] <persia> Yeah, well, while it's pointless under analysis, it was the best way to deal with "exceptions" that I thought of for Hardy.  Note that I've not sent it for Intrepid.
[03:15] <ScottK> Right.
[03:15]  * ScottK suggest just do away with the notion of 'exception'.
[03:16] <persia> ScottK: That could also work.  We didn't have exceptions before Hardy.
[03:16] <ScottK> Just as any other time, it's up to the developer to determine if a change is appropriate to upload given where we are in the release cycle.
[03:18] <ScottK> Speaking of which, me needs to go do some upstream work to see if I can get a release done and uploaded to Debian prior to DIF.
[03:18] <RAOF> Yay!  Boost is merged, so miro will build.
[03:18] <persia> Good luck :)
[09:20] <AnAnt> Hello, are there any cellphones that got Ubuntu mobile edition on it ?
[09:22] <persia> AnAnt: I only know of one "cell phone" that might be able to do Ubuntu mobile, but it wouldn't be idea.  Ubuntu Mobile is about handhelds: 4-6" screen, not phones.
[09:23] <persia> s/idea/ideal/
[09:23] <AnAnt> persia: which phone ? and why not ideal ?
[09:24] <persia> AnAnt: One of the big ugly phones that e-mobile has in Japan, and not ideal because Ubuntu Mobile isn't a phone OS.
[09:26] <AnAnt> I see
[09:26] <AnAnt> how about JeOS ?
[09:26] <AnAnt> oops, that's a server
[09:26] <persia> AnAnt: That's really a server-appliance OS.
[09:27] <AnAnt> persia: I think that I heard that there's an OS based on Ubuntu Mobile,
[09:29] <AnAnt> persia: is there a cell phone running any linux even ?
[09:29] <AnAnt> persia: other than the e-mobile running ubuntu
[09:29] <persia> AnAnt: You might want to be asking these questions in #ubuntu-mobile, if this is going to be a long conversation.
[09:30] <AnAnt> oh, thanks
[09:53] <philsf> Hi, I applied the following change in poppler debian/control  ( http://pastebin.ca/1052362 ) hoping to replace libpoppler2 with libpoppler3, but got the error in http://pastebin.ca/1052363.  What am I missing?
[09:56] <tillux1> heya. I build a .deb package using dh_make and dpkg-buildpackage -r, but these .debs are almost empty. (well, they contain nothing apart from the folder-structure, the copyright file and the doc folder...). Did I forget to do something?
[09:56] <persia> philsf: I don't see that you've changed the package name.  Note that you probably also want to update the shlibs
[09:57] <persia> philsf: You'll also need to recompile everything compiled against libpoppler2 with replacements compiled against libpoppler3 (assuming an API change here).
[09:58] <philsf> persia: I did think about changing the name, but I figured a conflict/replace/provides would be enough to keep apt satisfied - obviously I was wrong, but I can't figure out where
[09:58] <philsf> persia: I don't really know if there was an API change, I'm assuming not, but this is just a test, not for production use (unless, of course, it works) ;)
[09:59] <persia> philsf: If there wasn't an API change, was there an ABI change?  If not, there's no benefit from the name change.
[10:01] <persia> tillux1: A new package you constructed, or an existing package from the repositories?
[10:01] <philsf> persia: you're right, I'm assuming too much. but I'm not even to this problem yet :) To this point, I really expect apps that depend on libpoppler (evince is my target) to go crazy, but I'm still stuck in dpkg
[10:02] <persia> philsf: The error you posted was about apps failing: if you want to force it, just uninstall all the dependencies first.
[10:03] <tillux1> persia: I only have got the source, and I want to create .debs from it ;)
[10:05] <persia> tillux1: OK.  If you're constructing a new package, your issue makes more sense.  One of three things is possible: 1) The correct installation call to the build system is not in debian/rules, 2) The correct path for installation is not being passed to the build system, 3) The build system doesn't have an install hook, and you need to do it manually with something like dh_install
[10:06] <tillux1> persia: hm, thans ;)
[10:06] <tillux1> +k
[10:07] <philsf> persia: is Conflicts/Replaces AND Provides a logical mistake?
[10:07] <persia> philsf: Yes.
[10:08] <persia> Conflicts/Replaces means that you can overwrite the files from the other package, and that the other package cannot be installed.
[10:08] <philsf> persia: ok
[10:14] <philsf> isn't there a parameter to dpkg-buildpackage so it does not recompile everything, and just repackage what really changed?
[10:15] <philsf> (I'm just changing debian/control now)
[10:16] <persia> philsf: I'm not sure.  I use debuild, rather than dpkg-buildpackage, and only to build source packages: and sbuild to build the binary packages.
[10:16] <philsf> persia: I'll look those, thanks
[10:17] <persia> philsf: Note that those are even less likely to allow only rebuilding the bit you want.
[10:17] <philsf> persia: yeah, from man debuild, it first calls dpkg-buildpackge
[10:17] <lifeless> philsf: if you want performance, let me introduce you to ccache
[10:18] <philsf> lifeless: seems interesting
[10:40] <RAOF> Hm.  Could we make our xulrunner-1.9-dev package provide xulrunner-dev?
[10:42] <wgrant> RAOF: Is Debian xulrunner 1.9 now?
[10:42] <RAOF> wgrant: Yes.  That's why I'm asking.
[10:43] <Amaranth> is it really xulrunner or the stuff mozilla hated them for that they called xulrunner?
[10:43] <wgrant> I suppose that makes sense.
[10:43] <RAOF> Amaranth: I'm unaware of the latter object.  It's possible?
[10:43] <RAOF> Basically, I want to sync miro, damnit!
[10:44] <persia> If not already done, might want double-verification from #ubuntu-mozillateam
[10:44] <Amaranth> RAOF: I know some time ago some mozilla folks were made because the debian guys changed xulrunner and it made it so things not packaged couldn't use it
[10:45] <Amaranth> not without being incompatible with regular xulrunner's anyway
[10:45] <RAOF> Right.  That'd be annoying.
[10:45] <Amaranth> but that was years ago
[10:45] <Amaranth> i think xulrunner 1.4 was the hot new thing
[10:46] <RAOF> On the other hand, it'd be less annoying if gecko wasn't so evil to embed that everyone went of and started embedding webkit.
[10:46] <Amaranth> if epiphany gets something like awesome i'm switching back :P
[10:46] <Amaranth> err, awesomebar
[10:46] <RAOF> Epiphany has always had an awesomebar
[10:46] <Amaranth> not quite
[10:47] <RAOF> s/always/for some time/
[10:47] <RAOF> There _are_ one or two things I'd like to change about Epiphany, but I was enjoying their awesome bar lite long before ff3 :)
[10:48] <Amaranth> the firefox ones remembers that every time I type 'forum' I go to the intrepid forum on ubuntuforums and puts that one first
[10:48] <RAOF> Whereas Epiphany's will just match the 'forum' in the title?
[10:48] <Amaranth> it doesn't learn
[10:49] <Amaranth> firefox's learns what you go to when you type a string and sorts them by how often you go to them
[10:49] <RAOF> That seems like it should be not unreasonably hard to implement.
[10:49] <Amaranth> apparently opera goes one further and searches in the text of the pages in the history instead of just their titles
[10:49] <Amaranth> if they're still in the cache, I guess
[10:50]  * RAOF smells xesam integration.
[10:50] <Amaranth> no
[10:50] <RAOF> That'd be kinda cool, though.
[10:50] <Amaranth> Just...no.
[10:50] <RAOF> Beagle already indexes the sites I browse, which is quite useful.
[10:51] <Amaranth> i don't need beagle to
[10:51] <Amaranth> firefox does it :P
[10:51] <RAOF> But based on the full-text contents?
[10:51] <Amaranth> oh, that
[10:51] <Amaranth> I was just saying Opera does it, I don't really see how it would be useful
[10:51] <RAOF> I can see that being kinda cool.
[10:51] <Amaranth> cool but useless, just like tracker, beagle, and xesam
[11:00] <lifeless> RAOF: xesam?
[11:19] <stochastic> is there a Felipe Sateler anywhere in this room? (I'm looking for info on the pd-csound external package)
[12:20] <RAOF> lifeless: The xdg desktop search/index/metadatastore thingy.
[12:40] <danbhfive> ﻿anyone know about driver detection, for things like printers and wifi, and webcams too?  Is there a way I could help with those projects?
[12:41] <RAOF> danbhfive: That's (1) almost entirely done within the kernel, and (2) a pretty much solved problem.
[12:42] <danbhfive> hm, ok
[12:42] <persia> danbhfive: Actually, you could help.  Find devices for which it doesn't work, and submit your DeviceIDs and the appropriate driver to load to the linux-usb list.
[12:42] <persia> (make sure to check the trunk code before submitting to avoid duplication)
[12:43] <RAOF> Hah, right.  Better answer from persia :)
[12:43] <danbhfive> and I should do this even if the driver is binary from windows?   like ndiswrapper'ed drivers?
[12:43] <persia> RAOF: Yeah.  I'm still not sure what to do with my 922SH.  It has different deviceids depending on the "mode" :/
[12:43] <persia> danbhfive: My recommendation is only useful for USB stuff.
[12:44] <elky> http://www.linuxfoundation.org/en/OpenPrinting is probably a good place to look if you're interested
[12:45] <RAOF> danbhfive: Ok.  Not sure about ndiswrapper'd drivers, but they're going to be difficult to support at best :(.
[12:46] <danbhfive> RAOF: I thought there was a project to actually do that, which inspired my first question.
[12:46] <danbhfive> Ill probably poke around these sites, see if I can get hooked in somewhere
[12:47] <RAOF> danbhfive: There's ndiswrapper, but that's likely to remain a second-class citizen, having to provide a windows compatibility shim.
[12:48] <RAOF> Generally the hope is for actual native drivers, so that everything can Just Work(tm).  I'm not sure whether it's technically possible to make an ndiswrapper solution automatically work in the same way.
[12:48] <RAOF> And legally, there's the fun of redistributing binary drivers, etc.
[12:48] <RAOF> Dear Miro: I hate you.  Where do you put your downloaded files?
[12:55] <AnAnt> persia: Hello, please review those http://revu.tauware.de/details.py?package=ubuntume-gdm-themes  &  http://revu.tauware.de/details.py?package=usplash-theme-ubuntume
[12:59] <RAOF> Uuurm.  Miro?  Why are you saving your files in the directory I built your source package in?
[13:00] <RAOF> Oh, of course!  Because that's where I've run you from.  You silly, silly program.
[13:08] <amikrop> Hello. Which is a good Ubuntu package, written in Python that uses distutils with debhelper?
[13:08] <RAOF> specto?
[13:09] <amikrop> Someone here has suggested this package, for studying, before.
[13:09] <RAOF> That's probably me, 'cause it's mine :)
[13:09] <amikrop> RAOF: I don't think it was specto.
[13:09] <RAOF> I would not suggest miro, because it's crazy and stupid and can't find where it's downloaded any of its files, and I don't think that's my fault :)
[13:10] <amikrop> RAOF: But since specto uses distutils with debhelper, I 'll check it out ;)
[13:11] <RainCT> Is there some policy for packaging ruby applications/libraries?
[13:16] <RainCT> nvm, found it
[13:16] <amikrop> Actually, somebody had given me a link to launchpad, about a package that uses distutils with debhelper.
[13:20] <lifeless> RAOF: seen loggerhead+bzr-search yet ?
[13:21] <RAOF> lifeless: No?  Shall I go browse some bzr revisions?
[13:21] <lifeless> uhm, demo is down
[13:21] <lifeless> but I'll ping you tomorrow when beuno is up and give you a url
[13:21] <RAOF> Cool.
[13:22] <RAOF> Aargh, I hate you miro.  Where do you (incorrectly) set your Video directory?
[13:26] <lifeless> ugh, moin, your voice is passive and fugly
[13:27] <amikrop> Oh, I am sure somebody here had suggested me a package (and given me the launchpad page) that uses Python's distutils (setup.py) with debhelper (debian/rules), together.
[13:27] <RAOF> amikrop: Why do you want the launchpad page?
[13:27] <amikrop> RAOF: I just want to see the source package, and study it.
[13:28] <RAOF> amikrop: "apt-get source specto"
[13:28] <ember> amikrop stepic
[13:28] <POX_> amikrop: http://svn.debian.org/wsvn/python-apps/packages/
[13:28] <persia> ompaul: About your idea for creating a list of applications most needing work: how do you envision input?  Maybe a collection of https-accessible lists of packages with weighting?
[13:28] <amikrop> ember: Yes, I think it was stepic.
[13:29] <amikrop> RAOF: alright :)
[13:29] <amikrop> Thanks, guys.
[13:29] <RAOF> amikrop: Well, it doesn't _have_ to be specto.  But apt-get source does what you want :)
[13:29] <ompaul> persia, the weighting was exactly as you suggested -- the big numbers from LP
[13:29] <amikrop> RAOF: I go tit.
[13:30] <amikrop> * I got it
[13:30] <amikrop> (oops :P)
[13:30] <laga> _where_ do you go? ;)
[13:35] <ompaul> persia, the idea that the bottom 2.5% of a standard "snapshot" be used to create the space that needs the most attention, that number is random I have no idea what the real values should be, but then I do think that you should be able to look to the snapshot graph with a "red / green / blue" list where you make red small and blue likewise, i.e. tails on a bell curve, however taking it further, you should be able to see a weekly or daily buil
[13:35] <ompaul> d with the nasty o graph I mentioned before, the ever moving target with the heavier weighting being applied for time, thus saying straight away here is package 1 for this day / week or whatever, I expect something like this to create a kernel like rate of change almost
[13:36] <ompaul> I am in favour of that last graph being timestamped on a 24 hour basis
[13:37] <persia> I was thinking of something more like a 6-hourly update, and ignoring history.
[13:38] <persia> I also like the idea of showing the entire graph, but then only listing the packages most needing attention at the bottom.  That shows both the general distribution, and identifies work to be done.
[13:38] <ompaul> persia, well history is important for creating the tail
[13:39] <persia> Hrm?  History of packages, or history of the graph?
[13:39] <ompaul> persia, package history, which creates a portion of the weighting
[13:39] <ompaul> after all that is how it came to pass
[13:39] <ompaul> i.e. the idea - some things don't get touched
[13:39] <ompaul> iirc
[13:40] <ompaul> the graphs history is not important unless you want to archive the data points for a post release look back
[13:42] <ompaul> at the end of the day, the question is not what was done, but what have we learnt
[13:42] <ompaul> the work will get done, but are there better ways to make things available for doing
[13:47] <ompaul> persia, perhaps I should mock up a doc and pass it on to you as a sample of what I am thinking about - we have about 20k individual datum with maybe 7 or 8 weighting points
[13:48] <persia> Right.  I was thinking of a "days since last upload" for package history weighting, which is calculable.  Yeah, a doc sounds like a better way to get some initial planning, and the doc can become a spec, and so on until we have something.
[13:52] <amikrop> ember: How do I use stepic? I mean, how do I encode some data in an image, for example?
[13:53] <ompaul> persia, I'll poke OOo and see what my brains can transmit to it
[13:54] <ember> amikrop i'm not a stepic user but you can take a look at the API in http://domnit.org/stepic/doc/pydoc/stepic.html
[13:54] <amikrop> ember: I did so, but couldn't figure out how to use it.
[13:57] <ember> amikrop i don't know  either, better to ping ScottK about stepic
[14:13] <amikrop> ScottK: hello
[14:50] <ompaul> persia, <aol>you got mail</aol> ;-)
[14:51]  * persia looks for the hanksicide
[14:53] <ompaul> that has to be the worst joke this month
[14:53] <ompaul> mine tat is
[16:21] <RainCT> superm1: uhm.. from where have you got nautilus-image-converter 0.3.0?
[16:24] <RainCT> superm1: ie, if it's from SVN, shouldn't it be 0.3~svn<something>?
[16:26] <RainCT> and there's no change after 0.2.1
[16:35] <RainCT> superm1: ah ok, nevermind
[17:24] <LucidFox> http://en.wikipedia.org/wiki/Image:Microsoft_Silverlight_stack.svg <-- Microsoft at its finest.
[17:24] <LucidFox> Put N Microsoft programmers in the same project, and they'll add N-1 layers of abstraction. The Nth will requalify into a PR manager.
[18:11] <EagleScreen> hello
[18:12] <EagleScreen>  i have created a new servicemenu for D3lphin, i have putted it into src/servicemenus in sources, i have compiles a new .deb with pbuild, and the result is that my new package does not install my new servicemenu to /usr/share/apps/delphin/servicemenus
[18:27] <superm1> RainCT, new upstream version?
[18:27] <superm1> er what happened with it?
[18:28] <RainCT> superm1: nevermind, upstream changed the SVN so I didn't see it :)
[18:28] <superm1> ah
[18:30] <RainCT> I'm sending him a mail now and will mention that it would be good to update the homepage noting this :P
[19:55] <ScottK> YokoZar: Wine backport is ack'ed and in the archive admin's hands.
[20:12] <YokoZar> ScottK: Did you see my email wondering if an SRU is more appropriate?
[20:19] <henninge> Hi, can anybody teill me by any chance who is responsible for operating the repository server(s)?
[20:20] <henninge> like archive.ubuntu.com or security.ubuntu.com
[20:23] <Daviey> henninge: I would imagine canonical-sysadmin for archive.ubuntu.com and security.ubuntu.com
[20:25] <henninge> Daviey, thanks, I'll contact the team leader about it.
[20:26] <Daviey> henninge: they tend to be slow at replying over the weekend.. one other place to try is /j #canonical-sysadmin
[20:27] <Daviey> henninge: can i be nosey and ask why you need them?
[20:27] <henninge> Daviey, it is about bug #241305
[20:28] <Daviey> erk!
[20:28] <henninge> It really boiles down to the question if and when the servers will be available via IPv6
[20:29] <henninge> and I'd like to close that bug by saying that the request has been brought to the attention of the responsible people
[20:29] <henninge> and maybe even get a time frame for when that (IPv6) might happen.
[20:36] <YokoZar> ScottK: Thanks for the backport
[20:46] <norsetto> greetings and salutations
[20:57] <ScottK> YokoZar: I think -updates via -backports after some testing is the best way.
[20:58] <YokoZar> ScottK: Yeah I agree.  Give it a week or so
[23:32] <stochastic> here's a call for FLOSS art projects I just came across: http://makeart.goto10.org/call/index.en.html