Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Pappy's Kernel Seeds Part V
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 10, 11, 12, 13, 14  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2159
Location: The Peanut Gallery

PostPosted: Fri Jul 19, 2013 12:23 pm    Post subject: Reply with quote

NeddySeagoon wrote:
pappy can proxy maintain ...
Being a dev is not required.
..
The pappy_seeds overlay ...

No he doesn't need to be, but he should be in my opinion. Gentoo should be nurturing people like him and using their talent, as well as acknowledging it.
TomWij wrote:
Something like:

  • sys-kernel/pappy-seeds-gentoo-3.10.1 to install /usr/share/pappy-seeds/gentoo-3.10.1.config
  • sys-kernel/pappy-seeds-hardened-3.10.1 to install /usr/share/pappy-seeds/hardened-3.10.1.config
  • sys-kernel/pappy-1 to install the tool; this determines the kernel in /usr/src/linux, and writes (or asks to overwrite) the config to it. Parameters could allow customization of which kernel folder, the detection and which config to place there.

Great idea. Exactly like that.

I'd personally use it on my own machines, if it were available in-tree. (I don't use the seeds atm: I've always done my own config on every install.)

Is the above feasible without too much hassle, pappy? We can all help with scripting and makefiles, fwtw.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Fri Jul 19, 2013 1:18 pm    Post subject: Reply with quote

steveL wrote:
Is the above feasible without too much hassle, pappy? We can all help with scripting and makefiles, fwtw.


Yes, the ebuilds to do these are simpler than the average ebuild in the tree, they just need to pull the .config and install it in the right place; unless pappy had something else in mind, but I'd see that as more complicated than needs to be. As for the bumps, that can be scripted or put in a cron job; apart from monitoring the URLs and/or this thread.
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Fri Jul 19, 2013 7:23 pm    Post subject: Reply with quote

I have been thinking about the issue, but it's so new, I'm still processing. I am going to do a little research into licensing, and go from there. I am very much interested in the idea of adding my seeds to Gentoo as a normal feature.

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Sat Jul 20, 2013 7:25 am    Post subject: Reply with quote

For my own piece of mind, I wrote a letter to the GPL people at GNU to see what they had to say. Once I get word back, I'll do what it takes to get the licensing terms up on the site. I figure if anyone knows the particulars, they do.

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Mon Jul 22, 2013 6:54 am    Post subject: Reply with quote

I've just uploaded .configs for 2.6.32-hardened-r178, 3.0.87, 3.2.48-hardened-r4, 3.4.54, 3.9.11, 3.9.11-gentoo, 3.10.1-hardened-r1, and 3.10.2 in both x86 and x86_64 flavors. Enjoy!

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2159
Location: The Peanut Gallery

PostPosted: Mon Jul 22, 2013 7:28 pm    Post subject: Reply with quote

TomWij wrote:
the ebuilds to do these are simpler than the average ebuild in the tree, they just need to pull the .config and install it in the right place; unless pappy had something else in mind, but I'd see that as more complicated than needs to be.

Agreed.
Quote:
As for the bumps, that can be scripted or put in a cron job; apart from monitoring the URLs and/or this thread.

Shouldn't be any need to monitor in the longer-term, if pappy's committing: as you said, the ebuilds are basically a single-file download.

The tool might be more of a collaborative effort, but it's hardly rocket-science. I'd expect it to stay basically the same after initial development (which is always more reliable for users.)
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Tue Jul 23, 2013 7:20 am    Post subject: Reply with quote

Here's how I see it working...

Have a USE flag like -seed, or -pks (Pappy's Kernel Seeds). If selected, the ebuild will pull the .config file from either the main site, or the mirrors. That would place the seed as I title them, ie, 3.2.4-gentoo-x86-08.config into the root directory of the just installed kernel source. If that particular seed doesn't exist, then the script would pull the base of the family, in this case, 3.2.0-gentoo-x86-08.config. The user would rename the file, and do the configuration from there. Since all the configuration scripts run silent oldconfig, that would update the seed to the proper source automatically, with input needed only for any new items in the .config. That doesn't happen too often.

That seems to me to be the most logical way to approach this issue. I'm still waiting for word from GNU. Once I get that, I'll definitely be in a mind to go to that next level.

Anyone else want to offer input on the idea, how to make it work, whether my idea is decent, or whether there needs to be some tweaking? Don't be shy. This is the first time I've had someone even suggest putting my idea into portage. I don't quite know how to proceed, so I'm doing what seems like the next right (and hopefully logical) thing.

Also, to whoever had the idea, thanks. I am truly honored.

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2159
Location: The Peanut Gallery

PostPosted: Tue Jul 23, 2013 3:21 pm    Post subject: Reply with quote

pappy_mcfae wrote:
Have a USE flag like -seed, or -pks (Pappy's Kernel Seeds). If selected, the ebuild will pull the .config file from either the main site, or the mirrors. That would place the seed as I title them, ie, 3.2.4-gentoo-x86-08.config into the root directory of the just installed kernel source. If that particular seed doesn't exist, then the script would pull the base of the family, in this case, 3.2.0-gentoo-x86-08.config. The user would rename the file, and do the configuration from there. Since all the configuration scripts run silent oldconfig, that would update the seed to the proper source automatically, with input needed only for any new items in the .config. That doesn't happen too often.

Anyone else want to offer input on the idea, how to make it work, whether my idea is decent, or whether there needs to be some tweaking? Don't be shy. This is the first time I've had someone even suggest putting my idea into portage. I don't quite know how to proceed, so I'm doing what seems like the next right (and hopefully logical) thing.

At first reading, I liked the USE-flag idea. To the extent that I don't think it needs a USE-flag at all, given that the config is saved to a specific file, and it's part of the ebuild.

However you then get into the issue of changes. For instance, you said "the script would pull the base of the family", but what happens to a user who has downloaded the kernel-sources before you've put the config up? A few days later your config will be out, and they won't have it, whereas with a separate ebuild they'll see it in the emerge list.

Similarly, what happens when you update the config for a specific version? There's no way for the user to know that, and review the changes, to decide whether they want to rebuild their kernel.

Seems like we still have some bouncing around to do on this, if only so we're all happy. ;) We don't want emerge to think the kernel-sources ebuild needs reinstalling because the config file has changed.

What do you think, TomWij? Does the ebuild approach address both issues cleanly? Seems so to me, though I'm not sure whether a USE-conditional dep from kernel-sources would work, to pull in an updated config ebuild without itself reinstalling, or would make things messy.
Quote:
I'm still waiting for word from GNU. Once I get that, I'll definitely be in a mind to go to that next level.

What exactly are you expecting to hear from GNU? Personally I'd just do GPLv2+, since the kernel is v2.

I'd usually use AGPLv3+ since I think corporates won't distribute modifications, unless they have an obligation to, in general (it's cheaper not to deal with it.) But it's not so relevant here: this isn't a code-base, and there's not much they can add to the knowledge-pool. You already know the kernel configs inside out, for one. The only thing I can think of is the correct tweaks for specific hardware, and if they want it used more widely they have an interest in upstreaming them.
Quote:
I am truly honored.

You honour us with your effort, and the fruits of that labour.
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Tue Jul 23, 2013 4:38 pm    Post subject: Reply with quote

I'm cautious in some matters, like this. While I don't think there will be any baleful results if I go ahead and run with it, I'd rather have GNU's blessing in this matter. The last thing I want is to wind up on the bad side of their graces. I've upset enough people at linuxquestions. I would rather not do that with GNU, if it can be avoided.

As to the idea that the seeds are a separate entity requiring ebuilds of their own, it seems a bit more straightforward than my method. I'm not quite sure how to make it work, but then again, there are folks around here who do.

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Tue Jul 23, 2013 5:37 pm    Post subject: Reply with quote

steveL wrote:
However you then get into the issue of changes. For instance, you said "the script would pull the base of the family", but what happens to a user who has downloaded the kernel-sources before you've put the config up? A few days later your config will be out, and they won't have it, whereas with a separate ebuild they'll see it in the emerge list.


Ebuilds cannot pull one thing or the other, they need to pull something in specific; please note that everything is checksummed and that ebuilds should not change installed content without a revision bump. It is impossible for the same version to install different stuff; you can't have the same version checksum or fetch something that will release in the future. So, I think we need to release the actual version when it releases; as for generating from the base, that could perhaps be housed in a separate script, but not in an ebuild.

As for the kernel sources, you can't inspect the system (same reason as above, what is installed needs to remain the same); so, you would need to depend on the kernel sources. But that in itself is a problem as well, since the user is not guaranteed to run gentoo-sources but could run something else like hardened-sources; so, you would need to depend on a virtual in this case, but the virtual doesn't list the version. I'm not sure whether listing all possible sources as dependencies in the ebuild is an acceptable way to go.

steveL wrote:
Similarly, what happens when you update the config for a specific version? There's no way for the user to know that, and review the changes, to decide whether they want to rebuild their kernel.


This is the same way as with the kernel sources itself; the user spots the relevant pappy config package being updated, which can then use one or another tool to check for changes.

steveL wrote:
Seems like we still have some bouncing around to do on this, if only so we're all happy. ;) We don't want emerge to think the kernel-sources ebuild needs reinstalling because the config file has changed. What do you think, TomWij? Does the ebuild approach address both issues cleanly? Seems so to me, though I'm not sure whether a USE-conditional dep from kernel-sources would work, to pull in an updated config ebuild without itself reinstalling, or would make things messy.


Not sure what you mean here, did he mean to update the eclass to introduce a pappy flag to all kernel source packages? Since the pappy configs are distributed loosely from the kernels; this would mean that for a certain new releases the config might be missing, which brings us back to the above problem where the installed config changes and checksum problems. I don't see that work well; even if it did, such changes are peer reviewed on the mailing list amongst multiple developers on the ML. Consider that anyone who opposes to this idea _will_ comment on the matter; so, unless this is well thought-out I don't think this is the way to go. I think a low profile approach with separate pappy config packages is therefore more acceptable.

steveL wrote:
Quote:
I'm still waiting for word from GNU. Once I get that, I'll definitely be in a mind to go to that next level.

What exactly are you expecting to hear from GNU? Personally I'd just do GPLv2+, since the kernel is v2.

I'd usually use AGPLv3+ since I think corporates won't distribute modifications, unless they have an obligation to, in general (it's cheaper not to deal with it.) But it's not so relevant here: this isn't a code-base, and there's not much they can add to the knowledge-pool. You already know the kernel configs inside out, for one. The only thing I can think of is the correct tweaks for specific hardware, and if they want it used more widely they have an interest in upstreaming them.


Everything needed to know is in the license itself; so, I'm not sure whether contacting them will gain anything, I have no idea if they would provide advice on the matter. That usually is a task for a lawyer, whom is the only person who can really give you untampered advice; as the lawyer would have nothing to do with the license themselves. Though that is an overkill for this case; usually, matters of this size have a license picked after reading up on summaries of the common licenses and the differences between them...

pappy_mcfae wrote:
As to the idea that the seeds are a separate entity requiring ebuilds of their own, it seems a bit more straightforward than my method. I'm not quite sure how to make it work, but then again, there are folks around here who do.


What did you think of the approach I listed before with the different packages? I'll be happy to work this out with you / for you and push it to the Portage tree for you, I won't be able to do this until early August due to a devaway; so there's no hurry on the GPL matter and further thinking this out. If you want things to happen sooner, you'll need to take this through proxy-maint; you can file bugs on Bugzilla with them or mail them.

http://devmanual.gentoo.org/ https://www.gentoo.org/proj/en/qa/proxy-maintainers/ https://www.gentoo.org/proj/en/kernel/
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2159
Location: The Peanut Gallery

PostPosted: Tue Jul 23, 2013 11:01 pm    Post subject: Reply with quote

TomWij, you appear to have spent most of the post, in the part replying to me, responding to things that were directed at pappy, as if they were statements of how things should be done.

In this case, it was actually a discussion of why ebuilds can't and shouldn't just pull the "latest" config, but must indeed be tied to a specific file.

I'll try and filter out the signal later, when I have more headspace.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Tue Jul 23, 2013 11:20 pm    Post subject: Reply with quote

Couldn't wrap my head around Pappy's comment, merely because I was busy at that moment and I wasn't sure about some details when I quickly read that (eg. what the USE flag would be applied to, a package we introduce or an existing package; as well as what is meant with the base config, which I think I understood after reading your comment); so, I didn't end up replying to his comment.

Your post is not seen "as if they were statements of how things should be done.". Just jumping in now to note what's possible and what not, what takes more effort and what takes less effort and pointing out some restrictions the Portage tree and its rules impose; that way, we can avoid discussion of things that aren't possible in the current system. Also note that a decision is very often not definitive, and that if one approach shows to not work out at all; we can always switch to another approach later. So, we could lay the focus on something that benefits users in the short end and produce a long term solution later that is based on dealing with the drawbacks of the short end solution.
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Wed Jul 24, 2013 4:39 am    Post subject: Reply with quote

As long as there is no rush, I'm going to hang loose until you're a bit freer. It's okay, as I'm starting a new job, and things will probably be weird for a little bit of time.

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2159
Location: The Peanut Gallery

PostPosted: Wed Jul 24, 2013 4:08 pm    Post subject: Reply with quote

[tried to post this yesterday, but forum went down]
TomWij wrote:
Couldn't wrap my head around Pappy's comment, merely because I was busy at that moment and I wasn't sure about some details when I quickly read that (eg. what the USE flag would be applied to, a package we introduce or an existing package; as well as what is meant with the base config, which I think I understood after reading your comment); so, I didn't end up replying to his comment.

Your post is not seen "as if they were statements of how things should be done.". Just jumping in now to note what's possible and what not, what takes more effort and what takes less effort and pointing out some restrictions the Portage tree and its rules impose; that way, we can avoid discussion of things that aren't possible in the current system.

OK. I'm sorry I reacted badly; bit snowed-under atm.
Quote:
Also note that a decision is very often not definitive, and that if one approach shows to not work out at all; we can always switch to another approach later.

Sure.
Quote:
So, we could lay the focus on something that benefits users in the short end and produce a long term solution later that is based on dealing with the drawbacks of the short end solution.

I don't think there's much point in that approach in this case: the seeds have been in use quite successfully for a few years, so there's no need to rush. We might as well just do it right and clean, from the start: it'll still have bugs at the beginning. ;-) As it is, I don't think there's much to do technically, once we've thrashed out the details of what exactly it is we want to do, and we're all happy with it (or at least, you and pappy are;)

From what I've read so far, we need an ebuild for each of pappy's releases, which is nothing more than a single file download. Depending on kernel-sources is up to you: I guess that's where we could take a short-term approach, now I think of it, and just not bother with the dependency, unless and until there's a solution that doesn't require listing N versions, and preferably doesn't need a new type of virtual. To me that's more of a decision than a short-term approach: I don't see the hassle as being worth it.

The alternative is to implement the tool you mentioned, and let it download the best choice, based on sources in cwd, or a command-line parameter, with confirmation from the user if there's no exact match available. Not hard, and might be useful to patch from.

And yeah, he meant a USE-flag in kernel-sources, which I didn't think was that great an idea, but don't know the ins and outs well-enough to dismiss => ENEEDINFO. What I was asking was: if foo-sources depended on pappy-config:SLOT would an upgrade in pappy-config necessitate an upgrade in foo-sources? I don't think it would, without some sort of operator; whether the approach is viable in the context of kernel config, is another matter.

As to the dependency not being available until Pappy's committed a new release, I don't see that as a big issue, personally. A user has to opt-in to the flag, and in that case, they'll know what the dep error means, and can either hold off the upgrade or merge it with USE=-seed, as they decide. For a stable user, it's unlikely that Pappy will not have put out the config, way before it gets to us. Should he tail off, then the flag could be removed.

But again, I don't know the ins and outs: I was just discussing how Pappy's idea might be done, and problems I saw with it, same as you. ;)
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Fri Jul 26, 2013 10:17 am    Post subject: Reply with quote

Another night in Pomona setting up seeds. I've just uploaded .configs for 3.2.48-hardened-r5, 3.10.2-hardened, 3.10.3, and 3.10.3-gentoo in both x86 and x86_64 flavors. Enjoy!

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Sun Jul 28, 2013 9:24 pm    Post subject: Reply with quote

I've just uploaded .configs for 3.2.48-hardened-r6, 3.2.49, 3.10.3-gentoo-r1, and 3.10.3-hardened in both x86 and x86_64 flavors. Enjoy!

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Tue Jul 30, 2013 6:56 am    Post subject: Reply with quote

My humble apologies. I uploaded .configs for 3.0.88, 3.4.55, and 3.10.4 in both x86 and x86_64 flavors last night, but I forgot to announce that fact here. It was a long day, yesterday. Enjoy nonetheless!

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Thu Aug 01, 2013 9:11 am    Post subject: Reply with quote

Only two sources tonight. I've just uploaded .configs for 3.2.49-hardened and 3.10.4-hardened in both x86 and x86_64 flavors. Enjoy!

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2159
Location: The Peanut Gallery

PostPosted: Thu Aug 01, 2013 8:10 pm    Post subject: Reply with quote

TomWij wrote:
So, I think we need to release the actual version when it releases;

Of course, where pappy is upstream, and pappy-config-X.Y.Z etc is the ebuild.
Quote:
as for generating from the base, that could perhaps be housed in a separate script, but not in an ebuild.

Sure.
Quote:
As for the kernel sources, you can't inspect the system (same reason as above, what is installed needs to remain the same); so, you would need to depend on the kernel sources.

This is the wrong way round really.
Quote:
But that in itself is a problem as well, since the user is not guaranteed to run gentoo-sources but could run something else like hardened-sources; so, you would need to depend on a virtual in this case, but the virtual doesn't list the version. I'm not sure whether listing all possible sources as dependencies in the ebuild is an acceptable way to go.

No, it's not.
Quote:
steveL wrote:
Similarly, what happens when you update the config for a specific version? There's no way for the user to know that, and review the changes, to decide whether they want to rebuild their kernel.

This is the same way as with the kernel sources itself; the user spots the relevant pappy config package being updated, which can then use one or another tool to check for changes.

This is what I meant by answering the wrong points: I was discussing why a script that pulls in the config, without a specific ebuild is not a good idea.
Quote:
steveL wrote:
We don't want emerge to think the kernel-sources ebuild needs reinstalling because the config file has changed. What do you think, TomWij? Does the ebuild approach address both issues cleanly? Seems so to me, though I'm not sure whether a USE-conditional dep from kernel-sources would work, to pull in an updated config ebuild without itself reinstalling, or would make things messy.

Not sure what you mean here, did he mean to update the eclass to introduce a pappy flag to all kernel source packages?

A seed USE-flag in overlay ebuilds initially, I think. The two issues I was discussing with Pappy were: a) that we need version-specific checksums and ebuilds; and b) that kernel-sources (whichever variant) should not require rebuilding just because the config has upgraded: only the config-package does, and it doesn't affect anything till the user decides it does.
Quote:
Since the pappy configs are distributed loosely from the kernels; this would mean that for a certain new releases the config might be missing, which brings us back to the above problem where the installed config changes and checksum problems. I don't see that work well; even if it did, such changes are peer reviewed on the mailing list amongst multiple developers on the ML. Consider that anyone who opposes to this idea _will_ comment on the matter; so, unless this is well thought-out I don't think this is the way to go. I think a low profile approach with separate pappy config packages is therefore more acceptable.

