Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Sam Jorna]

On Tue, Jan 17, 2017 at 04:45:39AM -0800, Daniel Campbell wrote:
> On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> > On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
> >>
> >> The nice thing about ::graveyard or similar is that its a clear demarcation
> >> between maintained (in tree) and unmaintained (graveyard.) It also means
> >> that people doing actual maintenance work can basically ignore the
> >> graveyard as a matter of policy. The ebuilds are archived there (for users)
> >> but since they are unmaintained they may not work correctly.
> > 
> > This is what the Java team used to do. There was a java-graveyard-overlay. 
> > I 
> > do not believe any package ever moved there came back into the tree. It did 
> > result in a pretty messed up overlay, but makes it a user problem.
> > 
> > At the same time, something could always be restored from VC. Not like 
> > removal 
> > is removing all history and traces. Thus not sure such overlay is really 
> > even 
> > beneficial. Using it could cause lots of problems if they just care about 1 
> > package or a few.
> > 
> 
> There's a nice trick around that, actually: let's assume the overlay is
> called "foo-overlay".
> 
> In package.mask:
> 
> */*::foo-overlay
> 
> will mask all packages in the overlay. You can then add packages to
> package.unmask:
> 
> pkg-cat/foobar::foo-overlay
> 
> That should alleviate most issues, though it can make dependencies a
> PITA if those deps are also in the overlay. In that case, emerge should
> yell at you and suggest adding lines to package.unmask.

Another option would be to set the priority of the overlay to -1001 (one
less than gentoo.git) and explicitly emerge the package from the
overlay:

emerge -a pkg-cat/foobar::foo-overlay

Dependencies will by default be drawn from gentoo.git (if it has equal
or better version(s)), and overlay-only dependencies won't need to be
explicitly unmasked.

You may end up with gentoo.git-provided packages coming from the overlay
if they have newer versions, though when talking about graveyard, that
shouldn't be an issue.

-- 
Sam Jorna (wraeth)
GPG ID: 0xD6180C26



signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: Common rsync-gen errors, why they happen, and what you can do about it

[Dirkjan Ochtman]

On Wed, Jan 18, 2017 at 5:58 AM, Doug Freed  wrote:
> At some point, the repoman manifest-check, or some variation of it,
> will probably get added to a post-receive hook, which will then abort
> your push if you try to push something that would break the conversion
> process.  That said, you should still be doing your due diligence to
> ensure that eventual hook doesn't yell at you.

This sounds like a much better strategy to me. We're expecting people
to check things that should be easy to check for machines. Yes, some
people (like myself) will always use repoman to commit, but it would
be much better if something this important (because it basically
delays other updates to users everywhere) is checked by an automated
process for every push, and disallows pushes like this.

> I can see if it's something I need to fix with my code.  But it's been
> a while since that's been the case, so all the failures these days are
> primarily for the previously mentioned issues.

That makes sense. My other comment initially reading your email would
be, send those emails to gentoo-core or -project or whatever. If
others don't get to feel the pain (of every half-hour error emails,
for example), they will be much less compelled to fix the problem. So
absorbing this "pain" into just you or infra makes us less scalable as
a distribution, and less likely that someone will feel motivated to
add the extra bits of automation (like a git hook) that will make this
problem go away.

Cheers,

Dirkjan

[gentoo-dev] Re: Common rsync-gen errors, why they happen, and what you can do about it

[Doug Freed]

Oh, I missed some things.  First off, a general timeline of rsync-gen
events (all times occur every hour at roughly specified minute after
the hour):

:00 / :30 - current state of git tree is checked out on git server and
then rsynced to private master rsync server - this is your cutoff time
for getting changes into the rsync-gen run
:06 / :36 - rsync-gen script starts
:09 / :39 (ish) - md5-cache generation and manifest thickening have
usually completed by this time; rsync-gen runs repoman manifest-check
across the whole tree at this time
:15 / :45 (ish) - By this time any failure in the repoman
manifest-check has surfaced, and if so, I (as well as others, mostly
infra) have been emailed about it
:20 / :50 (ish) - The final transfer from the staging directory to the
final directory has usually finished by this time, though that depends
heavily on how many changes were made since the last transfer (if you
break things and don't fix them for a while, this can be a lot)

At some point, the repoman manifest-check, or some variation of it,
will probably get added to a post-receive hook, which will then abort
your push if you try to push something that would break the conversion
process.  That said, you should still be doing your due diligence to
ensure that eventual hook doesn't yell at you.

And in case you're wondering why I get emailed about these failures, I
wrote the script that thickens Manifests, which does the entire tree
as parallel as possible in under a minute.  In addition, I improved
sizable portions of the rsync-gen script itself.  The code isn't
absolutely perfect (no code is), so I get emails about any failures so
I can see if it's something I need to fix with my code.  But it's been
a while since that's been the case, so all the failures these days are
primarily for the previously mentioned issues.

-Doug

[gentoo-dev] Common rsync-gen errors, why they happen, and what you can do about it

[Doug Freed]

The two most common errors that occur in the rsync-gen process are
missing DIST entries in the Manifest committed to git, and
metadata.xml that fails to validate against the DTD.  Two much less
common errors that have occurred in the last 24 hours which prompted
this email are FILESDIR items that are way too large (>60 KiB), and
completely missing metadata.xml.  All four of these errors are fatal
to the rsync-gen process, and for good reason.

Anything fatal to rsync-gen completely stops the git to rsync
conversion, and the rsync tree remains at the state it was before the
failure until the failure is resolved.  If it isn't apparent, this
completely blocks all updates, GLSA distribution, news item
distribution, and anything else distributed by the rsync tree either
now or in the future, until the problem is fixed.  If you're curious
about the current age of the rsync tree due to failures, you can
retrieve the metadata/timestamp or metadata/timestamp.x (not
timestamp.chk) file from rsync.gentoo.org and inspect its contents (or
do a verbose listing of the file, and look at the mtime).  The
rsync.gentoo.org rotation only contains servers managed by infra,
which sync against the private master rsync server very frequently, so
you can be reasonably sure they're about as up to date as possible.
Explanation of the various timestamp files:

* timestamp: created by rsync-gen script in the staging directory
immediately after md5-cache generation and manifest thickening is
complete.
* timestamp.x: created by cron job periodically (script comment says
every 5 minutes, but I think it's less often than that) in the staging
directory
* timestamp.chk: created by cron job periodically (again, script
comment says every 5 minutes, but I think it's every 15 minutes) in
the *final* directory

The final directory is what is served by the private master rsync
server, so you can use timestamp.chk to see the age of your local
mirror relative to the private master rsync server.  The staging
directory is transferred to the final directory as part of successful
completion of the rsync-gen script (it's the last step), so if
anything bails before that, it doesn't happen (thus, timestamp and
timestamp.x are mostly equivalent in meaning).

Why do these happen?  The answer is very simple: you forgot to run
repoman in the package directory before pushing your changes.
Alternately, the metadata.xml failing to validate error can happen if
your repoman is old.

So what can you do about it?  First, make sure repoman is installed
and up to date.  As of portage 2.3.0, repoman is a separate package
(app-portage/repoman) with its own release schedule, so once you've
updated portage past that version, you need to install repoman
yourself.  Repoman needs to be at least version 2.3.0 as well (which
it will be if you've installed portage 2.3.0 or newer), because the
metadata.xml validation check does not exist in any previous version,
and as mentioned, that check is fatal to the rsync-gen process.
Second, and I cannot stress this enough, *run repoman.*  Before you
push any changes to a package, run repoman manifest followed by at
least repoman manifest-check.  Repoman manifest will ensure that all
your DIST entries are there, and repoman manifest-check will cover the
other three issues I mentioned.  Repoman's scan and full commands also
include the checks done by manifest-check, so if you're running one of
those already prior to pushing your changes, you don't need to do
repoman manifest-check as well.  Note: pkgcore's repoman-alike (I
believe it's called pcheck) does not behave the same as repoman as of
this writing, and some checks it does not consider fatal are fatal to
repoman (eg the FILESDIR item larger than 60 KiB), so if you're
relying on pcheck for your QA checks, you should also do a repoman
manifest-check for good measure.  This should go without saying, but
if you modify an eclass in a way that affects SRC_URI for any package,
you should go through the packages that use that eclass and run
repoman manifest on them.

Remember, QA includes YOU!  (This also applies to all of you
submitting pull requests or otherwise proxy maintaining packages, and
all members of proxy-maint project; you should all be doing these QA
steps before you submit or push changes.)

Sincerely,

The guy who gets emailed every half hour because you broke the rsync
conversion until it's fixed, also known as Doug or dwfreed.

Re: [gentoo-dev] Last-rites: www-plugins/pipelight

[Walter Dnes]

On Tue, Jan 17, 2017 at 04:51:35AM -0800, Daniel Campbell wrote
> On 01/10/2017 11:29 AM, NP-Hardass wrote:
> > # NP-Hardass  (19 Jan 2017)
> > # Upstream has discontinued Pipelight and Firefox is in the process
> > # of removing NPAPI support (which Pipelight relies upon), making
> > # this obsolete.
> > # Masked for removal in 30 days.
> > www-plugins/pipelight
> > 
> > 
> Would this work for Pale Moon by any chance?

  According to their webpage https://www.palemoon.org/roadmap.shtml
NPAPI plug-ins are still supported.

> Technology support
> Pale Moon supports and will continue to support the following
> features/technologies:
> 
> *  Full UI customization
> *  Full theming (complete themes) and lightweight theming (personas)
> *  XUL and XBL to build interfaces
> *  NPAPI plug-ins
> *  XPCOM binary components for extensions
> *  Overlay and bootstrapped extensions, including restartless ones
> *  Access to low-level APIs from extensions
> *  Pale Moon Sync (in the secure, time-tested Weave fashion)

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] bzipped manpages

[james]

On 01/17/2017 12:26 PM, Michał Górny wrote:

[sent off list to reduce amount of spam]

Please cease this off-topic. It has nothing to do with the subject
debated. If you want to talk over a beer, then please go to a pub. If
you want to compare your pe^w^w^w embedded systems, then please
find an appropriate media for that.


Apologies. Agreed.


Documents on embedded systems, now that we have a solid definition of 
what an embedded system actually is, is quite important and minimizing 
storage/ram usage of resources whilst accessing those docs is of great 
importance.  Expecting a workstation or even a server to have the latest 
mix of documents for the variety of codes and hardware found in a 
heterogeneous cluster, is an unreasonable stretch, and often leads to 
mismatches, imho. Imagine a variety of embedded systems that morph in a 
different cluster matrix, dozens or hundreds of times a day.  The 
admins, programmers or users with larger codes may need a deep read on 
the docs sporadically' but in a time-critical manner. They do not want 
or need extraneous or irrelevant docs in the pool. Heterogeneous 
clusters are now all the rage in clusters, particularly, for HPC. 
Current, accurate and minimized docs are keenly important for all 
embedded systems, particularly if they can

receive codes or binaries dynamically and morph.


As embedded systems venues of deployment morph, dynamically, their 
interned documentation should be "auto adjusted" like the system 
software despite being on identical hardware particularly since  the 
embedded clusters grow more complex with the latest codes and hi level 
language codes on top of these embedded clusters.  That is, in the role 
they (dynamically play) as well in how individual software is used on 
otherwise identical hardware can change rapidly. Lofty goals, yes, but 
since the subject of local documentation  on embedded systems came up, 
naturally it is quite reasonable to seek the fastest possible diverse 
usage with the least footprint on resources.



hth,
James

Re: [gentoo-portage-dev] [PATCH] emaint: exit with non-zero status code when module fails (bug 567478)

[Alexandru Elisei]

>
> Please move this sys.exit to the main().  So this should just return
> a list of the rcodes to match the tasks it was passed.
> TaskHandler can be used easily via api, so we don't want it to exit out
> of someone else's code.  That will also keep main() as the primary cli
> interface.  There process the list of rcodes and exit appropriately.


This was an oversight on my part, I will make the necessary changes.

Alexandru, I tend to not prefer using numbers to indicate success/fail.
> They can be confusing at times.  In this case 1 means fail, 0 means
> success.  Which is the opposite of True/False.  It would be different
> if there were multiple return code values.  Then they would be
> meaningful.


 Sure, I understand your point, we are only interested in success of
failure of the modules, so having True or False as return values makes
sense. I got the idea to use 1 as a failure return code because that's how
the portage sync modules work (for example:
https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/sync/modules/git/git.py#n46).
That's also why I chose to return (returncode, message) and not (message,
returncode).



On Tue, Jan 17, 2017 at 8:23 PM, Brian Dolbec  wrote:

> On Tue, 17 Jan 2017 19:48:16 +0200
> Alexandru Elisei  wrote:
>
> > Currently module functions return a message to emaint after
> > invocation. Emaint prints this message then exits normally (with a
> > success return code) even if the module encountered an error. This
> > patch aims to change this by having each module public function
> > return a tuple of (returncode, message). Emaint will inspect the
> > return code and will exit unsuccessfully if necessary.
> > ---
> >  pym/portage/emaint/main.py| 11 +--
> >  pym/portage/emaint/modules/binhost/binhost.py |  6 --
> >  pym/portage/emaint/modules/config/config.py   |  8 ++--
> >  pym/portage/emaint/modules/logs/logs.py   |  9 +
> >  pym/portage/emaint/modules/merges/merges.py   | 18 +++---
> >  pym/portage/emaint/modules/move/move.py   |  9 +++--
> >  pym/portage/emaint/modules/resume/resume.py   |  4 +++-
> >  pym/portage/emaint/modules/sync/sync.py   | 19
> > +-- pym/portage/emaint/modules/world/world.py |
> > 8 ++-- 9 files changed, 64 insertions(+), 28 deletions(-)
> >
> > diff --git a/pym/portage/emaint/main.py b/pym/portage/emaint/main.py
> > index 65e3545..ef4383a 100644
> > --- a/pym/portage/emaint/main.py
> > +++ b/pym/portage/emaint/main.py
> > @@ -115,6 +115,7 @@ class TaskHandler(object):
> >   """Runs the module tasks"""
> >   if tasks is None or func is None:
> >   return
> > + returncode = os.EX_OK
> >   for task in tasks:
> >   inst = task()
> >   show_progress = self.show_progress_bar and
> > self.isatty @@ -135,14 +136,20 @@ class TaskHandler(object):
> >   # them for other tasks if there is
> > more to do. 'options': options.copy()
> >   }
> > - result = getattr(inst, func)(**kwargs)
> > + rcode, msgs = getattr(inst, func)(**kwargs)
> >   if show_progress:
> >   # make sure the final progress is
> > displayed self.progress_bar.display()
> >   print()
> >   self.progress_bar.stop()
> >   if self.callback:
> > - self.callback(result)
> > + self.callback(msgs)
> > + # Keep the last error code when using the
> > 'all' command.
> > + if rcode != os.EX_OK:
> > + returncode = rcode
> > +
> > + if returncode != os.EX_OK:
> > + sys.exit(returncode)
> >
>
>
> Please move this sys.exit to the main().  So this should just return
> a list of the rcodes to match the tasks it was passed.
> TaskHandler can be used easily via api, so we don't want it to exit out
> of someone else's code.  That will also keep main() as the primary cli
> interface.  There process the list of rcodes and exit appropriately.
>
>
>
> >
> >  def print_results(results):
> > diff --git a/pym/portage/emaint/modules/binhost/binhost.py
> > b/pym/portage/emaint/modules/binhost/binhost.py
> > index cf1213e..8cf3da6 100644
> > --- a/pym/portage/emaint/modules/binhost/binhost.py
> > +++ b/pym/portage/emaint/modules/binhost/binhost.py
> > @@ -86,7 +86,9 @@ class BinhostHandler(object):
> >   stale = set(metadata).difference(cpv_all)
> >   for cpv in stale:
> >   errors.append("'%s' is not in the
> > repository" % cpv)
> > - return errors
> > + if errors:
> > + return (1, errors)
> > + 

Re: [gentoo-portage-dev] [PATCH] emaint: exit with non-zero status code when module fails (bug 567478)

[Brian Dolbec]

On Tue, 17 Jan 2017 19:48:16 +0200
Alexandru Elisei  wrote:

> Currently module functions return a message to emaint after
> invocation. Emaint prints this message then exits normally (with a
> success return code) even if the module encountered an error. This
> patch aims to change this by having each module public function
> return a tuple of (returncode, message). Emaint will inspect the
> return code and will exit unsuccessfully if necessary.
> ---
>  pym/portage/emaint/main.py| 11 +--
>  pym/portage/emaint/modules/binhost/binhost.py |  6 --
>  pym/portage/emaint/modules/config/config.py   |  8 ++--
>  pym/portage/emaint/modules/logs/logs.py   |  9 +
>  pym/portage/emaint/modules/merges/merges.py   | 18 +++---
>  pym/portage/emaint/modules/move/move.py   |  9 +++--
>  pym/portage/emaint/modules/resume/resume.py   |  4 +++-
>  pym/portage/emaint/modules/sync/sync.py   | 19
> +-- pym/portage/emaint/modules/world/world.py |
> 8 ++-- 9 files changed, 64 insertions(+), 28 deletions(-)
> 
> diff --git a/pym/portage/emaint/main.py b/pym/portage/emaint/main.py
> index 65e3545..ef4383a 100644
> --- a/pym/portage/emaint/main.py
> +++ b/pym/portage/emaint/main.py
> @@ -115,6 +115,7 @@ class TaskHandler(object):
>   """Runs the module tasks"""
>   if tasks is None or func is None:
>   return
> + returncode = os.EX_OK
>   for task in tasks:
>   inst = task()
>   show_progress = self.show_progress_bar and
> self.isatty @@ -135,14 +136,20 @@ class TaskHandler(object):
>   # them for other tasks if there is
> more to do. 'options': options.copy()
>   }
> - result = getattr(inst, func)(**kwargs)
> + rcode, msgs = getattr(inst, func)(**kwargs)
>   if show_progress:
>   # make sure the final progress is
> displayed self.progress_bar.display()
>   print()
>   self.progress_bar.stop()
>   if self.callback:
> - self.callback(result)
> + self.callback(msgs)
> + # Keep the last error code when using the
> 'all' command.
> + if rcode != os.EX_OK:
> + returncode = rcode
> +
> + if returncode != os.EX_OK:
> + sys.exit(returncode)
> 


Please move this sys.exit to the main().  So this should just return
a list of the rcodes to match the tasks it was passed.
TaskHandler can be used easily via api, so we don't want it to exit out
of someone else's code.  That will also keep main() as the primary cli
interface.  There process the list of rcodes and exit appropriately.



> 
>  def print_results(results):
> diff --git a/pym/portage/emaint/modules/binhost/binhost.py
> b/pym/portage/emaint/modules/binhost/binhost.py
> index cf1213e..8cf3da6 100644
> --- a/pym/portage/emaint/modules/binhost/binhost.py
> +++ b/pym/portage/emaint/modules/binhost/binhost.py
> @@ -86,7 +86,9 @@ class BinhostHandler(object):
>   stale = set(metadata).difference(cpv_all)
>   for cpv in stale:
>   errors.append("'%s' is not in the
> repository" % cpv)
> - return errors
> + if errors:
> + return (1, errors)
> + return (os.EX_OK, None)
> 

Alexandru, I tend to not prefer using numbers to indicate success/fail.
They can be confusing at times.  In this case 1 means fail, 0 means
success.  Which is the opposite of True/False.  It would be different
if there were multiple return code values.  Then they would be
meaningful.  I want to keep these modules pythonic in the sense that
they return standard True/False for API use.  In this case returning
True/False would also make it easy to process the list of rcodes
returned to main()

sys.exit(False in rcodes)

which will reverse the True/False to 0/1 automatically for us and make
it super simple to process a variable length list success/fail results.

-- 
Brian Dolbec 

[gentoo-portage-dev] [PATCH] emaint: exit with non-zero status code when module fails (bug 567478)

[Alexandru Elisei]

Currently module functions return a message to emaint after invocation.
Emaint prints this message then exits normally (with a success return
code) even if the module encountered an error. This patch aims to
change this by having each module public function return a tuple of
(returncode, message). Emaint will inspect the return code and will
exit unsuccessfully if necessary.
---
 pym/portage/emaint/main.py| 11 +--
 pym/portage/emaint/modules/binhost/binhost.py |  6 --
 pym/portage/emaint/modules/config/config.py   |  8 ++--
 pym/portage/emaint/modules/logs/logs.py   |  9 +
 pym/portage/emaint/modules/merges/merges.py   | 18 +++---
 pym/portage/emaint/modules/move/move.py   |  9 +++--
 pym/portage/emaint/modules/resume/resume.py   |  4 +++-
 pym/portage/emaint/modules/sync/sync.py   | 19 +--
 pym/portage/emaint/modules/world/world.py |  8 ++--
 9 files changed, 64 insertions(+), 28 deletions(-)

diff --git a/pym/portage/emaint/main.py b/pym/portage/emaint/main.py
index 65e3545..ef4383a 100644
--- a/pym/portage/emaint/main.py
+++ b/pym/portage/emaint/main.py
@@ -115,6 +115,7 @@ class TaskHandler(object):
"""Runs the module tasks"""
if tasks is None or func is None:
return
+   returncode = os.EX_OK
for task in tasks:
inst = task()
show_progress = self.show_progress_bar and self.isatty
@@ -135,14 +136,20 @@ class TaskHandler(object):
# them for other tasks if there is more to do.
'options': options.copy()
}
-   result = getattr(inst, func)(**kwargs)
+   rcode, msgs = getattr(inst, func)(**kwargs)
if show_progress:
# make sure the final progress is displayed
self.progress_bar.display()
print()
self.progress_bar.stop()
if self.callback:
-   self.callback(result)
+   self.callback(msgs)
+   # Keep the last error code when using the 'all' command.
+   if rcode != os.EX_OK:
+   returncode = rcode
+
+   if returncode != os.EX_OK:
+   sys.exit(returncode)


 def print_results(results):
diff --git a/pym/portage/emaint/modules/binhost/binhost.py
b/pym/portage/emaint/modules/binhost/binhost.py
index cf1213e..8cf3da6 100644
--- a/pym/portage/emaint/modules/binhost/binhost.py
+++ b/pym/portage/emaint/modules/binhost/binhost.py
@@ -86,7 +86,9 @@ class BinhostHandler(object):
stale = set(metadata).difference(cpv_all)
for cpv in stale:
errors.append("'%s' is not in the repository" % cpv)
-   return errors
+   if errors:
+   return (1, errors)
+   return (os.EX_OK, None)

def fix(self,  **kwargs):
onProgress = kwargs.get('onProgress', None)
@@ -177,4 +179,4 @@ class BinhostHandler(object):
if maxval == 0:
maxval = 1
onProgress(maxval, maxval)
-   return None
+   return (os.EX_OK, None)
diff --git a/pym/portage/emaint/modules/config/config.py
b/pym/portage/emaint/modules/config/config.py
index dad024b..a4a58d9 100644
--- a/pym/portage/emaint/modules/config/config.py
+++ b/pym/portage/emaint/modules/config/config.py
@@ -36,7 +36,10 @@ class CleanConfig(object):
if onProgress:
onProgress(maxval, i+1)
i += 1
-   return self._format_output(messages)
+   msgs = self._format_output(messages)
+   if msgs:
+   return (1, msgs)
+   return (os.EX_OK, None)

def fix(self, **kwargs):
onProgress = kwargs.get('onProgress', None)
@@ -65,7 +68,8 @@ class CleanConfig(object):
i += 1
if modified:
writedict(configs, self.target)
-   return self._format_output(messages, True)
+   msgs = self._format_output(messages, True)
+   return (os.EX_OK, msgs)

def _format_output(self, messages=[], cleaned=False):
output = []
diff --git a/pym/portage/emaint/modules/logs/logs.py
b/pym/portage/emaint/modules/logs/logs.py
index fe65cf5..8c638d7 100644
--- a/pym/portage/emaint/modules/logs/logs.py
+++ b/pym/portage/emaint/modules/logs/logs.py
@@ -40,7 +40,6 @@ class CleanLogs(object):
'NUM': int: number 

Re: [gentoo-dev] bzipped manpages

[james]

On 01/17/2017 01:05 AM, Daniel Campbell wrote:

On 01/13/2017 08:06 AM, james wrote:

On 01/13/2017 02:45 AM, Sven Eden wrote:


Btw.: Even "embedded experts" wholeheartedly agree that they disagree
what
"embedded" actually is. But I do think SoCs actually *do* qualify, at
least to
some degree...



Huh?

Probably who you deem as an expert; they have not clearly defined
systems types and semantics of an embedded systems. An embedded system
is one that is 'closed' to pedestrian/consumer/user modifications,
excepting rooting and other non-normal bypass mechanisms. A modification
is not the same thing as a configuration. An embedded system is designed
with limited functionality or "canned product functionality" for
consumers of very specific task-sets.  Early Micros where often more
accurately referred to as 'microcontrollers' as their function was
simply to replace mechanical control systems that were prone to wear and
failure. When programming occurs (again rooting and hacking do not
count), it is only allowed by the system designer(s). So a Rasp. Pi on
the internet, open to dozens or thousands of coders, is not an embedded
system. At some point it may become an embedded system, but it must be
locked down, limited in functionality and purged of all that software
used for development but not needed to run and function as the
designer(s) intend. Updates are usually in a binary form, again under
the strict control as designed by the product (embedded systems) developer.


Given that, the reason why so many folks are confused as to what an
embedded system actually is, is that there are lots of "open" platforms
where users are encouraged to be the designer, thus having architecture,
coding, and modification access that an ordinary user would not have;
again, security hacks that grant non-normal access
do not count. That is if you 'hack' into the product or the bios of a
computer, you have not converted the device's intended usage into a
embedded system, although you may have low level access to the hardware,
firmware and other subsystems that the designers did not intentionally
make available to you. When a computer is 'locked down and limited' like
a kiosk, it actually is an embedded system.


Traditionally, the easy way to set up product developers was through
vendors (OEM like Freescale, Samsung, Broadcom, etc) via a  'dev board'.
Example codes, minimal stack of an rtos or vendor supplied software
system, along with documentation and details of the in-situ hardware
that comprise the 'dev board'. Small systems did not have (nor do they
now) have an 'OS' instead they were simple state-machines or run a
polling algorithm. Most embedded systems still operate on these sorts of
codes, even today.


Fast forward, Rasp. Pi et. al are dev boards that can be turned into
open, multi user systems, say if you make it a typical minimized linux
system. Some even have inputs for keyboard, mouse and terminal; so that
sort of system, would not be an embedded system. Now take the same
board, lock it down so all it does is control the sprinklers in your
yard, with limited functional interfaces to the 'standard user' and it
is indeed an 'embedded system'. Most products with a small
microprocessor are 'embedded systems'. Most Rasp. Pi boards are user
systems because they are open and unlimited an any given time and are
not 'locked down'.


It takes a designer, or a team of designers to create an 'embedded
system', particularly if the embedded system is to be turned into a
commercial product. The net effect of boards like Rasp. Pi is open up
the opportunity for folks to learn 'product development'. Most have
chosen to create  user systems with some functionality not found in
traditional desktop systems. Surely there are edge cases that blur
the lines of distinction; but most are not a finalized product (embedded
system) as they are in a constant state of flux related to the interned
software, thus they are not an 'embedded system'. A properly designed
embedded system can last in its minimized and limited form for decades
or more and operated as intended (think digital alarm clock). Others do
need an update to the firmware (locked down internal software), but that
is only performed by the product owners or vendors, in the normal case
of operation. Indeterminant hardware is just hardware; it has to be
robustly defined, tested and implemented to be a user system, an
embedded system, or whatever the designer has in mind.


 So hopefully, I have articulated the fact that an 'embedded system' is
determined by the designer, not the underlying hardware from a vendor.
Robust embedded system design, regardless of VHDL or C or ? codes
are more of an art-form than a technical expose on software development.
I know embedded designers that have created thousands of products  some
in a matter of weeks, and other teams that fail to produce a single
robust product, in their entire lifetime.  The most prolific designer of
them all, is simple 

Re: [gentoo-dev] Last-rites: www-plugins/pipelight

[Daniel Campbell]

On 01/10/2017 11:29 AM, NP-Hardass wrote:
> # NP-Hardass  (19 Jan 2017)
> # Upstream has discontinued Pipelight and Firefox is in the process
> # of removing NPAPI support (which Pipelight relies upon), making
> # this obsolete.
> # Masked for removal in 30 days.
> www-plugins/pipelight
> 
> 
Would this work for Pale Moon by any chance?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Daniel Campbell]

On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
>>
>> The nice thing about ::graveyard or similar is that its a clear demarcation
>> between maintained (in tree) and unmaintained (graveyard.) It also means
>> that people doing actual maintenance work can basically ignore the
>> graveyard as a matter of policy. The ebuilds are archived there (for users)
>> but since they are unmaintained they may not work correctly.
> 
> This is what the Java team used to do. There was a java-graveyard-overlay. I 
> do not believe any package ever moved there came back into the tree. It did 
> result in a pretty messed up overlay, but makes it a user problem.
> 
> At the same time, something could always be restored from VC. Not like 
> removal 
> is removing all history and traces. Thus not sure such overlay is really even 
> beneficial. Using it could cause lots of problems if they just care about 1 
> package or a few.
> 

There's a nice trick around that, actually: let's assume the overlay is
called "foo-overlay".

In package.mask:

*/*::foo-overlay

