Am Freitag, 8. Januar 2021, 14:26:32 EET schrieb Joonas Niilola:
> # Now my question is, does anyone find any of these packages useful?
> Should we go ahead and last-rite them, since it doesn't seem useful to
> carry these in Gentoo? The ones broken are heading towards last-riting
> nevertheless.
On Freitag, 8. Januar 2021 13:26:32 CET Joonas Niilola wrote:
> # So the final list of "useless" libs is:
> dev-libs/atcore
This has IUSE="gui", EAPI=7 and kde proj as maintainer. Please keep.
Regards
signature.asc
Description: This is a digitally signed message part.
On 1/8/21 5:42 PM, Thomas Deutschmann wrote:
> Hi,
>
> I wonder how you composed this list. If you just checked if there is
> any revdep, the check was probably useless:
>
> For example,
>
>> dev-libs/cyberjack
>
> is up-to-date, has an active dev as maintainer and is required for any
> ReinerSCT
On Fri, Jan 8, 2021 at 7:27 AM Joonas Niilola wrote:
> dev-libs/clhpp
We want to keep this, though I admit I don't recall why nothing depends on it.
Hi,
please forget my previous mail. I was informed that I misread your mail,
sorry about that!
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
OpenPGP_signature
Description: OpenPGP digital signature
Hi,
I wonder how you composed this list. If you just checked if there is any
revdep, the check was probably useless:
For example,
dev-libs/cyberjack
is up-to-date, has an active dev as maintainer and is required for any
ReinerSCT chipcard reader.
--
Regards,
Thomas Deutschmann / Gentoo
On Fri, 8 Jan 2021 14:26:32 +0200
Joonas Niilola wrote:
> dev-libs/libgcrypt-compat
> dev-libs/libpcre-debian
These are maintained by me and I'd like to keep them. They can be
pulled in by running the esteam tool in steam-overlay for games that
need them. They could potentially be used for other
# With the help of jkroon I went through all dev-libs/* and media-libs/*
packages and located each one without reverse deps,
# List of dev-libs/* and media-libs/* without any revdeps:
dev-libs/atcore
dev-libs/bcm2835
dev-libs/bemenu
dev-libs/bitset
dev-libs/boost-mpl-cartesian_product
dev-libs/cali
Pacho Ramos napisał:
>El mié, 11-02-2015 a las 09:22 +0100, Jeroen Roovers escribió:
>> On Sun, 08 Feb 2015 11:17:19 +0100
>> Pacho Ramos wrote:
>>
>> > Many times has raised the question about how we could handle those
>> > packages (like icon packs, wallpapers...) that are not arch
>depende
On Sun, 08 Feb 2015 11:53:39 -0500 Brian Evans wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/08/2015 05:17 AM, Pacho Ramos wrote:
> > Hello
> >
> > Many times has raised the question about how we could handle those
> > packages (like icon packs, wallpapers...) that are not
El mié, 11-02-2015 a las 09:22 +0100, Jeroen Roovers escribió:
> On Sun, 08 Feb 2015 11:17:19 +0100
> Pacho Ramos wrote:
>
> > Many times has raised the question about how we could handle those
> > packages (like icon packs, wallpapers...) that are not arch dependent
> > and, then, could be stabi
On Sun, 08 Feb 2015 11:17:19 +0100
Pacho Ramos wrote:
> Many times has raised the question about how we could handle those
> packages (like icon packs, wallpapers...) that are not arch dependent
> and, then, could be stabilized all at the same time by the first arch
> team that is going to stabil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/08/2015 05:17 AM, Pacho Ramos wrote:
> Hello
>
> Many times has raised the question about how we could handle those
> packages (like icon packs, wallpapers...) that are not arch
> dependent and, then, could be stabilized all at the same time
Hello
Many times has raised the question about how we could handle those
packages (like icon packs, wallpapers...) that are not arch dependent
and, then, could be stabilized all at the same time by the first arch
team that is going to stabilize it.
Some months ago it was suggested that this packa
08.11.2013 09:04, Johann Schmitz пишет:
> On 07.11.2013 21:18, Rich Freeman wrote:
>> Seriously, though, I'd love to see these needs better supported.
>> I think we need to start by defining what the needs actually are
>> (less redundancy, more consistency, etc). Then we figure out how
>> to best
Johann Schmitz writes:
> Is it possible to run, say, mips on xen/whatever through some
> emulation layer or is real hardware a requirement for this archs?
Yes, via qemu. But very slow, nearly unusable even on a powerful
mainstream amd64 server.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07.11.2013 21:18, Rich Freeman wrote:
> Seriously, though, I'd love to see these needs better supported.
> I think we need to start by defining what the needs actually are
> (less redundancy, more consistency, etc). Then we figure out how
> to best
On 11/07/2013 03:07 PM, Denis M. wrote:
> On 11/07/2013 09:18 PM, Rich Freeman wrote:
>> On Thu, Nov 7, 2013 at 3:08 PM, Denis M. wrote:
>>> On 11/07/2013 08:59 PM, Matthew Thode wrote:
iirc, we give $200 if infra for developer accounts for a couple of
months. If a deal is struck it wou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/11/13 09:20 AM, Rich Freeman wrote:
> On Thu, Nov 7, 2013 at 7:14 AM, Denis M. wrote:
>> Almost every Gentoo dev that does software testings of some sorts
>> could benefit from these "build farms" (although I'd refrain from
>> using that term
On 11/07/2013 09:18 PM, Rich Freeman wrote:
> On Thu, Nov 7, 2013 at 3:08 PM, Denis M. wrote:
>> On 11/07/2013 08:59 PM, Matthew Thode wrote:
>>> iirc, we give $200 if infra for developer accounts for a couple of
>>> months. If a deal is struck it would likely be more and forever or
>>> something
On Thu, Nov 7, 2013 at 3:08 PM, Denis M. wrote:
> On 11/07/2013 08:59 PM, Matthew Thode wrote:
>> iirc, we give $200 if infra for developer accounts for a couple of
>> months. If a deal is struck it would likely be more and forever or
>> something.
>
> I've been running my VM for Ago for 13 month
On 11/07/2013 08:59 PM, Matthew Thode wrote:
> On 11/07/2013 12:26 PM, Markos Chandras wrote:
>> On 11/07/2013 02:48 PM, Matthew Thode wrote:
>>> Rackspace (where I work) currently has a developer discount program. I
>>> think we also host some open source stuff for various projects. Right
>>> no
On 11/07/2013 12:26 PM, Markos Chandras wrote:
> On 11/07/2013 02:48 PM, Matthew Thode wrote:
>> Rackspace (where I work) currently has a developer discount program. I
>> think we also host some open source stuff for various projects. Right
>> now you can try to use http://developer.rackspace.com
On 11/07/2013 02:48 PM, Matthew Thode wrote:
> Rackspace (where I work) currently has a developer discount program. I
> think we also host some open source stuff for various projects. Right
> now you can try to use http://developer.rackspace.com/ but if we want to
> make this more official I can
Rackspace (where I work) currently has a developer discount program. I
think we also host some open source stuff for various projects. Right
now you can try to use http://developer.rackspace.com/ but if we want to
make this more official I can ask around. Let me know if we want this
as a more of
On Thu, Nov 7, 2013 at 7:14 AM, Denis M. wrote:
> Almost every Gentoo dev that does software testings of some sorts could
> benefit from these "build farms" (although I'd refrain from using that
> term ;) ..).
Don't let me put a damper on your plans as-is, but I'd be interested
if developers who
On 11/07/2013 12:53 PM, hero...@gentoo.org wrote:
> Dear Denis,
Hi Benda,
>
> "Denis M." writes:
>
>> Please review this, and if you agree that it'd be a good idea come
>> with any suggestions to make it happen as well as with any other
>> thoughts/sys-specs/instances we should be looking for.
>
Dear Denis,
"Denis M." writes:
> Please review this, and if you agree that it'd be a good idea come
> with any suggestions to make it happen as well as with any other
> thoughts/sys-specs/instances we should be looking for.
Thanks for the offering. Though not a member, AT teams might benefit
fr
On 11/07/2013 12:37 AM, Andreas K. Huettel wrote:
> Am Donnerstag, 7. November 2013, 00:18:19 schrieb Denis M.:
>> Hello gentoo-dev@,
>>
>> Starting with a little intro, I'm currently providing a Gentoo VM to a
>> gentoo dev (Agostino Sarubbo (ago)) for the purpose of
>> testing/stabilizing/keyword
Am Donnerstag, 7. November 2013, 00:18:19 schrieb Denis M.:
> Hello gentoo-dev@,
>
> Starting with a little intro, I'm currently providing a Gentoo VM to a
> gentoo dev (Agostino Sarubbo (ago)) for the purpose of
> testing/stabilizing/keywording packages, which is part of his task as a
> developer
Hello gentoo-dev@,
Starting with a little intro, I'm currently providing a Gentoo VM to a
gentoo dev (Agostino Sarubbo (ago)) for the purpose of
testing/stabilizing/keywording packages, which is part of his task as a
developer and being part of the AT team. I've been running the VM for
him for a c
El mié, 06-06-2012 a las 14:53 -0400, Mike Frysinger escribió:
> On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote:
> > The problem is that grep keeps linked against libpcre and it can cause
> > problems like pointed in referred bug report, and it's really risky as
> > people can have their port
On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote:
> The problem is that grep keeps linked against libpcre and it can cause
> problems like pointed in referred bug report, and it's really risky as
> people can have their portage completely broken for example when libpcre
> is downgraded for some
El mié, 06-06-2012 a las 13:23 -0400, Mike Frysinger escribió:
> On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote:
> > I think that would be interesting to try to not get grep build with pcre
> > support by default, specially after reading "man grep" and seeing that
> > its support is tagged as
On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote:
> I think that would be interesting to try to not get grep build with pcre
> support by default, specially after reading "man grep" and seeing that
> its support is tagged as experimental:
>-P, --perl-regexp
> Interpret PAT
El mié, 06-06-2012 a las 10:37 +0200, "Paweł Hajdan, Jr." escribió:
> On 6/6/12 10:26 AM, Pacho Ramos wrote:
> > After reading:
> > https://bugs.gentoo.org/show_bug.cgi?id=419795
> >
> > I think that would be interesting to try to not get grep build with pcre
> > support by default, specially afte
On 6/6/12 10:26 AM, Pacho Ramos wrote:
> After reading:
> https://bugs.gentoo.org/show_bug.cgi?id=419795
>
> I think that would be interesting to try to not get grep build with pcre
> support by default, specially after reading "man grep" and seeing that
> its support is tagged as experimental:
T
After reading:
https://bugs.gentoo.org/show_bug.cgi?id=419795
I think that would be interesting to try to not get grep build with pcre
support by default, specially after reading "man grep" and seeing that
its support is tagged as experimental:
-P, --perl-regexp
Interpret PATT
On 10/17/2011 01:59 PM, Joost Roeleveld wrote:
> On Sunday, October 16, 2011 12:33:51 PM Zac Medico wrote:
>> If those LVM volumes require userspace tools to mount, then I think it's
>> perfectly reasonable to expect them to use either an initramfs or a
>> simple linuxrc approach [1] to ensure that
On Sunday, October 16, 2011 12:33:51 PM Zac Medico wrote:
> On 10/16/2011 06:07 AM, Rich Freeman wrote:
> > On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico wrote:
> >> I don't think it's a good idea for Gentoo to encourage users to have
> >> /usr on a separate partition. We should probably remove the
On 10/16/2011 06:07 AM, Rich Freeman wrote:
> On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico wrote:
>>
>> I don't think it's a good idea for Gentoo to encourage users to have
>> /usr on a separate partition. We should probably remove the separate
>> /usr partition from "Code Listing 2.1: Filesystem u
On Wed, Oct 12, 2011 at 12:40:23AM -0400, Walter Dnes wrote:
> Hi all
>
> Recently, there was a firestorm on the gentoo-user list over the idea
> that udev would eventually require /usr to be on the same physical
> parition as /, or else use initramfs, which is its own can of worms. I'm
> not a
On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico wrote:
>
> I don't think it's a good idea for Gentoo to encourage users to have
> /usr on a separate partition. We should probably remove the separate
> /usr partition from "Code Listing 2.1: Filesystem usage example" in our
> handbook:
>
> http://www.ge
On 10/15/2011 01:57 AM, Wulf C. Krueger wrote:
> On 15.10.2011 10:42, Michael Schreckenbauer wrote:
>> in what way will exherbo deal wih this mess? Are there any plans?
>
> We don't support /usr on a separate partition. People can, of course, do
> that and I'll point them to dracut for creating an
On Saturday, October 15, 2011 09:29:54 AM Michał Górny wrote:
> On Sat, 15 Oct 2011 00:06:03 -0400
>
> "Walter Dnes" wrote:
> > On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote
> >
> > > We're imposing our deep integration because it's the only way to
> > > make a compelling platfor
On Saturday 15 October 2011 03:29:54 Michał Górny wrote:
> On Sat, 15 Oct 2011 00:06:03 -0400 "Walter Dnes" wrote:
> > On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote
> > > We're imposing our deep integration because it's the only way to
> > > make a compelling platform that "just wor
On Sat, Oct 15, 2011 at 2:13 AM, Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger wrote:
>> On 15.10.2011 10:42, Michael Schreckenbauer wrote:
>>> in what way will exherbo deal wih this mess? Are there any plans?
>>
>> We don't support /usr on a separate partition. Pe
On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger wrote:
> On 15.10.2011 10:42, Michael Schreckenbauer wrote:
>> in what way will exherbo deal wih this mess? Are there any plans?
>
> We don't support /usr on a separate partition. People can, of course, do
> that and I'll point them to dracut for cr
On 15.10.2011 10:42, Michael Schreckenbauer wrote:
> in what way will exherbo deal wih this mess? Are there any plans?
We don't support /usr on a separate partition. People can, of course, do
that and I'll point them to dracut for creating an initramfs.
Or they can do whatever works for them. Peo
Sorry for being completely OT now, will be the only mail on this from my
side...
On Thursday, 13. October 2011 18:05:47 Ciaran McCreesh wrote:
> On Thu, 13 Oct 2011 11:14:31 -0400
>
> Olivier Crête wrote:
> > On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote:
> > > On Wed, 12 Oct 2011 23
On Wed, 12 Oct 2011 18:49:19 +0100
Ciaran McCreesh wrote:
> On Wed, 12 Oct 2011 23:00:23 +0530
> Nirbheek Chauhan wrote:
> > Then please continue with udev in package.mask and kindly stop
> > trying to impose your workflow on the rest of the world.
>
> Isn't the point here that the desktop / GN
On Sat, 15 Oct 2011 00:06:03 -0400
"Walter Dnes" wrote:
> On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote
>
> > We're imposing our deep integration because it's the only way to
> > make a compelling platform that "just works", forcing users to tell
> > the computer something the co
On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote
> We're imposing our deep integration because it's the only way to make a
> compelling platform that "just works", forcing users to tell the
> computer something the computer already knows is just plain lazy and
> stupid.
Eventually,
On Fri, Oct 14, 2011 at 8:37 PM, Walter Dnes wrote:
> On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote
>
>> https://www.xkcd.com/963/
>
> Xorg --configure
Funny, I haven't used a /etc/X11/Xorg.conf in years:
negra ~ # ll /etc/X11/
total 20
drwxr-xr-x 2 root root 4096 Sep 12 17:49 ap
On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote
> https://www.xkcd.com/963/
Xorg --configure
--
Walter Dnes
On Thursday 13 October 2011 14:55:45 Canek Peláez Valdés wrote:
> On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote:
> > On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
> >> While I've seen a lot of whining about this whole issue, I certainly
> >> haven't been seen any effort to actu
On Thu, Oct 13, 2011 at 11:55 AM, Canek Peláez Valdés wrote:
> On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote:
>> On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
>>> While I've seen a lot of whining about this whole issue, I certainly
>>> haven't been seen any effort to actually
On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote:
> On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
>> While I've seen a lot of whining about this whole issue, I certainly
>> haven't been seen any effort to actually solve the problem within the
>> existing framework. For example, i
On 10/13/2011 08:02 PM, Mike Frysinger wrote:
> On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
>> While I've seen a lot of whining about this whole issue, I certainly
>> haven't been seen any effort to actually solve the problem within the
>> existing framework. For example, if someone c
On Thu, 13 Oct 2011 11:14:31 -0400
Olivier Crête wrote:
> On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote:
> > On Wed, 12 Oct 2011 23:00:23 +0530
> > Nirbheek Chauhan wrote:
> > > Then please continue with udev in package.mask and kindly stop
> > > trying to impose your workflow on the
On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
> While I've seen a lot of whining about this whole issue, I certainly
> haven't been seen any effort to actually solve the problem within the
> existing framework. For example, if someone cares enough, why not
> write a wrapper script to tr
On 13 October 2011 20:58, Rich Freeman wrote:
> 2011/10/13 Olivier Crête :
>> We're imposing our deep integration because it's the only way to make a
>> compelling platform that "just works", forcing users to tell the
>> computer something the computer already knows is just plain lazy and
>> stupi
On Thursday 13 October 2011 11:17:07 Olivier Crête wrote:
> That said, we, the GNOME upstream, think that having a separate /usr is
> a completely stupid idea.
considering GNOME's track record wrt what they think is a "good idea" in the
UI land, i'm not sure this statement is terribly compelling
2011/10/13 Olivier Crête :
> We're imposing our deep integration because it's the only way to make a
> compelling platform that "just works", forcing users to tell the
> computer something the computer already knows is just plain lazy and
> stupid.
I'd also look at it another way. It is a lot eas
On Wed, 2011-10-12 at 00:40 -0400, Walter Dnes wrote:
> Hi all
>
> Recently, there was a firestorm on the gentoo-user list over the idea
> that udev would eventually require /usr to be on the same physical
> parition as /, or else use initramfs, which is its own can of worms. I'm
> not a program
On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote:
> On Wed, 12 Oct 2011 23:00:23 +0530
> Nirbheek Chauhan wrote:
> > Then please continue with udev in package.mask and kindly stop trying
> > to impose your workflow on the rest of the world.
>
> Isn't the point here that the desktop / GNOM
On 09:09 Wed 12 Oct 2011, Walter Dnes wrote:
> > Goodbye desktop users then.
> >
> > We recently dropped HAL. Now all the magic that was done by HAL (and
> > required udev anyway) is done through udev directly.
>
> My system worked just fine before HAL was introduced, thank you. I
> always had
On Wed, Oct 12, 2011 at 09:09:24AM -0400, Walter Dnes wrote:
> On Wed, Oct 12, 2011 at 05:32:05AM +, Nathan Phillip Brink wrote
>
> > You can already try out what using mdev instead of udev is like in
> > Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use,
> > remerge busybox
On Wednesday 12 October 2011 09:26:12 Rich Freeman wrote:
> On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes wrote:
> > Forking udev is probably not an option. The udev lead developer is a
> > Redhat employee, and his direction seems to be to drag everybody in
> > Redhat's direction. Our community
On Wed, Oct 12, 2011 at 1:49 PM, Ciaran McCreesh
wrote:
> On Wed, 12 Oct 2011 23:00:23 +0530
> Nirbheek Chauhan wrote:
>> Then please continue with udev in package.mask and kindly stop trying
>> to impose your workflow on the rest of the world.
>
> Isn't the point here that the desktop / GNOME OS
On Wed, 12 Oct 2011 23:00:23 +0530
Nirbheek Chauhan wrote:
> Then please continue with udev in package.mask and kindly stop trying
> to impose your workflow on the rest of the world.
Isn't the point here that the desktop / GNOME OS guys are trying to
impose their deep integration, tight coupling
On Wed, Oct 12, 2011 at 6:39 PM, Walter Dnes wrote:
>> Goodbye desktop users then.
>>
>> We recently dropped HAL. Now all the magic that was done by HAL (and
>> required udev anyway) is done through udev directly.
>
> My system worked just fine before HAL was introduced, thank you. I
> always ha
On Wed, 12 Oct 2011 09:09:49 -0400
"Walter Dnes" wrote:
> > Goodbye desktop users then.
> >
> > We recently dropped HAL. Now all the magic that was done by HAL (and
> > required udev anyway) is done through udev directly.
>
> My system worked just fine before HAL was introduced, thank you. I
On Wed, Oct 12, 2011 at 6:09 AM, Walter Dnes wrote:
>> Goodbye desktop users then.
>>
>> We recently dropped HAL. Now all the magic that was done by HAL (and
>> required udev anyway) is done through udev directly.
>
> My system worked just fine before HAL was introduced, thank you. I
> always ha
On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes wrote:
> Forking udev is probably not an option. The udev lead developer is a
> Redhat employee, and his direction seems to be to drag everybody in
> Redhat's direction. Our community doesn't have Redhat's billions.
We should note that RedHat is al
On Tue, Oct 11, 2011 at 10:05:15PM -0700, Zac Medico wrote
> Are you aware of the simple linuxrc approach that I suggested here?
>
> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
Thanks for the pointer. I've got a spare box kicking around that I'll
try this on
> Goodbye desktop users then.
>
> We recently dropped HAL. Now all the magic that was done by HAL (and
> required udev anyway) is done through udev directly.
My system worked just fine before HAL was introduced, thank you. I
always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mas
On Wed, Oct 12, 2011 at 05:32:05AM +, Nathan Phillip Brink wrote
> You can already try out what using mdev instead of udev is like in
> Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use,
> remerge busybox. You must be sure to be using busybox-1.92.2 or later
> for bug #83301
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/12/11 05:40, Walter Dnes wrote:
> Hi all
>
> The other option is to drop udev entirely. As an example, I
> suggest looking at Alpine Linux http://alpinelinux.org/ It's a
> lightweight server-oriented distro. It uses busybox's mdev instead
>
On Wed, 12 Oct 2011 00:40:23 -0400
"Walter Dnes" wrote:
> The other option is to drop udev entirely. As an example, I suggest
> looking at Alpine Linux http://alpinelinux.org/ It's a lightweight
> server-oriented distro. It uses busybox's mdev instead of udev, and
> some other mdev substitut
On Wed, Oct 12, 2011 at 12:40:23AM -0400, Walter Dnes wrote:
> Hi all
>
> Recently, there was a firestorm on the gentoo-user list over the idea
> that udev would eventually require /usr to be on the same physical
> parition as /, or else use initramfs, which is its own can of worms. I'm
> not a
On 10/11/2011 09:40 PM, Walter Dnes wrote:
> Hi all
>
> Recently, there was a firestorm on the gentoo-user list over the idea
> that udev would eventually require /usr to be on the same physical
> parition as /, or else use initramfs, which is its own can of worms. I'm
> not a programmer, let al
Hi all
Recently, there was a firestorm on the gentoo-user list over the idea
that udev would eventually require /usr to be on the same physical
parition as /, or else use initramfs, which is its own can of worms. I'm
not a programmer, let alone a developer. Rather than merely ranting, I
went an
W dniu 02.02.2011 08:59, Nikos Chantziaras pisze:
> It seems that KDE 4.6 is still hard-masked for x86 and amd64 because
> it's waiting for ppc and ppc64 keywords. I believe it would be
> beneficial for people if they wouldn't have to wait for arches that
> don't affect them at all.
>
> It seems
It seems that KDE 4.6 is still hard-masked for x86 and amd64 because
it's waiting for ppc and ppc64 keywords. I believe it would be
beneficial for people if they wouldn't have to wait for arches that
don't affect them at all.
It seems better if the packages can be unmasked for x86 and amd64 a
On Thu, 17 Jun 2010 14:04:42 +0200
Pacho Ramos wrote:
> In that case, could you then consider to un-CC from keywording bugs
> hppa team is not willing to fix? I think it would help a lot to
> "clean" the tree of old versions that are been kept as it's the inly
> keyworded on hppa
Sounds like a p
El jue, 17-06-2010 a las 06:07 +0200, Jeroen Roovers escribió:
> On Fri, 11 Jun 2010 07:39:01 -0400
> Joseph Jezak wrote:
>
> > Your preferred method is exactly how (as a ppc keyworder) I like to
> > see these kind of bugs handled. Dropping keywords makes an awful lot
> > more work for us and hur
On Fri, 11 Jun 2010 07:39:01 -0400
Joseph Jezak wrote:
> Your preferred method is exactly how (as a ppc keyworder) I like to
> see these kind of bugs handled. Dropping keywords makes an awful lot
> more work for us and hurts our users, especially since we're not
> always very prompt at handling b
El lun, 14-06-2010 a las 11:30 +0200, Jeroen Roovers escribió:
> On Mon, 14 Jun 2010 10:08:58 +0200
> Pacho Ramos wrote:
>
> > The problem is that, at least regarding gnome related bugs, there are
> > a lot of keywords dropped for your arch that could be prevented
> > use.masking an USE, like, fo
On Mon, 14 Jun 2010 10:08:58 +0200
Pacho Ramos wrote:
> The problem is that, at least regarding gnome related bugs, there are
> a lot of keywords dropped for your arch that could be prevented
> use.masking an USE, like, for example, dev-util/anjuta-2.28*, that is
> causing us to preserve and old
On 14.6.2010 5.59, Jeroen Roovers wrote:
> On Mon, 14 Jun 2010 00:29:19 +0200
> Pacho Ramos wrote:
>
>> El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió:
>>> El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió:
On 06/11/2010 12:27 PM, Pacho Ramos wrote:
>
> Fro
El lun, 14-06-2010 a las 04:59 +0200, Jeroen Roovers escribió:
> What is the problem? The files in place ask you to file a bug report
> instead of fiddling with the files yourselves. I put that in place
> because I got (fucking) tired of seeing the after effects of people
> fiddling with the arch p
On Mon, 14 Jun 2010 00:29:19 +0200
Pacho Ramos wrote:
> El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió:
> > El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió:
> > > On 06/11/2010 12:27 PM, Pacho Ramos wrote:
> > >
> > > >
> > > > From my point of view, I would prefer to:
>
El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió:
> El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió:
> > On 06/11/2010 12:27 PM, Pacho Ramos wrote:
> >
> > >
> > > From my point of view, I would prefer to:
> > > 1. Mask "caps" for net-wireless/bluez on affected arches, letti
El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió:
> On 06/11/2010 12:27 PM, Pacho Ramos wrote:
>
> >
> > From my point of view, I would prefer to:
> > 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to
> > keep bluez keyworded.
> > 2. Open two bug reports as done w
On 06/11/2010 12:27 PM, Pacho Ramos wrote:
>
> From my point of view, I would prefer to:
> 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to
> keep bluez keyworded.
> 2. Open two bug reports as done with current policy: one for keywording
> libcap-ng and other to check bluez
2010/6/10 Pacho Ramos:
> El jue, 10-06-2010 a las 12:23 -0600, Joe Peterson escribió:
>> I think a better solution, if we need to indicate this, is to have
>> bugzilla grab the status from devaway and display it next to the dev's
>> name in bug reports. Changing the user's name seems a bit cumbers
>
> Hello
>
> Let my explain the problem and my suggestion to handle it better (at
> least from my point of view) with an example:
>
> Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that
> bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added.
> Since libcap-ng was not
Pacho Ramos said:
> Hello
>
> Let my explain the problem and my suggestion to handle it better (at
> least from my point of view) with an example:
>
> Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that
> bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added.
> Since
Hello
Let my explain the problem and my suggestion to handle it better (at
least from my point of view) with an example:
Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that
bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added.
Since libcap-ng was not keyworded in all
1 - 100 of 178 matches
Mail list logo