No one was ever seriously discussing not having a separate package. And personally the more I think on it, the more I'm leaning to a dependency on a slotted ebuild, since the kernel ebuilds themselves are already slotted. This would only happen in overlay initially, and if it were to be used more widely it would really be of most use, and benefit distro-wide, for stable users imo. That's the target, and if people want to play in unstable they can deal with it: it's hardly taxing, in the overall scheme of things.

That's a worse-case scenario, ofc: I seriously doubt that Pappy is going to be the hold-up when it comes to shipping the ebuilds, if you do have the USE-flag in-tree.

Of course, if you come up with something better and put it in the tree, you won't get any complaints from me. ;-)
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Tue Aug 06, 2013 11:54 am    Post subject: Reply with quote

For my two cents, the idea that my seeds will have their own ebuild is a rather cool thing. I can see how that might make my life a little bit more hectic. Oh well...what better way to learn discipline than to jump in with both feet, yes? You bet.

On another topic, I should have done this earlier, but I was in Hollywood with my friend, and that was a bit more important. Sorry, folks.

I've just uploaded .configs for 2.6.32-hardened-r179, 3.0.88-gentoo, 3.2.50, 3.2.50-hardened, 3.4.55-gentoo, 3.4.56, 3.10.4-hardened-r1, 3.10.4-hardened-r2. 3.10.5, and 3.10.5-gentoo in both x86 and x86_64 flavors. Enjoy!

TomWij,

I'd rather discuss the particulars with just you. Please message me at your leisure. I'm still adjusting to life with employment, so I'm not putting a lot of coals on this particular fire at this point in time. I would like to get something going, or at least ideas on ebuild hacking, graduate level. But there truly is no rush at this point. :) Maybe get something going by the five-year anniversary of the site...perhaps?!

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Tue Aug 06, 2013 5:44 pm    Post subject: Reply with quote

steveL wrote:
TomWij wrote:
As for the kernel sources, you can't inspect the system (same reason as above, what is installed needs to remain the same); so, you would need to depend on the kernel sources.

This is the wrong way round really.
Quote:
But that in itself is a problem as well, since the user is not guaranteed to run gentoo-sources but could run something else like hardened-sources; so, you would need to depend on a virtual in this case, but the virtual doesn't list the version. I'm not sure whether listing all possible sources as dependencies in the ebuild is an acceptable way to go.

No, it's not.


Hmm, not sure if we're on the same line here; I agree that this indeed is not a problem assuming the seeds are for specific kernel versions; eg. -gentoo matches gentoo-sources and -hardened matches hardened-sources. Then you match versions as well with simple slotted dependencies. But what if the user wants to use another kernel like aufs-sources or ck-sources together with a seed which does not exist for this specific kernel in the tree? The hardened sources was a bad example. I still see this as a problem; not a wide spread one, but I think some users might be annoyed by a non virtual dependency.

pappy_mcfae wrote:
I'd rather discuss the particulars with just you. Please message me at your leisure. I'm still adjusting to life with employment, so I'm not putting a lot of coals on this particular fire at this point in time. I would like to get something going, or at least ideas on ebuild hacking, graduate level. But there truly is no rush at this point. :) Maybe get something going by the five-year anniversary of the site...perhaps?!


If possible, I prefer to do this over mail; since I don't know yours feel free to send me a short mail at TomWij@g.o (expand the last part to the domain we're currently on; cheap spam protection, because they usually crawl the other ...[at]...[dot]... variants. :-D).
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Tue Aug 06, 2013 7:24 pm    Post subject: Reply with quote

On a related topic, I've decided I'm going to put a GNU GPL disclaimer on the site. They haven't written me back. I'm not sure if that's a good thing or a bad thing, but since the kernel is GNU, I figure a derived work would be very much covered. The only thing is I won't be adding the "copy freely, as long as you give credit to X" into the seed proper, as I don't want to flip out the scripts that make the various make <X>config (xconfig, gconfig, menuconfig) operations happen.

I may do that later on today, or when I can squeak some free time into my reality.

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
pappy_mcfae
Watchman
Watchman


Joined: 27 Dec 2007
Posts: 5894
Location: Pomona, California.