will mask all packages in the overlay. You can then add packages to
package.unmask:

pkg-cat/foobar::foo-overlay

That should alleviate most issues, though it can make dependencies a
PITA if those deps are also in the overlay. In that case, emerge should
yell at you and suggest adding lines to package.unmask.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] bzipped manpages

[Fabian Groffen]

On 16-01-2017 22:13:39 -0800, Daniel Campbell wrote:
> On 01/10/2017 05:16 AM, Fabian Groffen wrote:
> > On 09-01-2017 09:08:22 +0100, Jan Stary wrote:
> >> The particular problem I am having is that http://mdocml.bsd.lv/ ,
> >> my manpage formatter of choice, does deliberately not support bzip
> >> (or any other outside decompressors for that matter).
> > 
> > Attached patch works for me.  XZ should be a similar exercise, a little
> > cleanup would be nice then though.
> > 
> This is awesome; has upstream been sent this yet, by any chance?

Nope, given the initial quoted email from the main developer, I gave it
zero chance of success, and not worth the bother.  AFAICT I posted the
patch to the public domain, so anyone can take it and use it as they see
fit.

Also, if Gentoo would ship this package, it probably should have this
patch since it would enable the package to work with our default
settings.  However, we don't ship this package.  I made a preliminary
ebuild, but ran into some issues, e.g. it cannot replace `/usr/bin/man`
because that would break lesspipe.sh's ability to view manpages.
Concluding that (for me) the manpages didn't render any faster, or
better -- I'd say even worse since I got no colours -- I decided to
leave the package as is, because of no gain.

Fabian


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature