Piotr Jaroszyński | 1 Jul 01:35 2007
Picon

[QA] RESTRICT clean up

Hello,

1) Should third party values be allowed? At first glance I have only found 
multilib.eclass, which is using "multilib-pkg-force". Imho no, it can use 
some eclass specific var for that like EMULTILIB="pkg-force" or whatever. If 
there is no objection QA will handle the tree transition.

2) clean up: we want to do global tree clean up after 1) is resolved, nofoo -> 
foo, rest of the invalid values die.

3) repoman check: I have contributed a RESTRICT check(10 lines wow:), which 
will be in the next portage release. warning for now, error after 2) is done.

-- 
Best Regards,
Piotr Jaroszyński
--

-- 
gentoo-dev <at> gentoo.org mailing list

Petteri Räty | 1 Jul 10:47 2007
Picon

Last rites: kde-misc/kdbus

+# Petteri Räty <betelgeuse <at> gentoo.org> (01 Jul 2007)
+# Upstream describes this as:
+# Buggy and unmaintained D-BUS service browser for KDE.
+# Seems to segmentation fault on me on startup with current
+# dbus. Removal in 30 days unless someone else takes this
+# package and fixes the problems.
+kde-misc/kdbus
+

Marijn Schouten (hkBst | 1 Jul 11:05 2007
Picon

Re: [QA] RESTRICT clean up


Piotr Jaroszyński wrote:
> 1) Should third party values be allowed?

I'm sorry, but I have no idea what `third party values' are.

> At first glance I have only found 
> multilib.eclass, which is using "multilib-pkg-force". Imho no, it can use 
> some eclass specific var for that like EMULTILIB="pkg-force" or whatever. If 
> there is no objection QA will handle the tree transition.

Marijn
Piotr Jaroszyński | 1 Jul 13:29 2007
Picon

Re: [QA] RESTRICT clean up

On Sunday 01 of July 2007 11:05:24 Marijn Schouten (hkBst) wrote:
> I'm sorry, but I have no idea what `third party values' are.

./multilib.eclass:      if hasq multilib-pkg-force ${RESTRICT} ||

-- 
Best Regards,
Piotr Jaroszyński
--

-- 
gentoo-dev <at> gentoo.org mailing list

Duncan | 1 Jul 15:06 2007
Picon
Picon

Re: Last rites: kde-misc/kdbus

Petteri Räty <betelgeuse <at> gentoo.org> posted 46876A05.30805 <at> gentoo.org,
excerpted below, on  Sun, 01 Jul 2007 11:47:01 +0300:

> +# Petteri Räty <betelgeuse <at> gentoo.org> (01 Jul 2007) 
> +# Upstream describes this as:
> +# Buggy and unmaintained D-BUS service browser for KDE. 
> +# Seems to segmentation fault on me on startup with current 
> +# dbus. Removal in 30 days unless someone else takes this 
> +# package and fixes the problems.
> +kde-misc/kdbus
> +

FWIW, it seems to work fine here, no segfaults I could cause just 
browsing tho I didn't try sending any dbus messages with it.  ~amd64 (so 
KDE 3.5.7) here except that I've unmasked gcc-4.2.0, and as recommended, 
done the emerge --emptytree thing.  So I've got a pretty freshly rebuilt 
system, but it doesn't segfault here, even built with gcc-4.2.0.

So it can't be /entirely/ borken.  I don't use it, and as you're the 
maintainer, if you wish to kill it, I've no objections.  Just sayin' it 
/does/ still work, so you'll need a reason other than that, even if it's 
just that you're tired of it and it's not a big loss since KDE-4's coming 
up and it's unmaintained, so would appear to be on borrowed time anyway.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--

-- 
(Continue reading)

Marijn Schouten (hkBst | 1 Jul 15:27 2007
Picon

Re: [QA] RESTRICT clean up


Piotr Jaroszyński wrote:
> On Sunday 01 of July 2007 11:05:24 Marijn Schouten (hkBst) wrote:
>> I'm sorry, but I have no idea what `third party values' are.
> 
> ./multilib.eclass:      if hasq multilib-pkg-force ${RESTRICT} ||

right, you're talking about (dis)allowing third party values in the RESTRICT
variable. I guess I should have read the topic better, but I also think mails
should be comprehensible in absence of the topic.

Where is the (proposed) list of allowed values? What is the point of
restricting to that list?

Marijn
Piotr Jaroszyński | 1 Jul 15:49 2007
Picon

Re: [QA] RESTRICT clean up

On Sunday 01 of July 2007 15:27:21 Marijn Schouten (hkBst) wrote:
> Where is the (proposed) list of allowed values? What is the point of
> restricting to that list?

man 5 ebuild. The point is that this variable is used by the package manager 
and adding third part values supported only by specific eclasses can mislead 
people into thinking that such third party value is supported by the package 
manager while it's not. Moreover the one example we 
have - "multilib-pkg-force" - doesn't really fit into RESTRICT, I still can't 
figure out what foo-force in RESTRICT was supposed to mean.

-- 
Best Regards,
Piotr Jaroszyński
--

-- 
gentoo-dev <at> gentoo.org mailing list

Ryan Reich | 1 Jul 16:48 2007
Picon

Inotify and (f)crontabs

My apologies for triple-posting this.  I can't tell which list would
be most appropriate, since it is a user, development, and performance
issue (albeit a minor performance issue).

This is a small essay on Gentoo's setup for fcron.

My issue:
I just installed fcron and I have to say, I'm a little disappointed
with the kludgy mechanism for implmenting:
1. easy configuration, meaning I don't have to run fcrontab personally
2. /etc/cron.{hourly,daily,weekly,monthly}
These are implmented by some very silly-looking polling tricks which,
even in principle, will necessarily waste 83% (that's 5/6) of their
efforts and clutter the logs with useless and uninformative messages.

The facts:
1. is implmented by putting the following rule in /etc/fcrontab:
     <at> mail(false),nolog(true) 10 /usr/sbin/check_system_crontabs -s 0
whose effect is to run a script, every ten minutes, to check whether
I've changed any of the various configuration files /etc/{,f}crontab,
/etc/cron.d/* and then add them all to the system crontab.

2. is implmented by putting the following rules in /etc/crontab:
    0  *  * * *      rm -f /var/spool/cron/lastrun/cron.hourly
    1  3  * * *      rm -f /var/spool/cron/lastrun/cron.daily
    15 4  * * 6      rm -f /var/spool/cron/lastrun/cron.weekly
    30 5  1 * *      rm -f /var/spool/cron/lastrun/cron.monthly
    */10  *  * * *      /usr/bin/test -x /usr/sbin/run-crons &&
/usr/sbin/run-crons
whose effect is, at intevals of one hour, day, week, and month, to
(Continue reading)

Daniel Schömer | 1 Jul 19:07 2007
Picon
Picon

Re: Inotify and (f)crontabs

Hi!

Ryan Reich wrote:
> [...]
> My issue: I just installed fcron and I have to say, I'm
> a little disappointed with the kludgy mechanism for
> implmenting:
>
> 1. easy configuration, meaning I don't have to run fcrontab
>    personally
>
> 2. /etc/cron.{hourly,daily,weekly,monthly} These are implmented
>    by some very silly-looking polling tricks which, even in
>    principle, will necessarily waste 83% (that's 5/6) of their
>    efforts and clutter the logs with useless and uninformative
>    messages.
> [...]

I just want to share my system-wide fcrontab:

  $ sudo fcrontab -l systab
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  !nice(15)
  !noticenotrun(false)
  !serial(true)

  %hourly  0-30  run-parts --report /etc/cron.hourly
  %daily   * *   run-parts --report /etc/cron.daily
  %weekly  * *   run-parts --report /etc/cron.weekly
(Continue reading)

Ryan Reich | 1 Jul 19:30 2007
Picon

Re: Re: Inotify and (f)crontabs

On 7/1/07, Daniel Schömer <daniel.schoemer <at> gmx.net> wrote:
> Hi!
>
> Ryan Reich wrote:
> > [...]
> > My issue: I just installed fcron and I have to say, I'm
> > a little disappointed with the kludgy mechanism for
> > implmenting:
> >
> > 1. easy configuration, meaning I don't have to run fcrontab
> >    personally
> >
> > 2. /etc/cron.{hourly,daily,weekly,monthly} These are implmented
> >    by some very silly-looking polling tricks which, even in
> >    principle, will necessarily waste 83% (that's 5/6) of their
> >    efforts and clutter the logs with useless and uninformative
> >    messages.
> > [...]
>
> I just want to share my system-wide fcrontab:
>
>   $ sudo fcrontab -l systab
>   PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>
>   !nice(15)
>   !noticenotrun(false)
>   !serial(true)
>
>   %hourly  0-30  run-parts --report /etc/cron.hourly
>   %daily   * *   run-parts --report /etc/cron.daily
(Continue reading)


Gmane