[gentoo-dev] [SECURITY] Minimizing the suid usage
Hello All, linux-2.6.24 supports file based capabilities via: CONFIG_SECURITY_FILE_CAPABILITIES This enables the use of filesystem attributes in order to store per executable capabilities list, more information at [1]. This enables improved security level for people who don't wish to move into SELinux or similar. I think a new global USE flags (or use current caps) may enable ebuilds to set correct capabilities on files. On my system at least: ping, ping6, tcpdump, wireshark, samba, ntpd, rlogin, vmware may enjoy this and drop the root suid. In order to make it simple for everybody, a new eclass may be introduced to force dependency on >=libcap-2 and provide some atoms. This will provide more secured installation for users with a little effort, less usage of root user. What do you think? Alon. [1] http://www.friedhoff.org/fscaps.html -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/23/08, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 23 Mar 2008 20:21:29 +0200 > "Alon Bar-Lev" <[EMAIL PROTECTED]> wrote: > > linux-2.6.24 supports file based capabilities via: > > CONFIG_SECURITY_FILE_CAPABILITIES > > > > > This will provide more secured installation for users with a little > > effort, less usage of root user. > > > > What do you think? > > > Needs package manager support. Effectively this requires an EAPI bump, > since ebuilds need to know whether they can rely upon caps being > preserved across a merge or whether they have to degrade to a setuid > bit. Why? A simple USE flag should be enough, if set use caps, if not use current. Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/23/08, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > Why? A simple USE flag should be enough, if set use caps, if not use > > current. > > > A user turns the use flag on, the ebuild creates files using caps > rather than set*id, the package manager merges it by copying the file > and the installed file ends up with no caps and no set*id bit. File system attributes already supported for selinux. I also checked this with capabilities and it works with portage. Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/24/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > Diego and i were talking ... we're going to go with USE=filecaps because it's > so new and doesnt require the libcap library in order to work at runtime. > probably be worthwhile to put together a little eclass of functions to make > people's lives easier ... Great!!! You write eclass, me start patching ebuilds and open bugs against maintainers :) Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/24/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > how much do we want to help the user ? if they have USE=filecaps, then dont > perform any checking ? we'll need a kernel with file capabilities turned on, > otherwise the prog wont work unless it's setuid ... so do we perform checking > and drop the setuid bit on the post sly ? i'd prefer we just make the > filecaps desc verbose: dont set this unless you have new enough kernel with > options enabled, otherwise things may stop working properly as non-root. I also prefer descriptive warning and not runtime checks. Worse case scenario, system will be usable for root only. root can remove this USE flag and emerge --update --deep --newuse world. Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New global USE flag: keyring
This may be confusing with Linux key store. I suggest gnome-something as it is gnome feature. Alon On Sun, Apr 20, 2008 at 5:45 PM, Peter Weller <[EMAIL PROTECTED]> wrote: > Unless anyone has any objections, I'll magically turn 'keyring' into a > global USE flag tomorrow evening: > > [EMAIL PROTECTED] ~/gentoo/cvs/gentoo-x86/profiles $ grep ':keyring' > use.local.desc > app-crypt/seahorse:keyring - Enable gnome-keyring support for storing > passwords > app-text/evince:keyring - Enable gnome-keyring support for storing > passwords > gnome-base/gvfs:keyring - Enable gnome-keyring support for storing > passwords > gnome-extra/evolution-data-server:keyring - Enable gnome-keyring support > for storing passwords > media-sound/rhythmbox:keyring - Enable gnome-keyring support for storing > passwords > net-im/gossip:keyring - Enable gnome-keyring support for storing > passwords > net-im/telepathy-mission-control:keyring - Enable gnome-keyring support > for storing passwords > net-misc/twitux:keyring - Enable gnome-keyring support for storing > passwords > net-misc/vino:keyring - Enable gnome-keyring support for storing > passwords > [EMAIL PROTECTED] ~/gentoo/cvs/gentoo-x86/profiles $ > > -- > gentoo-dev@lists.gentoo.org mailing list > > -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: New global USE flag: keyring
2008/4/20 Peter Weller <[EMAIL PROTECTED]>: > On Sun, 2008-04-20 at 18:32 +0300, Ali Polatel wrote: > > Alon Bar-Lev yazmış: > > > I suggest gnome-something as it is gnome feature. > > > > How about gnome-keyring? :) > > > > Why? All the ebuilds currently using the 'keyring' use flag are using it > for gnome-keyring. As long as there is a proper description of the USE > flag, there should be no confusion caused. Because it may be confusing. As long as it is local flag for gnome packages, the gnome is implicit. If you want it to be global, gnome should be explicit. Alon
Re: [gentoo-dev] Re: Re: New global USE flag: keyring
On Sun, Apr 20, 2008 at 7:06 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > I'd say we should convert it to a global use flag now with a good > description and change it to gnome-keyring later in case we really have a > package which needs 'keyring' for something else. If we know there may be a future problem, why make the next *VALID* addition perform extra work? This is gnome specific feature, should have gnome explicit mark. If we have keyring in KDE, or keyring in kernel or any other "generic" keyring. The extra work should be done now, so we have less conflict in future. Alon ���^�X��� ��(��&j)b�b�
Re: [gentoo-dev] New global USE flag: keyring
On 4/20/08, Gilles Dartiguelongue <[EMAIL PROTECTED]> wrote: > for what it's worth, as a gnome dev I didn't see any convincing > arguments as to why it should be renamed. Gnome makes things optional > for other to reuse (like xfce) but afaik no other "keyring" like > programs are optional deps of another package in portage. Let's not cast > a simple change into breakage for users already using it (even in > stable, and yes I'm lazy :D). Lazy is the word. I cannot argue with this one, I just know that it won't be the gnome herd who do the work when the time come to fix this (resolve conflict). The gnome herd will re-introduce the lazy ticket, and make other herd use yet another confusing USE flag. This is not the right way to maintain long term constants. You asked for objections... You got some. You can leave this local USE flag, and stay with generic term. Or you can rename it when it goes global so it have proper name. You can also ignore this and force gnome onto all users. Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 4/30/08, Denis Dupeyron <[EMAIL PROTECTED]> wrote: > It's my pleasure to introduce Markus Duft (mduft) as a new developer. > He will go among us under the name of mduft, and will work in the > Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that > means Gentoo on Win32. Welcome! I will love to see Windows support via cygwin and not commartial product. Something like [1], [2]. Alon. [1] http://gentoocygwin.sourceforge.net/ [2] http://gentoo-wiki.com/HOWTO_Gentoo_on_Cygwin -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 4/30/08, Fabian Groffen <[EMAIL PROTECTED]> wrote: > On 30-04-2008 19:51:42 +0300, Alon Bar-Lev wrote: > > On 4/30/08, Denis Dupeyron <[EMAIL PROTECTED]> wrote: > > > It's my pleasure to introduce Markus Duft (mduft) as a new developer. > > > He will go among us under the name of mduft, and will work in the > > > Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that > > > means Gentoo on Win32. > > > > Welcome! > > > > I will love to see Windows support via cygwin and not commartial product. > > Something like [1], [2]. > > > Interix is free and these days bundled with Windwows, IIRC. I couldn't understand it from [1], anyway the source is unavailable right? > Why do you want it to run on Cygwin? (Honest question...) It is the only project I know providing good support for POSIX Windows platform while having Open Source license. But if you are correct and a good POSIX layer is provided built-in in Windows, I will be happy to see stage3 for Windows. Alon. [1] http://www.interix.com/products_services.htm -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 4/30/08, Fabian Groffen <[EMAIL PROTECTED]> wrote: > I think in that sense Cygwin is more Open Source, because how you get > the primary shell/environment is available too. However, for me that > doesn't matter, as the OS itself is inherently non-free in that sense, > so that's what you have to accept first thing anyway. I separate operating system and applications... Just like you run on HPUX or AIX... There is Windows. > Just for your information, we don't do stages at the moment, not in the > forseeable future from my point of view either. Binpkgs are in the > planning. In general we just do a full bootstrap, on Interix you need > extra help from "prefix-launcher". This is sad... I would really like to see fully operating portage on Windows... It was more important to me in the past when I actually used this OS... I this sense [1] was a great idea! You could always use quickpkg to extract binaries. Alon. [1] http://gentoocygwin.sourceforge.net/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: qemu -> add gcc-3.x dependency
On 5/5/08, Jan Kundrát <[EMAIL PROTECTED]> wrote: > Hi Enrico, it is usually a good idea to search through the Bugzilla before > asking for some feature, chances are that it has been already requested (in > this case, you're looking for bug 190102). FYI, at least some of qemu's > features were ported to gcc4 -- for example, see the kvm-qemu ebuild from > bug 157987. I also waiting for gcc-4 enabled qemu for long time... The problem that "emerge --emptytree world" will not work when packages are compiled in different gcc versions. The kvm-qemu is not relevant if you don't have the hardware. One solution I saw is to compile gcc-3 as part of the qemu build process, and make the qemu use this gcc-3 instance. This way you can have qemu up and running while the system is configured for gcc-4. It is very disappointing that upstream does not allow gcc-4 configuration so long after gcc-4 release. Alon.
[gentoo-dev] Goodbye
Hello, I guess I am tired of fighting with people here. I am too old for this crap. There are few brutal developers here that make Gentoo a terrible place to be. Well... I can handle few developers, but when devrel enters the picture with arguments such as "volunteers can do crappy job as long as they have fun" enough is enough. I signed-up to work on distribution if I have fun in the process it is great! But always keep in mind the delivery I provide to users. Gentoo has some fundamental issues, the obvious one is lack of leadership. There is *NOBODY* that formally responsible or cares about the delivery Gentoo (AS A WHOLE) provide to its users. The council is just a political body that discuss the void issues. As a result the laud and brutal developers dictate the tune. With no proper mechanism to decide if a decision that was taken aligns with Gentoo goals. The devrel process is ridiculous, as proxy between developers without ability to determine anything does not help anyone. During the short time I was around Gentoo lost some of the best developers that were around, due to similar reasons. If Gentoo community cannot provide its own goals, at least it should embrace standards. Compliant to standards may resolve many conflicts. Roy worked hard to make Gentoo POSIX shell compliant, but this was not accepted, but imagine fully Gentoo work with busybox based system, isn't this an advantage we have? especially on small systems. I appreciate flameeyes work on reducing the system size, I am aware how hard it is. There are new violations of HFS in Gentoo, but nobody cares. Jacub, one of the best developers around that actually cared about the service we provide to our users was suspended while trying to do so, and now he is not active anymore. There are some more examples... The brutal developers remain, the quiet leave. Gentoo is built on a lot of inexperienced students, but the backbone of core developers with real-life experience is very weak. I think that current approach of the developers community will not able to resolve this, as a result Gentoo community will not mature. Gentoo has a great piece of technology (portage), this is unique and with the right leadership may be the tool to make Gentoo more stable and popular, as a result extending the user community and gain more resources. But leadership derives goals, goals derive complaint, complaint derives means of enforcement. None of these currently available in the community. Personal note on leadership: vapier - you are good, so good that many envy you. But this does not give you the right to not being nice. You are on of the few people here that can take at least partially resolve the leadership issue. With a little patience and care. (Just to make it clear: I am not leaving because of vapier). Packages to reassign: mobile: dev-libs/libx86 sys-power/suspend sys-power/hibernate-script antivirus ./sys-fs/dazuko misc: net-misc/openvpn media-sound/mp3unicode I am available at email:[EMAIL PROTECTED] Have fun, Alon. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] dev-libs/engine_pkcs11 masked for removal in 30 days
Replaced by dev-libs/libp11 unmaintained by upstream. Bug#609668. Removal in 30 days.
[gentoo-dev] gnutls-3.5 last remaining issues - please assist
Hello, I would like to push gnutls-3.5 into stable per[1]. Below are known related issues we still have, please help to push these forward. If anyone wishes to help testing before we progress, please move to non-stable gnutls and report back any issue. Please also emerge using the following settings and report back any failure: USE="test-full" FEATURES="test" emerge gnutls Thanks, Alon [1] https://bugs.gentoo.org/showdependencytree.cgi?id=612340&hide_resolved=1 --- url: https://bugs.gentoo.org/show_bug.cgi?id=595952 desc: net-libs/glib-networking-2.48.2 with net-libs/gnutls-3.5.4[-sslv3] fails test... owner: gnome If it is only test issue, we should disable the test. url: https://bugs.gentoo.org/show_bug.cgi?id=613418 desc: net-libs/gnutls-3.5.10 fails cert-key-exchange tests on sparc owner: sparc We have outage of sparc machine, if anyone with sparc can help it would be great. url: https://bugs.gentoo.org/show_bug.cgi?id=615008 desc: =sys-devel/autogen-5.18.4 - please add slot operator for guile owner: toolchain As the guile tests requires guile-2, it will be nice if we can have this to allow seamless upgrade/downgrade of guile without experiencing autogen issues. url: https://bugs.gentoo.org/show_bug.cgi?id=612348 desc: =app-admin/gkrellm-2.3.10 stable request owner: hppa, ia64, sparc gnutls-3.5 compatibility url: https://bugs.gentoo.org/show_bug.cgi?id=612344 desc: =mail-client/cone-0.92 stable request owner: ppc gnutls-3.5 compatibility url: https://bugs.gentoo.org/show_bug.cgi?id=391463 desc: Please stabilize =dev-libs/iksemel-1.4 owner: ppc gnutls-3.5 compatibility, a patch is available to fix test failure on ppc.
Re: [gentoo-dev] mingw-w64 crossdev prefix?
Hi, You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or crossdev -t i686-w64-mingw32 Alon On 18 May 2017 at 01:25, Marty Plummer wrote: > > Greetings, > > So, I'm a relatively new gentoo user (as of 2016-12) coming from arch, > and one thing I've noticed is the relative difficulty of setting up a > mingw-w64 cross-compile toolchain and libraries. > > I'm considering the idea of setting up a sort of prefix specifically > with the intent of being used on a 'normal' gentoo system with the sole > purpose of creating 'normal' windows binaries; does anyone have > suggestions/objections about the idea? > > As it currently stands I have to use an archlinux chroot to do my > cross-compiling, and I'd really enjoy to be able to do this sort of > thing without depending on an auxiliary distro. > > Marty. >
Re: [gentoo-dev] mingw-w64 crossdev prefix?
On 18 May 2017 at 06:46, Matthias Maier wrote: > [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set > EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the > cross-x86_64-w64-mingw32/gcc package. Hi, You should use the USE flags and not apply such workarounds, for example: USE="-sanitizer" crossdev ... Alon
Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine
On 18 May 2017 at 06:54, Marty Plummer wrote: > Greetings, > > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32 > target via crossdev ends up calling wine to run checks, which fails with > an access violation, and as such emerge cannot finish. > > Would it be an acceptable change to disable emake check for mingw-w64 > crossdev targets? > Why do you enable tests?
Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine
On 18 May 2017 at 07:10, Marty Plummer wrote: > On Thu, May 18, 2017 at 06:53:48AM +0300, Alon Bar-Lev wrote: >> On 18 May 2017 at 06:54, Marty Plummer wrote: >> > Greetings, >> > >> > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32 >> > target via crossdev ends up calling wine to run checks, which fails with >> > an access violation, and as such emerge cannot finish. >> > >> > Would it be an acceptable change to disable emake check for mingw-w64 >> > crossdev targets? >> > >> >> Why do you enable tests? >> > I did not, there is no use flag for dev-libs/libressl I can use to > disable tests. if there is a global flag I should disable, I'd be > greatly appreciative of it. > If you enable tests globally, then you can disable them for a specific build using: FEATURES="-test" emerge ...
[gentoo-dev] Call for help in testing - sparc + gnutls-3.5
Hello, I am looking for someone that is using gentoo on sparc and is willing to help out to resolve an issue[1] of gnutls-3.5 with sparc so that we can drop gnutls-3.3 from tree. I tried to create a bootable sparc qemu gentoo image and failed, so need someone with a live system. Regards, Alon [1] https://bugs.gentoo.org/show_bug.cgi?id=613418
[gentoo-dev] sys-auth/pam_pkcs11 masked for removal in 30 days
Upstream no longer maintain (Bug#628908). Removal in 30 days.
[gentoo-dev] dev-libs/cryptlib masked for removal in 30 days
Complex build system, hard to maintain, no dependencies in tree, upstream does not cooperate (Bug#630420). Removal in 30 days.
Re: [gentoo-dev] dev-libs/cryptlib masked for removal in 30 days
On 8 September 2017 at 22:44, R0b0t1 wrote: > > On Fri, Sep 8, 2017 at 2:40 PM, Alon Bar-Lev wrote: > > Complex build system, hard to maintain, no dependencies in tree, upstream > > does not cooperate (Bug#630420). > > Removal in 30 days. > > > > I don't have any reason to disagree with this but I expected a > citation for those things to be in the bug you referenced. They're > not, and I don't see any bugs on the tracker. The effort of upgrade per each version is becoming greater. Previous and next versions required significant work, issues reported to upstream with the hope of a change, but most is rejected. The build system is so complex that is specific to gcc/ld and hard-coded dependencies locations and cflags/ldflags magic. Unless we have a very good reason (important dependency), my suggestion is to drop it. Do we have such a reason?
[gentoo-dev] profiles 17.0 hardened/no-multilib missing?
Hi, Any reason we do not publish hardened/no-multilib? I see we have[1] in place and is working if explicitly added. Thanks, Alon [1] profiles/features/hardened/amd64/no-multilib
Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?
On 2 December 2017 at 23:08, Michał Górny wrote: > > W dniu sob, 02.12.2017 o godzinie 22∶43 +0200, użytkownik Alon Bar-Lev > napisał: > > Hi, > > Any reason we do not publish hardened/no-multilib? > > I see we have[1] in place and is working if explicitly added. > > > > One reason might be that: Thanks. > > 1) there's barely any use for it, Well, I think that whoever use hardened barely use multilib. > 2) we have too many profiles, and This has not stopped us so far. > 3) every added profile slows down repoman & pkgcheck seriously. Only when using '-d', no? Anyway, probably the default of hardened should be multilib so we end up with the same number. > > [1] profiles/features/hardened/amd64/no-multilib Regards, Alon
Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)
Hi, On 25 January 2018 at 14:35, Michał Górny wrote: > > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic > verification of the Gentoo rsync repository distributed over rsync > by default. This aims to prevent malicious third parties from altering > the contents of the ebuild repository received by our users. I did not looked into the detailed implementation, however, please make sure integrity check handles the same cases we have applied to emerge-webrsync in the past, including: 1. Fast forward only in time, this is required to avoid hacker to redirect into older portage to install vulnerabilities that were approved at that time. 2. Content integrity, especially removal, as far as I understand, the mechanism will not enable to detect authorized removal of content. Regards, Alon
Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)
On 26 January 2018 at 00:21, Robin H. Johnson wrote: > On Thu, Jan 25, 2018 at 11:55:58PM +0200, Alon Bar-Lev wrote: >> I did not looked into the detailed implementation, however, please >> make sure integrity check handles the same cases we have applied to >> emerge-webrsync in the past, including: > Gemato is the implementation of GLEP74/MetaManifest, which DOES > explicitly address both of these concerns. Good! Thanks. > >> 1. Fast forward only in time, this is required to avoid hacker to >> redirect into older portage to install vulnerabilities that were >> approved at that time. > Replay attacks per #1 are addressed via TIMESTAMP field in MetaManifest. Interesting, I tried again to understand how it is working without performing rsync to a temporary directory, compare the timestamp and reject if unexpected. Are we doing multiple rsync for the metadata? Long since I used this insecure rsync... For me it seems like webrsync and/or squashfs are much easier/faster to apply integrity into than rsync... :) Regards, Alon
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 9 February 2016 at 13:59, Rich Freeman wrote: > > On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile > wrote: > > On 2/8/16 10:09 PM, Rich Freeman wrote: > >> How many of those 14 distros have more than 14 users? > > > > gentoo is very unpopular as a distro. however, it excels as a meta > > distro. if you marginalize its special features, you take away all its > > charm. > > The controversy comes in when you want to make it a default, and start > arguing that it is somehow better than the solution everybody else is > using. > > Outside of Gentoo people either aren't concerned at all with eudev (it > probably isn't even in their distro repositories), or they're a tiny > distro whose main purpose in life seems to be to avoid installing > systemd. Of course you're going to get praise from them. > > I've always supported having eudev hosted by Gentoo. I just don't > support it being the default udev provider. > I too support eudev as default for openrc people, Gentoo is about choice, and OpenRC eco-system should get rid of all systemd related dependencies. This is a choice we provide. eudev should stand as its own and provide a service for the non-systemd users, these users actually care about what we provide, Gentoo is one of the last distros that enables that. I use eudev since its first beta, and these guys provides good service. I also mask all systemd files that somehow find their way into my system thanks to your past decisions as systemd supporter, instead of installing these only when systemd USE flag is set and adding openrc USE flag for the systemd users folks. It may in future that udev will completely relay on systemd and we left with eudev as the only choice for non systemd-eco system, it is better to start building this eco-system now, make sure we have a working solution at any given point in time. Alon
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 14 February 2016 at 22:23, Mike Frysinger wrote: > udev: it's the default in every major distro that everyone tests and > develops against. > > eudev: no one of any relevance outside of Gentoo runs it. I honestly don't understand this argument that pops over and over. No "major distro" using udev without systemd, so OpenRC people are already using udev in unsupported setup. Better to use a tool that is tested and supported in this setup. Or maybe I do not understand and mission is for us to switch to systemd? Systemd users/developers should not mind what the default is as they are forced to use one variant anyway, these users/developers should not force their opinion upon others. Thanks, Alon
Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support
On 20 April 2016 at 18:52, Ian Stakenvicius wrote: > > Hi everyone: > > After doing some experimentation with a mingw crossdev, I found that I > needed to do a lot of EXTRA_ECONF settings in combination with > USE="aqua" in order to get packages supporting a win32 API to be > configured appropriately. In order to support this situation better, > I propose adding a new global flag 'win32', modelled after the 'aqua' > flag, that can be used instead to provide this configuration directly > in ebuilds. > > Just like USE="aqua", the flag will be use.mask'ed in base/ so that > users don't erroneously enable it. I didn't un-use.mask it anywhere > yet since (A) I don't have a prefix/windows environment to test, and > (B) the mingw-based crossdev environments use profiles/embedded by > default, which doesn't inherit from profiles/base and so doesn't have > the use.mask restriction. > > The attached patch lists the necessary changes to profile/ as well as > the addition of USE=win32 to *ONE VERSION* of gtk+:2, gtk+:3 and cairo > (the actual commit will include more versions). > > Comments? You should be able to achieve similar behavior by looking at libc and/or CHOST without introducing new USE flag, just like we do for aix/solaris/freebsd etc...
Re: [gentoo-dev] dev-util/nsis: Maintainer request
Hi, I've revbumped this package. Regards, Alon On 6 June 2016 at 03:23, M. J. Everitt wrote: > On 05/06/16 22:55, Kristian Fiskerstrand wrote: >> dev-util/nsis curretly has no maintainer. It has a [critical security >> bug filed against it]. Does anyone want to pick it up? if not we'll >> start a last rite process for it. >> >> [critical security bug filed against it] >> https://bugs.gentoo.org/show_bug.cgi?id=568398 > Per conversation in #g-p-m I'll take this on via proxy if nobody else > volunteers in the next 7 days (w/e 12th June) to start with, as I'm > pretty sure a colleague is using it on a project, and we could do > without losing it from the tree .. ! > > Quick glance at the project page, and bug suggests revbump, stabilise > and drop old version might cure the existing issue, but will investigate > further. > Cheers, > Michael. >
Re: [gentoo-dev] dev-util/nsis: Maintainer request
Can you please check it out? I had no time nor setup. On 12 June 2016 at 14:49, M. J. Everitt wrote: > Cheers Alon, > > Michael. > On 12/06/16 12:43, Alon Bar-Lev wrote: >> Hi, >> I've revbumped this package. >> Regards, >> Alon >> >> On 6 June 2016 at 03:23, M. J. Everitt wrote: >>> On 05/06/16 22:55, Kristian Fiskerstrand wrote: >>>> dev-util/nsis curretly has no maintainer. It has a [critical security >>>> bug filed against it]. Does anyone want to pick it up? if not we'll >>>> start a last rite process for it. >>>> >>>> [critical security bug filed against it] >>>> https://bugs.gentoo.org/show_bug.cgi?id=568398 >>> Per conversation in #g-p-m I'll take this on via proxy if nobody else >>> volunteers in the next 7 days (w/e 12th June) to start with, as I'm >>> pretty sure a colleague is using it on a project, and we could do >>> without losing it from the tree .. ! >>> >>> Quick glance at the project page, and bug suggests revbump, stabilise >>> and drop old version might cure the existing issue, but will investigate >>> further. >>> Cheers, >>> Michael. >>> > >
Re: [gentoo-dev] Last rites: kde-apps/ksnapshot
Just tried to switch. Print-Screen shortcut is not working, any idea why? Saw some similar issues, but could not find out what is wrong as most of the fixes are embedded. Thanks! On 14 July 2016 at 20:33, Johannes Huber wrote: > > # Johannes Huber (14 Jul 2016) > # No longer released upstream. Use kde-apps/spectacle instead. > # Masked for removal in 30 days. > kde-apps/ksnapshot
Re: [gentoo-dev] Last rites: kde-apps/ksnapshot
I have only three: Application, Global, Web Shouldn't it be integrated into Global? On 14 July 2016 at 21:44, Johannes Huber wrote: > Please check systemsettings -> shortcuts -> 4th tab. > > Greetings, > Johannes > > Am Donnerstag 14 Juli 2016, 21:26:04 schrieb Alon Bar-Lev: >> Just tried to switch. >> Print-Screen shortcut is not working, any idea why? >> Saw some similar issues, but could not find out what is wrong as most >> of the fixes are embedded. >> Thanks! >> >> On 14 July 2016 at 20:33, Johannes Huber wrote: >> > # Johannes Huber (14 Jul 2016) >> > # No longer released upstream. Use kde-apps/spectacle instead. >> > # Masked for removal in 30 days. >> > kde-apps/ksnapshot > >
Re: [gentoo-dev] Last rites: kde-apps/ksnapshot
On 14 July 2016 at 23:15, Johannes Huber wrote: > Am Donnerstag 14 Juli 2016, 21:47:10 schrieb Alon Bar-Lev: >> I have only three: Application, Global, Web >> Shouldn't it be integrated into Global? > > Maybe this helps: > https://bbs.archlinux.org/viewtopic.php?id=206600 yes, I saw that, I thought it is older version of plasma as. I tried to installed khotkeys before I sent my question and it did not show the new tab, now I tried again just to make sure and it does, strange. When I installed it it created the ~/.config/khotkeysrc without the spectacle profile, I had to remove it logout/login in order to make it work. please consider making khotkeys a dependency of spectacle. Regards, Alon
[gentoo-dev] app-crypt/bcrypt package masked for removal in 30 days
# Weak cryptography (bug #592114) # Package will be removed from Gentoo in 30 days. app-crypt/bcrypt
[gentoo-dev] app-crypt/scl011-bin package masked for removal in 30 days
# No upstream, no maintainer (bug #592164) # Package will be removed from Gentoo in 30 days. app-crypt/scl011-bin
[gentoo-dev] dev-python/pssi package masked for removal in 30 days
# Alon Bar-Lev (05 Nov 2016) # Masked for removal in 30 days, bug#598982. # Upstream does not publish releases, no tags, last publish is on # google code, no dependencies. dev-python/pssi
Re: [gentoo-dev] RFC: Future EAPI version operator changes
On 6 November 2016 at 12:52, Michał Górny wrote: > Hi, everyone. > So, what are your comments? Hi, Just my 2 cents... I kinda love the prefix nature of the expressions which is consistent and easier to parse. Using infix only for versions and leaving all the rest prefix will create abnormality. Regards, Alon
[gentoo-dev] net-misc/gnutls-3.4 stabilization
Hi, I would like to start stabilizing gnutls-3.4. If anyone is aware of an issue please speak up. Thanks! Alon
Re: [gentoo-dev] OpenRc-0.12 and gentoo-oldnet-0.1 keywording question
On Sun, Aug 4, 2013 at 12:44 AM, William Hubbs wrote: > All, > > one thing that is going to be different about OpenRc-0.12 is the oldnet > scripts (net.* and /lib*/rc/net/*) are going to be split out into their > own package, gentoo-oldnet-0.1. This will be brought in by a pdepend > initially to make sure everyone who doesn't have newnet gets the > package. Hi, I do understand why Roy refer this as oldnet... but why in Gentoo do we keep the term old? The functionality of these script is huge, and is better than most distros out there. Do we want keep users out of it? are we going to obsolete this huge work? If we don't I suggest to remove the 'old' implication, to something like openrc-gentoo-net. Regards, Alon Bar-Lev.
Re: [gentoo-dev] renaming gentoo-oldnet
On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs wrote: > Hi all, > > I'm splitting the thread because this is a separate subject. > > On Sun, Aug 04, 2013 at 12:59:56AM +0300, Alon Bar-Lev wrote: >> I do understand why Roy refer this as oldnet... but why in Gentoo do >> we keep the term old? The functionality of these script is huge, and >> is better than most distros out there. Do we want keep users out of >> it? are we going to obsolete this huge work? If we don't I suggest to >> remove the 'old' implication, to something like openrc-gentoo-net. > > Actually the plan is to generalize it so that it works with other init > systems. Right now it is very tightly integrated with OpenRc, but there > is interest in changing that, so adding openrc to the name would be > misleading eventually. OK... so gentoo-networking? or just come up with own name? best-networking? However, I do not understand how you can port it without changing the notations... or lowering features... example: rc_net_*_provide, rc_net_*_need, or the rc_config, rc_use, rc_net_*_provide="!net" etc... Do you think systemd users can understand that /etc/conf.d/net is actually a shell script? I hope this is not going to be eliminated, as I use it a lot. Regards, Alon Bar-Lev.
Re: [gentoo-dev] renaming gentoo-oldnet
On Sun, Aug 4, 2013 at 11:37 PM, William Hubbs wrote: > > Doug and Brian, I'm going to reply in a little more detail. > > On Sat, Aug 03, 2013 at 07:38:04PM -0700, Brian Dolbec wrote: > > On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: > > > On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs wrote: > > > > On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: > > > >> On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs > > > >> wrote: > > > > > >> OK... so gentoo-networking? or just come up with own name? > > > >> best-networking? > > > > > > > > > You and I have had this talk more times than I can remember at this > > > point. Using the name "oldnet" sucks and was one of the worst choices > > > possible. Looking through our IRC chats, I had also suggested > > > gentoo-networking. > > I thought about gentoo-networking, but that sucks in a way too because > it implies that everyone on gentoo should be using it. > > That's not quite right because we have at least five network stacks I > can think of off the top of my head, and OpenRc upstream supports > another. > > - OpenRc upstream supports newnet, which I have played with, and I > believe people on Gentoo are using successfully. > - what we have been calling the oldnet stack, which most gentoo users > have been using. > - dhcpcd in standalone mode. > - wicd > - NetworkManager > - badvpn I do not understand... the 'old net' which is actually gentoo networking for years, are fully functional script to manage and create a lot of configurations, and one of the advantages we have at Gentoo over other distributions. The only reason why this is called old net is because Roy switched to *BSD. What you call new net requires vast knowledge in network tools usage and interaction, which makes life very difficult. Some examples I managed to document: http://alonbl.tropicalwikis.com/wiki/Gentoo/Firewall_Using_Firehol http://alonbl.tropicalwikis.com/wiki/Gentoo/OpenVPN_Server http://alonbl.tropicalwikis.com/wiki/Gentoo/OpenVPN_Non_Root http://alonbl.tropicalwikis.com/wiki/Gentoo/Vpnc_Non_Root http://alonbl.tropicalwikis.com/wiki/Gentoo/VM_Tap_Networking http://alonbl.tropicalwikis.com/wiki/Gentoo/PPP_Client http://alonbl.tropicalwikis.com/wiki/Gentoo/PPPoE_Client > As I have said before, none of this is an attempt to kill or deprecate > anything. It is just re-arranging things by moving the old gentoo > network stack into its own package. There are no plans to stop you from > using it if you want to use it. There is definitely nothing being said > here about the state of OpenRc in general. >From behind the words it indeed looks like there is a change coming. Alon
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani wrote: > Moreover, the lvm problem is caused by a very ancient and ill decision > about doing what upstream tells you to avoid: have mdev in the > initramfs and udev on the final pivot rooted system. This was just > looking for troubles but the smarties at the time decided that they > knew better... And now, tadam, the bug is served... > People can use genkernel-next, which comes with _proper_ udev support > (see --udev). I won't comment about the entire gnome monolithic windows like, vendor controlled system that we cooperate with. But the above statement is way too much... there should be nothing wrong in having mdev during boot. initramfs should be simple as possible and busybox provides this functionality well. The problem is in udev not in any other component, that probably expects now to run first and have total control over the boot process. I hope eudev does not suffer from this. If genkernel will start using udev instead of busybox, it will probably be the last day of me use it. I am just waiting for the point in which you claim that systemd should be run at initramfs, because of the dependency lock-in, so you have almost the entire system within initramfs. Regards, Alon
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman wrote: > Stability is about the quality of the ebuilds and the user experience > in general. It is not a statement that all Gentoo developers think > that the package is useful. Many would say that nobody should be > using MySQL/MariaDB for production work, but that has nothing to do > with its stability as a package either. This is not entirely correct. If from now on, a bug with systemd of new version of a package blocks that package stabilization, it means that all developers must support systemd. So having systemd stable is a decision that should be made by the entire community, and have huge overhead on us all. So apart of the politic message, there are implications of maintenance efforts, stabilization efforts. I appreciate the discussion at debian, it is not wise to support [I am adding: at stable] more than one solution for layout. Regards, Alon Bar-Lev.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen wrote: > On 08/08/13 20:57, Alon Bar-Lev wrote: >> >> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman wrote: >>> >>> Stability is about the quality of the ebuilds and the user experience >>> in general. It is not a statement that all Gentoo developers think >>> that the package is useful. Many would say that nobody should be >>> using MySQL/MariaDB for production work, but that has nothing to do >>> with its stability as a package either. >> >> >> This is not entirely correct. >> >> If from now on, a bug with systemd of new version of a package blocks >> that package stabilization, it means that all developers must support >> systemd. So having systemd stable is a decision that should be made by >> the entire community, and have huge overhead on us all. > > > That's not really true with systemd when the unit files (and related) are in > a format that they can be carried also by upstream and can be shared between > distributions. They are comparable to logrotate or bash-completion files. > > You don't necessarily use distcc, ccache, clang, ... and yet you let people > compile packages you maintain using them. > You don't necessarily use uclibc, yet you allow users to compile the > packages against it and expect them to file bugs if something is broken. > You don't necessarily use selinux and yet support building against > libselinux where possible. > You don't necessarily use zsh as your shell and yet let zsh-completion files > to be installed when requested. > > Yet any of the mentioned packages can be stabilized, what makes systemd so > special that it can't follow the same rules as other packages? logrotate, autocompletion are not functional dependencies. uclibc - is not mainline, people who use it for embedded are aware the it may be broken every bump. autocompletion, distcc, ccache etc... are optional components which can be disabled, while having usable system until issue is resolved. selinux - if a package breaks selinux it will be reverted (if maintainer care about his users) until resolution is found. as you may have unusable system if a bump does not support specific stable init layout, you do expect rollback similar to libselinux issue. init layout is not optional package nor optional feature, it how the system operates. >> So apart of the politic message, there are implications of maintenance >> efforts, stabilization efforts. > > > Just the normal efforts. > > >> >> I appreciate the discussion at debian, it is not wise to support [I am >> adding: at stable] more than one solution for layout. >> >> Regards, >> Alon Bar-Lev. >> > >
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:26 PM, Tom Wijsman wrote: > On Thu, 8 Aug 2013 20:57:15 +0300 > Alon Bar-Lev wrote: > >> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman wrote: >> > Stability is about the quality of the ebuilds and the user >> > experience in general. It is not a statement that all Gentoo >> > developers think that the package is useful. Many would say that >> > nobody should be using MySQL/MariaDB for production work, but that >> > has nothing to do with its stability as a package either. >> >> This is not entirely correct. >> >> If from now on, a bug with systemd of new version of a package blocks >> that package stabilization, it means that all developers must support >> systemd. > > This is not entirely correct either. > > Not necessarily, one can opt to mask this combination and stabilize > this combination later by removing the mask; it's an implementation > detail, but certainly there's no need to imply that they must. > > Another example is that when you add a package to the tree, you are not > required to initially commit both an OpenRC unit and systemd service > file; you are suggested to provide them for the convenience of the > user, if you don't know systemd service files then you aren't obligated > to support them as far as I am aware of. There are people that can help > you in supporting them as well as following up on their bugs; and if > you wonder, the ebuild change to support a systemd service is trivial. 1. There is huge difference between adding a new package that lacks feature and maintaining existing features. 2. When people say that something is trivial, my immediate reaction is fear. systemd is far from being trivial, but let's don't get into that one again. > >> So having systemd stable is a decision that should be made by >> the entire community, and have huge overhead on us all. > > systemd is already stable, it has not found to be an huge overhead; > whether it should have been a decision made by the entire community, I > doubt it, it neither seems to show any problematic wide spread problems. > >> So apart of the politic message, there are implications of maintenance >> efforts, stabilization efforts. > > Agreed; though, they are quite small and shouldn't be a bother. It's > worth doing these small implications to provide choice to our users... > >> I appreciate the discussion at debian, it is not wise to support [I am >> adding: at stable] more than one solution for layout. > > Can you share the link? I'm yet to see good reasoning why it's not wise. Latest[1], you can search for "debian openrc" for more. [1] http://www.marshut.com/rnvrp/survey-answers-part-3-systemd-is-not-portable-and-what-this-means-for-our-ports.html > -- > With kind regards, > > Tom Wijsman (TomWij) > Gentoo Developer > > E-mail address : tom...@gentoo.org > GPG Public Key : 6D34E57D > GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)
On Thu, Aug 8, 2013 at 9:47 PM, Tom Wijsman wrote: > On Thu, 8 Aug 2013, 20:57:18 +0300 > Alon Bar-Lev wrote: > >> If from now on, a bug with systemd of new version of a package blocks >> that package stabilization, it means that all developers must support >> systemd. So having systemd stable is a decision that should be made by >> the entire community, and have huge overhead on us all. > > On Thu, 8 Aug 2013 21:23:29 +0300 > Alon Bar-Lev wrote: > >> selinux - if a package breaks selinux it will be reverted (if >> maintainer care about his users) until resolution is found. >> >> as you may have unusable system if a bump does not support specific >> stable init layout, you do expect rollback similar to libselinux >> issue. init layout is not optional package nor optional feature, it >> how the system operates. > > Reverting and rolling back isn't really the good way going forward, it > implies waiting and that's going to certainly make people sad because > they need to wait for something that doesn't affect the package > combination that the user uses; we need to look at a different approach. > > What if we could stabilize package combinations instead of packages? Or > rather, when during stabilization it was found that a certain package > combination doesn't work, exclude that combination from stabilization? > > This is a concept that shouldn't be too hard to implement; it could > even be implemented using existing USE flag mask opportunities, although > we probably would have to figure out a solution for those occasions > where an USE flag is not present. > > Perhaps specify in the ebuild that the package shouldn't be regarded as > keyworded for a certain dependency? > > Since it's just an idea that jumps to mind, I'm not sure if this is the > best approach to do this; but we'll probably want to start brainstorming > in this field if this is going to stay or become a big problem. > > Multiple implementations shouldn't block Gentoo going forward. > > We need to come up with a solution similar to the above to avoid this... This is called a 'profile'. You can have systemd and openrc profiles, and then able to mask specific packages... It is a technical solution, but won't make lives much easier in this regard. Regards, Alon Bar-Lev
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:58 PM, Samuli Suominen wrote: > On 08/08/13 21:23, Alon Bar-Lev wrote: >> >> On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen >> wrote: >>> >>> On 08/08/13 20:57, Alon Bar-Lev wrote: >>>> >>>> >>>> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman wrote: >>>>> >>>>> >>>>> Stability is about the quality of the ebuilds and the user experience >>>>> in general. It is not a statement that all Gentoo developers think >>>>> that the package is useful. Many would say that nobody should be >>>>> using MySQL/MariaDB for production work, but that has nothing to do >>>>> with its stability as a package either. >>>> >>>> >>>> >>>> This is not entirely correct. >>>> >>>> If from now on, a bug with systemd of new version of a package blocks >>>> that package stabilization, it means that all developers must support >>>> systemd. So having systemd stable is a decision that should be made by >>>> the entire community, and have huge overhead on us all. >>> >>> >>> >>> That's not really true with systemd when the unit files (and related) are >>> in >>> a format that they can be carried also by upstream and can be shared >>> between >>> distributions. They are comparable to logrotate or bash-completion files. >>> >>> You don't necessarily use distcc, ccache, clang, ... and yet you let >>> people >>> compile packages you maintain using them. >>> You don't necessarily use uclibc, yet you allow users to compile the >>> packages against it and expect them to file bugs if something is broken. >>> You don't necessarily use selinux and yet support building against >>> libselinux where possible. >>> You don't necessarily use zsh as your shell and yet let zsh-completion >>> files >>> to be installed when requested. >>> >>> Yet any of the mentioned packages can be stabilized, what makes systemd >>> so >>> special that it can't follow the same rules as other packages? >> >> >> logrotate, autocompletion are not functional dependencies. >> >> uclibc - is not mainline, people who use it for embedded are aware the >> it may be broken every bump. >> >> autocompletion, distcc, ccache etc... are optional components which >> can be disabled, while having usable system until issue is resolved. >> >> selinux - if a package breaks selinux it will be reverted (if >> maintainer care about his users) until resolution is found. >> >> as you may have unusable system if a bump does not support specific >> stable init layout, you do expect rollback similar to libselinux >> issue. init layout is not optional package nor optional feature, it >> how the system operates. > > > > > I guess that's why we call Gentoo a meta-distribution instead of > distribution since we are not bound to one certain type of system operation > like eg. Debian is or any other binary distribution is. As this alternate layout did not exist at that time, I don't think it had not been the reason for this term.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman wrote: > On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer wrote: >> You just removed the upgrade path for users. >> > > Just install systemd. There really isn't any practical alternative. > Gentoo with systemd is as Gentooish a configuration as Gentoo with > OpenRC, or Gentoo with libav, or Gentoo with emacs. Again, I repeat my-self. Please stop writing these statements! There was no decision to support Gentoo using any other layout than openrc (baselayout). There is *HUGE* difference between optional components and core components. Claiming that Gentoo can use alternate layout is same as alternate that freebsd port is stable or that intel icc can be used as compiler. It has broad implications, which is far from the actual component usage or its own dependencies. If you have the agenda to switch to systemd, and you hide your intention in the argument of supporting multiple layouts, please do not hide and state so clearly. But do not claim that Gentoo with different layout than baselayout is still formal Gentoo, and is supported by the Gentoo developers. Regards, Alon Bar-Lev.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 4:49 PM, Samuli Suominen wrote: > On 09/08/13 15:36, hasufell wrote: >> >> On 08/09/2013 12:27 PM, Rich Freeman wrote: >>> >>> On Fri, Aug 9, 2013 at 5:30 AM, hasufell wrote: >>>> >>>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote: >>>>> >>>>> It is not a regression if a new version of gnome mrequires systemd >>>>> and does not work with OpenRc; it is a design choice. >>>> >>>> >>>> We are not just talking about random ebuild features here that have been >>>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a >>>> _regression_. >>> >>> >>> How does not supporting OpenRC matter for Gentoo? >> >> >> The question puzzles me. For one it is >> * an implementation of virtual/service-manager which is in @system >> * it is the default init system in stage3 >> * OpenRC is developed by gentoo devs, which means we especially want to >> make/keep it a usable tool. If we can't, then there is a regression. It >> doesn't matter whose fault it is. This is not about blame. > > > baselayout-1, then later baselayout-2 and OpenRC were all created because > there was an need and no suitable ready solutions > systemd however is starting to look like a viable ready solution to switch > to > it's definately not an regression to switch to actively maintained software, > it's more of an improvement because OpenRC has been stalled ever since Roy > stopped hacking on it (all work put in by vapier, WilliamH, and others is of > course appericiated) > you know it's true if you have been with gentoo enough long > At least we know what ssuominen thinks... some prople are trying to hijack the Gentoo project at the excuse of Gnome to switch into specific vendor solution, and be on its mercies from now on. This was the exact plan of whoever put all these $$ in udev/systemd/gnome/fedora and effect the entire ecosystem, and slowly own the entire solutions. As Linux userland become more and more monolithic per the plan of that vendor, and if we yield, there will be no real difference between Fedora and Gentoo, so what have we accomplished? There come the new Microsoft and conquered the free open source world using $$ and ambassadors. What we basically say is that Gentoo cannot have their own agenda and now submit to dictation of a single vendor of how Linux should be managed and run. To provide good service to our users we need a clear stand, what will developers (throughout the tree) will be maintaining. If a user installs a component he does expect it to work and maintained. And we cannot force all developers to support two different layouts, and we cannot allow developers to support layout of their choice, as users will get a totally broken solution, because of the aspirations of developer/herd they get different level of support. I don't care if systemd is worked on by people, however it must be clearly mark as unstable as long as there is no decision to switch. Regards, Alon Bar-Lev
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn wrote: > Alon Bar-Lev schrieb: >> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman wrote: >>> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer wrote: >>>> You just removed the upgrade path for users. >>>> >>> Just install systemd. There really isn't any practical alternative. >>> Gentoo with systemd is as Gentooish a configuration as Gentoo with >>> OpenRC, or Gentoo with libav, or Gentoo with emacs. >> Again, I repeat my-self. >> >> Please stop writing these statements! >> >> There was no decision to support Gentoo using any other layout than >> openrc (baselayout). > > I think there may be a misunderstanding here. He only said that if you > want to run Gnome 3.8, then switch to systemd. Because the Gnome team > will not support any other configuration. > > He did not say that everyone should install systemd, nor that you need > to support such a configuration. So users will have gnome working but not any other component? How can this a good service for users?
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 5:57 PM, Chí-Thanh Christopher Nguyễn wrote: > Alon Bar-Lev schrieb: >>> I think there may be a misunderstanding here. He only said that if you >>> want to run Gnome 3.8, then switch to systemd. Because the Gnome team >>> will not support any other configuration. >>> >>> He did not say that everyone should install systemd, nor that you need >>> to support such a configuration. >> So users will have gnome working but not any other component? How can >> this a good service for users? > > I am not sure what you mean by that. But every developer is free to > commit and support in Gentoo whatever package he wishes to, within > limitations set by policy. > And when a package is 30 days in tree and there is no objection from QA > or security teams then it can go stable. This is so narrow interpretation of the policy. You talk about a process, and user do not care about the process. 30 days? and what if a user has an issue 31 days after? And what if QA decides that now systemd must be supported? so we delay stabilization? People here tend to forget that Gentoo is not just ebuilds, but also an organization which requires a policy for the sake of its *USERS*. Regards, Alon
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Sat, Aug 10, 2013 at 1:59 PM, Rich Freeman wrote: > On Sat, Aug 10, 2013 at 6:51 AM, Patrick Lauer wrote: >> not must, but if I choose to run the official supported configuration, >> well, then telling me to go to an unsupported state is quite confusing >> and sends the wrong signal. >> > > There is no one official supported configuration of Gentoo. Nobody > has to agree to make systemd an official supported configuration, > because OpenRC isn't an official supported configuration either. At > least, not in the way that the terms seems to be being used. There is > no policy that requires packages to run when OpenRC is the service > manager, and there is no policy that requires packages to supply an > OpenRC init.d script. Every long lawyer like response make me re-check my sanity. The split of openrc was done by Roy in the past to be usable by other audiences, especially busybox and *bsd configurations. OpenRC is baselayout-1, just packaged in different way. Gentoo, well up to now, did have a policy that packages should support the baselayout which was single one, no alternatives where formally supported. The fact that OpenRC is now provided as own package (technical bit) could not have changed the policy of providing stable coherent solution for users. The fact that someone decided that init system may be virtual means nothing if the implications of users and developers were not been understood. Of course it matches the gnome and affiliated vendor agenda but for that do we break the entire tree and produce extra load for developers who maintain unrelated packages? Alon
Re: [gentoo-dev] systemd team consensus?
On Sun, Aug 11, 2013 at 9:59 PM, Tom Wijsman wrote: > On Sun, 11 Aug 2013 13:29:16 -0500 > William Hubbs wrote: > >> You may ask why I have offered patches instead of just fixing the >> ebuild since I am a team member. That is because even team members >> aren't allowed to touch bugs assigned to syst...@gentoo.org [1], > > Well, if there are conflicts within a team then I can agree that no > member is allowed to touch the bug without a collaborative decision; > but from what it appears this bug has been handed in a way that one > member appears to take all decisions and the other member has nothing > to say. In particular, comments 5 and 11 change the state of the bug > without giving any reasoning about why that change in state was made; > this is unacceptable, it gives us no reason to believe the state change. This is expected, as it is similar to how systemd/gnome is managed :) Regards, Alon Bar-Lev.
Re: [gentoo-dev] systemd team consensus?
On Mon, Aug 12, 2013 at 2:08 AM, Gilles Dartiguelongue wrote: > Le dimanche 11 août 2013 à 22:09 +0300, Alon Bar-Lev a écrit : >> On Sun, Aug 11, 2013 at 9:59 PM, Tom Wijsman wrote: >> > On Sun, 11 Aug 2013 13:29:16 -0500 >> > William Hubbs wrote: >> > >> >> You may ask why I have offered patches instead of just fixing the >> >> ebuild since I am a team member. That is because even team members >> >> aren't allowed to touch bugs assigned to syst...@gentoo.org [1], >> > >> > Well, if there are conflicts within a team then I can agree that no >> > member is allowed to touch the bug without a collaborative decision; >> > but from what it appears this bug has been handed in a way that one >> > member appears to take all decisions and the other member has nothing >> > to say. In particular, comments 5 and 11 change the state of the bug >> > without giving any reasoning about why that change in state was made; >> > this is unacceptable, it gives us no reason to believe the state change. >> >> This is expected, as it is similar to how systemd/gnome is managed :) > > I hope you are not talking about the Gentoo Gnome team as this would be > very wrong. Every team member is heard on the team. I was talking about the designated upstreams. Regards, Alon
Re: [gentoo-dev] open season on other-dev's packages -- policy change?
On Fri, Nov 1, 2013 at 9:53 PM, Peter Stuge wrote: > Peter Stuge wrote: >> It matters a whole lot if I have to wait for someone else to >> unblock me, in practice that completely demotivates me to >> contribute back, and I would simply work around the block. > > To clarify this point; contributing fixes back must always be the > least effort of all ways to implement the fix in my own system. > Optimize for the (desired) common case. Anything else pushes > contributions away. Hi, Just for me to understand, do you suggest everyone can commit into the tree? Or do you want to join in as a developer? Or something else? Regards, Alon Bar-Lev.
Re: [gentoo-dev] open season on other-dev's packages -- policy change?
On Fri, Nov 1, 2013 at 10:06 PM, Peter Stuge wrote: > Alon Bar-Lev wrote: >> >> It matters a whole lot if I have to wait for someone else to >> >> unblock me, in practice that completely demotivates me to >> >> contribute back, and I would simply work around the block. >> > >> > To clarify this point; contributing fixes back must always be the >> > least effort of all ways to implement the fix in my own system. >> > Optimize for the (desired) common case. Anything else pushes >> > contributions away. >> >> Just for me to understand, do you suggest everyone can commit into >> the tree? >> >> Or do you want to join in as a developer? >> >> Or something else? > > I'm discussing the policies for Gentoo developers, stating my > preferences and opinions under the assumption that my contributions > to such a discussion are receivable and maybe even appreciated > regardless of whether I ever become a developer or not. > Sure, but I may missed what you recommended... not exist in the thread... Blind commit without review of maintainer? More maintainers? More proxies? I understand that you want to shorten the time between bug opening and commit... but I do not understand what you suggest... > > //Peter >
Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC
On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs wrote: > > All, > > We got a request from Debian to rename the "rc" binary of OpenRC due to > a naming conflict they have. They have a port of the at&t plan 9 shell, > which has a binary named "rc" as well[1]. > > My thought is to rename our "rc" to "openrc", since that would be > unique. > > I know at least one thing that will break is everyone's inittab, so > should I sed their inittab in our live ebuild or expect them to fix it > and give a warning? I know that once OpenRC with this change is > released, it will need to probably be p.masked until there is a new > release of sysvinit that updates the inittab. > > I'm not sure what else will break. > > Does anyone have any ideas wrt other things to look for, or should I > make the changes upstream and have people let us know what > else breaks? are you going to rename also rc-service and rc-update? > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=493958
[gentoo-dev] Commit into profiles fails
Hi, Long time since I done this... maybe something had been changed. $ cvs commit -m "thirdpartymirrors: fixup gnupg mirros, bug#494842, thanks to Ben Kohler" cvs commit: cannot exec /var/cvsroot/CVSROOT/cvslogdate: Permission denied cvs commit: cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission denied cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! It looks like something is wrong in remote, but I see people succeed in committing today... What's wrong? Thanks, Alon
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs wrote: > > On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote: > > William Hubbs wrote: > > > The reason the split happened is pretty straight forward, and every other > > > "justification" for continuing it was come up with after the fact. > > > > I keep hearing this, but I really don't see how it's relevant. I'm sure > > you'll find lots of things in your life that you use for some purpose > > other than what they were originally invented for¹, and there's no > > reason why /usr should be any different. All that matters is whether or > > not the newer reasons for having separate /usr actually provide a benefit. > > And I would argue that the maintenance cost of having separate /usr in a > general sense is much higher than the benefit it provides. > > The problem with it is that it is next to impossible nowadays to define > what should go in / vs what should go in /usr. > > William Now it is difficult as too much time it was ignored. In the past it was quite simple, everything that requires a server to reach default runlevel. The problem is that instead of telling users: "If you are using special user mode devices, such as bluetooth keyboards, please make sure /usr is mounted at boot", we enforce all that configuration, so now initramfs should contain all that once was / with much harder maintenance. Alon
Re: [gentoo-dev] Re: Banning modification of pkg-config files
On Mon, May 12, 2014 at 9:48 PM, Peter Stuge wrote: > Samuli Suominen wrote: >> >> If we say we stick to upstream then we don't provide pkg-config files >> >> at all (in these cases). >> >> > I think this is a sane default. >> >> Except having pkg-config is the only way to fix some of the build >> issues we are seeing today, like getting 'Libs.private: ' for >> static linking, there has been multiple bugs lately, > > I honestly don't think that it's Gentoo's place to fix those issues. > > Just error out. Make users complain to upstream when upstream has a > problem. Don't hide the problem and amass a huge support workload. > >From my experience, there are lots of issues in upstream projects' build system, most of the these result from lack of knowledge. Up until now, downstream patches that were actually used by users found their way better into upstream than just complaining that stuff breaks, as upstream honestly does not have the knowledge to fix. It also gives a chance to test them properly before submitting. There are projects that will not accept any patch regardless of the problem it solves, unless it is for their own favour distribution and packager, so not providing solution for our users does not makes sense to me. Regards, Alon
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default
Hi, I do not know if this came up... glibc must be bumped first[1]. Alon [1] https://bugs.gentoo.org/show_bug.cgi?id=504032
Re: [gentoo-dev] Re: git security (SHA-1)
On Sun, Sep 21, 2014 at 2:13 PM, Ulrich Mueller wrote: >> On Sun, 21 Sep 2014, Michał Górny wrote: > >> Do you really consider keeping a key open for machine signing >> somewhat secure? > > You mean, as compared to manifests (or commits) signed by 250 > different developers' keys? > > Ulrich Unrelated to git discussion, in the past we discussed co-sign, so that developer signs using short term key, and infra co-sign using long term key if the developer sign is valid at that time. Portage infra should relay on infra key signature, while tractability is available up to developer. I will take the opportunity of responding to write that my preference is to keep the manifest signature detached from the version management technology, with no git specific feature usage, nor git specific development (signed hrefs). It will enable much easier use of each technology, one for file management and the other for security, while enabling rebase and reorg without effecting integrity. If we can establish co-sign I will be very happy. Regards, Alon
[gentoo-dev] Re: [gentoo-core] bugstest.gentoo.org - public beta for the new Gentoo BugZilla - please test!
On 11/16/06, Robin H. Johnson <[EMAIL PROTECTED]> wrote: The shiny new bugstest.gentoo.org! We're opening it up for all testers as of this email. It is current up the 14th of November, so I would also like to encourage everybody searching for existing bugs to use it. It should scale much better than the existing BugZilla setup. Just a stupid question... Can bugzilla be configured so that when you open a new bug you are able to modify the reporter? This is useful when s developer wishes to open a new bug on behalf to a user who reported multiple issues, and allow him to manage it as if it was his. Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [Attention] app-crypt/gnupg-2.0.1-r1 - Drop-in replacement to gnupg-1.4
Hello, Until now gnupg-1.9/gnupg-2 serieses were installed side-by-site with gnupg-1.4 series, and actually was depended on the old version. Starting from gnupg-2.0.1-r1 (masked) app-crypt/gnupg-2.0.1-r1 is configured to be a drop-in replacement. It lacks the static use flag, I could not find a simple way to achieve this. Also ecc patch is not ready yet. Effected packages which blocks the gnupg-2 series: gnome: app-crypt/seahorse-0.8.2 kde: kde-base/certmanager-3.5.5 kde-base/kdepim-3.5.5 The kde packages should just modify the dependency. The seahorse package should be checked more deeply, it looks like it gnupg version dependend. Anyone who wants to test help testing is welcome to provide feedback. Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] punt mingw ebuilds out of the tree and into a mingw overlay
On 12/20/06, Mike Frysinger <[EMAIL PROTECTED]> wrote: if we want to punt the toolchain packages as well (but i dont have a problem with these being in tree): dev-util/mingw-runtime dev-util/w32api -mike Hello, Please leave the toolchain so cross-compilation to win32 will be available as mainstream. Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] autotools eclass - set default for WANT_AUTO*
Hello, Is there any reason why not setting "latest" as default for WANT_AUTO* variables? I believe that an ebuild should set these variables only if there is some exception. Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*
On 1/6/07, Kevin F. Quinn <[EMAIL PROTECTED]> wrote: Not sure. Would we run the risk that working ebuilds would start to fail when newer autotools versions arrive? So what do you suggest of putting? Current revision? And we can drop the "latest" support... right? But then we should handle old ebuilds that use old auto*. I think a specific version should be specified only if something breaks with latest, thus it should be the default. Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*
On 1/7/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: On Saturday 06 January 2007 13:32, Diego 'Flameeyes' Pettenò wrote: > On Saturday 06 January 2007 19:23, Mike Frysinger wrote: > > why not just get rid of the idea of "latest" ? is there a scenario where > > autotools would be inherited but not actually used/added to DEPEND ? i > > guess that's what this all comes down to really ... > > If autotools were to be inherited by an eclass, and left to the eclass > users to depending on the correct versions, I'd say. and how likely is this situation ? -mike Well What is the verdict? 1. Add default. 2. Explicit specify version in WANT_AUTO*. 3. Continue adding WANT_AUTO*="latest" everyplace. Best Regards, Alon Bar-Lev -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: sys-apps/pcsc-ase-iiie-drv
Hello, Users that uses the above package should move to: app-crypt/asedriveiiie-serial app-crypt/asedriveiiie-usb Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*
On 1/12/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Sunday 07 January 2007 11:27, Alon Bar-Lev wrote:
> 1. Add default.
we've gone this route ... if/when an issue comes up where someone is
inheriting autotools but they're using it conditionally, we'll revisit this
autotools.eclass:
[[ -z ${WANT_AUTOCONF} ]] && WANT_AUTOCONF="latest"
[[ -z ${WANT_AUTOMAKE} ]] && WANT_AUTOMAKE="latest"
-mike
Thanks!
After you commit this, I will go over all my packages and remove the
latest setting.
Best Regards,
Alon Bar-Lev.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] New USE_EXPAND - CAMERAS
Hello, Per bug#139884, libgphoto2 has drivers for many cameras we should have a way for user to select the right drivers. Currently it uses environment variables in make.conf, any objection to adding it to USE_EXPAND? Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new herd suggestion: religion
On 2/2/07, Steve Dibb <[EMAIL PROTECTED]> wrote: I talked to squinky86 who was previously maintaining most of these, and since he is temporarily retiring I've assumed ownership of the packages in his absence. A herd would of course let anyone else interested work on them, and be recognized as joint maintainers as well. Any comments? I can take bibletime if you like. Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal
On 4/10/07, Alexandre Buisse <[EMAIL PROTECTED]> wrote: Hi everyone, as everyone probably noticed, there is a current atmosphere of sinking ship, with quite a lot of people leaving and many agreeing that gentoo is no fun working on anymore. Before it's too late, I'd like to propose a big reformation that would help solve some of the issues we are currently having and, hopefully, bring back some of the fun we all had developing and using this distribution. Thank you for bringing this up. I think the discussion is very important. It is first time I response to a "political" issue here... So forgive me if I am totally wrong. I don't think this is the reason people are leaving. I think people are leaving because a lack of direction. I am not aware of any goal Gentoo distribution wish to acquire. For example: Do we wish to use a mainstream distribution? Do we aim to a specific user community? Or Do we develop distribution for our use? If you wish to be (And I think we should be) mainstream distribution, we should derive targets, such as QA level, response times and content. Being more modular is one technical feature to achieve better stability. But we should discuss the basics first. I hear a lot that open source project with unpaid developers cannot be committed to deadlines or requirements from its developers, but I disagree. There can be an open source project with high quality products and dead lines, if these properly defined. I am quite new here, but it seems like there are few groups here, from a group that interested in anarchy to a group that interested in formal hierarchy. I must disclose that in my view whenever a large group of people are doing something together, some kind of hierarchy must be in place. And I am not talking about current council, it seems that current council does not LEAD Gentoo anywhere. I read that sometime in history there was an effort to impose structural format on the community, but then Daniel Robbins left? If we wish to be a major distribution, we must grow. If we to grow we must organize our-self better, and work toward a common goal. Common goal forces decision making. Decision making forces leadership. Leadership forces vision. Is there any vision? Now, for your idea. When I written something similar in the past, someone told me that it was already suggested... I don't know why it wasn't accepted. I think too that ebuilds should exists in several overlays. At least: Stage3 (current) Base (baselayout, networking, boot loaders etc) -tear- Each tear should have commitments for: 1. Time from upstream release package until it in overlay. 2. Time from security issue until it in stable. 3. Time from stable request until make stable per each platform. 4. Time for addressing bug, time for solving bug. 5. Keep last N stable version (major, minor). I guess you got the idea. For example, for crypto there can be several overlays, tear-1 overlay with core packages, tear-2 with misc packages, tear-3 with supported at free-time bases. Each tear has its own measures. tear-1 desktop cannot be dependent on tear-2 crypto, the desktop herd need to ask crypto herd to move the package into tear-1 before dependency is added. I totally agree that each user may ask for package of specific overlay, but I think that this should not be specified in the build, but by the user at /etc/portage. For example, I decide that dev-libs/gtk+ should be from overlay X the portage should take it from there. But I believe we should first discuss the community goals, then derive a technical solution. Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] FYI: Jakub suspended two weeks for bad behaviour
On 4/17/07, Jakub Moc <[EMAIL PROTECTED]> wrote: > holding developers to higher > standards is completely in line with the council wishes I believe. Indeed. I've noticed the high standards being pushed by devrel quite a couple of times, such as in [1]. So Bret, I sincerely hope you'll get your devbox finally running after 3 years or so and you'll continue to be such a great assett to Gentoo as you've been so far. ;) [1] http://bugs.gentoo.org/show_bug.cgi?id=38368 I totally agree. The slack developer should have been suspended... Not you. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites sys-apps/855resolution
Hello All, sys-apps/915resolution superseed this package and support 855 configurations. Please upgrade your configuration to sys-apps/915resolution. Comments/suggestions can be entered at bug#159586. Package will be masked at 2007-05-25, removed at 2005-06-08. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bugday is approaching!
Hi! Can you please add: http://bugs.gentoo.org/show_bug.cgi?id=183075 Need a psi user to close this. Thanks! On 7/3/07, Peter Weller <[EMAIL PROTECTED]> wrote: Hi, Don't forget that next Saturday is the first Saturday of the month, which means it's Bugday! For those of you who don't know, Bugday is a great opportunity for users to start fixing bugs, as well as testing bugfixes submitted by other users (and getting/giving help in the process). Feel free to join in by joining #gentoo-bugs on irc.freenode.net More information can be found at the following links: http://bugday.gentoo.org/ http://www.gentoo.org/proj/en/bugday/index.xml Thanks, welp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
I think we should have user space splash... As fbsplash does not work with all video cards and last time I checked the whole framebuffer in kernel is not actively maintained. Alon. On 7/7/07, Michal Januszewski <[EMAIL PROTECTED]> wrote: # Michał Januszewski <[EMAIL PROTECTED]> (06 Jul 2007) # Unsupported, use media-gfx/splashutils instead. # Masked for removal in 30 days. media-gfx/bootsplash We don't provide any kernels patched with bootsplash anymore and media-gfx/bootsplash has no support for baselayout-2. media-gfx/splashutils together with the fbsplash patches provides the same functionality as bootsplash. Best regards. -- Michal Januszewski JID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
On 7/7/07, Michal Januszewski <[EMAIL PROTECTED]> wrote: On Sat, Jul 07, 2007 at 01:06:07AM +0300, Alon Bar-Lev wrote: > I think we should have user space splash... As fbsplash does not work splashutils is a _userspace_ splash. fbsplash isn't, but then it only provides the "verbose" mode (background pictures on system consoles) and there is no way of doing that in userspace (other than implementing the whole console system in userspace, which has indeed been proposed and might get done one day). I think what important to user is the silent mode where graphical progress can be shown. Maybe run X or something simpler? > with all video cards and last time I checked the whole framebuffer in Which fb driver doesn't it work with? i915, even if splash gets working X does not. A lot of issues there. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
On 7/7/07, Rémi Cardona <[EMAIL PROTECTED]> wrote: Try using vesafb-tng (I know it doesn't support some resolutions either) but interactions between vesafb-tng and the intel X driver are _much_ better. Does not work either. There is a memory conflict between the X space and vesa. I basically think that users (As advanced Gentoo user can be) cannot have a workable environment in a reasonable effort... I know I have failed. We need to provide simper and workable solution. Alon. ��í¢^����(� ��X��X�
Re: [gentoo-dev] Last rites: media-gfx/bootsplash
On 7/7/07, Roy Marples <[EMAIL PROTECTED]> wrote: The whole thing is moot anyway as baselayout-2 now uses C plugins for hooks like splash. So unless you or someone else steps up to the plate and write a baselayout-2 plugin for bootsplash there will be a point where it will stop working. I don't use bootsplash either... If I get this correctly, since both bootsplash and fbsplash are framebuffer users, there is no much different between them... It is fine to drop boosplash support. But both is unworkable for many users. Alon. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On 7/21/07, Roy Marples <[EMAIL PROTECTED]> wrote: This is just a heads up for getting baselayout-2 stable. Next week I plan to put baselayout-2.0.0_rc1 into the tree without any keywords and it will be removed from package.mask (keeping the current alphas masked though). Arch teams will then be pinged on a bug to keyword baselayout-2. Hi! Just an issue I thought a long while ago... What about adding USE flags for all optional networking components... So that they installed without manually merging them one by one? Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Packages of for grabs
On 8/29/07, Christian Heim <[EMAIL PROTECTED]> wrote: > - dev-libs/openct (kaiowas) crypto ack > crypto: > - sys-auth/pam_p11 (kaiowas) > - dev-libs/libp11 (kaiowas) > - dev-libs/opencryptoki (kaiowas) > - dev-libs/engine_pkcs11 (kaiowas) crypto ack. Alon -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Latest Gentoo installcd lacks lsusb
Hello All, I may be totally wrong here (as usual)... But before I let it go, I think we require some more views regarding this matter. lsusb is not included in latest installcd, I believe that determine available USB devices is important to bootstrap installation, in order to detect network card, ADSL modem, determine which USB mass storage exists and more. Release engineering believes that as there is no dependency of libusb, lsusb should not be provided as it is not required for installation. Ignoring comment#7, bug is available at: https://bugs.gentoo.org/show_bug.cgi?id=195666 If you think lsusb is important or not important for installcd, please help explain why. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites sys-libs/libtpm
Hello, This package will be masked at 2007-11-22. If you need this package, please comment at bug#198696. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [RFC] gnupg-2 stable plans
Hello, I want to make gnupg-2 stable. The problem is that gnupg-1.9 was slotted as slot "1.9" and made stable. So now we have two slots, slot "0" and slot "1.9". gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. As far as I see, there are two migration pathes I can use: 1. Mark gnupg-2 stable, as it blocks older versions, this results in forcing users to manually unmerge the gnugp-1.9 series, this is the quickest and simplest migration path. 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. Any thoughts? Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Dec 9, 2007 9:21 AM, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: > > Hello, > > > > I want to make gnupg-2 stable. > > > > The problem is that gnupg-1.9 was slotted as slot "1.9" and made stable. > > > > So now we have two slots, slot "0" and slot "1.9". > > > > gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting > > should be used. > > > > As far as I see, there are two migration pathes I can use: > > > > 1. Mark gnupg-2 stable, as it blocks older versions, this results in > > forcing users to manually unmerge the gnugp-1.9 series, this is the > > quickest and simplest migration path. > > Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather > than SLOT 1.9? he end result would be one slot... If I need to chose 1.9 or 0, I prefer the standard is to have slot 0. > > 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so > > migration will be smooth. The problem is that I need all archs to work > > with me in timely manner so that this will be possible. I have > > bug#194113 waiting for arm, mips, s390, sh, and this only for the > > dependencies. > > I can imagine this resulting in very weird issues, when you have two of > the same package installed in the same slot. What? These are two versions If nobody else address this, I will chose the easy way -> option#0. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > On 22:49 Tue 11 Dec , Alon Bar-Lev wrote: > > On Dec 9, 2007 9:21 AM, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > > On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: > > > Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather > > > than SLOT 1.9? > > > > he end result would be one slot... If I need to chose 1.9 or 0, I prefer the > > standard is to have slot 0. > > What happens to people who only have slot 1.9 installed and not slot 0, > or vice versa? You might want to test a few different upgrade scenarios > to see what portage does. OK, I will try this. > > > > 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so > > > > migration will be smooth. The problem is that I need all archs to work > > > > with me in timely manner so that this will be possible. I have > > > > bug#194113 waiting for arm, mips, s390, sh, and this only for the > > > > dependencies. > > > > > > I can imagine this resulting in very weird issues, when you have two of > > > the same package installed in the same slot. > > > > What? > > These are two versions > > Right, but two versions are never supposed to be installed into the same > slot. They are during upgrade/downgrade, but that's short-term. Some > package managers could respond oddly. If you were going to go this > route, it would again be worth testing in advance. I don't understand... It works quite some time for many people. Alon. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, William L. Thomson Jr. <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-12-08 at 15:49 +0200, Alon Bar-Lev wrote: > > > > gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting > > should be used. > > Drop in according to YOU, which I have taken issue with since 1/1/07. > Per last upstream release, and every one since 2.x was release, just as > I have quoted and stated many times before. > > http://lists.gnupg.org/pipermail/gnupg-announce/2007q3/000259.html > > "GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that > it splits up functionality into several modules. However, both > versions may be installed alongside without any conflict. In fact, > the gpg version from GnuPG-1 is able to make use of the gpg-agent as > included in GnuPG-2 and allows for seamless passphrase caching. The > advantage of GnuPG-1 is its smaller size and the lack of dependency on > other modules at run and build time. We will keep maintaining GnuPG-1 > versions because they are very useful for small systems and for server > based applications requiring only OpenPGP support." As I told you before, I wont slot these two. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, Jan Kundrát <[EMAIL PROTECTED]> wrote: > Alon Bar-Lev wrote: > > As I told you before, I wont slot these two. > > Could you provide a link to reasons that lead you to this decision so > that interested readers can make their own opinion? http://bugs.gentoo.org/show_bug.cgi?id=159623 Best Regards, Alon Bar-Lev.
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, Mart Raudsepp <[EMAIL PROTECTED]> wrote: > With no slotting I can bet on GnuPG-1 going away shortly after all > architectures have stabled GnuPG-2, gpg-1.X series will be available as long as upstream maintain it. > or is that not so and such users can > mask >=GnuPG-1.9 and keep using a smaller version that perfectly fits > their needs? If yes, why not slot it as is designed? Slotting makes logic if there is some advantage of having both slots installed at the same machine, as gnupg-2 does all gnupg-1 does, there is no point in slotting, forcing users to mess with eselect in order to resolve the dependency of other packages with gnupg. You can always mask >=gnupg-2 if you want the 1.X series on embedded devices. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [RFC] gnupg-2 stable plans
Hello, I selected the blocker option, forcing users to unmerge gnupg-1.9. Users that used only 1.9 slot, will be notified later by revbumping this slot. I am truly sorry for bothering users, but this is the only way to push this forward. Thank you for your comments, Alon Bar-Lev. BTW: If someone what to step forward and maintain gnupg, I will be most happy! But this derives maintaining all g10 Code GmbH software, as they are closely related. dev-libs/libgcrypt dev-libs/libksba dev-libs/libgpg-error app-crypt/pinentry dev-libs/libassuan app-crypt/dirmngr app-crypt/gpgme And probably more. On 12/8/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > Hello, > > I want to make gnupg-2 stable. > > The problem is that gnupg-1.9 was slotted as slot "1.9" and made stable. > > So now we have two slots, slot "0" and slot "1.9". > > gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting > should be used. > > As far as I see, there are two migration pathes I can use: > > 1. Mark gnupg-2 stable, as it blocks older versions, this results in > forcing users to manually unmerge the gnugp-1.9 series, this is the > quickest and simplest migration path. > > 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so > migration will be smooth. The problem is that I need all archs to work > with me in timely manner so that this will be possible. I have > bug#194113 waiting for arm, mips, s390, sh, and this only for the > dependencies. > > Any thoughts? > > Best Regards, > Alon Bar-Lev. > -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
Publish to layman? On 1/1/08, Roy Marples <[EMAIL PROTECTED]> wrote: > Uh, forgot the link :) > > http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord.git;a=summary > > -- > [EMAIL PROTECTED] mailing list > > -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
Thanks! Works! Roy, why didn't you digest and commit the files? On 1/1/08, Petteri Räty <[EMAIL PROTECTED]> wrote: > Alon Bar-Lev kirjoitti: > > Publish to layman? > > > > Done. layman -a openrc after the web nodes have synced from CVS. > > Regards, > Petteri > > > ��í¢^����(� ��X��X�
Re: [gentoo-dev] OpenRC available for testing.
Thanks for adding digest, but: Calculating dependencies /!!! Digest verification failed: !!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 3629 !!! Expected: 3602 On 1/1/08, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > Thanks! > Works! > > Roy, why didn't you digest and commit the files? > > On 1/1/08, Petteri Räty <[EMAIL PROTECTED]> wrote: > > Alon Bar-Lev kirjoitti: > > > Publish to layman? > > > > > > > Done. layman -a openrc after the web nodes have synced from CVS. > > > > Regards, > > Petteri > > > > > > >
Re: [gentoo-dev] OpenRC available for testing.
On 1/1/08, Roy Marples <[EMAIL PROTECTED]> wrote: > > It took me some time to find /etc/conf.d/modules, but it's certainly > > useful :). > > It also means all config files, with the exceptions of fstab and rc.conf > are in conf.d and not some random dir :) Took me a while too... Some ChangeLog documentation should be available. Also I think this is a regression: # update-modules /sbin/update-modules: line 118: KV_to_int: command not found /sbin/update-modules: line 118: KV_to_int: command not found /sbin/update-modules: line 263: is_older_than: command not found And I think there is a circular dependency of: openrc->init-module-tools->baselayout->openrc I did not understand the comments in rc.conf regarding the external dependency... # It's possible to define extra dependencies for services like so #rc_config="/etc/foo" #rc_need="openvpn" #rc_use="net.eth0" #rc_after="clock" #rc_before="local" How can I add a specific service dependency using this mechanism? The modified service name is missing... I also notice that the timezone of clock is gone, any alternative? Also the network dependency of stopping/starting services when network is unavailable/available is gone, any alternative? Thanks! Alon. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
On 1/2/08, Roy Marples <[EMAIL PROTECTED]> wrote: > Those functions were removed from functions.sh as only update-modules > still uses them. udev does use KV_to_int though. I don't really want to > add those functions back. Although we could trivially add is_older_than > as a C applet built into rc. So who should take care of this? > > How can I add a specific service dependency using this mechanism? The > > modified service name is missing... > > They're supposed to belong in /etc/conf.d/$SVCNAME > Maybe you could suggest better wording? > > I suppose we could also allow > rc_$SVCNAME_$depend to work, for example > > rc_clock_need="modules" Oh... This is good, just document it... :) You did not reply regarding this one: > > Also the network dependency of stopping/starting services when network > > is unavailable/available is gone, any alternative? Regards, Alon. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
Again... !!! Digest verification failed: !!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 3666 !!! Expected: 3629 On 1/1/08, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > Thanks for adding digest, but: > > Calculating dependencies /!!! Digest verification failed: > !!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-.ebuild > !!! Reason: Filesize does not match recorded size > !!! Got: 3629 > !!! Expected: 3602 > > On 1/1/08, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > > Thanks! > > Works! > > > > Roy, why didn't you digest and commit the files? > > > > On 1/1/08, Petteri Räty <[EMAIL PROTECTED]> wrote: > > > Alon Bar-Lev kirjoitti: > > > > Publish to layman? > > > > > > > > > > Done. layman -a openrc after the web nodes have synced from CVS. > > > > > > Regards, > > > Petteri > > > > > > > > > > > > ��í¢^����(� ��X��X�
