* Mike Frysinger :
> On Sunday 17 January 2010 16:12:29 David Leverton wrote:
> > On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
> > > With GLEP 42 and proper logging of e* messages I think we shouldn't
> > > annoy users any more with ebeep or epause so attached is a patch only
> > > define
(I'm resending this email as the original apparently did not make it
to the list, although Thomas probably received it)
Hi Thomas,
I'm replying to the original thread below to allow those who have
missed it to have the full context.
On Sun, Aug 16, 2009 at 5:37 AM, Thomas Sachau wrote:
> Let me
> On Mon, 18 Jan 2010, Sebastian Pipping wrote:
> isn't a package tree somehow having "system-wide implications"?
> i'm not really sure about /var/db - doesn't seem to be in FHS.
> is a package tree a database?
This depends on your definition of "database". At least some parts of
the tree (li
On 01/17/2010 08:23 PM, Ben de Groot wrote:
What about something like: if a bug has been open for 2 months without
any apparent maintainer activity, anyone can step in and commit a fix?
How about - anybody at any time can at their discretion post a comment
in a bug asking if there are objecti
On Sunday 17 January 2010 15:31:26 Thilo Bangert wrote:
> Ciaran McCreesh said:
> > I realise this is a lost cause, but... Repositories are databases, so
> > /var/db/ is your friend.
>
> i like it. Closely followed by /var/lib/layman...
>
> wikipedia says in
> http://en.wikipedia.org/wiki/Filesy
2010/1/17 Thilo Bangert :
> no - i wasn't talking about maintainer-needed bugs. it is my impression,
> that many apparently maintained packages have simple bugs lingering for
> extended periods of time. Fx. users reporting bugs AND supplying fixes,
> ready to be committed.
>
> i dont want to step o
On 01/17/10 21:31, Thilo Bangert wrote:
> /var/layman i dislike due to this sentence in the FHS:
>
>"Applications must generally not add directories to the top level of
> /var. Such directories should only be added if they have some system-wide
> implication[...]"
isn't a package tree someh
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2010-01-17 23h59 UTC.
Removals:
app-i18n/ibus-table-additional 2010-01-13 13:52:38
matsuu
app-i18n/ibus-table-jyutping2010-01-13 13:53
On Sunday 17 January 2010 17:12:27 Thilo Bangert wrote:
> Sebastian Pipping [snip] said:
> [snip]
>
> > i chose maintainer-wanted to indicate that co-maintainers and
> > non-maintainer-bumps are welcome. what valid means can i use to send
> > such a message, instead?
>
> i dont know of any. i ge
Mike Frysinger said:
> On Sunday 17 January 2010 15:20:46 Thilo Bangert wrote:
> > Ben de Groot said:
> > > I think we have a bigger problem with packages that have a
> > > maintainer, at least nominally, but said maintainer does not
> > > actually maintain the package anymore.
> >
> > full ack.
Sebastian Pipping [snip] said:
[snip]
> i chose maintainer-wanted to indicate that co-maintainers and
> non-maintainer-bumps are welcome. what valid means can i use to send
> such a message, instead?
i dont know of any. i generally assume all packages are looking for more
maintainers, but that a
On Sunday 17 January 2010 16:12:29 David Leverton wrote:
> On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
> > With GLEP 42 and proper logging of e* messages I think we shouldn't
> > annoy users any more with ebeep or epause so attached is a patch only
> > defines these functions for EAPIs 0
On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause so attached is a patch only
> defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
> keep these around for EAPI 3
On Sunday 17 January 2010 15:20:46 Thilo Bangert wrote:
> Ben de Groot said:
> > I think we have a bigger problem with packages that have a maintainer,
> > at least nominally, but said maintainer does not actually maintain the
> > package anymore.
>
> full ack. i was thinking that maybe we need a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 17.1.2010 21:38, Petteri Räty napsal(a):
> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause so attached is a patch only
> defines these functions for EAPIs 0, 1 and 2. Anyone have a rea
On 01/17/2010 03:20 PM, Thilo Bangert wrote:
Ben de Groot said:
I think we have a bigger problem with packages that have a maintainer,
at least nominally, but said maintainer does not actually maintain the
package anymore.
full ack. i was thinking that maybe we need an 'easy-fix' team, which
Hello fellow devs, users and Gentoo community,
in this election we received 87 valid ballots from a total of 260
voters, which means we had a 33.462% turnout. Without much ado, Tomas
Chvatal (scarabeus) was elected to the council. The full ranked list for
this election is:
scarabeus
patrick
wired
With GLEP 42 and proper logging of e* messages I think we shouldn't
annoy users any more with ebeep or epause so attached is a patch only
defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
keep these around for EAPI 3? If not I will apply the attached patch.
Regards,
Petteri
Ind
Ciaran McCreesh said:
> I realise this is a lost cause, but... Repositories are databases, so
> /var/db/ is your friend.
>
i like it. Closely followed by /var/lib/layman...
wikipedia says in
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
/var/lib/
State information. Persistent d
Ben de Groot said:
> I think we have a bigger problem with packages that have a maintainer,
> at least nominally, but said maintainer does not actually maintain the
> package anymore.
full ack. i was thinking that maybe we need an 'easy-fix' team, which can
do all the easy fixes, which have been
> >>> Please: When you run tools which break checksums/dates of the database,
> >>> give the user the possibility to decide whether he really wants this.
> >> Good point, I didn't realize that. However, I'd rather fix the tool (for
> >> example to update the portage database).
> On the other hand,
On 1/17/10 7:28 PM, Krzysiek Pawlik wrote:
> On 01/17/10 18:20, "Paweł Hajdan, Jr." wrote:
>>> Please: When you run tools which break checksums/dates of the database,
>>> give the user the possibility to decide whether he really wants this.
>> Good point, I didn't realize that. However, I'd rather
On 01/17/10 18:20, "Paweł Hajdan, Jr." wrote:
>> Please: When you run tools which break checksums/dates of the database,
>> give the user the possibility to decide whether he really wants this.
>
> Good point, I didn't realize that. However, I'd rather fix the tool (for
> example to update the por
On 1/17/10 6:57 PM, Vaeth wrote:
> On Sun, 17 Jan 2010, "Paweł Hajdan, Jr." wrote:
>> I wonder why the affected package (eselect-opengl) couldn't run
>> lafilefixer itself. It's mandatory for all users, and would save a lot
>> of frustration.
> It is not mandatory: You could as well re-emerge the a
On 01/17/10 10:01, Ciaran McCreesh wrote:
> I realise this is a lost cause, but... Repositories are databases, so
> /var/db/ is your friend.
Right, that's a way you can see it.
Does anyone _strongly_ prefer
/var/db/layman
over
/var/layman
?
Sebastian
On Sun, 17 Jan 2010, "Paweł Hajdan, Jr." wrote:
> I wonder why the affected package (eselect-opengl) couldn't run
> lafilefixer itself. It's mandatory for all users, and would save a lot
> of frustration.
It is not mandatory: You could as well re-emerge the affected packages
(shown by revdep-rebu
2010/1/17 "Paweł Hajdan, Jr." :
> I wonder why the affected package (eselect-opengl) couldn't run
> lafilefixer itself. It's mandatory for all users, and would save a lot
> of frustration.
Indeed. You can simply have this version of eselect-opengl depend on
lafilefixer and run it in pkg_postinst.
Am Samstag 16 Januar 2010 19:26:04 schrieb Sebastian Pipping:
> On 01/16/10 13:56, Ben de Groot wrote:
> >> anybody objecting to /var/layman ?
> >
> > I like that.
>
> it seems that
>
> /var/layman
>
> is the only location nobody has objected to, yet. i plan to go with
> that atm. /var/lib/l
On 01/17/2010 01:26 PM, Tomáš Chvátal wrote:
> Howdy guys,
> please review the attached file and suggest updates to in.
> I was asked for this thing going stable due to its being dependency of
> new nvidia-drivers.
>
> Also this thing is probably blocker for the bug on eselect-opengl i just
> open
On 1/17/10 12:26 PM, Tomáš Chvátal wrote:
> please review the attached file and suggest updates to in.
> I was asked for this thing going stable due to its being dependency of
> new nvidia-drivers.
I wonder why the affected package (eselect-opengl) couldn't run
lafilefixer itself. It's mandatory f
Howdy guys,
please review the attached file and suggest updates to in.
I was asked for this thing going stable due to its being dependency of
new nvidia-drivers.
Also this thing is probably blocker for the bug on eselect-opengl i just
opened:
http://bugs.gentoo.org/show_bug.cgi?id=301271
Cheers
2010/1/17 Christian Faulhammer :
> Ciaran McCreesh :
> As much as you love to have the new and shiny VDB2, it is far off.
> Prototyping and drafting implementations would be great to have some
> base where we can discuss on (in a civil manner). So having this
> timestamp would be a good way to pr
Hi,
Ciaran McCreesh :
> That probably wouldn't be possible. One of the reasons we want to
> ditch VDB is to allow multiple slots of the same cat/pkg-ver to be
> installed in parallel (which is in turn necessary to allow some of the
> more hideous dynamic slot abuses that people are after). VDB doe
2010/1/17 Tobias Klausmann :
>> No, we'd not do it that way. If we're ditching VDB, the only sane way
>> to do it is to ditch it with an rm -fr when creating the new layout.
>> Keeping two sets of data around is going to lead to breakage no matter
>> how well we do things.
>
> Please also provide a
Hi!
On Sun, 17 Jan 2010, Ciaran McCreesh wrote:
> > 1) portage/pkgcore support the PMS defined vdb2 while paludis doesn't
> > 2) portage/pkgcore are invoked modifying the livefs; vdb1, vdb2 is
> > updated.
> > 3) paludis is invoked. vdb1 is updated, vdb2 is not
> > 4) portage and pkgcore now can
2010/1/15 Sebastian Pipping :
> By default layman currently stores overlays into
>
> /usr/local/portage/layman
>
> (was /usr/portage/local/layman before that).
> As of bug 253725 [1] that's not without problems.
>
> I would like to get it right with the next switch.
I realise this is a lost cause
2010/1/12 Brian Harring :
>> There's no discussion because Brian refuses to address any comments
>> on the proposal and just says "we should do it anyway, and if you
>> want it done properly instead, do it yourself".
>
> This is a bit of bullshit, per the norm. There is plenty of
> discussion- the
On Sun, Jan 17, 2010 at 12:55 AM, Sebastian Pipping wrote:
> On 01/16/10 23:46, Benedikt Böhm wrote:
>> One thing all you /usr naggers forget is, that /var cannot be shared
>> read-only via nfs (or bind mounts in case of virtual servers).
>
> Why is that? Please tell more.
Maybe you should actua
38 matches
Mail list logo
