[gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
Cheers,
Alin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 3/22/09 11:47 PM, Ryan Hill wrote:
On Sun, 22 Mar 2009 17:50:26 +0100
Alin Năstac mrn...@gentoo.org wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
Um, why?
I'm not having six identical patches with different version numbers in
FILESDIR.
Fine, then remove $PV from patch name and use it in any ebuild version
you want. Or just decouple the patch version from the ebuild version
(foo-bar-r1.patch sounds OK to me).
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 3/23/09 1:42 AM, Ryan Hill wrote: On Mon, 23 Mar 2009 01:19:26 +0100 Alin Năstac mrn...@gentoo.org wrote: Fine, then remove $PV from patch name and use it in any ebuild version you want. Or just decouple the patch version from the ebuild version (foo-bar-r1.patch sounds OK to me). No. It's done this way for a reason. I saw your reason about wanting to know the package version for which the patch was created and I cannot see any reason for knowing that other than submitting the patch to upstream. Somehow I doubt upstream is interested in patches for version x.y.1 when the current version is x.y.10. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 3/23/09 1:44 AM, Jeremy Olexa wrote: Alin Năstac wrote: snip Fine, then remove $PV from patch name and use it in any ebuild version you want. Or just decouple the patch version from the ebuild version (foo-bar-r1.patch sounds OK to me). What exactly is your problem that you are trying to solve here? Posting to the community to stop doing something without providing reasons to stop is not going to go anywhere. I like having the PV in the patch name..so, you haven't convinced me. IMO prefixing a patch name with $P creates the perception that the patch is used only from ebuild version $PV. Apparently we do not agree on this so there is not much more I can tell to convince others. I suppose what everyone does in their part of the tree is their business, but a small subset of packages I maintain have other maintainers as well. It is annoying to see rules you assume being respected on your ebuilds being broken at every bump made by others. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Doug Goldstein wrote: The only reason why OpenRC has not come up for stabilization by it's maintainers is the fact that everytime there's a new version readied for release, on the horizon there's new incompatible changes being planned for the next version. The OpenRC maintainers in Gentoo have always chosen to wait until OpenRC settles down a little bit. Now with the plan to drop support for certain features (ADSL and PPP support in the networking code), it's going to rewrite more Gentoo people to step up to develop and maintain this code. rp-pppoe support should be removed because its scripts don't work well under baselayout, but are you sure OpenRC mantainers also plan to drop generic PPP support? signature.asc Description: OpenPGP digital signature
[gentoo-dev] ISDN packages need some love
ISDN packages from net-dialup herd were neglected for more than a year. Stefan Briesenick is our current ISDN developer but he apparently lost interest in them. If you're interested in maintaining these packages and you're already a developer, feel free to join net-dialup team and handle their bugs. If you're not a developer and you want to become one, I'm willing to be your mentor. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On 10/9/09 7:57 PM, Matthias Schwarzott wrote: * does new scripts already can do all that was possible with net.* ? No. PPP is not compatible with the new scripts. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham wrote: Why can't the simple little default .bash_profile from /etc/skel be put into /root as well? $HOME directories shouldn't be touched by emerge. This is the user's turf. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] meaning of sqlite/sqlite3 use flag
Mike Frysinger wrote:
how about 'sqlite' means you want sqlite irregardless of version ... then
sqlite-2 either gets punted from apr-util or it gets a local USE
flag 'sqlite-old' for older cruft
Wouldn't be better to determine what version of sqlite should be used
based on the version of sqlite currently installed on the system?
Something like:
sqlite_atom=$(best_version dev-db/sqlite)
sqlite_major_version=${sqlite_atom#*/*-} #reduce it to $PV-$PR
sqlite_major_version=${sqlite_major_version%%.*} # major version
... ebuild stuff...
econf \
$(use_enable sqlite sqlite${sqlite_major_version})
Better yet, why not make an sqlite.eclass that would contain at least
get_sqlite_major_version()?
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-proxy/squidguard: ChangeLog squidguard-1.2.1-r2.ebuild squidguard-1.2.1-r1.ebuild
Christian Faulhammer wrote:
Alin Nastac (mrness) [EMAIL PROTECTED]:
Added:squidguard-1.2.1-r2.ebuild
Removed: squidguard-1.2.1-r1.ebuild
Log:
Fix regular expresion matching (#193712).
[...]
unpack ${A} || die unpack problem
unpack will die on its own.
make prefix=/usr INSTDIR=${D} install || die make
install has failed
emake not possible?
Both suggestions have been applied. Thanks!
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openswan: ChangeLog openswan-2.4.9-r1.ebuild openswan-2.4.9.ebuild
Mike Frysinger wrote:
On Wednesday 26 September 2007, Donnie Berkholz wrote:
On 08:14 Wed 26 Sep , Alin Nastac (mrness) wrote:
mrness 07/09/26 08:14:22
Modified: ChangeLog
Added:openswan-2.4.9-r1.ebuild
Removed: openswan-2.4.9.ebuild
Log:
Fix erroneous creation of rundir and subsysdir (#193824). Sanitize the
ebuild code. (Portage version: 2.1.2.12)
1.1 net-misc/openswan/openswan-2.4.9-r1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openswan/openswa
n-2.4.9-r1.ebuild?rev=1.1view=markup plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openswan/openswa
n-2.4.9-r1.ebuild?rev=1.1content-type=text/plain
pkg_setup() {
linux-info_pkg_setup
if kernel_is 2 6; then
einfo This ebuild will set ${P} to use 2.6 native IPsec
(KAME).
einfo KLIPS will not be compiled/installed.
MYMAKE=programs
elif kernel_is 2 4; then
if ! [ -d /usr/src/linux/net/ipsec ]; then
This isn't ROOT-safe.
it should be using the vars from the linux eclasses anyways ...
-mike
fixed in cvs. thanks!
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-filter/dspam: ChangeLog dspam-3.8.0-r7.ebuild
Donnie Berkholz wrote:
On 11:30 Sun 30 Sep , Alin Nastac (mrness) wrote:
1.1 mail-filter/dspam/dspam-3.8.0-r7.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/mail-filter/dspam/dspam-3.8.0-r7.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/mail-filter/dspam/dspam-3.8.0-r7.ebuild?rev=1.1content-type=text/plain
if use mysql || use postgres ; then
myconf=${myconf} --enable-preferences-extension
fi
I think you could use use_enable() or use_with() for many of these.
$(use mysql || use postgres use_enable virtual-users)
According to bash manual, has a greater precedence than ||. That
would translate in:
$(use mysql || (use postgres use_enable virtual-users))
which will result in use_enable virtual-users being enabled only when
USE=-mysql postgres.
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-filter/dspam: ChangeLog dspam-3.8.0-r7.ebuild
Donnie Berkholz wrote: On 08:58 Mon 01 Oct , Alin Năstac wrote: According to bash manual, has a greater precedence than ||. That would translate in: Where'd you see that? Here's my man page: A list is a sequence of one or more pipelines separated by one of the operators ;, , , or ||, and optionally terminated by one of ;, , or newline. Of these list operators, and || have equal precedence, followed by ; and , which have equal precedence. Oh, now I see. You're reading about precedence in [[ ]] blocks, which aren't being used here. OK, I misread the manual, but even if and || have same precedence, bash manual says: The control operators and || denote AND lists and OR lists, respectively. An AND list has the form command1 command2 command2 is executed if, and only if, command1 returns an exit status of zero. An OR list has the form command1 || command2 command2 is executed if and only if command1 returns a non-zero exit status. The return status of AND and OR lists is the exit status of the last com- mand executed in the list. In this case, $(use mysql || use postgres use_enable virtual-users) will result in use_enable virtual-users being executed if and only if USE=-mysql postgres. See this pseudocode: if use mysql do nothing else if use postgres use_enable virtual Wouldn't be best to die in pkg_setup if USE=virtual-users -mysql -postgres ? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-filter/dspam: ChangeLog dspam-3.8.0-r7.ebuild
Donnie Berkholz wrote: On 10:11 Mon 01 Oct , Alin Năstac wrote: In this case, $(use mysql || use postgres use_enable virtual-users) will result in use_enable virtual-users being executed if and only if USE=-mysql postgres. See this pseudocode: No if use mysql succeeds, || use postgres is skipped entirely and we go straight to the use_enable. It's considered directly in order with no precedence. You're right again. :-[ if use mysql do nothing else if use postgres use_enable virtual Wouldn't be best to die in pkg_setup if USE=virtual-users -mysql -postgres ? It's better to do something smart than to force interactivity. In this case, you as the maintainer would decide whether this USE combo meant the user wanted virtual-users (if so, forcibly enable one of mysql or postgres), or whether the user definitely did not want to pull in a database (if so, force off virtual-users). I cannot force mysql or postgres dependency just because user enabled virtual-users flag. IMO this case would definitely qualify for a pkg_setup die because virtual-users is a local useflag. By selecting virtual-users without enabling mysql or postgres storage backend, the user proved to be clueless and ebuild should provide the much needed clue. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-filter/dspam: ChangeLog dspam-3.8.0-r7.ebuild
Donnie Berkholz wrote:
On 10:43 Mon 01 Oct , Alin Năstac wrote:
Donnie Berkholz wrote:
It's better to do something smart than to force interactivity. In this
case, you as the maintainer would decide whether this USE combo meant
the user wanted virtual-users (if so, forcibly enable one of mysql or
postgres), or whether the user definitely did not want to pull in a
database (if so, force off virtual-users).
I cannot force mysql or postgres dependency just because user enabled
virtual-users flag.
IMO this case would definitely qualify for a pkg_setup die because
virtual-users is a local useflag. By selecting virtual-users without
enabling mysql or postgres storage backend, the user proved to be
clueless and ebuild should provide the much needed clue.
One way to proceed is to not have both mysql and postgres as USE flags.
Have one as a flag, and have negation of that flag mean to use the
other. Does that make sense for this package, or can they both
reasonably be used at the same time?
sqlite, mysql and postgres useflags controls the storage backend drivers
installed by this package. dspam can be installed with multiple storage
drivers, but only one can be active and it is selected through its
configuration file.
I strongly discourage dying here; do something smart and log a warning
to the user about it.
okay, how about this code:
if use mysql || use postgres; then
myconf=${myconf} $(use_enable virtual-users)
else
myconf=${myconf} --disable-virtual-users
use virtual-users ewarn virtual-users support has been
disabled because none of the compatible storage drivers who support that
are enabled
fi
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] new syslog global USE flag
How about promoting syslog to global USE flag? In addition to the list below, I would need it in mail-filter/dspam. global use flags (searching: syslog) no matching entries found local use flags (searching: syslog) [-] syslog (dev-libs/openobex): enable syslog support [-] syslog (mail-mta/exim): defines syslog as the default log path if none is specified in the conf file. [-] syslog (net-firewall/nufw): Add support user activity logging in syslog [-] syslog (net-fs/samba): Enables support for syslog [-] syslog (net-misc/partysip): Enable syslog support signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new syslog global USE flag
Global syslog use-flag has been added. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: controlling src_test
Ryan Hill wrote:
NEWFEATURES=
for f in ${FEATURES}; do
if [[ ! $f == test ]]; then
NEWFEATURES=${NEWFEATURES} $f
fi
done
FEATURES=${NEWFEATURES}
There is a simpler way to remove a word from an environment variable:
FEATURES= ${FEATURES} # make sure every word is prefixed by a space
FEATURES=${FEATURES/ test/}
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-proxy/polipo: ChangeLog polipo-1.0.3.ebuild polipo-1.0.1.ebuild polipo-1.0.0.ebuild polipo-0.9.12-r1.ebuild
Donnie Berkholz wrote:
On 15:38 Fri 02 Nov , Alin Nastac (mrness) wrote:
1.1 net-proxy/polipo/polipo-1.0.3.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-proxy/polipo/polipo-1.0.3.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-proxy/polipo/polipo-1.0.3.ebuild?rev=1.1content-type=text/plain
pkg_setup() {
enewgroup polipo
enewuser polipo -1 -1 /var/cache/polipo polipo
}
...
pkg_preinst() {
pkg_setup
}
What's up with this?
You have to create users and groups in both pkg_ functions:
- pkg_setup : when installation is performed the usual way, through
compilation
- pkg_preinst: when installed from binary package (-k)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-proxy/polipo: ChangeLog polipo-1.0.3.ebuild polipo-1.0.1.ebuild polipo-1.0.0.ebuild polipo-0.9.12-r1.ebuild
Donnie Berkholz wrote: On 10:37 Sat 03 Nov , Alin Năstac wrote: You have to create users and groups in both pkg_ functions: - pkg_setup : when installation is performed the usual way, through compilation - pkg_preinst: when installed from binary package (-k) You shouldn't, all pkg_* functions should always be run regardless of binary or source package. File a portage bug if pkg_setup() isn't getting run, don't work around it. If that is true (dunno, I didn't tested it yet) then someone should correct http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml . Quote from the aforementioned document: pkg_setup Use this function to perform any miscellaneous prerequisite tasks. This might include checking for an existing configuration file. If it is necessary to add users here, you must also do this check in pkg_preinst() before the package gets installed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Good-bye
Seemant Kulleen wrote: The time has finally come for me to resign from Gentoo. A sad day for Gentoo :-( May the Force be with you! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]
Mike Frysinger wrote: 3. Should Gentoo even continue to support mips? i see dropping keywords as a very last resort. getting a port *back* into the tree is a *tremendous* amount of work (i went through it and it was hell), while keeping ~arch alive is a sliver of effort and generally not a blocker for package maintainers. How about arm, s390 and sh arches? If I'm not mistaken, you are the only one taking care of these arches and apparently you loosed interest in maintaining them. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] sqlite/sqlite3 useflag inconsistency
Petteri Räty wrote: Benedikt Morbach kirjoitti: In my humble opinion it would be nice to have a greater degree of control by separating this into two useflags, sqlite2 and sqlite3, just like e.g. qt3 and qt4 Probably. Even better would be to get rid of sqlite2 but that probably doesn't happen any time soon. I understood this will be the case, so I removed sqlite2 support from mail-filter/dspam even though it could support both versions. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] sqlite/sqlite3 useflag inconsistency
Petteri Räty wrote: Alin Năstac kirjoitti: Petteri Räty wrote: Benedikt Morbach kirjoitti: In my humble opinion it would be nice to have a greater degree of control by separating this into two useflags, sqlite2 and sqlite3, just like e.g. qt3 and qt4 Probably. Even better would be to get rid of sqlite2 but that probably doesn't happen any time soon. I understood this will be the case, so I removed sqlite2 support from mail-filter/dspam even though it could support both versions. If a program supports both then go with sqlite3. The things is that there are sqlite2 only things left. I don't have much interest in sqlite2. If a program supports only sqlite2, shouldn't sqlite? ( =dev-db/sqlite-2* ) be used as dependency atom? signature.asc Description: OpenPGP digital signature
[gentoo-dev] detecting if a file is used or not
How could I detect in a init script if a socket file is used or not? I need to be sure I can delete it before starting the service. I would hate to add sys-process/psmisc to RDEPEND just for this (fuser seems to be the only way of doing that). signature.asc Description: OpenPGP digital signature
[gentoo-dev] last rites for net-dialup/{mclient,mserver,linesrv,xlc}
Packages in $subj will be removed in 30 days because: - upstream is dead (for years in the case of the first 2 packages) - I don't think they have even one gentoo user (who would be crazy enough to install gentoo while using a dialup connection?) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] lastrite: dev-cpp/libherdstat and app-portage/herdstat
Tiziano Müller wrote: # Tiziano Müller [EMAIL PROTECTED] (07 Jun 2008) # Various bugs and dead upstream # herdstat: 164254, 184035, 222887 # libherdstat: 119589, 206876 # Masked for removal in 30 days app-portage/herdstat dev-cpp/libherdstat Sorry people, but we (Halcy0n and I) really don't have the time nor the will to maintain this package (dev-cpp/libherdstat) anymore without an upstream. glimpse can be used to search stuff in all metadata.xml files. All you have to do is: mkdir metasearch echo '*' metasearch/.glimpse_exclude echo metadata.xml metasearch/.glimpse_include glimpseindex -i -B -H metasearch portage-dir glimpse -H metasearch regex signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat
Diego 'Flameeyes' Pettenò wrote: Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] writes: The tree's small enough that grep -r gives enough performance. Even better grep */*/metadata.xml the tree is not big enough that it exceeds the maximum arguments from bash. According to my local copy, we have 12876 metadata.xml files. Something tells me that your command line will exceed the maximum command line length supported by any shell ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
Peter Volkov wrote: В Сбт, 21/06/2008 в 10:56 +0200, Albert Zeyer пишет: Perhaps install a script which automatically takes the CVS comment when some of these files is changed and adds this comment automatically to the ChangeLog? Some days ago Diego (flameeyes) suggested to write script which will abort commit in case ChangeLog is not filled. Taking into account a number (about 1 commit per day(!)) of developers who forgive to use echangelog I think this is the only way to go if we want that ChangeLog's to be useful... How about fixing the right problem instead forcing devs to complete yet another step? The right way of fixing that is by creating changelogs automatically, based on cvs commit comments. signature.asc Description: OpenPGP digital signature
[gentoo-dev] strange portage behaviour
Portage no longer install ._cfg_* files for the CONFIG_PROTECTed files touched by the user. Even if I remove the package and reinstall it again, the protected file will remain like it is. Can someone enlighten me? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] strange portage behaviour
Zac Medico wrote:
It's common for people get get confused like this by the confmem
behavior that's built into portage's merge process. You can use
--noconfmem to disable it.
Ah, I didn't knew we had this option, thanks for the info. However, a
user complained in [1] that net-dialup/ppp failed to update its
/etc/ppp/ip-{up,down} scripts.
I don't know exactly how it works, but I presume portage will install
the protected files if the checksum of the new file present in $D is
different than the one who was there when the old version were
installed, right?
[1] http://forums.gentoo.org/viewtopic-t-699957.html
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] unwanted CVS keyword substitution on patch files
Every once in a while, I get bitten by the $Id keyword replacement done on patches in $FILESDIR. Can we do something to fix this annoyance? If repoman cannot add -kb for *.patch and *.diff files, at least it should verify you have added those files with this options. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-firewall/ipp2p maintainer needed
Jakub Moc wrote: net-firewall/ipp2p ebuild is outdated and useless w/ 2.6.17+ kernels (Bug 141700). It needs a bump to 0.8.2 and some active maintainer, eradicator apparently doesn't care. I've tooked this one. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-misc/openswan needs a maintainer
Jakub Moc wrote: This thing has been neglected for ages, needs a version bump and has lots of stale open bugs: http://bugs.gentoo.org/show_bug.cgi?id=62970 http://bugs.gentoo.org/show_bug.cgi?id=105272 http://bugs.gentoo.org/show_bug.cgi?id=124272 http://bugs.gentoo.org/show_bug.cgi?id=127288 http://bugs.gentoo.org/show_bug.cgi?id=127314 http://bugs.gentoo.org/show_bug.cgi?id=134484 http://bugs.gentoo.org/show_bug.cgi?id=137737 http://bugs.gentoo.org/show_bug.cgi?id=147116 If you are using IPSec and would like to make it working again on Gentoo, please step up and see the above bugs. Since no one else stepped up (spooky...), I will take the maintainership. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-misc/openswan needs a maintainer
Lars Weiler wrote: Will look into it during the next days for sure ;-) (I already hit that kernel version bug on one machine.) I think strongswan's ebuild should be simplified. I will bump openswan to 2.4.7 in a couple of days. Please use it as starting point for your bump. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] (open|strong)swan ipsec-config-path
Lars Weiler wrote:
* Alin Năstac [EMAIL PROTECTED] [06/12/07 08:37 +0200]:
I think strongswan's ebuild should be simplified.
I will bump openswan to 2.4.7 in a couple of days. Please use it as
starting point for your bump.
While we are at it: Should we keep installing the config
into /etc/ipsec/ and create symlinks from /etc/ipsec.d -
/etc/ipsec/ipsec.d ? I think we are the only distro which
installs the configs into /etc/ipsec, some others place
ipsec.{conf,d,secrets} just into /etc
I find that useful. It is more easy to find ipsec related files this way.
Don't forget you can include other files into ipsec.conf. Custom updown
scripts can also be grouped this way.
If you feel we should drop /etc/ipsec directory, a poll on forums might
tell us what users want.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] punt mingw ebuilds out of the tree and into a mingw overlay
Mike Frysinger wrote: however, i think it's a lovely idea to open a mingw overlay and populate the sucker until it's stuffed full of crap for people to use I kinda need dev-util/nsis, but moving mingw stuff to an overlay would be fine by me as long as the overlay is *official*. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] punt mingw ebuilds out of the tree and into a mingw overlay
Mike Frysinger wrote: why do you feel the need to label crap as official ? Because I consider it should be maintained by Gentoo devs. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] punt mingw ebuilds out of the tree and into a mingw overlay
Mike Frysinger wrote: On Wednesday 20 December 2006 03:59, Alin Năstac wrote: Mike Frysinger wrote: why do you feel the need to label crap as official ? Because I consider it should be maintained by Gentoo devs. as i said, that's up to you and other devs to decide ... it's location doesnt matter; if you care add yourself to the overlay and fix stuff What is your motivation ? Do you want to move relatively unpopular branches into their own overlays for keeping the base tree lean and mean? If the answer is yes, I totally agree with you. However, I don't want to see Gentoo crippled by this decision. I wanna official overlays in which commit access is automatically given to any Gentoo dev (automatically == no human interaction needed). Those should represent optional branches available to a more specialized audience. nsis might be garbage for you, but for me it is a valuable tool that helps me at work. For those of us eager to remove it, nsis compiles as a Linux program, even though the output of its execution happens to be a Windows install program. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] punt mingw ebuilds out of the tree and into a mingw overlay
Mike Frysinger wrote: none of this belongs in the tree as we do not have a windows port But dev-util/nsis installs a native application - makensis - which creates win32 setups. I think this excludes nsis from your list. I find it useful because I can automatize updates of my win32 setups on server (Gentoo, of course). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new herd suggestion: religion
Steve Dibb wrote: @devs, I'd like to propose a new herd: religion. The herd would take care of the Bible and religious software along with any genealogy programs in the tree, which there actually are a few of. Sword, gnomesword, sword modules, bibletime, gramps would all fall under the responsibilty of the herd. Maybe you should create a separate category as well such as religion-christian :-D signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Network configuration and bash
Roy Marples wrote: This email is about network configuration. Before I joined Gentoo, network configuration was done in bash arrays like so (note, that the variable name was changed in baselayout-1.11) ifconfig_eth0=( 10.1.1.1 netmask 255.255.255.0 10.1.1.2 netmask 255.255.255.0 ) This is all well and good, but only bash and zsh can use it. Infact I'm guilty as I embraced arrays and used them as the basis for our entire network scripts. They have also served us well, but as they are also array based they will have to be re-written too. So, to free baselayout of forcing bash down our throats I/we am/are looking at re-writing our network setup, including configuration. How about leaving baselayout depending on bash and make baselayout-lite do whatever you want instead? Such an upgrade will be a major pita for our entire user base, unless of course you make conf.d/net syntax transition as easy as running dispatch-conf. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Distrowatch
Caleb Cushing wrote: Perhaps they're more interested in generating ad revenue from whipped-up scandals... or maybe they have a point. distrowatch hpd ranking show's us down from a few years ago we were 7 in '04 9 '05 10 '06 11-12 '07 Yeah, the good old days when Gentoo was the new cool kid in block were over. right now were 12 going up probably from all the sites saying negative things. funny sabayon a gentoo fork and overlay is in 8. I know these statistics aren't 100% accurate (given how they're generated) but maybe they mean something. If you analyze a moment what kind of users navigate through available distros on DW, you will actually see that our rank is better than before. The users that end up on DW, searching for a new distro to fit their needs, are looking mostly for a desktop distro. Since Sabayon is mostly a pre-installed Gentoo build for desktop purposes, we could claim that our score is actually Gentoo.HPD + Sabayon.HPD. On the last 6 months, this would place us on the 4th rank. Not bad for a meta-distribution, isn't it? :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Kevin F. Quinn wrote: The problem I have with NOTABUG is pretty much the same problem I have with INVALID - it's not as severe, but it still does the same thing to the user (i.e. slaps him with a wet fish rather than a frozen one). Maybe, just maybe, the problem is not with the resolution name, but with peeps who cannot accept they could be wrong. For the most of us, INVALID doesn't mean YOUAREAMORON. A NOTOURBUG resolution would be pointless. I cannot imagine a possible scenario in which I could choose such resolution over the existing ones. Probably you want it as a replacement for UPSTREAM? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Christopher Sawtell wrote: On Sun, 25 Mar 2007, Jakub Moc wrote: Kevin F. Quinn napsal(a): [snip] See, I don't really care how the reporter feels, if something's not a bug, then it's not a bug. In which case it must be a feature, so why not use the keyword FEATURE? Why would we need a keyword for that? We already have enhancement as a possible value of the severity field. imnsho it's very important not to cause deliberate offense, because doing so perpetuates the idea that FOSS movement people are an unpleasant bunch of individuals. This causes users to make the choice of using computer products from elsewhere, and developers to spend their free time doing other things. FOSS _is_ a bunch of individuals, each with their own agenda. Whether they're unpleasant or not, it is a subjective issue. One of the FOSS strengths is always telling the truth, which applied to invalid bugs translates as closing them with INVALID resolution. If the reporter takes it as a personal offense, it is by all means his problem, not ours. Someone once said (Linus maybe?) Linux is user-friendly, only chooses its friends more carefully. signature.asc Description: OpenPGP digital signature
[gentoo-dev] net-dialup/slirp removal
Anyone have a good reason to keep net-dialup/slirp in the tree? The package installation generates numerous QA notices and most keywords are -arch. signature.asc Description: OpenPGP digital signature
[gentoo-dev] net-dialup/pppoed pending for removal
pppoed is a user space implementation of PPPoE, needed only for kernel versions 2.4. Since we don't have such kernel versions in our tree anymore, I've hard masked it and I intend to remove it on May the 15th. signature.asc Description: OpenPGP digital signature
[gentoo-dev] net-dialup/slirp pending for removal
# Alin Năstac [EMAIL PROTECTED] (17 Apr 2007) # Pending for removal on 17 May 2007 # Reasons: #- all keywords are -arch (except for x86) #- source has numerous QA violations #- unmaintained for years net-dialup/slirp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [POLICY] Keywording/Stabilizing Bug Assignment Policy
Stefan Schweizer wrote: In my opinion the last architecture should also remove the old ebuild they have just made obsolete by stabling/keywording the new version, since they commit to the directory anyway. This might be good, but also bad. I usually let the older stable version linger in our tree for an extra month or more, just to be sure I didn't inserted some horribly broken version that cannot be rolled back easily by the users. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: File collisions
Rob C wrote: On 19/04/07, *Christian Faulhammer* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Steve Long [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: On the issue of QA, I think enabling FEATURES=collision-detect by default would do a lot more good at this stage than test. Arch teams normally have collision-protect enabled when doing keywording/stablingin my eyes this is sufficient. V-Li Its obviously not, Many users are reporting file-collisions on a weekly basis. So either this isn't sufficient or the arch teams are not acting as you describe. The fact you can install a package using collision-detect is not a guarantee that the package don't collide with some other package you don't have installed on your test box (or with a package installed on your box but not with the right USE flags). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bye Gentoo!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bryan Østergaard wrote: It's with a bit of sadness but also a bit of relief that I'm finally retiring from Gentoo. I'm sorry to see another key developer leaving Gentoo. :( I hope you'll come back someday... ;) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXj4AozkEeOnWD00RApXkAKDVhdHijzlfGkI0Ul0W5445IOQ/VwCfYfjj QpdDAZ67VXamxCJj/HI6erY= =jqpG -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New (old) Developer: Deedra Waters (dmwaters)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrej Kacian wrote: Hah, yet another proof that Gentoo is addictive. I wonder when we will be forced to put stickers like Gentoo may affect your social life on our media :-) Welcome back, Deedra! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZYMUozkEeOnWD00RAmAOAKCCpUYKrbA6hv9iV81ngvEdWmMcQwCg1S/u S8NyzI1tHAF1kBlPWHX9c6c= =vGrj -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Smoother moderation scheme?
Ken wrote: I may just be a lowly Arch Tester, but I don't necessarily see why individual dev's who are bothered by the noise can't just set up their own killfiles and filters. Do you have a solution to filter flamefests out of a ml? If you do, please share it with the list. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: ML changes
Steve Long wrote: Donnie Berkholz wrote: Matthias Langer wrote: no offense, but this is one of the worst proposals i've ever read on this list; why? because, one of gentoo's major problems is that it is becoming more and more a toy exclusively for its own developers. Gentoo's always been exclusively for the developers. Nobody's paying us to do this. It just so happens that the things we want to do also benefit other people, and so they use them. It also happens that bugs are reported, and patches provided, by users. Not to mention documentation written, support provided on irc and in forums, which are the envy of every OS out there. Oh and the small matter of defending Gentoo against detractors, the most telling of which are those who criticise elitist ``devs''. Are you really claiming that Gentoo could possibly function as an organisation without the users? No, Gentoo *the organisation/community* wouldn't be where it is today without its users, that is for sure. However, Gentoo devs - as individuals - don't owe to community anything. Quite the contrary, if I may say so myself. That being said, all devs are working on our beloved distro having the common interest in mind, just it gets harder and harder to keep your morale/motivation high while you are exposed to rants and flame wars like this. signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
I was asked to discuss here a portage enhancement proposed by me [1].
Basically I need a pkg_create() that will be executed only in the
context of the upcoming ebuild ${PF}.ebuild create command.
The package where I need it is app-mobilephone/bitpim. The upstream doesn't
offer a source tarball, so I need to construct it myself from their svn
repository. Up till recently, I used some hackery in pkg_setup() to
create it
(see the ebuild), but now ebuild $PF.ebuild setup verify the digest before
running pkg_setup().
[1] http://bugs.gentoo.org/show_bug.cgi?id=185567
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
Marius Mauch wrote: Two questions: - are there more packages that could benefit from this? None that I know of. However, there might be other similar packages without a source tarball (slim chance, but quite possible). At first, I asked upstream to provide such tarball, but I got refused because SourceForge file release process is far too annoying. As a side note, if bitpim wasn't such a fairly popular package, I wouldn't even bother with it (personally I don't use it). - is there a particular reason this has to be integrated into the ebuild and should not be handled by an ordinary script? There are 2 reasons: a) convenience - no need to pass version to the script b) maintainability - easy to take over when I will be gone P.S: The name proposed by me isn't exactly right, as Mike already remarked on the bug. I suggest to use src_create as function name. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
Jan Kundrát wrote: Alin Năstac wrote: The upstream doesn't offer a source tarball, so I need to construct it myself from their svn repository. If you're creating a live ebuild, there are already existing eclasses that works from the user's POV. I'm not speaking about live ebuilds, only about building a source tarball for a specific version where upstream doesn't offer such thing. If your aim is to create an ebuild for a specific version, you might as well checkout stuff yourself and let Gentoo mirror the generated tarball (your mail doesn't talk about RESTRICT=fetch). If you let Gentoo mirror the tarball, users are likely to be happier because they'll get the file faster and in a more reliable way. What I want is a function that creates the source tarball, based on whatever developer needs for that (the most usual case is a tag export from a svn/cvs repository). The tarball will be placed on Gentoo mirrors at the end (users will not run this new function, only the maintainer). See app-mobilephone/bitpim ebuild example, it will speak for itself. This can be solved also through an external script, but IMO this solution is ugly. Ebuilds should contain whatever is needed for their maintenance. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
Luca Barbato wrote: I'm not sure how many special cases/option would be necessary for such script, like exclude dir, one tar per dir and so on. The process of creating the tarball is quite specific to the package in question, therefore you cannot make an universal function that does that. See the app-mobilephone/bitpim maketarball() and you'll see. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
Luca Barbato wrote: My idea is to have your overlay with live ebuilds and a tool to make a release out of it. All the messy stuff remains in pkg_setup/src_unpack all you need to do then is to iterate the workdir and make tarballs of what you find there. Sounds good enough? Basically you propose to have a src_whatever function that will work as a substitute for src_unpack() in case you don't find the tarball on mirrors, isn't it? That could work too, but what if, depending on some useflag, I need to patch the source tree? Because the new function must be capable to replace src_unpack, you will have to add a command like use foo epatch ... at the end of the new function. If foo useflag is enabled on your system, the external tool that build the tarball will create it based on a wrongly patched source tree. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites for net-dialup/l2tpd
# Alin Năstac [EMAIL PROTECTED] (19 Jul 2007) # Dead upstream, forked in net-dialup/xl2tpd. # Pending removal 19 Sep 2007 net-dialup/l2tpd signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
Duncan wrote: If the user sees it, it means the maintainer failed to do his job. The tarball couldn't have even been changed upstream without notice, since it'd then fail the sanity/security/signing checks. I think that's the suggestion, that it be mandatory for maintainers to deal with, and the user shouldn't ever see it. You seems to forget the fact that Gentoo is a source distro and as such, emerge foo can fail on users boxes while on maintainer's box works like a charm. As a maintainer, you cannot possibly test all the USE/installed libs/CFLAGS combinations. I don't say maintainer shouldn't fix whatever problems has his package, but don't be in such a hurry to blame someone when you happen to find a bug. signature.asc Description: OpenPGP digital signature
[gentoo-dev] last rites for net-dialup/l2tpd
# Alin Năstac [EMAIL PROTECTED] (25 Aug 2007) # Has been inactive for several years; scheduled for removal in 60 days. # Please use net-dialup/xl2tpd (fork actively maintained by Xelerance) # or use net-dialup/rp-l2tp. net-dialup/l2tpd signature.asc Description: OpenPGP digital signature
[gentoo-dev] /etc/ppp/(ip-up.d,ip-down.d} directories
A gentoo user requested in bug 190143 [1] to change the way pppd deals
with interface up/down events. He requested to break current
ip-up/ip-down functionality into different scripts contained in
/etc/ppp/(ip-up.d,ip-down.d}.
What do you think about? Is it worth it?
Personally I think it is a good idea, but I have reserves when it comes
to user defined {ip-up,ip-down}.local scripts. IMO the best way to solve
this is to add this code to pkg_postinst():
if [ -f ${ROOT}etc/ppp/ip-up.local ]; then
mv ${ROOT}etc/ppp/ip-up.local ${ROOT}etc/ppp/ip-up.d/99-local
fi
[1] http://bugs.gentoo.org/show_bug.cgi?id=190143
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] /etc/ppp/(ip-up.d,ip-down.d} directories
Thomas Anderson wrote: I do have one question though, how will this affect programs like pppconfig? Programs such as these may not look at these scripts and break. Pretty much my one worry is about breaking compatibility with other programs in the tree. pppconfig do not care what the /etc/ppp/ip-up script is doing, nor any other package AFAIK. The current scripts handle /etc/resolv.conf generation in our own way. From this point of view, it wouldn't matter if you use a dialer program, baselayout PPP support or run pppd by yourself. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] /etc/ppp/(ip-up.d,ip-down.d} directories
W.Kenworthy wrote: From a users point of view - dont do it. Stay simple and standard (i.e., equal to upstream as per the gentoo philosophy). I don't see it: a) The current ip-up ip-down scripts are provided by us, not by upstream. b) If this is going to be implemented, it will be done by altering our ip-* scripts, not by patching the pppd. c) Users were not supposed to modify these scripts, but make their own ip-*.local scripts. If these scripts exists, they are going to be automatically moved into ip-*.d directories. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: net-proxy/squid needs your love
Hi Markos, I'm very busy in real life, but I'll try to solve all squid issues this week. Btw, [2] and [3] were solved from net-proxy's perspective and [1] wasn't fixed by upstream AFAIK. Cheers, Alin On 04/08/2010 13:50, Markos Chandras wrote: Hi there net-proxy/squid needs your love. Bug #311927 and Bug #304751 require a version bump. Our user community did an excellent job there providing an improved ebuild for that. Furthermore there are several open security bugs wrt squid [1][2][3][4]. net-proxy herd what is your status? Security bugs should be your first priority. If you are unable to maintain certain packages you could ask for help instead of staying quiet. Maybe we should list this package as maintainer-needed and request some proxy-maintainers from our user community. What do you think about that? @Council: Yet another example that we need to track the status of every single project in order to have a clear picture of which projects are active and which are dead @QA: Should step up and commit these ebuilds just to get rid of the security bugs which, frankly, don't look that good ( distro wise ). I know technically is not our job, but we need to step up here and either fix the security bugs since net-proxy can't do that, or mask this package which is a no-go. [1] http://bugs.gentoo.org/261208 [2] http://bugs.gentoo.org/279379 [3] http://bugs.gentoo.org/279380 [4] http://bugs.gentoo.org/301828
[gentoo-dev] Lastrite: net-mail/vmailmgr and vmailmgr-tools
# Alin Năstac mrn...@gentoo.org (13 Nov 2011) # Dead project, masked for removal in 30 days net-mail/vmailmgr net-mail/vmailmgr-tools signature.asc Description: OpenPGP digital signature
