1 |
Steven J. Long posted on Tue, 16 Jul 2013 02:01:40 +0100 as excerpted: |
2 |
|
3 |
> Duncan wrote: |
4 |
>> Steven J. Long posted |
5 |
>> > Duncan wrote: |
6 |
>> >> Then I created a framework that works much like epatch_user, except |
7 |
>> >> instead of automatically applying patches to upstream sources, it |
8 |
>> >> automatically applies patches to gentoo ebuilds and instead of using |
9 |
>> >> the /etc/portage/patches/ tree, it uses |
10 |
>> >> /etc/portage/patches.ebuild/. |
11 |
>> > |
12 |
>> > Hmm that's quite interesting. Not something I'd personally want in |
13 |
>> > the tree, but definitely of interest to more advanced admins, as |
14 |
>> > opposed to end-users. |
15 |
>> |
16 |
>> Of course, as I guess you'll recall (you've been around long enough I |
17 |
>> think) that's what was originally said about epatch_user as well... |
18 |
> |
19 |
> Perhaps, but there's a qualitative difference, in distro terms, between |
20 |
> patching the upstream source, and changing what the distro recommends. |
21 |
> Sure, both leave you to pick up the pieces (as if anything else ever |
22 |
> happens;) |
23 |
> but patching the ebuilds is the same as using an ebuild from overlay: |
24 |
> get your support from whoever provided it, not the distro. |
25 |
|
26 |
Of course public overlays were supposed to be the doom of gentoo too. |
27 |
Maybe they were and we're all oblivious... |
28 |
|
29 |
Meanwhile, it's my "weekend" now (three day but with a meeting tomorrow), |
30 |
so I've a couple days to spend on this and other personal projects. My |
31 |
goal is to be posting in the forum by the end of it, preferably with the |
32 |
first code posted. We'll see. |
33 |
|
34 |
Something that's been bothering me a bit. So far, this "framework" is |
35 |
pretty much just a function in my sync script that applies my patches |
36 |
after a pull. It's pretty simple, not even that much code or time, |
37 |
actually. So it'll need adapted for a wider audience, but I /do/ hope to |
38 |
get at least the initial function posted to the forum before this |
39 |
"weekend" is over. |
40 |
|
41 |
> However we should still make it so that an upgrade doesn't actually |
42 |
> change existing patches. That pushes us in the direction of the patch, |
43 |
> review and later use of an ebuild, rather than a live patch during an |
44 |
> emerge itself, which fits with the separate overlay model. |
45 |
|
46 |
Don't worry, the patches themselves are still manually created by / |
47 |
someone/, they're simply applied immediately after the sync (before a |
48 |
cache regen since they affect deps), and if they no longer apply for |
49 |
whatever reason, it's not fatal, so the result will simply be that ebuild |
50 |
returns to upstream gentoo/kde default and wants to pull in the semantic- |
51 |
desktop junk again, until someone comes up with an updated patch. |
52 |
|
53 |
And I've had the first round of patch updates now. So I know the fail |
54 |
mode and what's involved in updating the patches, now. I was still |
55 |
running on original patches until then, so failure mode was just theory, |
56 |
until now. Always good to have it tested. =:^) |
57 |
|
58 |
(I've a couple tweaks to make the next couple days too, before posting |
59 |
it, based on that testing.) |
60 |
|
61 |
> I just mean the overall design is one of patching as one process, |
62 |
> and use as a later, independent phase that does not have any awareness |
63 |
> of the fact that the ebuild has been patched (apart from the metadata |
64 |
> tag for QA.) |
65 |
|
66 |
You'll be happy to know that's the way it works. =:^) I hadn't even |
67 |
consciously considered the other way until you mentioned it, I think |
68 |
because I too was so horrified by the possibility, that I rejected it out |
69 |
of hand and considered the separate phases the only realistic approach |
70 |
from the get-go. |
71 |
|
72 |
> It's never going to need to get a different set of sources according to |
73 |
> whether it's been patched or not, for example; the kind of thing we'd |
74 |
> check version for in a live ebuild that can be used for fixed sources. |
75 |
> By definition it's always patched. |
76 |
|
77 |
> That makes the ebuilds produced candidates for use elsewhere, should |
78 |
> they be wanted. Not for our stuff ofc, but for other users like |
79 |
> overlays, where submission of patched ebuilds to Gentoo might be a |
80 |
> future possibility. |
81 |
|
82 |
Very good point. Agreed. |
83 |
|
84 |
> So if forum-users reply, it's because they're interested in the topic, |
85 |
|
86 |
My ideal would be newsgroups, which is what lists end up being, thru |
87 |
gmane, for me. But I guess the newsgroups-for-the-common-man ship sailed |
88 |
a long time ago... Thanks for your insights on web forum dynamics. They |
89 |
make sense and should be useful. =:^) |
90 |
|
91 |
>>> I can get the overlays, git and trac setup |
92 |
>> |
93 |
>> That would be useful. |
94 |
> |
95 |
> Okey-dokey: I'll mail you off-list in the next day or two |
96 |
|
97 |
Cool. =:^) |
98 |
|
99 |
> I always regretted that I couldn't persuade you to use update[1] ;) |
100 |
|
101 |
The timing was wrong. By the time I heard of it, I already had my own |
102 |
system setup. Which I'd always thought about packaging and making |
103 |
publicly available, but never got the properly rounded tuit. =:^\ |
104 |
|
105 |
But my system parallels emerge much more closely, being in effect little |
106 |
more than a bunch of emerge aliases, most of them starting ea (emerge -- |
107 |
ask) or ep (--pretend), with various other letter combinations added that |
108 |
parallel the similar emerge options (eaw= emerge --ask @world... with |
109 |
--update --deep --newuse --oneshot implied, etc). |
110 |
|
111 |
The parallels make it very easy to transfer emerge option knowledge to my |
112 |
system, and the reverse as well. |
113 |
|
114 |
slashdot style mandatory car analogy: Update is like power steering for |
115 |
emerge; emerge by itself is manual steering; my system's manual steering |
116 |
but with a custom steering ratio and wheel and with one of those tilt- |
117 |
wheel things that lets you set the angle of the steering wheel. =:^) |
118 |
|
119 |
In contrast, my "esyn" (no c) already had a bunch of pre/post/parallel-to- |
120 |
sync functions doing everything from mounting the appropriate partition |
121 |
if necessary, to layman-syncing along with emerge sync, to regenerating |
122 |
caches and auto-fetching sources for the emerge @world to follow. So |
123 |
throwing in another function to auto-ebuild-patch was no big deal. |
124 |
|
125 |
Which means it's probably a good thing I didn't end up running update, or |
126 |
I'd have likely never had the inspiration that lead to this thread in the |
127 |
first place. =:^| |
128 |
|
129 |
> for some perverse reason I wanted [bash] to fall over on me with such a |
130 |
> large script. |
131 |
|
132 |
LOL. I understand the feeling. =:^P |
133 |
|
134 |
> All in all, I'd say people who think bash is slow are using it wrong. |
135 |
|
136 |
> Shell-scripts are slow, because people call externals when they don't |
137 |
> know better, typically on a crap OS that can't handle fork very easily, |
138 |
> whereas it's trival on Unix. |
139 |
|
140 |
I think a large part of it is that people forget just how slow the |
141 |
machines were that shell had to still be practical on back in the day. |
142 |
As a consequence, it's pretty impressive on today's machines, even if |
143 |
it's not as efficient as tuned native code. |
144 |
|
145 |
> Unfortunately since it was designed for use by any user, that means any |
146 |
> idiot can knock something together and think they know it well, though |
147 |
> their script would earn them a day of lessons (or a roasting if they |
148 |
> think they're it) in #bash. |
149 |
|
150 |
And I imagine I'm in for a reasonable set of lessons myself. But even if |
151 |
I'm looking forward to it with a bit of trepidation, it's a good thing |
152 |
none-the-less. =:^) |
153 |
|
154 |
OTOH, I think my /base/ is reasonably solid, because after all, I learned |
155 |
"hands-on", originally by rewriting Mandrake's initscripts, back in the |
156 |
day (2002-ish in this case). And those scripts had naturally had years |
157 |
of hacking and tuning for the real world, which I think is why I took off |
158 |
so fast with shell, because I was hacking real-world bootscripts with a |
159 |
real-world purpose and real-world consequences if I screwed up, not some |
160 |
artificially weak script designed to use only what was presented in that |
161 |
lesson, with little real-world use. |
162 |
|
163 |
But what I'm missing and should get with this project, is real-world |
164 |
experience in the translation back from "it works for me" to "it's broad- |
165 |
based enough to work, with a bit of reasonable configuration, for pretty |
166 |
much everyone who'd have a reason to run it." (Tho I've had a bit of |
167 |
that elsewhere, but nothing like this project's likely to be.) |
168 |
|
169 |
>> > How to opt out of a semantic-desktop? |
170 |
>> > http://forums.gentoo.org/viewtopic-t-963504.html |
171 |
|
172 |
Keepin' that link in for reference... |
173 |
|
174 |
> Continue with the topic. If it needs to be moved the moderators will do |
175 |
> it, when they feel the time is right. |
176 |
|
177 |
> Let's just start with that thread, and make the tools work for our |
178 |
> use-case, while keeping them in a git repo others can use and |
179 |
> collaborate around. We have a reasonably simple aim for the tools, and |
180 |
> we're both committed to making them useful for more than the one |
181 |
> project, so I'm reasonably happy we're not going to make them |
182 |
> unportable, or completely specific to kde. |
183 |
|
184 |
Makes sense. |
185 |
|
186 |
> The pro-audio overlay list is quite interesting for the same reason, |
187 |
> though the discussion is a lot sparser nowadays, and it's mostly just |
188 |
> the bot. I like to think that's because most of the problems are |
189 |
> well-understood, and people are just concentrating on the ebuilds. I |
190 |
> have a vague feeling that probably means we're due for a big round of |
191 |
> "innovation" to make things more 'interesting' |
192 |
> or 'time-wasting' depending on your view. ;) |
193 |
|
194 |
LOL. It's OT but we could probably compare stories, that against the pan |
195 |
lists that I've been on for a decade now. |
196 |
|
197 |
> But still I'm glad you raised it, since it means I can keep an eye on it |
198 |
> too, and email you if I think you're burning out (or posting too much |
199 |
> and not fixing stuff instead;) |
200 |
|
201 |
Thanks. We'll see how this "weekend" goes... |
202 |
|
203 |
>> kde4 itself is planned to continue getting further updates until say |
204 |
>> mid-year 2014 (or later if they get behind on kde5/frameworks), which |
205 |
>> means it'll probably remain available in gentoo until end of 2014 or |
206 |
>> so, at least. |
207 |
> |
208 |
> Good to know, thanks. |
209 |
|
210 |
By-the-by, they're also discussing possibly doing 3-month cycles now, |
211 |
since both kdelibs and plasma-workspaces are feature-frozen for kde4 with |
212 |
4.11. The argument is that there's less really potentially destructive |
213 |
change, while it would get fixes and any small feature updates out to |
214 |
users faster. The OpenSuSE maintainers appear to be the biggest |
215 |
opposition, as it'd screw up their established work cycle, but others are |
216 |
arguing that a packaging approach similar to that taken for the even |
217 |
faster cycling firefox and chrome/chromium should solve that. |
218 |
|
219 |
The story has been covered in several of the Linux/FLOSS newsfeeds I |
220 |
follow. |
221 |
|
222 |
> Secondly, I have a lot more faith in Gentoo users when |
223 |
> it comes to scratching the itch to make stuff work. They've basically |
224 |
> "self-selected" again when it comes to that. And they have a very wide |
225 |
> range of computing experience. AFAIC they're basically _the_ elite |
226 |
> userbase. |
227 |
|
228 |
Good point. I guess the whole kde-sunset as well as sunrise overlays |
229 |
demonstrated that well enough. Thanks for the reminder. =:^) |
230 |
|
231 |
>> Short term, is it worth it to post the 4.10.80+ patches as I have them |
232 |
>> either here or to the forum thread linked above, or is it better to |
233 |
>> wait until we have an overlay to put them in and/or until 4.11.0 is |
234 |
>> available? |
235 |
> |
236 |
> Do please post them to the forum thread, in a [code]block[/code] if the |
237 |
> diff is reasonably small; you can Preview any post to check how it'll |
238 |
> look, or Edit it (top-right of the post) after you've submitted it. If |
239 |
> you do that before anyone replies, it doesn't show up as an edit (Last |
240 |
> edited..; edited X times in total.) |
241 |
> But in general preview everything with tags in it. |
242 |
> |
243 |
> Or at a reasonably light pastebin with a [url=http://..]link text[/url] |
244 |
> I use http://sprunge.us/ generally, but IDK if that's at all permanent. |
245 |
> I doubt it ;) http://paste.debian.net/ is used by quite a few people, |
246 |
> and checking it I see it allows "permanent" posts. |
247 |
|
248 |
Thanks. Hopefully in the next couple days... |
249 |
|
250 |
> (Forgive me Gentoo for I have sinned: it's been 3 months since my last |
251 |
> completed emerge world..;) and see what's happening in the latest stable |
252 |
> versions. |
253 |
|
254 |
FWIW, I generally update about twice a week on my main machine. I have |
255 |
something, somewhere, configured to warn me if I go more than a week |
256 |
between syncs, but AFAIK I've only actually seen that warning once, and |
257 |
can't even remember where it's configured. Three months... I'd have to |
258 |
be in the hospital or something for most of that time. |
259 |
|
260 |
But on the netbook (which I build for in a 32-bit build partition on my |
261 |
main machine), I think I went a year and a half between updates at one |
262 |
point... at which point the update gets rather "interesting", but can be |
263 |
done by a suitably well experienced gentooer, especially if they've been |
264 |
doing regular updates on another machine, thus having that memory to fall |
265 |
back on as to how they resolved various issues as they came up one at a |
266 |
time. |
267 |
|
268 |
> Thank god for FEATURES=binpkg[3] though: I can roll back if 4.10/11 |
269 |
> turns out to be a stinker. |
270 |
|
271 |
I've always thought FEATURES=binpkg was one of the best under-recommended |
272 |
features in portage... and wondered how paludis could fail to have the |
273 |
feature at all (tho for all I know it has it now). |
274 |
|
275 |
> There's some nice stuff in kate for 4.11 I want to try though. |
276 |
|
277 |
With 4.10 I began running the 4.x.49.9999 live-branch builds from the |
278 |
gentoo/kde overlay, and now that they're available (and patched) for 4.11 |
279 |
branch too, I'm running that. |
280 |
|
281 |
With ccache it's actually not too bad. I'm not running a full kde (127- |
282 |
ish live packages including a couple non-kde), and with my 6-core |
283 |
bulldozer, ssd-based main system and package trees, a tmpfs based |
284 |
PORTAGE_TMPDIR, and ccache, a full update twice a week typically takes me |
285 |
about an hour, including pre-scanning changelogs for anything interesting |
286 |
and doing the post-update etc-update, revdep-rebuild and emerge |
287 |
--depclean. (The live-package update on its own is under 20 minutes.) |
288 |
|
289 |
What I'm /really/ waiting for is wayland, tho. There's some options (USE |
290 |
flags, etc) showing up for it now in kde (kwin-4.11.49.9999 has a wayland |
291 |
USE flag, for instance), but I've not turned any of that stuff on nor |
292 |
emerged wayland at all yet. There's a fair chance I'll try it in the |
293 |
4.11 time frame, however, and I'm guessing at a final switchover attempt |
294 |
next spring or so. We'll see. But that transition will be easiest if |
295 |
I'm already familiar with the latest kde, so I've an additional incentive |
296 |
to stay very current for the next few months. |
297 |
|
298 |
-- |
299 |
Duncan - List replies preferred. No HTML msgs. |
300 |
"Every nonfree program has a lord, a master -- |
301 |
and if you use the program, he is your master." Richard Stallman |