PostPosted: Wed Aug 07, 2013 5:51 am    Post subject: Reply with quote

A big thanks to the GPL people. They did get back to me.

I can cover the seeds with GPL by putting a blurb in some of the pages. I am also going to put an associated text file in each kernel seed directory. So, that is that.

TomWij, if you got my outside email, please respond. I've got a little GPL blurb worked up. I want to run it by your eyes before I put it out for general consumption. As long as it covers me and allows me to put my contribution into portage, I'm a happy panda. Thanks.

Cheers,
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.grytpype-thynne.org/
Mirror 2: http://kernel-seeds.gentoostudio.org/
Mirror 3: http://www.elilabs.com/~pappy/
Mirror 4: http://62.3.120.142/~seeds/
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2159
Location: The Peanut Gallery

PostPosted: Wed Aug 07, 2013 4:36 pm    Post subject: Reply with quote

TomWij wrote:
I agree that this indeed is not a problem assuming the seeds are for specific kernel versions; eg. -gentoo matches gentoo-sources and -hardened matches hardened-sources. Then you match versions as well with simple slotted dependencies. But what if the user wants to use another kernel like aufs-sources or ck-sources together with a seed which does not exist for this specific kernel in the tree?

You're not seriously suggesting Gentoo release ebuilds-in-tree that will pull an unverified config for a different set of sources are you? The only way that could work is to pull the base set, eg gentoo, hardened or vanilla. But it would still be a QA joke afaic.
Far better would be for someone who wants to use it, to collaborate with Pappy to make it happen with a verified config.
Quote:
The hardened sources was a bad example. I still see this as a problem; not a wide spread one, but I think some users might be annoyed by a non virtual dependency.

