| micahg | SpamapS: around? | 01:55 |
|---|---|---|
| ScottK | AlanBell: It looks like your recipe fails to specify the necessary build-depends be installed, but I've zero experience with recipies, so I've no advice on that. | 02:07 |
| AlanBell | ok, thanks ScottK. Odd that I took the debian stuff from the current maverick package and now it builds on Lucid, but not Maverick | 09:09 |
| AnAnt | anyone using cowbuilder ? | 09:11 |
| ari-tczew | if someone changed B-D debhelper from 5 to 7, should also bump it in debian/compat file? | 10:53 |
| sebner | ari-tczew: yes | 10:54 |
| ari-tczew | then I found a bug | 10:54 |
| geser | ari-tczew: what was the reason to bump debhelper to 7? | 10:54 |
| ari-tczew | geser: * Bump build-depend on debhelper to install udev rules into /lib/udev/rules.d, add Breaks on udev to get correct version | 10:55 |
| ari-tczew | https://launchpad.net/ubuntu/+source/sane-backends-extras/1.0.19.11ubuntu2 | 10:56 |
| ari-tczew | debhelper (>= 7.0.17ubuntu2) | 10:57 |
| ari-tczew | is it necessary? >= 7 is not enough? | 10:57 |
| sebner | ari-tczew: depends, I guess he wanted the change that was made in debhelper 7.0.17ubuntu2 | 10:58 |
| geser | ari-tczew: I guess not as we want the specific behaviour for udev rules which got probably added in that debhelper version | 10:58 |
| sebner | jaunty is EOL in 5 days and that's not really a bug though | 10:58 |
| ari-tczew | sebner, geser: but at this moment practically, will get debhelper 8, so I don't understand depend on stricte 17ubuntu2 | 10:59 |
| sebner | ari-tczew: this was done in jaunty ... | 11:00 |
| ari-tczew | sebner: I know. I want to merge this one and I want to be sure, whether B-D on debhelper (>= 7) is enough | 11:01 |
| geser | ari-tczew: our debhelper 8 package probably has that change too (either patched or included in the debian version) | 11:01 |
| sebner | ari-tczew: I strongly suspect it isn't ;) | 11:01 |
| ari-tczew | sebner: makes no sense | 11:01 |
| geser | ari-tczew: think about backporting | 11:02 |
| ari-tczew | geser: why? | 11:03 |
| Rhonda | Please use 7.0.17ubuntu2~ instead of without the ~ | 11:03 |
| Rhonda | Otherwise it might hinder backports. | 11:03 |
| sebner | ari-tczew: well, of course *now* a newer debhelper version gets installed but if there is someone backporting it where debhelper is older than ..17ubuntu2 you get problems | 11:03 |
| sebner | hola Rhonda =) | 11:03 |
| ari-tczew | geser: I don't use this package (perhaps). I could upload a SRU which change debian/compat correctly | 11:04 |
| sebner | ari-tczew: not important enough for a SRU | 11:05 |
| Rhonda | The thing is, do you know what the impact of that change would be? | 11:05 |
| ari-tczew | install udev correctly | 11:05 |
| sebner | ari-tczew: why do you think this isn't the case now? | 11:08 |
| ari-tczew | sebner: I don't understand your question. I don't want drop this delta. | 11:08 |
| sebner | ari-tczew: right, I guess you want to know if you should bump debian/compat too? | 11:11 |
| ari-tczew | sebner: I guessed that I should bump debian/compat. I would ask to be sure. | 11:18 |
| sebner | ari-tczew: yeah, I think so | 11:21 |
| Laney | wait, what? | 11:43 |
| Laney | compat level doesn't have to correspond with debhelper BD version | 11:43 |
| ari-tczew | Laney: you didn't understand. B-D was on debhelper 7, but d/compat says 5 | 11:43 |
| Laney | see the debhelper manpage for the meaning of the various compat levels | 11:43 |
| Laney | I do understand | 11:43 |
| ari-tczew | Laney: so d/compat is not necessary? | 11:44 |
| Laney | matching it to the debhelper major version isn't necessary | 11:44 |
| Laney | debhelper(7) explains more | 11:45 |
| ari-tczew | Laney: so if I will bump d/compat also, I will be fired? | 11:45 |
| AnAnt | anyone using cowbuilder ? xulrunner-1.9.2 doesn't seem to install in a maverick cowbuilder chroot | 11:47 |
| Laney | ari-tczew: err, I didn't say anything of the sort. I'm just saying that it's not necessary. I'd never bump it in a diverging change from Debian unless that is the correct way to fix a bug. | 11:52 |
| ari-tczew | Laney: pedantic I'll bump it | 11:53 |
| * Laney shrugs | 11:53 | |
| Laney | it's another delta to maintain | 11:53 |
| Laney | but do what you will | 11:53 |
| tumbleweed | ari-tczew: why would you bump it? Does it have any benefit? | 11:53 |
| ari-tczew | tumbleweed: yes, not confusing which debhelper uses | 11:54 |
| tumbleweed | ari-tczew: compat is different to a minimum required version. It tells debhelper how this package expects debhelper to behave. | 11:55 |
| ari-tczew | tumbleweed: odd. | 11:56 |
| tumbleweed | ari-tczew: not really. It allows debhelper to make incompatible changes and still produce predictable builds. | 11:57 |
| ari-tczew | tumbleweed: on your responsibility, I'll leave compat 5. | 11:58 |
| tumbleweed | ari-tczew: we don't change things unecessarily (you'll find many packages using compat 5) | 11:58 |
| Laney | this is why I advised you to look at the manpage. It tells you what will change when you update compat. | 12:04 |
| * persia encourages *not* changing compat levels without very good reasons, as this can change the behaviour of the dh_* tools in unexpected ways | 12:17 | |
| directhex | 7! | 12:18 |
| persia | Only if the rest of the packaging is set to match... If folk *really* care about that stuff, emulate directhex and go make the changes in Debian. | 12:19 |
| geser | directhex: 5040 :) | 12:20 |
| directhex | 400! | 12:20 |
| nigelb | 42 | 12:21 |
| geser | 6.40345228466238952 * 10^868 | 12:21 |
| * geser hopes that this is precise enough | 12:22 | |
| persia | Depends what one wishes to accomplish. I don't think it's sufficient to enable transmogrifications. | 12:23 |
| kklimonda | up to 11 ;) | 12:24 |
| kklimonda | good afternoon | 12:24 |
| geser | does someone know a good example for how to use dpkg-vendor in debian/rules? | 12:48 |
| === Ng_ is now known as Ng | ||
| simar | ari-tczew, ping | 19:20 |
| ari-tczew | simar: pong | 19:20 |
| simar | ari-tczew, haha | 19:20 |
| simar | ari-tczew, i'm learning some packaging now .. i hope i can do merging and syncs .. | 19:21 |
| ari-tczew | simar: I must go out right now. | 19:21 |
| ari-tczew | simar: good luck and have fun | 19:21 |
| simar | ari-tczew, :(( | 19:21 |
| simar | ari-tczew, c ya later.. | 19:21 |
| simar | ari-tczew, i will try to get help here | 19:21 |
| ari-tczew | simar: friend from Ireland is visiting our country. we didn't see 2 years. | 19:22 |
| simar | ari-tczew, go dude and rock out.. we'll catch up later | 19:22 |
| simar | shadeslayer, see you facebook .. | 19:23 |
| simar | shadeslayer, there?? | 19:38 |
| simar | hey could anyone here give me a start on merges and syncs .. i'm almost started packaging but need small overview .. | 19:41 |
| Bachstelze | simar: sync is when the Debian package is imported in Ubuntu as is (i.e. no ubuntuX version number added) | 20:12 |
| simar | Bachstelze, ya i know that | 20:13 |
| Bachstelze | merge is when we have a package in UBuntu that has diverted from Debian and a new Debian version is out, we need to check whether some Ubuntu changes are made irrelevant by the new Debian version, and if so, drop them | 20:13 |
| Bachstelze | and document those that were kept and why | 20:13 |
| simar | Bachstelze, I want to contribute to that, could you guide me from where can i start | 20:13 |
| simar | Bachstelze, I have read twice tha ubuntu packaging guide and i have a print out of it for reference | 20:14 |
| Bachstelze | https://wiki.ubuntu.com/UbuntuDevelopment/Merging | 20:14 |
| Bachstelze | syncing should be done automagically | 20:14 |
| ScottK | Except for if there used to be Ubuntu changes needed, but they've all been incorporated by Debian and we can sync over a merge. That has to be requested. | 20:17 |
| simar | Bachstelze, It means we need not do anything to sync | 20:18 |
| simar | If all of the reasons that the Ubuntu version existed (bug fixes, dependencies, etc.) are fixed in the new Debian package (or if the residual difference is sufficiently trivial it's not worth the maintenance overhead of merging) then we can just take the Debian package directly. | 20:20 |
| simar | we can just take the debian package directly .. is this automatic | 20:21 |
| tumbleweed | simar: no, you have to request the sync (with requestsync). That's what ScottK was saying. | 20:21 |
| simar | tumbleweed, ok thanks.. | 20:23 |
| Bachstelze | yes, I meant syncing if the Ubuntu package has not diverted from Debian | 20:27 |
| Bachstelze | if it has, you have to request it as ScottK said | 20:27 |
| persia | geser, http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/ isn't precisely an example, but may help | 20:30 |
| simar | https://merges.ubuntu.com/universe.html | 20:32 |
| * ajmitch should probably try & do one or two of them | 20:32 | |
| simar | are these all packages to be merged .. or already merged .. i mean i'm not getting what are the tabs mean there | 20:33 |
| ajmitch | packages still to be merged | 20:36 |
| * geser is fighting with one merge most part of this day | 20:39 | |
| ari-tczew | geser: vim? | 20:39 |
| geser | yes | 20:39 |
| ari-tczew | I saw discussion on #ubuntu-devel. | 20:39 |
| geser | the hard part is to get it build with gcc-4.5 which seems to be a vim upstream problem | 20:40 |
| simar | shadeslayer, ping | 22:01 |
| ari-tczew | ScottK: what do you think about Depends on gnupg for binary pinentry-gtk2 ? | 22:08 |
| ScottK | Not much, why? | 22:09 |
| ari-tczew | without gnupg, pinentry-gtk2 won't show window for password | 22:09 |
| ScottK | ari-tczew: gnupg is in minimal. Without minimal installed, a system isn't really guaranteed t work. | 22:10 |
| ari-tczew | ScottK: anyway, it should depend on gnupg. I did a fresh installation and my maverick lost window for password. then I've installed gnupg and window for password came back | 22:11 |
| azeem | ari-tczew: shouldn't whatever uses pinentry-gtk2 in combination with gnupg depend on both? | 22:12 |
| ScottK | If you have ubuntu-minimal installed, how did you not have gnupg? | 22:12 |
| geser | and which password did you want to enter in pinentry? | 22:13 |
| ari-tczew | geser: when I'm signing source package | 22:13 |
| ScottK | None of the other pinentry's have it either. | 22:13 |
| ari-tczew | ScottK: dunno | 22:13 |
| geser | ari-tczew: how did you planned to sign without gpg? | 22:13 |
| ScottK | ari-tczew: Since it ubuntu-minimal depends on gnupg, I think something else was up. | 22:14 |
| ari-tczew | geser: I don't understand the question. where I wrote about my plans? | 22:14 |
| azeem | ari-tczew: it's not pinentry-gtk2's fault that gnupg isn't installed | 22:15 |
| ari-tczew | azeem: hmm. any ideas? | 22:15 |
| azeem | 23:10 < azeem> ari-tczew: shouldn't whatever uses pinentry-gtk2 in combination with gnupg depend on both? | 22:15 |
| azeem | 23:12 < ScottK> ari-tczew: Since it ubuntu-minimal depends on gnupg, I think something else was up. | 22:15 |
| geser | ari-tczew: I'm wondering why you want to enter a password without a program to do the signature | 22:16 |
| simar | I want to merge/sync packages for natty .. i used sudo pbuilder create | 22:23 |
| simar | and then sudo pbuilder update --distribution natty --override-config | 22:24 |
| simar | is it correct.. | 22:24 |
| persia | simar, You might find pbuilder-dist from ubuntu-dev-tools interesting. | 22:31 |
| simar | persia, i'm a beginner in packaging .. trying to merge my first package .. isn't what i did will work | 22:32 |
| persia | I recommend against starting with merging, if you're a beginner :) | 22:32 |
| persia | I've no idea if what you did might work: I don't use pbuilder. | 22:33 |
| simar | persia, no i'm beginner in merging | 22:33 |
| simar | persia, i have done some packaging before | 22:33 |
| persia | Do you have any outstanding changes you made that need to be merged? | 22:33 |
| simar | persia, actually i'm still looking at the package that weather it need merging or just a sync will work.. | 22:34 |
| simar | https://merges.ubuntu.com/i/ikiwiki/REPORT | 22:34 |
| simar | persia, this is the report of the package | 22:35 |
| simar | It is updated frequently in debian .. I hope a sync will be ok for it.. | 22:35 |
| tumbleweed | simar: start by reading the diffs, see what Ubuntu has changed | 22:35 |
| persia | Testing in pbuilder won't help determine if that is still required. | 22:35 |
| tumbleweed | simar: It helps to ask for help when you are stuck. "Is this right" is a hard question to answer | 22:36 |
| * tumbleweed isn't making much sense there... | 22:36 | |
| simar | ya, but i thought before all i can see if the new debian version will get properly build at all or not.. | 22:36 |
| simar | so i tried to use pbuilder for that.. but i want for natty and i have it for licid | 22:37 |
| simar | right now | 22:37 |
| tumbleweed | simar: look at pbuilder-dist, it lets you have multiple pbuilders without much work. | 22:37 |
| persia | pbuilder won't test that. No local build will test that, because of the specific issue. | 22:37 |
| simar | persia, but if i build in pbuilder using sudo pbuilder *.dsc isn't that will help me determine that the package correctly builds or not .. | 22:40 |
| simar | persia, i know i will have to still look into patches for merging .. | 22:40 |
| tumbleweed | simar: persia is talking about the reason Ubuntu patched ikiwiki. Read the changelog | 22:40 |
| persia | simar, No, it won't. The specific issue for the ikiwiki merge cannot be tested using pbuilder. | 22:41 |
| simar | tumbleweed, .. i think have to look into patches the 'old ubuntu'.patch and the 'new debian'.patch | 22:42 |
| persia | simar, So, would you like to go through this merge in great and exhausting detail? I'd be happy to do that. You won't need a pbuilder for natty. | 22:42 |
| === jenkins1 is now known as jenkins | ||
| simar | persia, ya sure i will appriatiate that | 22:43 |
| persia | (and I still don't think merges are a good place to start until one has done some bugfixes, and been *assigned* some merges) | 22:43 |
| === jenkins is now known as Guest14708 | ||
| persia | simar, OK. The first step is to look at the changelog entries in Ubuntu since the last reconciliation with Debian. We have a description of a change to fix a specific issue. | 22:43 |
| simar | persia, ok | 22:44 |
| simar | persia, i have fixed some FTBFS before though.. | 22:44 |
| persia | The explained change is that wdg-html-validator is not being used as a build-dependency, because the namespace definition is a URI that requires network access during build. | 22:44 |
| persia | simar, Excellent. Are any of the FTBFS fixes ready to be merged yet? | 22:44 |
| simar | persia, i did those some 3 months back .. | 22:45 |
| persia | I'm not sure I see the connection. | 22:46 |
| simar | persia, URI? | 22:46 |
| kklimonda | is there a way to marry git packaging branches from debian with our, bzr-based ones? | 22:46 |
| persia | Basically, my opinion is that folks should concentrate on bugfixing until they are assigned merges because they did the bugfix, at which point they will be in a better position to understand the merge details. | 22:46 |
| persia | kklimonda, Not in any sane way, no. You might try a vcs-imports branch of debian, but for non-native, it's unlikely to correspond to anything bzr-buildpackage expects. | 22:47 |
| persia | simar, http://www.w3.org/1999/xhtml | 22:48 |
| persia | Also http://www.w3.org/2005/Atom | 22:48 |
| simar | persia, ok .. i take you opinion. so I will work on some more bug fixes before merging .. | 22:48 |
| kklimonda | persia: so the only sane workflow is to work on both branches separately using patches, minimalize delta and then make package syncable or mergeable with the smallest changes possible? | 22:49 |
| persia | simar, I'm still happy to walk through *this* merge with you if you like, just in general I think it's better to wait until you've been assigned some. | 22:49 |
| kklimonda | I wonder if there is something like dpkg-vendor for patches ;) | 22:49 |
| micahg | kklimonda: you can manage the ubuntu branch in debian git | 22:49 |
| persia | kklimonda, Don't use the vendor patch hack in dpkg unless you have a *really* strong reason. It makes it much harder to get back in sync. | 22:49 |
| kklimonda | micahg: hmm, sounds like a nice idea but then I'm outside of the warm and fuzzy LP space :) | 22:49 |
| simar | persia, ya i too.. thanks | 22:50 |
| kklimonda | persia: I'm not planning to :) | 22:50 |
| persia | Personally, I find it easiest to ignore bzr when working with Debian packages in git: one can use git, generate some patches, apply those, and upload (or submit a debdiff if one does it that way) | 22:50 |
| persia | There's lots of infrastructure in place that will make the upload into a bzr branch appropriate. | 22:50 |
| micahg | persia: why not use dpkg-vendor, especially if Debian will take a patch? | 22:50 |
| kklimonda | well, I'd hate to hack applying a patch using dpkg-vendor | 22:51 |
| kklimonda | I was hoping for some way to indicate that the patch is ubuntu only | 22:51 |
| persia | micahg, I don't have an objection to dpkg-vendor: I have an objection to the way that vendor-specific patch application hackery works for Format: 3.0 (quilt) packages: there's no sane means to derive or overlay: if one starts, one needs to maintain multiple separate series trees. | 22:51 |
| === nixternal_ is now known as nixternal | ||
| kklimonda | either a field in patch's description or even a naming scheme (like 00-20 for upstream patches, 21-40 for debian, 41-60 for derivatives, 61-80 for local etc.) | 22:52 |
| micahg | persia: oh, that thing with distro specific patches? | 22:52 |
| * micahg saw a post on that recently | 22:52 | |
| azeem | yeah, I thought that was bad design as well | 22:52 |
| persia | The issue is that it's been around for a *very* long time, so someone has to investigate to ensure no regressions if the design is to be changed. | 22:53 |
| persia | And there's all sorts of complicated reasons involving handling .pc/ that make it hard to do in a layered manner. | 22:53 |
| azeem | it won't change apparently | 22:53 |
| simar | * s | 22:53 |
| azeem | and there's a bug with the .pc handling which I forgot to file, damn | 22:54 |
| persia | simar, So, the first step is to make sure we understand the precise problem being fixed. Do you understand about wdg-html-validator? | 22:54 |
| simar | persia, no | 22:55 |
| persia | simar, OK. So, do you know what wdg-html-validator does? | 22:56 |
| kklimonda | hmm, looks like I've don rm -rf in a wrong folder.. yay me | 22:56 |
| * ajmitch hopes it wasn't anything important | 22:56 | |
| simar | persia, no .. | 22:57 |
| simar | persia, not even heard of it | 22:57 |
| kklimonda | fortunately I've kept the folder synced with right repositories so I don't think I've lost much. | 22:57 |
| persia | simar, OK. So, you might start by reading the description of the wdg-html-validator package (apt-cache show) | 22:57 |
| simar | persia, seems helping | 22:58 |
| * kklimonda wonders why does we use bzr and not git - It would make working with debian.. and most upstreams so much easier :/ | 22:58 | |
| persia | kklimonda, Huge chunks of us don't use bzr. Lots of us use git. | 22:59 |
| kklimonda | persia: ok, let me rephrase that - I wonder why is LP (and our distributed development model) built around bzr and not git | 23:00 |
| kklimonda | i guess all those years back it wasn't clear if git is going to get so popular | 23:00 |
| persia | Oh, because sabdfl likes bzr, and he owns the company that does LP, and he funded the work on the distributed development model. | 23:00 |
| azeem | git wasn't on the radar back then I think | 23:00 |
| kklimonda | yeah, that's the likely reason.. actuall both are :) | 23:01 |
| simar | persia, i read it got some idea .. of what it do | 23:01 |
| ajmitch | & LP has been developed to work with bzr for the last 5 or so years | 23:01 |
| persia | Wasn't LP developed *with* bzr even before it changed to be called "bzr"? | 23:02 |
| ajmitch | yes | 23:02 |
| kklimonda | hmm, is there any way to get gconf schemas installed without actually having gconf as a dependency (both build-time and install-time)? | 23:03 |
| persia | You don't need it at build-time if you use a static file to set defaults and schemas. | 23:03 |
| ajmitch | http://jelmer.vernstok.nl/blog/archives/263-Samba-4-and-OpenChange-daily-Ubuntu-packages.html gives a good example of using upstream git branches | 23:04 |
| ajmitch | though that doesn't solve the problem of merging debian git branches | 23:04 |
| kklimonda | persia: well, I actually care more about runtime (or installation time) dependency :) | 23:04 |
| persia | simar, So, do you understand the changelog entry? | 23:04 |
| ajmitch | it should be possible though | 23:04 |
| persia | kklimonda, So, here's the thing: if you're setting gconf, you must have an expectation that this will affect something, so obviously you'd want things to be able to read the settings you made, so you need gconf installed. | 23:05 |
| simar | persia, i only got that it should be dropped from build-depends but why i didn't get.. | 23:05 |
| simar | persia, generated <html> elements | 23:05 |
| simar | persia, from where it gets generated | 23:06 |
| kklimonda | persia: well, in this case the only reason for using gconf is to set up transmission as a default handler for magnet: links | 23:06 |
| kklimonda | I wonder if it could be done with .desktop file.. | 23:06 |
| persia | kklimonda, And which use case do you seek to support that would not involve gconf being installed? | 23:06 |
| simar | persia, also xmlns.. what is it, i don't know | 23:06 |
| persia | simar, http://www.w3.org/TR/REC-xml-names/ | 23:07 |
| kklimonda | persia: transmission works fine without gconf installed - in this case an association of magnet: links with transmission is left to user. | 23:07 |
| persia | Hmm. Well, if it's just that, I agree adding gconf as a dependency seems heavy. | 23:08 |
| persia | You could try with a mime type handler (remember to register both in .desktop file and debian/mime-types~ | 23:09 |
| persia | But that depends on the browser using the desktop or the Debian MIME system to determine what to use as a viewer. | 23:09 |
| simar | persia, I think i picked the wrong package .. I have no idea of it .. i think i will try to get it by tomorrow if possible .. its 3am already and i think i must sleep for tomorrows calss at 8 .. thanks though for helping me out | 23:10 |
| simar | persia, i will take seek advide on bug fixes tomorrow .. | 23:11 |
| persia | simar, Have a good night. This was actually a trivially simple merge :) This is why I recommend folks start by merging stuff they changed before: makes the understanding part faster. | 23:11 |
| kklimonda | I don't know if magnet links (which are in basic a hash of a torrent) have their own mime type. I did think about it right now though and will investigate. I've had two other ideas - dlopening libgconf at the runtime and installing mimehandler as a gconf schema. dlopen would still require a dependency (but I could probably downgrade it to Recommends or even Suggests) and gconf schemas still have | 23:11 |
| persia | Sleep well. | 23:11 |
| kklimonda | to be installed using gconf-schemas binary. | 23:11 |
| persia | kklimonda, If you are going to use a gconf schema, put up with a gconf-dependency. Working around that is only likely to cause you pain. | 23:12 |
| persia | But there's no reason you can't create a MIME type for magnet: the hard part there is working with other parties to ensure it is generally accepted. | 23:13 |
| simar | persia, i din't get what you mean .. do you mean i should start by mearging to understand faster | 23:13 |
| kklimonda | and yeah - gconf (and probably a dozen other libraries) are a little heavy dependency only for that. That's why Debian doesn't ship transmission with it, maintainer has actually considered creating another package - transmission-gnome which links with libgconf (and libcanberra, but that's another thing) | 23:13 |
| persia | simar, Ask me tomorrow :) I meant that your first merges should be the merges for your FTBFS stuff (or other bugfixing) when it shows in the queue. | 23:14 |
| kklimonda | persia: is it actually possible to create a mime type for a scheme? | 23:14 |
| persia | transmission-gnome was my other thought, but that would be too heavy for just magnet: | 23:15 |
| simar | persia, thanks :)) | 23:15 |
| persia | kklimonda, Could you rephrase? | 23:15 |
| kklimonda | persia: hmm.. uri is created from scheme:path?query#fragment and magnet link is just magnet:?xt=um;some_hash and that's more or less it | 23:16 |
| kklimonda | persia: there is no file associated with it - you just enter this uri to any program that is compatible and you are good to go. | 23:16 |
| persia | So, MIME is about the content of some stream/file/etc. Has nothing to do with URIs. | 23:16 |
| persia | What? if I access the URI, what am I expected to get as a return? | 23:17 |
| ajmitch | kklimonda: how does it currently work for the browser to associate magnet: & transmission? | 23:19 |
| kklimonda | persia: well, application can turn this uri into torrent's hash and then, using dht and pex (both are distributed means of getting list of peers) client learns how to obtain data that this hash is for | 23:19 |
| kklimonda | ajmitch: transmission, when first run, uses gconf to set itself as a handler for magnet: | 23:20 |
| persia | So would it be sane to claim that such a URI represents a torrent hash? | 23:20 |
| kklimonda | persia: yes, among other things | 23:23 |
| persia | Well, needs a definition to use a MIME type... | 23:23 |
| kklimonda | what do you mean? | 23:26 |
| kklimonda | I could probably create a transmission-gnome package which only job would be to register uri handler - I can make it depend on transmission-gtk.. and then start thinking how to propose a new Uri: field for desktop files ;) | 23:27 |
| persia | So, MIME is a way to provide a machine-readable description of a file/stream/whatever so that the system can know how to process it. | 23:28 |
| persia | Don't: a URI field in .desktop files is exceedingly unlikely to be accepted, for any number of incredibly good reasons. | 23:28 |
| persia | A URI is intended to be a globally unique pointer to some file/stream/whatever (resource). | 23:29 |
| kklimonda | right | 23:29 |
| persia | So, if you can describe the resource that a magnet: URI references, you can use that description to describe the MIME type of the result. | 23:29 |
| persia | And you can set the MIME handler, and stuff ought just work. | 23:30 |
| persia | Without a definition for the resource the URI references, you can't have a MIME type (and arguably, shouldn't have a URI) | 23:30 |
| kklimonda | persia: I was actually thinking of a way for application to say "hey, I can handle following uri schemas" | 23:31 |
| persia | Note that a given resource may have more than one MIME-type | 23:31 |
| persia | (for example, I might give you a URI for "Moby Dick" that could provide text/plain, text/html, etc.) | 23:31 |
| kklimonda | yes, but applications interested in a specific uri are most likely to handle it in some way - in case of Firefox it may be launching an external application. | 23:32 |
| kklimonda | ha, I've actually found post of someone working on it: http://www.hadess.net/2010/10/new-control-center-and-you.html | 23:33 |
| kklimonda | I'm not saying that Fx launching an external application is a good thing - but that it would be a nice thing to have an easy and cross desktop way of defining that you can handle some uri | 23:34 |
| * persia grumbles at the inelegance of that solution | 23:34 | |
| kklimonda | I think it's just a hack for now | 23:34 |
| kklimonda | there is a discussion on xdg mailing list related to it, I'm trying to find actual mails now. | 23:34 |
| kklimonda | http://www.mail-archive.com/xdg@lists.freedesktop.org/msg06217.html here we go | 23:35 |
| * persia thinks aseigo's criticism is good, and that KDE did this right already | 23:36 | |
| persia | But really, the entire mess is ugly. | 23:37 |
| persia | A nice clean implementation would have a set of libraries that just handled various URIs, and programs encountering them could call into the libraries. | 23:37 |
| persia | We don't really need N implementations of each protocol handler (although N implementations of each MIME-handler is nice) | 23:38 |
| kklimonda | persia: but there would still have to be a way to register your application with this new system. | 23:38 |
| persia | Why? | 23:39 |
| kklimonda | what do you mean by "N implementations of each protocol handler?" | 23:39 |
| persia | Lets use FTP as an example. | 23:39 |
| kklimonda | for example, when you install a new browser it has to register as a handler for http, https, maybe even ftp | 23:39 |
| persia | I don't really need N implementations of FTP. Just one, with flexible bindings. | 23:40 |
| persia | So *every* application that needs FTP just uses the ftp handler. | 23:40 |
| kklimonda | and I probably should not do this discussion at 1AM as I feel like I'm making an idiot out of myself.. | 23:40 |
| kklimonda | persia: but that's whishful thinking :) | 23:40 |
| persia | So is Bastien's hacky misuse of MIME to handle URIs. | 23:41 |
| persia | KDE has current protocol handlers, although they have vast scope for improvement. | 23:41 |
| kklimonda | sure, I agree that KDE's solution is less hacky. | 23:42 |
| persia | The main difference between the implementations we use today and wishful thinking is that someone spent a bit of time and wrote it down in a formalised manner. | 23:42 |
| === dantaliz1ng is now known as dantalizing | ||
| kklimonda | persia: as I understand your description you propose a layer between services and applications? This layer would register itself as the only handler for uri schemas and then application would make use of it? | 23:43 |
| kklimonda | probably a little like gio | 23:43 |
| kklimonda | and gvfs | 23:43 |
| persia | Sure, although I'd naively probably try to use a D-Bus API for the protocol handlers. | 23:44 |
| persia | Not saying it's best. | 23:44 |
| persia | Anyway, at least talking about protocol handling gets it started. | 23:44 |
| persia | And once we have protocol mapping, we can look at code consolidation between implmentations. | 23:44 |
| persia | Not that this solves the transmission issue: | 23:46 |
| persia | Because there's still no clear definition of the resource a magnet: URI references. Runs into the same wall that way. | 23:46 |
| kklimonda | right, to make it even more complicated magnet link is not really tied to BitTorrent - you can use it to describe files for othe p2p networks. | 23:47 |
| kklimonda | for other* | 23:47 |
| persia | Sure. The trick is mostly to come up with a definition of the *resource* that a magnet link produces. | 23:49 |
| persia | I'm sure it's not that hard, but I'm not sure that anyone put much thought into the semantics of it. | 23:49 |
| kklimonda | I think my brain just exploded at "a definition of the resource" :) | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!