From Fedora Project Wiki
| skvidal | okay | 10:59 |
|---|---|---|
| skvidal | it's 2pm | 10:59 |
| skvidal | abadger1999: you here? | 11:00 |
| skvidal | spot: you around? | 11:00 |
| --> james_w has joined this channel (~james_w@jameswestby.net). | 11:01 | |
| * Oxf13 watches from the cheap seats | 11:01 | |
| *** stickster_afk is now known as stickster. | 11:01 | |
| * skvidal watches no one else be around | 11:01 | |
| --> sgallagh has joined this channel (~sgallagh@pool-173-48-144-223.bstnma.fios.verizon.net). | 11:01 | |
| skvidal | okay, so - here's what I've been working on this last week | 11:01 |
| skvidal | 1. got a basis for how mock is going to do vm-based rebuilds. - essentially the command to generate the vm is just a config value | 11:02 |
| skvidal | 2. so you generate the vm | 11:02 |
| skvidal | 3. edit the disks using guestfish (or maybe in other incarnations other tools) to put the srpm and the mock config in a specific path | 11:02 |
| skvidal | 4. when you boot the vm it has a simple python script I put together called auto-mock-build which is init scripts - it boots, builds the pkgs in mock in the vm, then writes them out in a specific path and exits | 11:03 |
| skvidal | 5. mock fetches the results out of the vm disk using guestfish (or maybe another tool for other types of vms) | 11:04 |
| Oxf13 | neat | 11:04 |
| skvidal | so - yah - that's actually working - though I've not figured out the nice way to put the mock commands/ configs in place | 11:04 |
| *** sankarshan_away is now known as sankarshan. | 11:04 | |
| skvidal | a lot of that is just picking the least ugly which is something I tend to suck at sometimes | 11:04 |
| skvidal | so - another problem set i'm working on | 11:04 |
| skvidal | you have 20pkgs in a repo OUT THERE | 11:04 |
| skvidal | you have 2 new pkgs to add to that repo | 11:04 |
| * mizmo is here | 11:04 | |
| skvidal | you do not want to sync down all the 20 pkgs | 11:05 |
| skvidal | add your 2 pkgs | 11:05 |
| skvidal | and run createrepo again | 11:05 |
| skvidal | so I'm working on something right now which grabs the repodata from OUT there, adds the 2 new pkgs to the repodata and gives you a dir/path with the repodata + the 2 new pkgs you can sync back up | 11:05 |
| * abadger1999 applauds | 11:06 | |
| skvidal | this keeps us from beating up the site where we host the pkgs from having createrepo's run on it all the time | 11:06 |
| Oxf13 | nice | 11:06 |
| skvidal | and it should, in theory, make for a useful tool by itself for folks NOT using ppas. | 11:06 |
| Oxf13 | yeah it does sound useful | 11:07 |
| skvidal | It's going to take some testing but I believe our very own mr callaway has agreed to test this out once I'm figured out how to make it hard for him | 11:07 |
| skvidal | err, I mean - figured out how to make it easy and painless to use | 11:07 |
| skvidal | :-D | 11:07 |
| --> drago01_ has joined this channel (~linux@chello062178124135.3.13.univie.teleweb.at). | 11:08 | |
| skvidal | right now all I know for certain is | 11:08 |
| skvidal | I hope everyone likes relative paths to files | 11:08 |
| skvidal | b/c those are going to stick around | 11:08 |
| skvidal | :) | 11:08 |
| skvidal | okay, yah - I think I'm done for now | 11:08 |
| skvidal | adamw: ping | 11:08 |
| skvidal | adamw: did you get anything back from jono? | 11:08 |
| skvidal | or anyone suse-ish? | 11:08 |
| skvidal | susish? | 11:09 |
| skvidal | okie doke! | 11:09 |
| abadger1999 | hehe. | 11:09 |
| * skvidal wonders if adamw is lunching it, yet | 11:09 | |
| skvidal | abadger1999: you have something to show and tell? | 11:09 |
| abadger1999 | A small bit. | 11:10 |
| abadger1999 | I took a look at amqp for most of last week. | 11:10 |
| abadger1999 | API wise it seems pretty good for transporting hte messages between a task scheduler and the task runners that will fulfill the jobs. | 11:10 |
| abadger1999 | But the system administration of qpid (the amqp server that RH and apache is getting behind) isn't that great. | 11:11 |
| abadger1999 | So I'm thinking of degsigning the first cut around func. | 11:11 |
| --> ReneP has joined this channel (ReneP@fedora/ReneP). | 11:11 | |
| spot | abadger1999: fwiw, it would be useful for you to document the limitations of qpid that you hit and send it along to that team | 11:12 |
| abadger1999 | We'll have a build system piece that receives jobs from packagers -- mostly on the commandline but with a web server component so people can view builds and such. | 11:12 |
| abadger1999 | spot: Yeah -- let me tlak to you afterwards about contact info for them. | 11:12 |
| spot | Red Hat is spending a non-zero amount of time and money on that technology, it would be good to be able to explain why we're not using it if someone asks. :) | 11:12 |
| abadger1999 | The build system will decompose a request into a set of related tasks that it sends to the task scheduler. | 11:13 |
| abadger1999 | The task scheduler will use func to farm out the jobs to builders and build new repositories when it's done. | 11:13 |
| abadger1999 | Currently, I'm figuring out the best way to push the results of distinct tasks around -- srpms, build logs, built rpms, etc... I'm thinking using fixed paths on a networked filesystem might be best for that but I'm going to see what koji does. | 11:15 |
| abadger1999 | Also; I just discovered that plague is still being used in a few more places than I thought so I'll take a look at who's using it today and see if we should work on enhancing that. | 11:15 |
| abadger1999 | On the other end of this chain, end-users -- we talked with mizmo last week about how that should look. | 11:16 |
| abadger1999 | mizmo: how did the information we gave you last week seem? Need more information? | 11:16 |
| skvidal | okay, crickets! | 11:19 |
| abadger1999 | Yay! | 11:19 |
| skvidal | anyone have any new thoughts on the discussion from last week | 11:19 |
| skvidal | about the tradeoffs of offering hosting of this kind for what are ultimately 3rd party repos | 11:19 |
| mizmo | abadger1999: well, i haven't had time to do anything yet although i talked a bit with ajax & halfline about how ppa works to figure out how they might use such a thing | 11:19 |
| mizmo | oh i did do a very stupid start at a mock actually | 11:20 |
| mizmo | are there going to be dependencies allowed between repos? | 11:20 |
| skvidal | spot: a question I forgot to ask - the reason the chromium pkgs are not in fedora - even in rawhide - but are on fedorapeople is... - b/c of the bundled libraries? | 11:21 |
| abadger1999 | mizmo: We were thinking there would be but I've been trying to decide if we could get away without it. | 11:21 |
| skvidal | mizmo: I don't entirely know how we can avoid them - if repos are only ever selfcontained then it just means we'll end up with a bunch of duplication of pkgs, won't we? | 11:21 |
| abadger1999 | PPAs don't seem to have interrepo deps so it would be a place where we could either be better or be getting ourselves into hot water. | 11:21 |
| abadger1999 | skvidal is correct about duplication of packages -- but it makes certain things easier to manage. | 11:22 |
| james_w | PPAs can have dependencies | 11:22 |
| skvidal | abadger1999: hmm - when you setup the ppa it looks like you can specify the builddep repos to call from | 11:22 |
| abadger1999 | hmm.. | 11:22 |
| spoleeba | james_w, across ppas? | 11:22 |
| skvidal | james_w: on other PPAs, right? | 11:22 |
| james_w | yes | 11:22 |
| james_w | not external archives | 11:22 |
| spoleeba | james_w, can you point to an example of that | 11:22 |
| mizmo | spoleeba: tons of them do | 11:23 |
| mizmo | we looked thru them before | 11:23 |
| mizmo | interPPA deps | 11:23 |
| james_w | spoleeba: no offhand | 11:23 |
| spoleeba | mizmo, hmm | 11:23 |
| halfline | skvidal: why is duplication of packages a bad thing here? | 11:23 |
| skvidal | abadger1999: look here https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage | 11:24 |
| skvidal | and look at "Depending on other PPAs" | 11:24 |
| mizmo | skvidal: well if youre worried about disk space, heres a dumb idea. each repo is version controlled. lets say pkg perl-crap is in repo A. joe maintainer updates perl-crap v1 with perl-crap v2. but my awesome inkscape in repo B depends on perl-crap v1. so it links to the v1 version of the perl-crap repo A | 11:24 |
| halfline | the point is to have a little playground where the stuff you work on it destabilized and the stuff you depend on is rock solid, right? | 11:24 |
| skvidal | mizmo: I'm not worried about disk space | 11:24 |
| skvidal | I'm worried about this | 11:24 |
| skvidal | I have koper foo | 11:24 |
| skvidal | which I've copied a new gtk2 in from koper bar | 11:24 |
| spoleeba | mizmo, was that a by hand process where you spot checked ppas.. knowing how interconnected ppa-space now generally speaking would be instructive i think | 11:25 |
| abadger1999 | skvidal: Ah okay -- must have missed that subsection. | 11:25 |
| skvidal | if I cannot have cross-koper deps - I have to do that | 11:25 |
| skvidal | so I have my local copy | 11:25 |
| mizmo | spoleeba: just went to the ppa web site and clicked on various repos | 11:25 |
| skvidal | and I build the pkgs I care about against it | 11:25 |
| skvidal | two weeks goes by | 11:25 |
| james_w | spoleeba: not very at a guess. | 11:25 |
| skvidal | the gtk2 ppa maintainer fixes a bug in her pkg | 11:25 |
| skvidal | and i never get the bug update in mine | 11:25 |
| mizmo | (thanks for the her) | 11:25 |
| abadger1999 | halfline: That's one use case but not all of the use cases (unfortunately). | 11:26 |
| spoleeba | james_w, so tons of shallow interppa deps? | 11:26 |
| skvidal | meanwhile the users consuming my ppa are vulnerable to the bug | 11:26 |
| mizmo | skvidal: but the other case is, the gtk2 ppa maintainer adds some new thing that breaks my koper foo | 11:26 |
| james_w | spoleeba: the majority of PPAs currently only depend on the main archive I would think. I have no hard data on this though. | 11:26 |
| skvidal | mizmo: yep - but that kind of breakage isn't silent | 11:26 |
| mizmo | skvidal: what if, you depend on a particular version of the other koper. but when the other koper gets updated, you get a notification | 11:26 |
| mizmo | and can manually up | 11:26 |
| skvidal | mizmo: it breaks in flashy 'holy crap yum says this won't depsolve' ways - so at least you KNOW about it | 11:26 |
| --> acaleechurn has joined this channel (~acaleechu@cust.static.84-253-34-194.cybernet.ch). | 11:27 | |
| skvidal | anyway - I'm not saying this stops anything - I'm just saying it seems to me that cross-koper deps are going to be used and/or necessary | 11:27 |
| abadger1999 | skvidal: Or not.... that's why I argue with java and python bundling people upstream. | 11:27 |
| skvidal | bundlin people? | 11:27 |
| skvidal | oh | 11:28 |
| skvidal | I see | 11:28 |
| abadger1999 | skvidal: ie: foo-1.0 and foo-1.3 are fine for use with my package but foo-1.1 and 1.2 have runtime breakage. | 11:28 |
| skvidal | sorry, I read that sentence kinda sideways | 11:28 |
| mizmo | skvidal: if it breaks like that though, it should break before people pulling from the koper know about it | 11:28 |
| skvidal | mizmo: ?? | 11:28 |
| mizmo | skvidal: eg break fantastically and spew crap at the maintainer but dont break people's systems | 11:28 |
| skvidal | how so? | 11:28 |
| james_w | so, one thing that PPAs don't do, is stack for the binary packages, it's just a dep for taking build deps from. That means if you require libfoo that is in Eve's PPA, it will build against it, but users have to add two entries to actually install. | 11:28 |
| mizmo | eg if im running awesome nightly build inkscape koper and it depends on crazy perl koper, and crazy perl goes crazy, i boot up in the morning and i cant get my job done | 11:29 |
| skvidal | mizmo: again - unless we're going to be running repoclosure for all possible combinations - it's not going to be easy to tell | 11:29 |
| --> J5 has joined this channel (~quinticen@66.187.234.199). | 11:29 | |
| mizmo | skvidal: but you just said it breaks in obvious ways? | 11:29 |
| skvidal | to the end user | 11:29 |
| skvidal | it breaks b/c their yum update doesn't work | 11:29 |
| abadger1999 | james_w: Oh, that's interesting to know. So the apt repository adding tools do or don't take care of that automatically? | 11:29 |
| skvidal | james_w: that's how it would be w/yum, too | 11:30 |
| skvidal | james_w: we don't have repository dependencies - though that's been discussed | 11:30 |
| spot | skvidal: yeah, chromium is out because of aggressive bundling | 11:30 |
| mizmo | skvidal: i guess what im trying to say is that their yum update shouldn't not work. | 11:30 |
| james_w | abadger1999: no, they could in theory with some more smarts add an entry for Eve's PPA too as you can get that information over the API. | 11:30 |
| abadger1999 | <nod> | 11:31 |
| skvidal | mizmo: how can it not not work? | 11:31 |
| abadger1999 | james_w, skvidal: For dealing with that I was thinking about dropping the koperFoo-release.rpm packages in a repo and having them dep on each other. | 11:31 |
| abadger1999 | So the build deps would be reflected in the packages that hold the yum repository configs. | 11:32 |
| skvidal | abadger1999: at that point it's almost worth talking about a kopers yum plugin | 11:32 |
| abadger1999 | <nod> | 11:32 |
| skvidal | abadger1999: so we could give the user the set of repos they want and the kopers those repos dep on | 11:32 |
| skvidal | w/o them have to explicitly enable them | 11:32 |
| skvidal | of course - that opens the user up to lots of interesting issues with Obsoletes | 11:32 |
| mizmo | skvidal: so to be able to say 'holy crap this wont depsolve', you have to run repoclosure? | 11:32 |
| abadger1999 | Excellent. That's a problem I was deferring figuring out. | 11:32 |
| skvidal | mizmo: to be able to say that before we let the pkg out, yes | 11:33 |
| skvidal | mizmo: it's one of the things the autoqa people are doing for our full repos. | 11:33 |
| skvidal | mizmo: if we don't check the deps/provs/obsoletes in and out we cannot know that updates-release will depsolve with fedora | 11:33 |
| skvidal | abadger1999: sorry | 11:33 |
| adamw | skvidal: catching up from earlier - no, didn't hear back from jono yet. i'll ping him again. | 11:33 |
| james_w | so, one thing we haven't got it a way (as mizmo would probably like) to say "OMG! it's all broken today, get me back to the good state", partly because we don't support downgrades of packages. You are relying on the owners to fix it, or to re-upload the older version, quickly. | 11:33 |
| skvidal | but let's hold on a few minutes here | 11:33 |
| mizmo | skvidal: well... what if it worked based off of the maintainer's machine. the very potentially flawed assumption here is the maintainer actually uses her own koper but - | 11:33 |
| skvidal | mizmo: and then arch problems :) | 11:34 |
| skvidal | james_w:yum can downgrade | 11:34 |
| james_w | if you can get that then it makes these things more palatable for day-to-day usage. | 11:34 |
| mizmo | skvidal: a new version of something my koper depends on comes out. before my koper pulls in the new version, i get an email asking me to approve it. so i update to the new one. if it breaks, i dont allow it thru | 11:34 |
| skvidal | james_w: provided we can get the old pkg | 11:34 |
| skvidal | james_w: and yum history undo works pretty damned well, now | 11:34 |
| james_w | skvidal: apt /can/ downgrade, it's just that the results are undefined in a few cases, so it's not encouraged | 11:34 |
| james_w | great that you have that | 11:34 |
| *** mchua is now known as mchua_afk. | 11:34 | |
| skvidal | james_w: right - downgrades are not fun | 11:35 |
| [Whois] james_w is ~james_w@jameswestby.net (James Westby) | 11:35 | |
| [Whois] james_w is a user on channels: ##distros #fedora-devel #fedora-meeting | 11:35 | |
| [Whois] james_w is online via bartol.freenode.net (Luxembourg, Luxembourg). | 11:35 | |
| [Whois] james_w has been idle for 14 seconds. | 11:35 | |
| [Whois] james_w has been online since 03/28/10 9:56:17 am. | 11:35 | |
| [Whois] End of WHOIS list. | 11:35 | |
| james_w | is it worth keeping superseded versions around for 24/48 hours to make that easier? | 11:35 |
| skvidal | adamw: thank you. | 11:35 |
| skvidal | james_w: keeping whatever around is really up to the repo maintainer, I'd guess | 11:35 |
| mizmo | james_w: yeh so what if the owners get broke, and disallow the breakage to hit the users | 11:35 |
| skvidal | spot: how many builds of chromium do you keep around? | 11:35 |
| james_w | skvidal: ah, I didn't realise it was a manual process to remove them | 11:36 |
| skvidal | james_w: it's an entirely future process | 11:36 |
| james_w | ah | 11:36 |
| skvidal | james_w: ie - we haven't defined the removal process yet | 11:36 |
| skvidal | james_w: so, you're not wrong - nor are you right :) | 11:36 |
| skvidal | james_w: unless you want to implement it - then you're 100% right :) | 11:36 |
| skvidal | james_w: and your code is welcome | 11:36 |
| james_w | in PPAs, older packages are garbage collected after a few hours, but immediately removed from the indices, so apt can't see them | 11:37 |
| skvidal | james_w: very useful to know | 11:37 |
| skvidal | thanks | 11:37 |
| skvidal | james_w: do you know anything about other common problems folks have run into w/ppas? | 11:38 |
| james_w | skvidal: I tried to comment on your blog to suggest distributions@lists.freedesktop.org to get some feedback from other distros, but it seems my browser ate my comment. | 11:38 |
| --> biertie has joined this channel (~bert@fedora/biertie). | 11:39 | |
| skvidal | i will | 11:40 |
| james_w | most of the problems that people have are from automated packaging: scripts that stuff the packaging from yesterday in to todays tip of upstream VCS. | 11:40 |
| spoleeba | james_w, does suse's build service do the equivalent of cross repository deps? | 11:40 |
| james_w | which is clearly not going to go well on occaision | 11:40 |
| spot | skvidal: right now, just the latest | 11:40 |
| james_w | spoleeba: no idea, sorry | 11:40 |
| spot | skvidal: but for a while there, i was also keeping the previous build for each target | 11:40 |
| james_w | one thing we do is to disable external repos on upgrade to a new release, which stops the problems of external packages from at least one end of the upgrade. | 11:41 |
| james_w | but I don't think we're far enough along yet to start seeing the real issues from that sort of thing | 11:41 |
| skvidal | james_w: but trips you up on the other end, doesn't it? | 11:41 |
| james_w | skvidal: it obviously can do, but there's little we can do about that | 11:42 |
| --> anthro-diana has joined this channel (~Sollitair@c9.fa.3845.static.theplanet.com). | 11:42 | |
| james_w | I would say that a lot of use is single upload repos that just fix a bug in some package. This is useful for getting feedback from bug reporters and the like. | 11:42 |
| * abadger1999 fully expects some packager to start packaging glibc w/ crazy optimizations and an epoch in a PPA. | 11:42 | |
| skvidal | abadger1999: ensc | 11:43 |
| james_w | there's also ones that enable some wacky feature that the distro won't support or similar | 11:43 |
| abadger1999 | heh -- well, he might not be a crazy optimization guy but his repos will be crazy in a different way :-) | 11:43 |
| james_w | and then the new release type ones that pull in code (manually or automatically) from newer upstream | 11:43 |
| james_w | they are the ones that cause the most issues | 11:43 |
| james_w | but it's very clear that if you enable them you have to deal with the fallout | 11:44 |
| james_w | but it obviously doesn't mean that everyone understands why something broke | 11:44 |
| abadger1999 | james_w: Do you have some method to separate out those types of repos from others? Or is it just word of mouth that some repos are crazier than others? | 11:44 |
| james_w | there's just a freeform description on each one | 11:44 |
| skvidal | abadger1999: I can think of a couple of ways | 11:44 |
| mizmo | it would be nice to attach a sort of badge to the repos | 11:44 |
| skvidal | abadger1999: if a repo contains things like glibc or rpm or yum, it gets progressively chancier | 11:45 |
| james_w | they aren't really listed by type or anything, usually people hear about them from links on the forums etc. | 11:45 |
| abadger1999 | mizmo: Thinkin' the same thing :-) | 11:45 |
| james_w | mizmo: I like that idea. | 11:45 |
| skvidal | abadger1999: hell a programmatic way would be to see if the items in your ppa/koper are depended on deeply or by a significant number of things in the main tree | 11:45 |
| spot | or something as simple as an indicator of "does not replace anything in main tree" | 11:46 |
| spot | e.g. chromium repo | 11:46 |
| skvidal | s/main tree/critpath/ | 11:46 |
| spot | sure. | 11:46 |
| spoleeba | yes the suse build service does have cross repo deps... and a new concept called a pattern | 11:46 |
| abadger1999 | mizmo: Also -- if we did run things like repoclosure, how often does repoclosure break for this repo? | 11:46 |
| james_w | do you have the concept of one repo superseding another, or is the comparison done mainly on version numbers? | 11:47 |
| abadger1999 | mizmo: Maybe also user feedback. | 11:47 |
| skvidal | abadger1999: running repoclosure on N repos is going to get pricey | 11:47 |
| skvidal | james_w: not repos, no | 11:47 |
| skvidal | james_w: just pkgs | 11:47 |
| mizmo | the badges i think would be: (1) optimization of something (2) changing a distro default (3) nightly build for major fans of a package (4) developer wanting people to test something (5) add on software that isn't available in distro | 11:47 |
| abadger1999 | skvidal: On N repos or between N repos? | 11:47 |
| skvidal | abadger1999: yes | 11:47 |
| mizmo | (6) infrastructure boxes stuff | 11:47 |
| mizmo | abadger1999: yeh i was thinking you could have a forum | 11:47 |
| mizmo | abadger1999: and recommended repos other people like you use | 11:47 |
| mizmo | ill upload my mockup although its got almost nothing in it | 11:48 |
| james_w | skvidal: right, so one of the difficulties is that some people sometimes get version numbers wrong, as it's really hard to write documentation that tells you how to pick a version number that will give you the desired behaviour. | 11:48 |
| skvidal | version numbers of their pkgs? | 11:48 |
| james_w | yeah | 11:48 |
| mizmo | http://duffy.fedorapeople.org/temp/kopers.png | 11:48 |
| skvidal | james_w: we actually have a tool to test if your version number is newer/older than another | 11:48 |
| mizmo | see the heart is the 'badge' | 11:48 |
| mizmo | and there's a listing of who is using the repo | 11:48 |
| skvidal | james_w: it's in the fedora packager pkg | 11:48 |
| mizmo | and other repos you might want based on that one | 11:48 |
| mizmo | i was gonna do a forum or something in the space under the badge | 11:49 |
| <-- ReneP has left this server (Ping timeout: 264 seconds). | 11:49 | |
| james_w | skvidal: we do, but you are testing against the possible versions that will appear in an unknown number of repos at any point in the future | 11:49 |
| skvidal | james_w: oh - I see what you mean | 11:49 |
| skvidal | james_w: yah - and who knows what you're going to get | 11:49 |
| abadger1999 | <nod> | 11:49 |
| abadger1999 | skvidal, james_w: It's in rpmdevtools | 11:49 |
| abadger1999 | rpmdev-vercmp | 11:50 |
| --> mr-woot has joined this channel (~AndChat@c-67-163-48-10.hsd1.il.comcast.net). | 11:50 | |
| abadger1999 | mizmo: Nice start! | 11:50 |
| skvidal | abadger1999: yah - what's he's talking about won't be solved by that, though :) | 11:50 |
| abadger1999 | <nod> | 11:50 |
| mizmo | if we have rpms for installing the repos it would be cool to use the firefox package kit plugin for one click install | 11:51 |
| skvidal | so | 11:51 |
| skvidal | right now | 11:51 |
| <-- gregdek has left this server (Ping timeout: 258 seconds). | 11:51 | |
| skvidal | I'm inclined to believe that most repos | 11:51 |
| skvidal | will be one-off pkgs | 11:51 |
| skvidal | weird rebuild cases | 11:51 |
| skvidal | and stuff like chromium | 11:52 |
| skvidal | and that the complicated cases we're worrying about will happen | 11:52 |
| skvidal | but will be less common | 11:52 |
| abadger1999 | spot: Wuestion: Have you ever needed to pull in and replace a Fedora package with a newer/older/some other version in order to get a working chromium? | 11:52 |
| skvidal | does anyone disagree with that basic assessment? | 11:52 |
| spot | abadger1999: yep, but i did it in a way that did not conflict with the base fedora package | 11:52 |
| abadger1999 | spoleeba: Or for that matter, changed chromium's source code but a lesser programmer might have taken an easier way out? | 11:52 |
| spot | abadger1999: see icu42 in F-11: http://spot.fedorapeople.org/chromium/F11/ | 11:53 |
| skvidal | hmm | 11:53 |
| drago01_ | skvidal: are we going to allow everything or only stuff that can be in fedora? | 11:53 |
| skvidal | I hadn't thought about doing this | 11:53 |
| drago01_ | (patents) | 11:53 |
| spot | abadger1999: uh, yeah, a lesser programmer would have left all of the bundling intact. | 11:53 |
| skvidal | drago01: if there are things that are illegal to ship in fedora, they are illegal to ship in a personal repo hosted by fedora | 11:54 |
| mizmo | maybe we should do a survey of fedora package maintainers who maintain repos in their fedora people space to see what they're doing 'em for | 11:54 |
| skvidal | spot: correct me if I'm wrong on there - but we cannot host patent-infringing sw anymore than we can distribute it, can we? | 11:54 |
| spot | skvidal: that's right. | 11:54 |
| mizmo | just to get a rough guesstimate of the percentages of which ones would cause problems | 11:54 |
| skvidal | mizmo: I was actually doing that directly | 11:54 |
| abadger1999 | skvidal: I think I agree with you in terms of repos by quantity -- not sure about repos by package quantity. | 11:54 |
| mizmo | oh okay cool | 11:54 |
| skvidal | mizmo: find -name repodata on people1 | 11:54 |
| drago01_ | skvidal: ok, so it won't end up with "a rebuild of foo with x,y and z" enabled | 11:54 |
| mizmo | lol great minds think alike but greater minds think faster :) | 11:54 |
| skvidal | mizmo: gonna get a list of all repos out there | 11:55 |
| skvidal | the legal cases will have to be handled by legal and then addressed by admins in fedora | 11:55 |
| skvidal | so - there are 390 repos on fedorapeople.org | 11:55 |
| mizmo | daaamn | 11:56 |
| abadger1999 | drago01_: Where x,y, and z == patent encumbered, yeah... but where z,y,and z == an added dep that we didn't want to end up on the livecd or a config option that we just don't turn on because we don't like it, yeah it could. | 11:56 |
| skvidal | mizmo: hosted by 66 users | 11:56 |
| abadger1999 | drago01_: Like if someone wanted to make a system that ran with initng instead of upstart in sysv compat mode, they might rebuild packages with a different set of init scripts. | 11:57 |
| skvidal | I can email these users and ask them what's in their repo and why. | 11:57 |
| drago01_ | abadger1999: ok | 11:57 |
| skvidal | mizmo: let's be fair - 390 'repodata' directories - how many of those are actual repos, I don't know.. | 11:58 |
| skvidal | mizmo: like 5 of them are mine and those are make yum explode repos | 11:59 |
| --> noriko has joined this channel (~noriko@d58-106-24-234.rdl801.qld.optusnet.com.au). | 11:59 | |
| skvidal | so I guess this makes a good 'actionitem' | 11:59 |
| skvidal | I'll email these folks and ask what's in their repos, how do they maintain them, and what would actually help them maintain them | 12:00 |
| skvidal | and see what we get back | 12:00 |
| drago01 | abadger1999: but we don't have any reviews to make sure that this is the case | 12:01 |
| --> liknus has joined this channel (~liknus@adsl-141-45.adsl.ntua.gr). | 12:01 | |
| --> ReneP has joined this channel (ReneP@fedora/ReneP). | 12:01 | |
| drago01 | abadger1999: i.e stuff can be removed once known but we don't have a "pre check" like we do have for fedora packages | 12:01 |
| abadger1999 | drago01: Yeah -- spot, are we going to go on a -- "someone reported that package Foo has patent encumbered code, we need to remove it" system? | 12:02 |
| skvidal | abadger1999: I believe that was the plan | 12:02 |
| skvidal | abadger1999: enforce as reported | 12:02 |
| * abadger1999 notes we're at an hour | 12:02 | |
| spot | abadger1999: yeah, probably with me doing basic sanity checks from time to time | 12:02 |
| spot | e.g. ffmpeg is obviously not acceptable. | 12:03 |
| abadger1999 | mizmo: Oh -- another badge/metric could be: maintained by the same people who maintain in Fedora. | 12:03 |
| skvidal | james_w: another question if you have a moment | 12:03 |
| <-- noriko has left this server (Quit: i will be back!). | 12:03 | |
| james_w | sure | 12:03 |
| skvidal | james_w: do you ever see issues with folks being confused where a package came from and if it is an official ubuntu pkg or not? | 12:04 |
| skvidal | think of it as a branding problem | 12:04 |
| drago01 | skvidal: and what about $randomclosessourceapp ... do we have a policy here? | 12:04 |
| drago01 | (assume no legal issues) | 12:04 |
| skvidal | drago01: random closed source is illegal | 12:04 |
| drago01 | skvidal: my point is that this could end up as a dumping ground for stuff that can't go into fedora | 12:05 |
| abadger1999 | skvidal: But not, say -- distributable closed source. | 12:05 |
| james_w | skvidal: not in my experience. For the most part people that use PPAs are the people that track all that stuff anyway. We have checks in apport that stop them filing bugs against the official package and things like that. | 12:05 |
| skvidal | drago01: yes, I think that is possible. | 12:05 |
| abadger1999 | spot: ? Have an idea on that? | 12:05 |
| drago01 | skvidal: what? being closed does not mean not legaly distributable | 12:05 |
| spot | drago01: for now, i'd rather focus on stuff that meets the licensing guidelines. if there is pent up demand for packaging junk which isn't free or doesn't have source, we can revisit it. | 12:05 |
| skvidal | james_w: fair enough | 12:05 |
| abadger1999 | spot: i guess we're setting this up, though, in the opposite way -- do we want to spend energy keeping it out? | 12:06 |
| mizmo | abadger1999: oh yeh thats an awesome idea | 12:06 |
| spot | abadger1999: eh, only to the extent that we should check the spec for license tag compliance. | 12:06 |
| abadger1999 | Okay. | 12:07 |
| spot | and yes, i realize how trivial that is to bypass, but most folks won't, and it will likely be noticed if they do it. | 12:07 |
| *** mchua_afk is now known as mchua. | 12:07 | |
| skvidal | okay. | 12:08 |
| --> MooDoo has joined this channel (~paulmello@cpc3-mapp2-0-0-cust899.nott.cable.ntl.com). | 12:08 | |
| skvidal | so as to my earlier statement | 12:08 |
| skvidal | is anyone convinced we're going to see too many problems to proceed? | 12:09 |
| *** mchua is now known as mchua_afk. | 12:09 | |
| skvidal | b/c I'm not convinced we are going to see too many problems, yet, though I reserve the right to be wrong later :) | 12:09 |
| * spot is not convinced of that, but is not going to ram it forward if others think that it is | 12:09 | |
| mizmo | i have a question. what if say amazon wanted to build a version of their (closed source) mp3 downloader for fedora. is this something they could use? | 12:09 |
| skvidal | mizmo: to build it? or to host it? | 12:10 |
| mizmo | skvidal: to build it | 12:10 |
| skvidal | I'd like to think that amazon has their own systems that can run mock | 12:10 |
| drago01 | mizmo: didn't we just talk about that? | 12:10 |
| drago01 | oh | 12:10 |
| spot | mizmo: from a technology perspective, possibly, but our policies wouldn't permit it. | 12:10 |
| mizmo | drago01 sorry if i missed it i saw closed source not allowed skimming it | 12:10 |
| mizmo | im just scared because more and more i see our distro not being supported for 3rd party apps like that | 12:11 |
| abadger1999 | i'm not convinced we'll see too many problems but wants us to message that this is a system for people who have a tolerance for breakage and dead-ends of development. | 12:11 |
| drago01 | mizmo: no this was about hosting not (ab)using the build infrastructure | 12:11 |
| mizmo | fedora as a platform to third party app devels isnt so attractive it would be nice if this could help solve that problem but i understand if its out of scope too | 12:11 |
| skvidal | mizmo: this doesn't really help longterm interfaces | 12:12 |
| abadger1999 | mizmo: I'm not sure if the build system I was envisioning would aid them in doing that but I can see if there's anyway I could. | 12:12 |
| drago01 | mizmo: yeah being a (fast) moving target is the primary cause imo | 12:12 |
| skvidal | mizmo: nor does it make anything better if their app requires older/newer items | 12:12 |
| mizmo | well other distros make it easier too | 12:12 |
| skvidal | mizmo: make it easier, how? | 12:12 |
| mizmo | there is some movie player thing, | 12:12 |
| mizmo | and they only offer an ubuntu deb | 12:12 |
| mizmo | and i filed a ticket with customer support | 12:12 |
| mizmo | and they were really nasty to me saying it was too hard to build for fedora | 12:12 |
| mizmo | so they wont even bother | 12:12 |
| mizmo | i cant think of the name of it... | 12:13 |
| skvidal | mizmo: any specifics? | 12:13 |
| skvidal | mizmo: as to why fedora was hard to build for? or was it 'does not stay the same for long enough' | 12:13 |
| mizmo | if i could remember the stupid name of it i could pull up the email by search | 12:13 |
| spoleeba | mizmo, i would have thought that Suse build system solved this particular problem for 3rd party app developers who want to distribute from their own site | 12:13 |
| mizmo | i think they more said, ubuntu made it easier | 12:13 |
| skvidal | b/c that latter concern is valid and beyond changing the support lifespan of the distro we're out of luck | 12:13 |
| mizmo | and didnt complain about our specific problems | 12:14 |
| drago01 | skvidal: not breaking ABI/API _during_ the lifecycle would be a start | 12:14 |
| skvidal | drago01: sure | 12:14 |
| skvidal | mizmo: if you can find the mail, I'd love to hear more | 12:14 |
| skvidal | mizmo: but my suspicion is that the problem is lifecycle-related | 12:15 |
| spoleeba | mizmo, is amazon even using a PPA? | 12:15 |
| skvidal | mizmo: but, again, I'm fine with being wrong there | 12:15 |
| spoleeba | mizmo, or are they building locally and distributing locally? | 12:15 |
| skvidal | looks like locally | 12:16 |
| spoleeba | skvidal, so if mock isnt easy enough...i dont know how it gets easier | 12:16 |
| mizmo | spoleeba: i dont know how they build but the debs were on their own website | 12:16 |
| drago01 | well google does ship rpms | 12:17 |
| drago01 | even a repo afaik | 12:17 |
| skvidal | but we're getting a bit off in the weeds here | 12:17 |
| drago01 | adobe has a yum repo too | 12:17 |
| skvidal | mizmo: if you can find the email - let us know about it, okay? | 12:17 |
| mizmo | sorry about that its my fault | 12:17 |
| skvidal | drago01: yep | 12:17 |
| mizmo | i will | 12:17 |
| mizmo | it was an app like miro... but closed source... argh | 12:17 |
| skvidal | boxeetv? | 12:18 |
| skvidal | they only have ubuntu pkgs | 12:18 |
| mizmo | yes! that was it | 12:18 |
| spoleeba | mizmo, its a good point.. if the kopers stuff can be replicated easily so third parties can set up their own repos....but that's a bigger commitment than just one package on one website | 12:18 |
| mizmo | grr i cant find the damn email though | 12:19 |
| skvidal | wow | 12:19 |
| skvidal | so the boxee tv deb | 12:19 |
| skvidal | is 54mb | 12:19 |
| spoleeba | skvidal, does it have any...deps | 12:19 |
| drago01 | mizmo: write a new one ;) | 12:19 |
| mizmo | hehe | 12:20 |
| spoleeba | skvidal, sounds like something alien could covert without loss of fidelity | 12:20 |
| drago01 | spoleeba: didn't someone package dbpkg for fedora ;) | 12:20 |
| skvidal | righto | 12:20 |
| skvidal | so <shrug> | 12:22 |
| skvidal | no idea on why boxee is easier to pkg for ubuntu than fedora - and speculation is not gonna help much | 12:22 |
| drago01 | yeah it might be even as trival as we are not shipping al required deps | 12:23 |
| <-- inode0 has left this server (Quit: Leaving.). | 12:23 | |
| drago01 | but the large package size makes that unlikl | 12:23 |
| drago01 | y | 12:23 |
| <-- ReneP has left this server (Ping timeout: 246 seconds). | 12:23 | |
| skvidal | drago01: who knows | 12:23 |
| --> constanton has joined this channel (~constanto@athedsl-4502970.home.otenet.gr). | 12:24 | |
| skvidal | mizmo: if you can't find the email - would you be willing to email them again? | 12:24 |
| mizmo | skvidal: sure | 12:24 |
| drago01 | skvidal: yeah I don't think we are going anywhere by speculating ... | 12:24 |
| skvidal | ok | 12:24 |
| skvidal | mizmo: thx | 12:25 |
| skvidal | james_w: just wanted to say thanks for the input - it's been helpful | 12:25 |
| skvidal | anyone have anything else? | 12:25 |
| james_w | np | 12:25 |
| --> cmpahar has joined this channel (~cmpahar@83.212.126.199). | 12:25 | |
| mizmo | i justed emailed them | 12:25 |
| skvidal | mizmo: for great justed | 12:26 |
| skvidal | abadger1999: you have anything else you wanted to ask/cover/talk about? | 12:26 |
| mizmo | hehe | 12:26 |
| abadger1999 | Noe, all set. | 12:26 |
| skvidal | okie doke | 12:27 |
| skvidal | thanks for coming along and discussing everyone | 12:27 |
| abadger1999 | Oh -- one thing -- we need a name | 12:27 |
| abadger1999 | I want to start throwing code on fedorahosted. | 12:28 |
| skvidal | not to be obvious but | 12:28 |
| skvidal | fpr? | 12:28 |
| skvidal | fedora personal repo? | 12:28 |
| Southern_Gentlem | derby? | 12:28 |
| skvidal | hmm - should fedora be left out? | 12:28 |
| --> heffer has joined this channel (~felix@fedora/heffer). | 12:28 | |
| abadger1999 | they aren't really personal and ... yes, I'd leave fedora out. | 12:28 |
| skvidal | abadger1999: arbitrary package builds? | 12:29 |
| abadger1999 | apb is already the name of a java build system so there might be some confusion in that space. | 12:29 |
| skvidal | ah | 12:29 |
| jwb | s/builds/repos | 12:29 |
| skvidal | jwb: apr is REALLY already used by apache iirc | 12:30 |
| skvidal | Summary : Apache Portable Runtime library | 12:30 |
| skvidal | URL : http://apr.apache.org/ | 12:30 |
| jwb | what was wrong with kopers | 12:30 |
| skvidal | they aren't koji based | 12:30 |
| skvidal | so the ko doesn't work so much | 12:30 |
| abadger1999 | We're not building with koji, and they aren't really personal. | 12:30 |
| jwb | kewl other package repos | 12:30 |
| skvidal | tbnr - to be named repos? | 12:30 |
| skvidal | kopr :) | 12:31 |
| skvidal | cute | 12:31 |
| abadger1999 | :-) | 12:31 |
| * skvidal doesn't much care | 12:31 | |
| skvidal | spot: you got a preference here? | 12:31 |
| spot | hey, he who writes it gets to name it. | 12:32 |
| abadger1999 | kewl other package repos catches the spirit of what we're doing best so far. | 12:32 |
| dgilmore | dlrr | 12:32 |
| skvidal | abadger1999: worksforme->closed | 12:32 |
| abadger1999 | I have access to fas so I guess I can go with that and perform the rename if I need to. | 12:32 |
| skvidal | dgilmore: did you have stroke? | 12:33 |
| dgilmore | dirty little rpm repo | 12:33 |
| abadger1999 | hahah | 12:33 |
| spot | man, that is begging to be lolcatted | 12:33 |
| spot | "did you have stroke?" | 12:33 |
| dgilmore | skvidal: :) | 12:33 |
| * skvidal decides it is in his best interest to find another thing to look at | 12:34 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!