1 |
Duncan wrote: |
2 |
> Steven J. Long posted |
3 |
> > Duncan wrote: |
4 |
> >> Then I created a framework that works much like epatch_user, except |
5 |
> >> instead of automatically applying patches to upstream sources, it |
6 |
> >> automatically applies patches to gentoo ebuilds and instead of using |
7 |
> >> the /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/. |
8 |
> > |
9 |
> > Hmm that's quite interesting. Not something I'd personally want in the |
10 |
> > tree, but definitely of interest to more advanced admins, as opposed to |
11 |
> > end-users. |
12 |
> |
13 |
> Of course, as I guess you'll recall (you've been around long enough I |
14 |
> think) that's what was originally said about epatch_user as well... |
15 |
|
16 |
Perhaps, but there's a qualitative difference, in distro terms, between |
17 |
patching the upstream source, and changing what the distro recommends. |
18 |
Sure, both leave you to pick up the pieces (as if anything else ever happens;) |
19 |
but patching the ebuilds is the same as using an ebuild from overlay: get |
20 |
your support from whoever provided it, not the distro. |
21 |
|
22 |
> Administrating a computer system is a serious job, and the more people |
23 |
> that consider it so, the less danger everyone, both those that treat the |
24 |
> job seriously and those who don't, are in. |
25 |
|
26 |
Like all things were "it would be better if only everyone did X" everyone |
27 |
does NOT do X by definition, or we wouldn't have anything to discuss. |
28 |
|
29 |
I don't personally feel the user should have to do anything to have a |
30 |
reasonably secure machine, and I'd counter that the real problem is that most |
31 |
people are using an inherently secure system (apparently by design if recent |
32 |
news is accurate.) IOW we have bigger problems than what Linux users do. |
33 |
|
34 |
But overall, we agree on approach: the user is in charge, and thus its their |
35 |
responsibility. Given that we're all human, and further that I don't really |
36 |
have the inclination to administer a large network and deal with end-users on |
37 |
a daily basis, I still won't call myself an admin ;-) and will continue to |
38 |
hero-worship the good ones, since I can't really get much done without them, |
39 |
if it's outside my front-door. |
40 |
|
41 |
> an appropriate level of verbosity saying an ebuild was modified in emerge |
42 |
> --info <pkg>, for posting with bugs) will be needed. |
43 |
|
44 |
Definitely. A terse line should be in every emerge --info, near the top. |
45 |
|
46 |
> > Hell yeah :-)[2] You picked an odd forum for it though: I only found out |
47 |
> > about this because Dominique posted to pro-audio list. |
48 |
> |
49 |
> I picked this list/forum for a couple (related) reasons, in addition to |
50 |
> convenience (I was already subscribed). |
51 |
> |
52 |
> 1) It's the coordinating list for kde-sunset, and this seemed a |
53 |
> reasonably similar project, so using the same list seemed appropriate. |
54 |
|
55 |
Ah wasn't aware of that. It seemed odd to me, since the gentoo-kde team |
56 |
clearly thinks the approach is a waste of time, so why expect a positive |
57 |
response on their ML. |
58 |
|
59 |
> >> A hybrid alternative would be to adopt an idea much like the existing |
60 |
> >> kde overlay, where there's a documentation or tools directory that |
61 |
> >> carries them, in addition to the kde-base category and etc, carrying |
62 |
> >> the patched ebuilds themselves. |
63 |
> > |
64 |
> > That sounds ideal, but why not just have two overlays? One for |
65 |
> > ebuild-patch which others can use and collaborate around, and one |
66 |
> > conventional kde-lean for people who want the end-product. |
67 |
> |
68 |
> kde-lean definitely beats kde-nosemantic, my working title. |
69 |
> |
70 |
> As for ebuild-patch, an overlay just for it? What about setting up a git |
71 |
> repo somewhere (github's popular, but not open source...) and putting the |
72 |
> ebuild for it, presumably using git2.eclass for a live-9999 version, in |
73 |
> the sunrise overlay? Once it gets mature enough to tag, if we don't want |
74 |
> to bother with a tarball, a versioned ebuild can still use the git |
75 |
> infrastructure, and simply checkout a specific tag. |
76 |
|
77 |
Yeah a repo for it works fine, for me. People can just use a live vcs ebuild |
78 |
to stay current; after all it's an experimental setup, so if you use it blindly |
79 |
you're an idiot. The user must be aware that they need to review the patches |
80 |
they apply to ebuilds on every bump, so being aware of the need to keep an eye |
81 |
on epatch-user itself isn't that much of a hardship. |
82 |
|
83 |
However we should still make it so that an upgrade doesn't actually change |
84 |
existing patches. That pushes us in the direction of the patch, review and later |
85 |
use of an ebuild, rather than a live patch during an emerge itself, which fits |
86 |
with the separate overlay model. |
87 |
|
88 |
(Yes, I'm aware you can't patch an ebuild during an emerge, because metadata has |
89 |
to be constant.) I just mean the overall design is one of patching as one process, |
90 |
and use as a later, independent phase that does not have any awareness of the |
91 |
fact that the ebuild has been patched (apart from the metadata tag for QA.) |
92 |
|
93 |
If that's required, I'd actually argue against it, even where it's similar to the |
94 |
check of version being 99999*, as conceptually it feels broken: the whole point |
95 |
is to patch the ebuild for a specific situation, and only to distribute as |
96 |
equivalent ebuilds in an overlay. If you've patched it right, there should be |
97 |
no need for anything like that. |
98 |
|
99 |
It's never going to need to get a different set of sources according to whether |
100 |
it's been patched or not, for example; the kind of thing we'd check version for |
101 |
in a live ebuild that can be used for fixed sources. By definition it's always |
102 |
patched. |
103 |
|
104 |
That makes the ebuilds produced candidates for use elsewhere, should they be |
105 |
wanted. Not for our stuff ofc, but for other users like overlays, where submission |
106 |
of patched ebuilds to Gentoo might be a future possibility. |
107 |
|
108 |
> > I'd ask that we collaborate on the forums[2] about this: things can move |
109 |
> > much quicker there, and you get general encouragement and lots of bug |
110 |
> > feedback, as well as others to help. |
111 |
> |
112 |
> I've actually seen lists/newsgroups move in very close to real-time -- as |
113 |
> close as I generally care to get (I don't do IRC as I like a bit more |
114 |
> time to compose my posts). |
115 |
|
116 |
Lists can move in near to realtime yes, but they seldom move usefully when they're |
117 |
moving that quickly, ime. Part of the problem is that all subscribers get a copy |
118 |
of the email delivered to them, whereas forum posters have chosen to read your |
119 |
post. Reading lists via gmane shields you from that, but it's important to remember |
120 |
that many others get your posts in their mailboxes. |
121 |
|
122 |
So if forum-users reply, it's because they're interested in the topic, and you |
123 |
never get people who are just posting because they're irritated at what to them is |
124 |
noise, since they're not actually interested in your new thing. If that were the |
125 |
case they wouldn't even have opened the thread, let alone got to the end. |
126 |
|
127 |
> But, web-forums do seem to be more popular, and I guess I could dust off |
128 |
> my old forum login or create a new one... |
129 |
|
130 |
Yay! :-) |
131 |
|
132 |
> > I can get the overlays, git and trac setup, same as we did for hardened |
133 |
> > a few years ago, if that helps. |
134 |
> |
135 |
> That would be useful. |
136 |
|
137 |
Okey-dokey: I'll mail you off-list in the next day or two, after I've got the git |
138 |
repo setup, as we'll need to also setup an ssh login for you, to commit. |
139 |
|
140 |
> Person to person, let me also say I'm absolutely thrilled to have you |
141 |
> helping. |
142 |
|
143 |
Thanks man :) Your words gave me a real boost. I'm delighted to be collaborating |
144 |
with you too: I always regretted that I couldn't persuade you to use update[1] ;) |
145 |
|
146 |
> Of course there's other than shell/bash, but that's the scripting I'm |
147 |
> most familiar with. I tried perl but that didn't go so well. I have on |
148 |
> my list to learn python some day, but it's been on my list for awhile, |
149 |
> and bash can do way more than a lot of people give it credit for, even if |
150 |
> it's not the most efficient choice for the job otherwise. |
151 |
|
152 |
Exactly. I was amazed at how far we could push bash, when I only had a 32-bit |
153 |
machine. In the end, I gave up worrying about it, though slightly regretfully: |
154 |
for some perverse reason I wanted it to fall over on me with such a large script. |
155 |
As for performance, it's pretty sh1t-hot imo: the plan was to rewrite large chunks |
156 |
in awk once we'd got the basics running, but it was never needed. |
157 |
|
158 |
All in all, I'd say people who think bash is slow are using it wrong. Sure it's not |
159 |
as fast as bb for basic sh. But if you want to write a moderately complex application |
160 |
you'll tear your hair out with sh, in places where bash has constructs designed by |
161 |
people who've been scripting for decades, to fix the exact *coding* limitation you've |
162 |
come up against. Granted a lot came from ksh, and bash takes ideas from other shells |
163 |
like zsh. Personally I like that ;) |
164 |
|
165 |
Shell-scripts are slow, because people call externals when they don't know better, |
166 |
typically on a crap OS that can't handle fork very easily, whereas it's trival on Unix. |
167 |
Then they walk away declaiming how the language is useless. Unfortunately since it was |
168 |
designed for use by any user, that means any idiot can knock something together and |
169 |
think they know it well, though their script would earn them a day of lessons (or a |
170 |
roasting if they think they're it) in #bash. |
171 |
|
172 |
> > [2] How to opt out of a semantic-desktop? |
173 |
> > http://forums.gentoo.org/viewtopic-t-963504.html |
174 |
> |
175 |
> I guess you're more of a forums user than I. If we do the forums, new |
176 |
> topic in desktop environment, or unsupported software, or ...? Or |
177 |
> continue with the topic above? |
178 |
|
179 |
Continue with the topic. If it needs to be moved the moderators will do it, when |
180 |
they feel the time is right. |
181 |
|
182 |
> And do we combine the kde and tools subjects in a single topic or one for |
183 |
> each? |
184 |
|
185 |
Let's just start with that thread, and make the tools work for our use-case, |
186 |
while keeping them in a git repo others can use and collaborate around. We have |
187 |
a reasonably simple aim for the tools, and we're both committed to making them |
188 |
useful for more than the one project, so I'm reasonably happy we're not going |
189 |
to make them unportable, or completely specific to kde. |
190 |
|
191 |
> How strong are your forum prefs and do you have any further thoughts/reasons |
192 |
> why switching to the forums would be better? |
193 |
|
194 |
Just what I said above, about the forum users self-selecting that they care |
195 |
about the thread, as opposed to spamming everyone's mailbox with it. Moderation is |
196 |
useful too, when done as well as the Gentoo Forums are moderated. Though I prefer |
197 |
IRC for people I actually have to collaborate with directly: it's more like email |
198 |
than people imagine, so effectively works as async/offline, but it can be as quick |
199 |
as real-life when needed. Plus it's all about your attitude and your knowledge, |
200 |
not about what badge you have attached to your address. (In fact, flaunting +o is |
201 |
actively discouraged.) |
202 |
|
203 |
I won't do development on a mailing list, personally. Discussion around proposals |
204 |
and ideas, to elicit feedback from the wider community before moving forward is |
205 |
a great idea, and personally I think that's why Gentoo has done well. AIUI |
206 |
when drobbins set it up he'd been burnt by the descent into clique that is a |
207 |
peril for any FLOSS project, and so the dev ML has always had that as an explicit |
208 |
purpose. Not that that stops it getting cliquey, it just means the current clique |
209 |
(and they're nebulous things;) can never take over and destroy the distro. At |
210 |
least, not without a clear record that users hated what was happening, before they |
211 |
all left. |
212 |
|
213 |
I quite like lists about patch submissions, though. When we used to get |
214 |
gentoo-commits follow-ups on-list, it was actually interesting, since people |
215 |
were talking about the code we actually want from them (ie ebuilds) and not |
216 |
their latest dream of an idiot-box, or why portage sucks and can we have your |
217 |
ebuilds. |
218 |
|
219 |
The pro-audio overlay list is quite interesting for the same reason, though the |
220 |
discussion is a lot sparser nowadays, and it's mostly just the bot. I like to |
221 |
think that's because most of the problems are well-understood, and people |
222 |
are just concentrating on the ebuilds. I have a vague feeling that probably |
223 |
means we're due for a big round of "innovation" to make things more 'interesting' |
224 |
or 'time-wasting' depending on your view. ;) |
225 |
|
226 |
> It's just that... I've been a regular on some lists and/or newsgroups for |
227 |
> a decade or more (I've been a regular on the pan lists since 2002, |
228 |
> according to gmane, and I've been on some newsgroup or another since I |
229 |
> discovered them back in 1997 or so, back on MS with the IE4 previews), |
230 |
> but despite the best of intentions, I've never been able to handle a |
231 |
> forum for more than a couple months before I burn out on it, so quite |
232 |
> apart from the personal preference thing, a real-life consideration is |
233 |
> that my own longevity as a project contributor before burnout may well be |
234 |
> conditional on what form the project communications take, list or forum, |
235 |
> with the latter very possibly leading to much faster burnout. |
236 |
|
237 |
I think you should just deal with the issue, which is that you burnout on |
238 |
forums, likely because you get too involved, and post at such length you |
239 |
don't have time left over for yourself. |
240 |
|
241 |
Don't do that. Learn to let go. Why does it matter if "someone on the internet |
242 |
is wrong"? ;) |
243 |
|
244 |
But still I'm glad you raised it, since it means I can keep an eye on it too, |
245 |
and email you if I think you're burning out (or posting too much and not fixing |
246 |
stuff instead;) |
247 |
|
248 |
I think though, that the reason you burnout on forums is actually because they |
249 |
move quicker than mailing lists, and people who are posting are usually as |
250 |
caught up in the topic as you are: without moderators you basically don't have |
251 |
any externals, unlike a ML, or IRC (where people are happy to tell you it's got |
252 |
boring, and no one takes offense. Well, no-one you can't /ignore. ;) |
253 |
|
254 |
> kde4 itself is planned to continue getting further updates until say mid-year |
255 |
> 2014 (or later if they get behind on kde5/frameworks), which means it'll |
256 |
> probably remain available in gentoo until end of 2014 or so, at least. |
257 |
|
258 |
Good to know, thanks. |
259 |
|
260 |
> However, with interest and help from others, it's quite possible my |
261 |
> initial patches and tool code can help jumpstart things, and the project |
262 |
> will be able to continue without me by then. |
263 |
> |
264 |
> What do you (and anyone else who cares to jump in) think? Is it |
265 |
> reasonable to expect the project to be sustainable without me once I |
266 |
> decide to move on to kde5/frameworks |
267 |
|
268 |
Yup. Or we're doing it wrong, which we'll find out within the first two months. |
269 |
|
270 |
> As I said, you're more experienced in the forums than I. There's |
271 |
> certainly some interest there. But is it likely enough to build |
272 |
> something that I can reasonably expect to be sustainable without me in a |
273 |
> reasonable time, or is it likely that I (and possibly you) will be doing |
274 |
> nearly everything myself/ourselves, and once I move on, the whole thing |
275 |
> will dry up and blow away? |
276 |
|
277 |
It's always a possibility. I don't think it's very likely for two reasons: |
278 |
Firstly, I'm a lazy sh1t when it comes to anything that's not code, and a lot |
279 |
of this won't be about coding, so it's very unlikely I'll be doing all the work ;) |
280 |
Secondly, I have a lot more faith in Gentoo users when it comes to scratching |
281 |
the itch to make stuff work. They've basically "self-selected" again when it comes |
282 |
to that. And they have a very wide range of computing experience. AFAIC they're |
283 |
basically _the_ elite userbase. |
284 |
|
285 |
IME you just have to give them the support and encouragement to try stuff, and wait |
286 |
to see who contributes the most. And what's good about it, is that even people who |
287 |
think they can't contribute, do so, just by encouraging you, or giving you feedback. |
288 |
There's been times when I would have given up on update, since it's just me now, |
289 |
only for someone to post out of the blue and thank me. I cannot tell you the boost |
290 |
that gives you, since it validates all the effort you've put in. |
291 |
|
292 |
Again, because it's a self-selected group even when it comes to reading the thread, |
293 |
the only people involved care about making it work. I was really surprised at how |
294 |
nice people are on the forums, especially when compared to the mailing-list. Now I |
295 |
take it as a given that anyone posting is coming from a positive space. |
296 |
|
297 |
I wish I could say the same about the lists. |
298 |
|
299 |
> And if it does dry up and blow away when I |
300 |
> leave, will it have been worth the trouble for the time it will have been |
301 |
> available (hey, it gave people six months they'd have not had otherwise |
302 |
> and that's something!), or not? |
303 |
|
304 |
That's your call to make. All I'd say is: don't think of it as all-consuming, |
305 |
and don't let your head go there when you are posting on the forums. You have |
306 |
to remind yourself from time to time, that you're doing it because you want to, |
307 |
and no-one's paying you a dime, so you don't owe anyone a thing. You care about it, |
308 |
so it's easy to forget: it's low-priority. Period. |
309 |
|
310 |
The only exception is when you've pushed a buggy version. Then you better fix it |
311 |
quick (and not with a forced rebase), or expect a bollocking (as I've learnt, and |
312 |
so shall I teach, since it cuts through the haze.[2] ;-) |
313 |
|
314 |
> Finally, it's worth confirming one thing brought up on the forum thread. |
315 |
> I don't see any realistic possibility of doing anything further with |
316 |
> kdepim in a no-semantic kde. That's an upstream hard-dependency and I |
317 |
> don't see anyw way around it, making kdepim totally non-viable for our |
318 |
> purposes. Agreed? Given that, I believe it best not to carry kdepim in |
319 |
> the kde-lean overlay at all, and to recommend that people use something |
320 |
> else. |
321 |
|
322 |
Agreed. I never thought I'd stop using KMail, but there it is. |
323 |
|
324 |
> And one more thing: Short term, is it worth it to post the 4.10.80+ |
325 |
> patches as I have them either here or to the forum thread linked above, |
326 |
> or is it better to wait until we have an overlay to put them in and/or |
327 |
> until 4.11.0 is available? |
328 |
|
329 |
Do please post them to the forum thread, in a [code]block[/code] if the diff is |
330 |
reasonably small; you can Preview any post to check how it'll look, or Edit it |
331 |
(top-right of the post) after you've submitted it. If you do that before anyone |
332 |
replies, it doesn't show up as an edit (Last edited..; edited X times in total.) |
333 |
But in general preview everything with tags in it. |
334 |
|
335 |
Or at a reasonably light pastebin with a [url=http://..]link text[/url] I use |
336 |
http://sprunge.us/ generally, but IDK if that's at all permanent. I doubt it ;) |
337 |
http://paste.debian.net/ is used by quite a few people, and checking it I see it |
338 |
allows "permanent" posts. |
339 |
|
340 |
Just not pastebin.com please. It used to have an awful lot more ads, but it's |
341 |
still heavy, and it also used to insert CR/LF. I don't know if it still does; |
342 |
I refuse to use it, and only occasionally follow a link to it on IRC if it's |
343 |
something I'm really interested in reading. If someone's asking me for help, |
344 |
they won't get it with a pastebin.com link, unless they're cool and use another |
345 |
pastebin when asked. |
346 |
|
347 |
> kdelibs ebuild was still kde 4.10.4. My patches are tested not to pull in |
348 |
> the deps here at all but they're for 4.10.80+, where the semantic-desktop USE |
349 |
> flag is already gone, and thus won't apply cleanly to earlier versions that still |
350 |
> have it. |
351 |
|
352 |
Good, we need them in those versions, and we need to start thinking of the whole set |
353 |
so collaboration early is better, as ever. I'd better get my update --toolchain patch |
354 |
set finished so I can upgrade my system (Forgive me Gentoo for I have sinned: it's been |
355 |
3 months since my last completed emerge world..;) and see what's happening in the |
356 |
latest stable versions. |
357 |
|
358 |
Thank god for FEATURES=binpkg[3] though: I can roll back if 4.10/11 turns out to be a |
359 |
stinker. The way I feel about 4.9, is kinda how I felt about 3.5, so it's all good. |
360 |
There's some nice stuff in kate for 4.11 I want to try though. |
361 |
|
362 |
> Also, while complete for the packages I have installed, I don't |
363 |
> have a full kde installed (obviously not kdepim, but beyond that too), so |
364 |
> further patches will likely be needed for other packages. |
365 |
|
366 |
Yeah. Please post the patches to forums, so we can get cracking. |
367 |
|
368 |
Regards, |
369 |
steveL. |
370 |
|
371 |
[1] http://forums.gentoo.org/viewtopic-t-546828.html |
372 |
[2] http://www.paulgraham.com/head.html |
373 |
-- very useful to explain ourselves to non-coders, if you've not read it. |
374 |
"I don't hate you, I just can't stand it when you talk to me.." ;) |
375 |
[3] http://forums.gentoo.org/viewtopic-p-7165614.html#7165614 |
376 |
-- I know you're using it, but others might not be yet. |
377 |
-- |
378 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |