Re: [gentoo-dev] Re: Re: On hosting self-produced distfiles
Mike Frysinger wrote: On Thursday, January 20, 2011 14:47:24 Diego Elio Pettenò wrote: << SNIP >> Also "angry unhelpful tools"? You're putting words in my mail that aren't there. I said infra _used_ to be against that; it was obvious that knowing that I wouldn't just push the issue against their will. no, you didnt. you said "the Infra team has been against this idea". you didnt say anywhere that infra had changed their mind, and this statement made it sound like basically "screw infra, this is what QA says, and if infra doesnt like it they can figure something out on their own". <>-mike Actually, yea he did. In your quote of him, he said "has been'. Maybe you misread it but that means they had a different view or opinion in the past but that has changed. Dale :-) :-)
Re: [gentoo-dev] genkernel 3.4.11.1 released
On Fri, 21 Jan 2011 01:15:19 +0100 Sebastian Pipping wrote: > On 01/20/11 22:06, Jeroen Roovers wrote: > > Version bumps have no place on the dev-announce list /unless/ they > > impact developers' work directly. > > Fine. > > > > (and not because you want to celebrate the glory of another version > > release). > > I'm not sure if I'm just interpreting things, but I wish you would > speak to me in a way, where I would not have to wonder on each mail, > if you're just trying to piss me off. Thanks. You were reading my interpretation of your upstream release notice. I'm not sure why that would piss you off. I can, however, make it absolutely clear that I didn't write anything between the lines. jer
Re: [gentoo-dev] genkernel 3.4.11.1 released
On 01/20/11 22:06, Jeroen Roovers wrote: > Version bumps have no place on the dev-announce list /unless/ they > impact developers' work directly. Fine. > (and not because you want to celebrate the glory of another version release). I'm not sure if I'm just interpreting things, but I wish you would speak to me in a way, where I would not have to wonder on each mail, if you're just trying to piss me off. Thanks. Sebastian
Re: [gentoo-dev] genkernel 3.4.11.1 released
On 01/20/11 21:55, Fabian Groffen wrote: > Unless if you are on some git repo, we have commit mails which can serve > this purpose very well. I am on a git repo, and a commit list serves a different purpose: low level tracking of changes. Sebastian
Re: [gentoo-dev] Re: Re: Re: Re: On hosting self-produced distfiles
On Thursday, January 20, 2011 16:21:33 Diego Elio Pettenò wrote: > Il giorno gio, 20/01/2011 alle 22.14 +0100, Jeroen Roovers ha scritto: > > I'd be happier if you responded my proposal of changing the meaning of > > mirror://gentoo - the mirror sync scripts could take care of the > > entire > > thing by forever storing files described that way. That way, no > > ebuilds/eclasses using mirror://gentoo would need changing, and we > > could conveniently move away from using dev.gentoo.org for > > availability > > of old self-hosted SRC_URI files. > > http://bugs.gentoo.org/show_bug.cgi?id=176186 > > I'VE NOT DREAMT ABOUT THIS LAST NIGHT. This is why there was no > "discussion": it was all planned already, from a long time ago. first off, drop the caps crap. second, while *you* might be aware of a long history, you provided absolutely none in your first e-mail. thus it completely looked like only 1 person (you) was making a decision which had not been discussed with anyone else. and having recently been placed into QA lead, you decided to use that position to force everyone else to agree. again, without any discussion. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: On hosting self-produced distfiles
On Thursday, January 20, 2011 14:42:03 Diego Elio Pettenò wrote: > Il giorno gio, 20/01/2011 alle 20.27 +0100, Matti Bickel ha scritto: > > Not sure what you mean: if someone quickpkg's php and needs all the > > source? Well, they already downloaded them. Better keep them around, > > since it's *your* binary, not mine. > > We do distribute part of our packages as binaries already so we have to > be compliant with their licenses to begin with. Better doing it with a > single sweep than trying to come up with abstruse case-by-case points, > no? my understanding is that releng already has a process in place so that when they do a binary release, they tag all the versions so that our mirrors retain the source archives. > > Same thing, as already pointed out in another message. I see the point > > in making it easier for them. That's okay. So what you're saying is > > we're upstream too and upstream's should provide their historical stuff. > > This is but _one_ reason, and just another thing to trickle down. I > don't care if "FSF says it's their problem"; what is it costing us, > really? The cost is minimal (as we need the archive anyway), and the > gain is there for many people. if we needed the archive, then this bullet point wouldnt have been relevant. but if we dont need the archive, then keeping it around for some unknown derivative distro out there doesnt make sense. how do you pick which archives to keep ? all of them ? for how long ? if you cant come up with a clear expiration process, then dont bother. and yes, there is real cost to keeping around archives we dont need. i cant imagine the people providing mirrors for our project for free are going to say "sure, balloon the lists of files we have to mirror all you want". > Arguing against this is just getting to the point of arguing because > somebody is doing what nobody did for a long time: taking decisions. semantically speaking, you make decisions -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: On hosting self-produced distfiles
On Thursday, January 20, 2011 14:47:24 Diego Elio Pettenò wrote: > Il giorno gio, 20/01/2011 alle 14.28 -0500, Mike Frysinger ha scritto: > > then you should have mentioned this in your original e-mail rather > > than > > painting infra as angry unhelpful tools. the changes you propose are > > merely a > > stop gap measure until infra finishes their work. > > You of all people to sound surprised about this really doesn't look > right. The fact that such an archive has been in the work is something > know since I became a dev, six years ago; the bug was open in 2007. just because a bug has been opened for a long time doesnt mean i'm aware of it. ive never heard of this project before. > Also "angry unhelpful tools"? You're putting words in my mail that > aren't there. I said infra _used_ to be against that; it was obvious > that knowing that I wouldn't just push the issue against their will. no, you didnt. you said "the Infra team has been against this idea". you didnt say anywhere that infra had changed their mind, and this statement made it sound like basically "screw infra, this is what QA says, and if infra doesnt like it they can figure something out on their own". > If you were trying to pick a fight for the sake of it, I'd suggest you > find something else to do. ah yes, i'm sure that's what i'm doing. i love picking fights with you because you're awesome and i am not. and/or i have no fscking idea what you're talking about. hmm, one of those. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: Re: On hosting self-produced distfiles
On 01/20/2011 09:46 PM, Diego Elio Pettenò wrote: > So I'm not asking _you_ to waste 90% of your time discussing and > auditing licenses. We have a team for that. We do? Cool, I didn't know about that. Which team is it? > At the same time I'm not going to ask the developers to all evaluate > case by case whether they should or shouldn't keep their stuff > available. I'm telling them to put it there rather than in another > place; what that will change shouldn't really be a problem. I reiterate: I just wanted to understand what the bloody point is. I saw your logic for "let's have permanent space", not "we need everybody to use permanent space". But "Because I say so" 's valid enough for me. Dunno, but I'd try to make stuff so cool and easy to use that people *want* it and forget about the rest. But that's just me. > Again, you might not care, we have other teams that do care. Since I'm > not asking you to do a 180° jump changing your habits, can we please > just agree that you don't see the point but you'll follow the request > anyway? Sure. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 18.42 -0300, Alexis Ballier ha scritto: > Solution b): update the distfiles-local mirroring script to store a copy > where > it wont be deleted... > The interim solution is the current one with the files being deleted when not > used in the tree. Won't happen, infra is already spending time on the _final_ solution. > Your solution more or less > annihilates this in the case it's bumped by different developers. Wrong. Check app-emulation/libvirt for a two-developers package, or dev-lang/ruby for shared team packages. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] On hosting self-produced distfiles
On Wednesday, January 19, 2011 09:50:35 pm Diego Elio Pettenò wrote:
> Hi all,
>
> I just wanted to write here a clarification regarding self-produced
> distfiles, such as patchset tarballs, SCM snapshots and the like. Some
> people seem under the impression that the correct way to host these is
> to use mirror://gentoo/ and copy them on /space/distfiles-local on
> dev.g.o. Please don't do this.
>
> If you produced the file yourself, and it doesn't matter if the file is
> reproducible (unless it is reproducible to sha512 identity), please use
> the public_html directory in your dev.gentoo.org home to host these.
> This makes sure that the file won't be deleted from all its sources if
> the ebuild is removed (or more likely replaced) from tree. Ask the Emacs
> team how "easy" has been to recover gentoo-syntax files before.
Solution b): update the distfiles-local mirroring script to store a copy where
it wont be deleted...
The interim solution is the current one with the files being deleted when not
used in the tree.
I'm sorry but your solution doesn't really seem well thought. I'm used and
like to use $P and alikes, sometimes with versionator, in SRC_URI for not
having to modify this part when bumping a package. Your solution more or less
annihilates this in the case it's bumped by different developers. IIRC at least
one of {devmanual, policy, quizzes} mandates to have such scalable SRC_URI's.
A.
[gentoo-dev] Re: Re: Re: Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 22.14 +0100, Jeroen Roovers ha scritto: > > I'd be happier if you responded my proposal of changing the meaning of > mirror://gentoo - the mirror sync scripts could take care of the > entire > thing by forever storing files described that way. That way, no > ebuilds/eclasses using mirror://gentoo would need changing, and we > could conveniently move away from using dev.gentoo.org for > availability > of old self-hosted SRC_URI files. http://bugs.gentoo.org/show_bug.cgi?id=176186 I'VE NOT DREAMT ABOUT THIS LAST NIGHT. This is why there was no "discussion": it was all planned already, from a long time ago. You want to change the plan? Talk with Robin/infra. In the mean time, though, this is what future ebuilds/eclasses will have to look right until further notice. Notice that I hope will soon come with a final solution without the current drawbacks (which are still a bit less troublesome than those we had before). -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] last rites: games-misc/jugglemaster games-util/taxidraw
+# Michael Sterrett (20 Jan 2011) +# wxgtk:2.6 is going away so mask these for removal on 20110219 +games-misc/jugglemaster +games-util/taxidraw
Re: [gentoo-dev] Re: Re: Re: On hosting self-produced distfiles
On Thu, 20 Jan 2011 21:58:43 +0100 Diego Elio Pettenò wrote: > Let's be clear, I'm not asking for anybody to spend the next couple of > days to convert all the packages out there for this very reason. That wasn't entirely clear. > *But* I'm asking for the _future_ ebuilds to have it moved in a place > where we can pick it up to move it when possible. That wasn't clear either. I'd be happier if you responded my proposal of changing the meaning of mirror://gentoo - the mirror sync scripts could take care of the entire thing by forever storing files described that way. That way, no ebuilds/eclasses using mirror://gentoo would need changing, and we could conveniently move away from using dev.gentoo.org for availability of old self-hosted SRC_URI files. (This is probably why several people have requested you propose this change to the developer community instead of wearing your QA hat and pretending to lay down the law - I see QA as the executor of common sense, technically sensible, commonly approved approaches to problems, i.e. generally approved policy, not in the role of policy maker. If we've been doing things against policy for years, then maybe we should change the policy, or at least discuss it without the pretence of a developer hierarchy.) jer
Re: [gentoo-dev] genkernel 3.4.11.1 released
On Thu, 20 Jan 2011 21:57:46 +0100 Sebastian Pipping wrote: > On 01/20/11 21:45, Rich Freeman wrote: > > On Thu, Jan 20, 2011 at 3:38 PM, Fabian Groffen > > wrote: > >> Like Jeroen, I don't think new package releases should be > >> announced on these developer-related lists. > > > > Tend to agree, at least in general. If a genkernel upgrade impacted > > multiple teams/etc, such as requiring changes to install media, or > > the handbooks, etc, then I'd consider it completely fair game for > > the lists. Likewise if some big change that will really impact the > > distro is being considered I'd consider that fair game as well. > > Fair point. > > I'll keep posting to Planet Gentoo. How about gentoo-dev-announce? Version bumps have no place on the dev-announce list /unless/ they impact developers' work directly. It's described as "Gentoo development-specific announcements list". So what you post there is relevant to Gentoo development work. More or less like Fabian said it, if it requires changes or else it will break the distro, that's when you give all developers the heads-up (and not because you want to celebrate the glory of another version release). jer
[gentoo-dev] Re: Re: Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 21.38 +0100, Jeroen Roovers ha scritto: > > > I'm lost now. Do you/infra/$GENTOO_DEITY plan to first force everyone > to > use dev.g.o and then move to mirror://gentoo-projects soon after? "soon after"? Sorry I don't foresee the next move to happen within six months. And once we know which files need to be migrated, I can do the migration myself, or infra can do that. Let's be clear, I'm not asking for anybody to spend the next couple of days to convert all the packages out there for this very reason. *But* I'm asking for the _future_ ebuilds to have it moved in a place where we can pick it up to move it when possible. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] genkernel 3.4.11.1 released
On 01/20/11 21:45, Rich Freeman wrote: > On Thu, Jan 20, 2011 at 3:38 PM, Fabian Groffen wrote: >> Like Jeroen, I don't think new package releases should be announced on >> these developer-related lists. > > Tend to agree, at least in general. If a genkernel upgrade impacted > multiple teams/etc, such as requiring changes to install media, or the > handbooks, etc, then I'd consider it completely fair game for the > lists. Likewise if some big change that will really impact the distro > is being considered I'd consider that fair game as well. Fair point. I'll keep posting to Planet Gentoo. How about gentoo-dev-announce? > That said, there are some nice genkernel changes being made and I for > one appreciate them (even though I don't yet run it - the mdadm > inclusion will probably push me over the edge)! If you get the chance please try genkernel-9 (five nines) exposing the experimental branch. That may save both of us the trouble to fix things post release. Best, Sebastian
Re: [gentoo-dev] genkernel 3.4.11.1 released
On 20-01-2011 21:47:19 +0100, Sebastian Pipping wrote: > On 01/20/11 21:38, Fabian Groffen wrote: > > Like Jeroen, I don't think new package releases should be announced on > > these developer-related lists. > > It's not about the package, it's about the release itself. > I don't send mails on package bumps I do. Unless if you are on some git repo, we have commit mails which can serve this purpose very well. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] genkernel 3.4.11.1 released
On 01/20/11 21:38, Fabian Groffen wrote: > Like Jeroen, I don't think new package releases should be announced on > these developer-related lists. It's not about the package, it's about the release itself. I don't send mails on package bumps I do. Sebastian
[gentoo-dev] Re: Re: Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 21.35 +0100, Matti Bickel ha scritto: > On 01/20/2011 08:42 PM, Diego Elio Pettenò wrote: > No. Licenses are not a valid argument to me. I'd accept that if we're > Debian and pushing 100% of *our* stuff as binary. What we do 90% of the > time is distributing text - ebuilds. So I'm not asking _you_ to waste 90% of your time discussing and auditing licenses. We have a team for that. At the same time I'm not going to ask the developers to all evaluate case by case whether they should or shouldn't keep their stuff available. I'm telling them to put it there rather than in another place; what that will change shouldn't really be a problem. > I just was curious about the reasons, as I see no > compelling point in *forcing* this. The reason to *force* this is two fold: we need a policy so that we stop the fact that everybody does as he pleases and this is replacing a _different_ forcing that we _used_ to have, and which I'm not surprised you didn't hear about, that told developers to use mirror://gentoo/. Which is unfortunately troublesome *as Ulrich and Christian already shown*. And since in Gentoo we cannot simply scratch rules, as otherwise people will keep referencing them forever and ever, a new rule replaces the old rule: you use dev.gentoo.org rather than mirror://gentoo/. > Take php-5.3.2: I don't care if you found a security issue in my tarball > or in php's tarball. I'll have a look to determine if the bug's still in > the newest version. If it is, I'll rename the bug. If it is not, it > doesn't matter to me. You might not care. I would, and it's not just a matter of being the current QA lead in charge, but rather a question of professionalism. If I would find you or another developer to have introduced a backdoor in a custom tarball, I'm going to have said developer booted, quickly. Again, you might not care, we have other teams that do care. Since I'm not asking you to do a 180° jump changing your habits, can we please just agree that you don't see the point but you'll follow the request anyway? -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] genkernel 3.4.11.1 released
On Thu, Jan 20, 2011 at 3:38 PM, Fabian Groffen wrote: > Like Jeroen, I don't think new package releases should be announced on > these developer-related lists. Tend to agree, at least in general. If a genkernel upgrade impacted multiple teams/etc, such as requiring changes to install media, or the handbooks, etc, then I'd consider it completely fair game for the lists. Likewise if some big change that will really impact the distro is being considered I'd consider that fair game as well. More routine upgrades probably don't need specific annoucements. That said, there are some nice genkernel changes being made and I for one appreciate them (even though I don't yet run it - the mdadm inclusion will probably push me over the edge)! Rich
[gentoo-dev] Re: Rail Model font for coders
On 01/20/2011 11:14 AM, hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com wrote: There is a font for coders called Rail Model, please include it with Linux distributions: http://code.google.com/p/railmodel/downloads/detail?name=RailModelFont.zip&can=2&q= If this is a joke, I don't get it :-P I was curious about what this font is about, and its description is: "Rail Model Font is a Pro Bono (for the public good) Hare Krishna Ritvik Universal Religion Project for spiritual / philosophical reasons and thus any full or part technical or non-technical opensource resources and licenses used of Local Religion (e.g. Christianity, Islam, Judaism, Buddhism, Jainism) organisations and individuals and/or commercial organisation and individuals and/or other non-profit organisations and individuals, they are considered donations to His Divine Grace A C Bhaktivedanata Swami Prabhupada, Founder Acharya & Permanent Sole Initiator of the Hare Krishna Movement the permanent person, not the estate, state, representative/s or representative organisation/s etc." Wait, what... huh?
Re: [gentoo-dev] genkernel 3.4.11.1 released
On 20-01-2011 21:34:36 +0100, Sebastian Pipping wrote: > On 01/20/11 21:08, Jeroen Roovers wrote: > > On Thu, 20 Jan 2011 16:00:06 +0100 > > Sebastian Pipping wrote: > > > >> This release fixes two bugs both affecting 3.4.11 (not earlier > >> releases). > > > > I'm a Gentoo developer. > > I've never used genkernel for private purposes. > > So I don't see why you would send this to gentoo-dev@ and > > gentoo-dev-announce@. > > I don't think a bit of extra visibility can hurt with this. > > Still, I may take it off the list if another Gentoo developer seconds > that request. Like Jeroen, I don't think new package releases should be announced on these developer-related lists. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: Re: On hosting self-produced distfiles
On Thu, 20 Jan 2011 21:23:49 +0100 Diego Elio Pettenò wrote: > Now we're re-joining policy and practice. By forcing use of dev.gentoo.org for self-hosted SRC_URI files? > > What legitimate use does mirror://gentoo retain when we do have a > > solution? Ultimate patch attached. > Yes and? We're going to have a distinct mirror://gentoo-projects/ > (just to be on the safe side for overlays mainly) to fetch the > distfiles for the custom packages. By forcing use of mirror://gentoo-projects for self-hosted SRC_URI files? I'm lost now. Do you/infra/$GENTOO_DEITY plan to first force everyone to use dev.g.o and then move to mirror://gentoo-projects soon after? Why don't we just change the meaning of mirror://gentoo and be done with it, without the interim being extended? We could even have the mirror sync scripts interpret mirror://gentoo in a new way. All we then need to do on the QA side is to somehow enforce the way mirror://gentoo is used. :) jer
Re: [gentoo-dev] Re: Re: On hosting self-produced distfiles
On 01/20/2011 08:42 PM, Diego Elio Pettenò wrote: > We do distribute part of our packages as binaries already so we have to > be compliant with their licenses to begin with. Better doing it with a > single sweep than trying to come up with abstruse case-by-case points, > no? No. Licenses are not a valid argument to me. I'd accept that if we're Debian and pushing 100% of *our* stuff as binary. What we do 90% of the time is distributing text - ebuilds. > Arguing against this is just getting to the point of arguing because > somebody is doing what nobody did for a long time: taking decisions. Yes, and I'm not going to stop you. Frankly, I don't care enough where my tarballs end up. I just was curious about the reasons, as I see no compelling point in *forcing* this. >> If you're reporting a security issue in a ebuild that's no longer in >> tree (in php's case, chances are it got removed b/c of security :p), the >> bug wouldn't be investigated, right? > > There are cases and cases there; in the case of _custom_ tarballs, I'd > expect us to investigate if the security issues was found on our version > and not in the upstream-provided one for instance. Take php-5.3.2: I don't care if you found a security issue in my tarball or in php's tarball. I'll have a look to determine if the bug's still in the newest version. If it is, I'll rename the bug. If it is not, it doesn't matter to me. > Once again, please tell me: what does it change to you? If anybody > should complain about this request is Infra. What it changes for me? The target argument of my scp command. Which is so small that I don't care (see above for why I still replied). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] genkernel 3.4.11.1 released
On 01/20/11 21:08, Jeroen Roovers wrote: > On Thu, 20 Jan 2011 16:00:06 +0100 > Sebastian Pipping wrote: > >> This release fixes two bugs both affecting 3.4.11 (not earlier >> releases). > > I'm a Gentoo developer. > I've never used genkernel for private purposes. > So I don't see why you would send this to gentoo-dev@ and > gentoo-dev-announce@. I don't think a bit of extra visibility can hurt with this. Still, I may take it off the list if another Gentoo developer seconds that request. Sebastian
[gentoo-dev] Re: Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 21.02 +0100, Jeroen Roovers ha scritto:
> It isn't exactly a solution and the interim has lasted for years now.
No, for years now we had policies going one way ("don't use dev.g.o")
because they were written at one point by one person, and practices for
most of us going the other (using dev.gentoo.org), as the original
reason not to use it is no longer relevant.
Now we're re-joining policy and practice.
> What legitimate use does mirror://gentoo retain when we do have a
> solution? Ultimate patch attached.
Yes and? We're going to have a distinct mirror://gentoo-projects/ (just
to be on the safe side for overlays mainly) to fetch the distfiles for
the custom packages.
> The way I see it, losing important files because you didn't
> store copies privately or publicly is not a problem our distfiles
> mirrors should solve.
For Gentoo-produced distfiles, it is nothing new that we have to have
long term access available. We've been meaning to for years as you said.
I'm positive that the issue went to the council once already.
Let's be clear here: Infra is the same page as this; this _is_ going
through. This was being worked on for months and months, and people
start complain now because... they are being asked for all of us to
follow a single policy rather than case-by-case whether to delete
distfiles or not?
There isn't _more_ work to be done with the exception of using a script
that signs the files rather than simply scp'ing them over, so it's not a
matter of "you're asking us to do more work in the future" as much as
"you're asking us to follow a procedure". Well, duh!
--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
Re: [gentoo-dev] Rail Model font for coders
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com dixit (2011-01-20, 15:06): > > please fix your stupid e-mail > > Meeku: Very good email address. Since we're onto hares why not shorten it to: tea_party@mad_hatter.uk? -- [a]
Re: [gentoo-dev] genkernel 3.4.11.1 released
On Thu, 20 Jan 2011 16:00:06 +0100 Sebastian Pipping wrote: > This release fixes two bugs both affecting 3.4.11 (not earlier > releases). I'm a Gentoo developer. I've never used genkernel for private purposes. So I don't see why you would send this to gentoo-dev@ and gentoo-dev-announce@. jer
Re: [gentoo-dev] Rail Model font for coders
2011-01-20
Thread
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare
> please fix your stupid e-mail Meeku: Very good email address.
Re: [gentoo-dev] Re: On hosting self-produced distfiles
On Thu, 20 Jan 2011 14:25:23 +0100 Diego Elio Pettenò wrote: > Il giorno gio, 20/01/2011 alle 07.23 +0100, "Paweł Hajdan, Jr." ha > scritto: > > > > Storing distfiles in public_html is not a perfect solution either. > > If the developer retires, what do we do with the files? > > That's why (and I answer to Peter here as well), it is an ad interim > solution. As I said and repeated Robin is working on the final one but > until then we still prefer this method. It isn't exactly a solution and the interim has lasted for years now. What legitimate use does mirror://gentoo retain when we do have a solution? Ultimate patch attached. The way I see it, losing important files because you didn't store copies privately or publicly is not a problem our distfiles mirrors should solve. Having SRC_URI files taking up space indefinitely because of a special SRC_URI value is not the solution either, say when we would create a static-distfiles.gentoo.org for that purpose. What if an upstream dies? Lots of packages have broken SRC_URIs because of that, and yet as long as the ebuilds are in the tree, the files are nicely mirrored for us. So, as asked here and there in this thread, what exact problem are we solving? Hopefully not merely the loss of some files in the past? jer Index: thirdpartymirrors === RCS file: /var/cvsroot/gentoo-x86/profiles/thirdpartymirrors,v retrieving revision 1.269 diff -u -B -r1.269 thirdpartymirrors --- thirdpartymirrors 19 Jan 2011 06:03:50 - 1.269 +++ thirdpartymirrors 20 Jan 2011 19:48:14 - @@ -13,7 +13,6 @@ filefront http://ftp.games.skynet.be/pub/www.filesnetwork.com ftp://ftp.games.skynet.be/pub/www.filesnetwork.com flightgear ftp://ftp.de.flightgear.org/pub/fgfs http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp ftp://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp ftp://ftp.kingmont.com/flightsims/flightgear ftp://ftp.ihg.uni-duisburg.de/Mirrors/ftp.flightgear.org freebsd ftp://ftp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.FreeBSD.org/pub/FreeBSD/ ftp://ftp.ar.FreeBSD.org/pub/FreeBSD/ ftp://ftp.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp.at.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.at.FreeBSD.org/pub/FreeBSD/ ftp://ftp.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp.ca.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.ca.FreeBSD.org/ ftp://ftp.cn.FreeBSD.org/pub/FreeBSD/ ftp://ftp.cz.FreeBSD.org/pub/FreeBSD/ ftp://ftp.dk.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.dk.FreeBSD.org/pub/FreeBSD/ ftp://ftp.ee.FreeBSD.org/pub/FreeBSD/ ftp://ftp.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp.gr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.gr.FreeBSD.org/pub/FreeBSD/ ftp://ftp.hk.FreeBSD.org/pub/FreeBSD/ ftp://ftp.is.FreeBSD.org/pub/FreeBSD/ ftp://ftp.id.FreeBSD.org/pub/FreeBSD/ ftp://ftp.ie.FreeBSD.org/pub/FreeBSD/ ! ftp://ftp2.ie.FreeBSD.org/pub/FreeBSD/ ftp://ftp.it.FreeBSD.org/pub/FreeBSD/ ftp://ftp.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp1.us.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.us.FreeBSD.org/pub/FreeBSD/ -gentoo http://gentoo.osuosl.org/distfiles http://mirrors.kernel.org/gentoo/distfiles http://ftp.halifax.rwth-aachen.de/gentoo http://gentoo-distfiles.mirrors.tds.net/distfiles http://gentoo.ussg.indiana.edu/distfiles ggz http://ftp.belnet.be/packages/ggzgamingzone/ggz http://mirrors.dotsrc.org/ggzgamingzone/ggz http://mirrors.ibiblio.org/pub/mirrors/ggzgamingzone/ggz ftp://ftp.belnet.be/packages/ggzgamingzone/ggz ftp://mirrors.dotsrc.org/mirrors/ggzgamingzone/ggz gimp ftp://ftp.gimp.org/pub/gimp http://ftp.gwdg.de/pub/misc/grafik/gimp/gimp ftp://ftp.cs.umn.edu/pub/gimp gmt ftp://mirror.geosci.usyd.edu.au/pub/gmt/ ftp://ftp.soest.hawaii.edu/gmt/ ftp://ftp.soest.hawaii.edu/gmt/ ftp://ibis.grdl.noaa.gov/pub/gmt/ ftp://ftp.iris.washington.edu/pub/gmt/ ftp://ftp.iag.usp.br/pub/gmt/ ftp://ftp.geologi.uio.no/pub/gmt/
[gentoo-dev] Re: Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 14.28 -0500, Mike Frysinger ha scritto: > > then you should have mentioned this in your original e-mail rather > than > painting infra as angry unhelpful tools. the changes you propose are > merely a > stop gap measure until infra finishes their work. You of all people to sound surprised about this really doesn't look right. The fact that such an archive has been in the work is something know since I became a dev, six years ago; the bug was open in 2007. Also "angry unhelpful tools"? You're putting words in my mail that aren't there. I said infra _used_ to be against that; it was obvious that knowing that I wouldn't just push the issue against their will. If you were trying to pick a fight for the sake of it, I'd suggest you find something else to do. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Blockers and package moves
On Thu, 20 Jan 2011 09:07:20 -0500 Jacob Godserv wrote: > On Mon, Jan 17, 2011 at 11:10, Donnie Berkholz > wrote: > > How about playing nicely with overlays where the moves didn't happen > > (yet)? > I'm not sure you have to worry about overlays. The developers of the > overlays will worry about them. > > Now, for the educated: is this fair or accurate? I maintain just the one overlay, which is my own, non-public playpen. On bugs.gentoo.org, we generally deal with invalid bugs filed because of out of date / moved / broken overlays, or the maintainers of the now broken packages in the main tree will, by marking them as invalid, or perhaps by assigning the bugs to the overlay's maintainer, if [1] lists the overlay, thereby making it official. Generally, fixing the main tree because of problems in overlays isn't desirable, and shouldn't be done, provided it actually could be done at all. jer [1] http://www.gentoo.org/proj/en/overlays/layman-global.txt
[gentoo-dev] Re: Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 20.27 +0100, Matti Bickel ha scritto: > Not sure what you mean: if someone quickpkg's php and needs all the > source? Well, they already downloaded them. Better keep them around, > since it's *your* binary, not mine. We do distribute part of our packages as binaries already so we have to be compliant with their licenses to begin with. Better doing it with a single sweep than trying to come up with abstruse case-by-case points, no? > Same thing, as already pointed out in another message. I see the point > in making it easier for them. That's okay. So what you're saying is > we're upstream too and upstream's should provide their historical stuff. This is but _one_ reason, and just another thing to trickle down. I don't care if "FSF says it's their problem"; what is it costing us, really? The cost is minimal (as we need the archive anyway), and the gain is there for many people. Arguing against this is just getting to the point of arguing because somebody is doing what nobody did for a long time: taking decisions. > If you're reporting a security issue in a ebuild that's no longer in > tree (in php's case, chances are it got removed b/c of security :p), the > bug wouldn't be investigated, right? There are cases and cases there; in the case of _custom_ tarballs, I'd expect us to investigate if the security issues was found on our version and not in the upstream-provided one for instance. Once again, please tell me: what does it change to you? If anybody should complain about this request is Infra. And Infra in the person of Robin is okay with this policy as it was planned anyway. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Rail Model font for coders
On Thursday, January 20, 2011 04:14:28 hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com wrote: please fix your stupid e-mail > There is a font for coders called Rail Model, please include it with Linux > distributions: package requests go into bugzilla, not mailing lists -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: On hosting self-produced distfiles
On Thursday, January 20, 2011 13:51:23 Diego Elio Pettenò wrote: > Il giorno gio, 20/01/2011 alle 19.41 +0100, Matti Bickel ha scritto: > > So, I'm not opposed to your idea. If ya want to archive your stuff > > forever, by all means do it. I just see no point in forcing this on > > all > > devs. So, care to explain or give me pointer on why this is necessary? > > License compliance when distributing binaries how is this relevant ? if there are issues with distributing binaries, then were they get distributed isnt important. > distributions built upon Gentoo that might use old and set-in-stone Portage > trees last i heard, the FSF's interpretation of the GPL was that this is the problem of said derivatives. i'm not saying we shouldnt help out where possible, just that we shouldnt be bending over backwards for them. they want to stay behind, then that is their problem. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: On hosting self-produced distfiles
First, thanks for pointing this out. On 01/20/2011 07:51 PM, Diego Elio Pettenò wrote: > License compliance when distributing binaries; Not sure what you mean: if someone quickpkg's php and needs all the source? Well, they already downloaded them. Better keep them around, since it's *your* binary, not mine. > distributions built upon Gentoo that might use old and set-in-stone > Portage trees; Same thing, as already pointed out in another message. I see the point in making it easier for them. That's okay. So what you're saying is we're upstream too and upstream's should provide their historical stuff. > security issues that might be reported and needs to be > investigated, ... If you're reporting a security issue in a ebuild that's no longer in tree (in php's case, chances are it got removed b/c of security :p), the bug wouldn't be investigated, right? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: On hosting self-produced distfiles
On Wednesday, January 19, 2011 22:57:59 Diego Elio Pettenò wrote: > Il giorno mer, 19/01/2011 alle 22.31 -0500, Mike Frysinger ha scritto: > > we havent > > > > hosted files on dev.g.o because we've felt the distfiles tree to be > > sufficient. since there seems to be more need now, let's find out > > what infra > > can do to help out. > > I'm pretty sure you have, for pax-utils and portage-utils, didn't you? my personal choice to keep an archive of packages i build does not mean a hard policy must be forced upon everyone. > > here's a better idea: figure out something with the infra team. > > [snip] > > again, declaring policy ahead of talking to anyone else is not the way > > to go. > > Actually, we meant to move to a stable archive of distfiles for years, > and Robin has been working on it for months already. then you should have mentioned this in your original e-mail rather than painting infra as angry unhelpful tools. the changes you propose are merely a stop gap measure until infra finishes their work. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 19.41 +0100, Matti Bickel ha scritto: > > So, I'm not opposed to your idea. If ya want to archive your stuff > forever, by all means do it. I just see no point in forcing this on > all > devs. So, care to explain or give me pointer on why this is necessary? > License compliance when distributing binaries; distributions built upon Gentoo that might use old and set-in-stone Portage trees; security issues that might be reported and needs to be investigated, ... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 13.34 -0500, Anthony G. Basile ha scritto: > > shows 39 eclasses which refer to mirror:// That's not much of a problem, mirror://kde/ mirror://debian/ and the like are fine, most of the time. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] On hosting self-produced distfiles
On 01/20/2011 01:50 AM, Diego Elio Pettenò wrote: > I just wanted to write here a clarification regarding self-produced > distfiles, such as patchset tarballs, SCM snapshots and the like. Some > people seem under the impression that the correct way to host these is > to use mirror://gentoo/ and copy them on /space/distfiles-local on > dev.g.o. Please don't do this. As one of those under the impression that mirror://gentoo was the right choice: why is it bad? From Fauli's post I gather the emacs team wanted to support ancient versions and have all files necessary to install an ebuild whatsoever it's age. In my case, that would mean installing php-4.0, for example. Why on earth should I support something like that? If I'm PHP upstream, okay, maybe allow others to see the evolution of the language. But the evolution of the php patchset? Sounds not that necessary to me. So, I'm not opposed to your idea. If ya want to archive your stuff forever, by all means do it. I just see no point in forcing this on all devs. So, care to explain or give me pointer on why this is necessary? Thanks, Matti signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] On hosting self-produced distfiles
On 01/20/2011 01:34 PM, Anthony G. Basile wrote: > On 01/20/2011 01:23 AM, "Paweł Hajdan, Jr." wrote: >> On 1/20/11 1:50 AM, Diego Elio Pettenò wrote: >>> If you produced the file yourself, and it doesn't matter if the file is >>> reproducible (unless it is reproducible to sha512 identity), please use >>> the public_html directory in your dev.gentoo.org home to host these. >>> This makes sure that the file won't be deleted from all its sources if >>> the ebuild is removed (or more likely replaced) from tree. Ask the Emacs >>> team how "easy" has been to recover gentoo-syntax files before. >> Storing distfiles in public_html is not a perfect solution either. If >> the developer retires, what do we do with the files? >> > There is another problem: > >grep mirror /usr/portage/eclass/* | sed -e 's/:.*$//' | sort | uniq > > shows 39 eclasses which refer to mirror:// > Sorry darkside pointed out that there are other mirrors, grep "mirror://gentoo" /usr/portage/eclass/* | sed -e 's/:.*$//' | sort | uniq shows 16 eclasses which would have to be changed. -- Anthony G. Basile, Ph.D. Gentoo Developer
Re: [gentoo-dev] On hosting self-produced distfiles
On 01/20/2011 01:23 AM, "Paweł Hajdan, Jr." wrote: > On 1/20/11 1:50 AM, Diego Elio Pettenò wrote: >> If you produced the file yourself, and it doesn't matter if the file is >> reproducible (unless it is reproducible to sha512 identity), please use >> the public_html directory in your dev.gentoo.org home to host these. >> This makes sure that the file won't be deleted from all its sources if >> the ebuild is removed (or more likely replaced) from tree. Ask the Emacs >> team how "easy" has been to recover gentoo-syntax files before. > Storing distfiles in public_html is not a perfect solution either. If > the developer retires, what do we do with the files? > There is another problem: grep mirror /usr/portage/eclass/* | sed -e 's/:.*$//' | sort | uniq shows 39 eclasses which refer to mirror:// -- Anthony G. Basile, Ph.D. Gentoo Developer
[gentoo-dev] genkernel 3.4.11.1 released
Hello! This release fixes two bugs both affecting 3.4.11 (not earlier releases). Bugs fixed == 351906 Move application of kernel config after "make mrproper" as that deletes .config (whereas "make clean" does not) 351909 busybox 1.18.1: Return of mdstart as an applet (regression) Special thanks go to Xake. Thanks for your interest. Sebastian
Re: [gentoo-dev] Blockers and package moves
On Mon, Jan 17, 2011 at 11:10, Donnie Berkholz wrote: > How about playing nicely with overlays where the moves didn't happen > (yet)? I'm not a developer, but based on my experience, playing nicely with overlays in general is a can of worms, and as far as I can tell has to do with the fact that overlays have always needed to react to changes in portage tree. (For example, if an overlay has pkg-0.1-r1 that fixes a bug, and in portage tree 0.2 is available but still has the bug, then the overlay needs to have a 0.2-r1.) I'm not sure you have to worry about overlays. The developers of the overlays will worry about them. Now, for the educated: is this fair or accurate? -- Jacob "For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened." Are you ready?
[gentoo-dev] Re: On hosting self-produced distfiles
Il giorno gio, 20/01/2011 alle 07.23 +0100, "Paweł Hajdan, Jr." ha scritto: > > Storing distfiles in public_html is not a perfect solution either. If > the developer retires, what do we do with the files? That's why (and I answer to Peter here as well), it is an ad interim solution. As I said and repeated Robin is working on the final one but until then we still prefer this method. Besides, developers' home is usually archived already on retirement so we can recover the files from there without having to beg users to send them to us, as Ulrich testified. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: On hosting self-produced distfiles
Hi, Ulrich Mueller : > missing, we sent a plea for help to -dev (or was it planet?) and had http://www.faulhammer.org/archiv-mainmenu-31/35-gentoo/293-we-are-looking-for-distfiles V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Rail Model font for coders
2011-01-20
Thread
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_hare
There is a font for coders called Rail Model, please include it with Linux distributions: http://code.google.com/p/railmodel/downloads/detail?name=RailModelFont.zip&can=2&q= Copyright: Copyright (c) 2010, Copyright (c) Holder for the commissioned (Unicode 0915) devanagri glyph design as the new 11th english and european glyph and the cancellation of the previous k / K is (His Divine Grace) Prabhupada, Founder Acharya & Permanent Sole Initiator of the Panca Tattva / Caitanya Mahaprabhu / Vaisnava Movement, the permanent person not the estate, state, representative/s or representative organisation/s etc. All Rights Reserved. (full and also other copyright information at accompanying font files) Description: November 20 2010 (Hrant H Papazian) Version 1.1 Ð k/K (Unicode glyphs /006B and /004B) exchanged through Unicode glyph / uni0915 Ð released as N: Hrant H Papazian E: hpapazian. W: http://www.themicrofoundry.com D: Designer Ð Unicode glyph /uni0915 upper and lower case Best, Meeku
Re: [gentoo-dev] Last rites: net-analyzer/ipcad
В Срд, 19/01/2011 в 11:58 -0500, Dane Smith пишет: > # Packages below fail to build with > # >=sys-kernel/linux-headers-2.6.35 and block its > # stabilization. Bugs untouched in over 3 months. > # Masking for removal on 21 Mar 2011. > # net-analyzer/ipcad (bug 335592) This one is fixed and will stay in the tree. Thanks. -- Peter.
Re: [gentoo-dev] On hosting self-produced distfiles
В Чтв, 20/01/2011 в 03:50 +0100, Diego Elio Pettenò пишет: > Do you really think I should have "discussed" with "a team" about this? > More than asking Robin as part of infra if it's okay (with his answer > being "yeah, that's fine | i do it too", literally)? This was already mentioned in this thread, but still. AFAIR (betelgeuse knows better) average developer's age is less then three years and thus, many files hosted in home directory became unavailable after developer retires. Thus the solution you propose does not address the problem we have and it's not a nice to enforce it in the policy (without some additional policy to keep developer's home directory on server for three years and anyway this needs discussion with infra first). -- Peter.