I don't see why. If they want a config for an unsupported kernel, they can do exactly what they'd do now, only they'd have the option of making their life a lot easier by submitting patches to Pappy and testing new variants before they hit the tree (or while they're still hard-masked.) The same motivation for anyone getting involved with volunteer development, really: to make their life as a user easier.

Or at least, that's the one that lasts ;)

Also, this way they get slotted dependencies, so new configs get pulled in for their perusal: should there be a new config for the kernel you're running, you'd most likely want to check the diff out.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Wed Aug 07, 2013 5:06 pm    Post subject: Reply with quote

pappy_mcfae wrote:
TomWij, if you got my outside email, please respond.


Received, I'm still processing mails, I'll get back to you once that is done; I'll probably write up an example you could look into or so.

steveL wrote:
TomWij wrote:
I agree that this indeed is not a problem assuming the seeds are for specific kernel versions; eg. -gentoo matches gentoo-sources and -hardened matches hardened-sources. Then you match versions as well with simple slotted dependencies. But what if the user wants to use another kernel like aufs-sources or ck-sources together with a seed which does not exist for this specific kernel in the tree?

You're not seriously suggesting Gentoo release ebuilds-in-tree that will pull an unverified config for a different set of sources are you? The only way that could work is to pull the base set, eg gentoo, hardened or vanilla. But it would still be a QA joke afaic.


Indeed not, I did not state any such thing; what I state is that the user could use the config that way, I did not mean to introduce a separate unverified package.

steveL wrote:
Far better would be for someone who wants to use it, to collaborate with Pappy to make it happen with a verified config.


Agreed, people that will see it as a good idea might jump the bandwagon and contribute; let's hope that happens.

steveL wrote:
Also, this way they get slotted dependencies, so new configs get pulled in for their perusal: should there be a new config for the kernel you're running, you'd most likely want to check the diff out.


I'm in doubt if were thinking about the same slotted dependencies here; I though you meant the configs depending on the slotted kernel, but do you mean the kernels depending on slotted configs?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3 ... 10, 11, 12, 13, 14  Next
Page 11 of 14

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum