[gentoo-dev] Last rites: mail-client/postler
# Christoph Mende ange...@gentoo.org (09 Apr 2013) # Fails to build (bug #449860), abandoned by upstream. # Removal in 30 days. mail-client/postler
[gentoo-dev] Packages up for grabs
Hi all, since I don't own a Samsung laptop anymore and my new laptop has Intel graphics, I'd like to drop maintainership of the following packages: app-laptop/easy-slow-down-manager (belongs to samsung-tools) app-laptop/nvidiabl app-laptop/samsung-tools net-wireless/ndiswrapper They're all really low traffic, nvidiabl and ndiswrapper are the only ones with really active upstream (i.e. bumps every few weeks/months). None of those has open bugs. So, feel free to grab any if you use them.
Re: [gentoo-dev] rfc: location of portage tree
On Wed, Mar 28, 2012 at 8:43 PM, Aaron W. Swenson titanof...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/27/2012 03:05 PM, William Hubbs wrote:
All,
I know this has come up before, but I don't really recall what the
specific objections were.
IMO the portage directory doesn't belong under /usr at all. I was
chatting with another developer who uses
/var/cache/portage/{tree,distfiles}, and I'm thinking about
switching my default setup to do this.
I realize that historically the portage tree has been installed
under /usr, but Can we consider changing this default for new
installations and providing instructions for users for how to get
the portage tree out of /usr? William
So, we're all getting way off topic and discussing reorganizing the
whole enchilada.
How about we all agree or disagree on the primary point: The Portage
tree doesn't belong in /usr.
I believe that it does belong under /var/cache/.
I believe it's /var/lib/name. Here's what FHS says:
/var/cache is intended for cached data from applications. Such data is
locally generated as a result of time-consuming I/O or calculation.
The application must be able to regenerate or restore the data. Unlike
/var/spool, the cached files can be deleted without data loss.
And:
/var/lib/name is the location that must be used for all distribution
packaging support.
[gentoo-dev] Packages up for grabs
Hi, I'm currently lacking time for some packages, so I'm looking for someone to take over a few, most notably: - net-misc/curl - net-dns/c-ares (preferably both together) And while we're at it there's also some lower maintenance packages I'd like to get rid of just because I don't use them anymore: - app-misc/granule - dev-cpp/libassa (was added for granule, not sure if it's used by anything else, might be last rited soon if upstream doesn't update it) - media-gfx/shotwell - media-sound/audio-entropyd - net-wireless/ndiswrapper - sys-fs/gt5 - x11-misc/launchy - x11-misc/transset-df If you want any of those, just remove me from metadata and add yourself. Thanks.
Re: [gentoo-dev] Removing herdno-herd/herd?
On Sat, 2011-09-10 at 11:22 +0300, Markos Chandras wrote: On 10/09/2011 11:15 πμ, Mike Gilbert wrote: I would say that each package needs to have at least one herd or maintainer (which may be maintainer-needed or maintainer-wanted). Well, you can easily assign your packages to dozen of herds and still be the only one who touches them. So what's the point? Just to pretend that the package is supported by an entire herd? I don't think that's what Mike was trying to say. He prolly wanted to say that it's required to have at least one of maintainer or herd, i.e. having one tag for m-n or the real maintainer is enough (no extra no-herd entry). Sounds pretty reasonable to me. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] contribution to colorgcc
On Sun, 2011-08-07 at 11:45 +0200, Michał Górny wrote: On Sat, 6 Aug 2011 20:48:09 -0400 Dmitry Goncharov dgoncha...@users.sf.net wrote: Is anybody maintaining dev-util/colorgcc? I'd like to contribute certain improvements for gcc and also support for the sun, ibm, hp and intel compilers. I pushed the current version to https://github.com/dgoncharov/colorgcc. You can pull from there or i can submit a set of patches. I suggest you start with pinging upstream. The homepage [1] indicates the project is on github too [2], so I guess you can go with a pull request if you forked it. Also, please use github's fork feature, so you don't lose the entire history. And, like Michał said, you really should take your changes upstream, they seem pretty active (last commit in June). They also quite often accept pull requests if you look at the history. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due dragonheart retirement
On Wed, 2011-07-20 at 18:06 +0200, Christoph Mende wrote: On Wed, 2011-07-20 at 17:08 +0200, Pacho Ramos wrote: Due dragonheart retirement the following packages need a new maintainer: net-misc/curl I'll take one of those And net-dns/c-ares too. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due dragonheart retirement
On Wed, 2011-07-20 at 17:08 +0200, Pacho Ramos wrote: Due dragonheart retirement the following packages need a new maintainer: net-misc/curl I'll take one of those signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Formal Adopt a Package Program
On Mi, 2011-06-22 at 18:33 +0300, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 22/06/2011 06:19 ??, Dane Smith wrote: - gpg control packet All, [..] Thanks! [1] http://dev.c1pher.net/index.php/2011/03/c1phers-adopt-a-package-program/ Hi Dane, I tried to do the same a year ago. Have a look here. It may help you understand why that effort did not succeed http://www.gossamer-threads.com/lists/gentoo/dev/209204 I see concerns about to-be-orphaned ebuilds where proxied maintainers only care about the ebuild for a short period. This would only be a problem with new ebuilds that will be added to the tree with a proxy maintainer. Instead of encouraging that, this project could have a goal to reduce m-n packages by assigning proxy maintainers. So no new packages, only old ones revived. Sounds reasonable to me. Although I didn't read the full thread, so please don't decapitate me if there were other concerns. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Formal Adopt a Package Program
On Mi, 2011-06-22 at 19:18 +0300, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 22/06/2011 06:47 μμ, Christoph Mende wrote: On Mi, 2011-06-22 at 18:33 +0300, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 22/06/2011 06:19 ??, Dane Smith wrote: - gpg control packet All, [..] Thanks! [1] http://dev.c1pher.net/index.php/2011/03/c1phers-adopt-a-package-program/ Hi Dane, I tried to do the same a year ago. Have a look here. It may help you understand why that effort did not succeed http://www.gossamer-threads.com/lists/gentoo/dev/209204 I see concerns about to-be-orphaned ebuilds where proxied maintainers only care about the ebuild for a short period. This would only be a problem with new ebuilds that will be added to the tree with a proxy maintainer. Instead of encouraging that, this project could have a goal to reduce m-n packages by assigning proxy maintainers. So no new packages, only old ones revived. Sounds reasonable to me. This is what treecleaners try to do. Announce the upcoming removal of a package so users can step up and maintain a package Well yes, but with such a project users might notice the packages before they're about to be removed. Also the important difference is that not one Gentoo dev does the commits, but many - whoever reads the mail/ticket/bug/whatever first. Although I didn't read the full thread, so please don't decapitate me if there were other concerns. The purpose of Dane's proposal is to push ebuilds to portage tree that you, as developer, have no interest in them at all, but users do. If the proxy-maintainer disappears, you can always leave it portage tree as m-n (assuming no open bugs) or ask treecleaners to remove it. Guess I'm proposing something different then. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On Sat, 2011-04-02 at 16:41 -0300, Alexis Ballier wrote: On Saturday, April 02, 2011 07:02:54 AM Paweł Hajdan, Jr. wrote: On 3/31/11 9:37 AM, Tomáš Chvátal wrote: Ok two versioned virtuals (0.5 0.6) are now in the tree if people need to specify the version. Thank you, but it's still not enough for chromium. The virtual uses =ffmpeg-0.6, and chromium is known to be broken with ffmpeg-0.6_p25767. We need to require =ffmpeg-0.6_p25767, not just 0.6. By the way, I still didn't have time to test with libav, but it seems that it's expected to be compatible. iirc, this dep in chromium is due to the need for libavcore, but this lib has been merged back to libavutil in latest snapshots (and thus chromium fails to build); if chromium goes back to look for the functions in libavutil, you may have chances to be compatible with 0.6 A. I've reported that upstream 2 days ago and it was fixed yesterday. I'm running chromium-11.0.696.28 against libav-0.7_pre20110327 here and it works fine. signature.asc Description: This is a digitally signed message part
[gentoo-dev] GNOME 3.0 slotting done
Hi, this is just a quick heads up, because nirbheek forced me to do it. GNOME 2.0 slot deps should be fixed after about 1,000 commits and the tree is good to go for GNOME 3.0. Everyone adding non-slot deps on gtk+ or GNOME libs will be stabbed. Thank you for your attention. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] developer profile, FEATURES=digest
On Mon, 2011-03-28 at 16:57 +0200, Thomas Kahle wrote: On 13:13 Sun 27 Mar , Paweł Hajdan, Jr. wrote: FEATURES=digest results in a scary warning and a possibly dangerous re-generation of manifests at the beginning of every emerge: * The FEATURES=digest setting can prevent corruption from being noticed. * The `repoman manifest` command is the preferred way to generate * manifests and it is capable of doing an entire repository or category at * once. However, FEATURES=digest is enabled in the developer profile, and only in that profile: $ egrep '^FEATURES=.*digest' -r /usr/portage/profiles/ /usr/portage/profiles/targets/developer/make.defaults:FEATURES=collision-protect digest multilib-strict sign splitdebug stricter test test-fail-continue userpriv usersandbox I'd like to suggest removing digest from the line above. I've been running with the developer profile and -digest in /etc/make.conf, and everything is working fine. +1. I disabled it on the first day and never had any issues. Thomas I guess the real question here is: why was it enabled? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] developer profile, FEATURES=digest
On Mon, 2011-03-28 at 13:03 -0400, Mike Frysinger wrote: On Mon, Mar 28, 2011 at 11:43 AM, Christoph Mende wrote: On Mon, 2011-03-28 at 16:57 +0200, Thomas Kahle wrote: On 13:13 Sun 27 Mar , Paweł Hajdan, Jr. wrote: FEATURES=digest results in a scary warning and a possibly dangerous re-generation of manifests at the beginning of every emerge: * The FEATURES=digest setting can prevent corruption from being noticed. * The `repoman manifest` command is the preferred way to generate * manifests and it is capable of doing an entire repository or category at * once. However, FEATURES=digest is enabled in the developer profile, and only in that profile: $ egrep '^FEATURES=.*digest' -r /usr/portage/profiles/ /usr/portage/profiles/targets/developer/make.defaults:FEATURES=collision-protect digest multilib-strict sign splitdebug stricter test test-fail-continue userpriv usersandbox I'd like to suggest removing digest from the line above. I've been running with the developer profile and -digest in /etc/make.conf, and everything is working fine. +1. I disabled it on the first day and never had any issues. I guess the real question here is: why was it enabled? because doing active development on ebuilds by definition invalidates the manifest. portage didnt use to whine about it at all. a lot easier to `emerge foo` without having to manually run `ebuild foo manifest` all the damn time. personally, i use FEATURES=digest on my development machine, but i can see how people would find this undesirable as a profile default. -mike Ah, yes, now that you mention it, I really like it that I can just repoman full instead of repoman manifest; repoman full. Although for testing I use ebuild foo.ebuild digest clean install most of the time, so it's not relevant there. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-plugins/gmpc-{q,}osd
# Christoph Mende ange...@gentoo.org (26 Mar 2011) # Unmaintained upstream and replaced by media-plugins/gmpc-libnotify # and gmpc's built in notifications. # Will be removed in 30 days. media-plugins/gmpc-osd media-plugins/gmpc-qosd
Re: [gentoo-dev] validity of manifest signing key
On Fri, 2011-03-25 at 10:55 +0100, Antoni Grzymala wrote: Thomas Kahle dixit (2011-03-25, 10:47): it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 that the validity should be 6 month. What is the protocol when the expiry date is approaching? “After size comes the expiration date. Here smaller is better, but most users can go for a key that never expires or to something like 2 or 3 years.” Can't find anything about 6 months. He prolly wanted to post http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6
[gentoo-dev] mono.eclass EAPI3(/4)
Hi,
this should make mono.eclass EAPI3 compatible, please review the
attached patch before I commit it, so you can throw your stones before
it appears on gentoo-commits. Thanks.
Index: mono.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/mono.eclass,v
retrieving revision 1.13
diff -u -b -B -r1.13 mono.eclass
--- mono.eclass 8 Mar 2009 15:46:54 - 1.13
+++ mono.eclass 24 Mar 2011 22:47:08 -
@@ -35,24 +35,26 @@
unset MONO_AOT_CACHE
egacinstall() {
+ [[ -z ${ED+set} ]] local ED=${D%/}${EPREFIX}/
gacutil -i ${1} \
- -root ${D}/usr/$(get_libdir) \
+ -root ${ED}/usr/$(get_libdir) \
-gacdir /usr/$(get_libdir) \
-package ${2:-${GACPN:-${PN}}} \
|| die installing ${1} into the Global Assembly Cache failed
}
mono_multilib_comply() {
+ [[ -z ${ED+set} ]] local ED=${D%/}${EPREFIX}/
local dir finddirs=() mv_command=${mv_command:-mv}
- if [[ -d ${D}/usr/lib $(get_libdir) != lib ]]
+ if [[ -d ${ED}/usr/lib $(get_libdir) != lib ]]
then
- if ! [[ -d ${D}/usr/$(get_libdir) ]]
+ if ! [[ -d ${ED}/usr/$(get_libdir) ]]
then
- mkdir ${D}/usr/$(get_libdir) || die Couldn't mkdir ${D}/usr/$(get_libdir)
+ mkdir ${ED}/usr/$(get_libdir) || die Couldn't mkdir ${ED}/usr/$(get_libdir)
fi
- ${mv_command} ${D}/usr/lib/* ${D}/usr/$(get_libdir)/ || die Moving files into correct libdir failed
- rm -rf ${D}/usr/lib
- for dir in ${D}/usr/$(get_libdir)/pkgconfig ${D}/usr/share/pkgconfig
+ ${mv_command} ${ED}/usr/lib/* ${ED}/usr/$(get_libdir)/ || die Moving files into correct libdir failed
+ rm -rf ${ED}/usr/lib
+ for dir in ${ED}/usr/$(get_libdir)/pkgconfig ${ED}/usr/share/pkgconfig
do
if [[ -d ${dir} $(find ${dir} -name '*.pc') != ]]
@@ -64,9 +66,9 @@
popd ${dir} /dev/null
fi
done
- if [[ -d ${D}/usr/bin ]]
+ if [[ -d ${ED}/usr/bin ]]
then
- for exe in ${D}/usr/bin/*
+ for exe in ${ED}/usr/bin/*
do
if [[ $(file ${exe}) == *shell script text* ]]
then
Re: [gentoo-dev] mono.eclass EAPI3(/4)
On Thu, 2011-03-24 at 23:48 +0100, Christoph Mende wrote:
Hi,
this should make mono.eclass EAPI3 compatible, please review the
attached patch before I commit it, so you can throw your stones before
it appears on gentoo-commits. Thanks.
Tiny update to the patch:
24/235024 @ABCD I would set ED as follows: `use !prefix has
${EAPI:-0} 0 1 2 ED=${D}`
[gentoo-dev] Packages up for grabs
Hi, I want to drop maintainership for these packages because I don't use them anymore. They all are low maintenance, most haven't had releases in over a year. If you are interested in any of those, feel free to remove me from metadata.xml: app-editors/hexedit app-misc/granule app-misc/tdfsb dev-cpp/libassa dev-libs/argtable sys-apps/pv sys-fs/gt5 x11-misc/transset-df
[gentoo-dev] Last rites: sys-apps/inotail
# Christoph Mende ange...@gentoo.org (22 Feb 2011) # Masked for removal, inotify support has been in tail -f since coreutils-7.5 sys-apps/inotail
Re: [gentoo-dev] ndiswrapper, anyone?
On Tue, Jun 22, 2010 at 10:42 PM, Samuli Suominen ssuomi...@gentoo.org wrote: there's nothing usable left in tree, it's bitrotted for too long. will be masked for removal in 30 days if nobody wants to pick it up. Well, I'm not using it, but I'd hate to see it go since I remember how I was forced to use it, so... let me take it
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/anki: anki-0.9.9.5.ebuild metadata.xml ChangeLog
On Thu, 15 Jan 2009 14:38:26 +0100 Maciej Mrozowski reave...@poczta.fm wrote: That being said, I would rather suggest adding always *precise* and *non- general* USE flags descriptions even for global USE flags (actually especially for them) as I usually found it pretty much necessary to look up ebuilds to get to know what does particular USE flag actually do, and I guess this should be avoided at all cost, especially when it does not cost a penny as maintainer actually already knows what's all about with those USE flags for particular package. That'd definitely be annoying when doing euse -i some flag and getting over 9000 hits, so let's remove the always -- Christoph Mende Gentoo/AMD64 Operational Lead and Release Engineering GPG: EE2A 454A 6A3B A2D8 E43B FF45 2A19 C3B3 6DA0 C1AF signature.asc Description: PGP signature
[gentoo-dev] Reinstating eclasses
Hi, I'm currently working on a new eclass for Xfce4 that, as opposed to the previous ones (xfce42.eclass, xfce44.eclass), is supposed to be used for all versions. Now the most logical name for an eclass like that would be xfce4.eclass, except that eclass already exists. It seems like it was used for Xfce 4.2 and has been deprecated for quite some time now. Obviously, packages using that eclass (which is zero in the main tree and zero in the xfce herd's overlay btw) wouldn't work with my new eclass, so I can't just extend said eclass. Now my big question is: Do I have to think of a new name for my eclass (was thinking of something like xfce4-r1.eclass, which I don't really like though) or can I just overwrite the old eclass? -- Christoph Mende Gentoo/AMD64 Operational Lead and Release Engineering GPG: EE2A 454A 6A3B A2D8 E43B FF45 2A19 C3B3 6DA0 C1AF signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Reinstating eclasses
On Tue, 4 Nov 2008 13:15:25 -0600 Ryan Hill [EMAIL PROTECTED] wrote: On Tue, 04 Nov 2008 13:43:55 -0500 Joe Peterson [EMAIL PROTECTED] wrote: Christoph Mende wrote: Now the most logical name for an eclass like that would be xfce4.eclass, except that eclass already exists. Since the new eclass is not version specific, how about simply xfce.eclass? Well, the desktop is usually called Xfce4, plus that'd match gnome2... and more or less kde4 why bother introducing yet another xfce*.eclass when you can re-use an existing one? That's what I want to do :P We currently have xfce4.eclass, xfce42.eclass and xfce44.eclass. 42 and 44 are obviously versioned, 4 isn't, but isn't nearly compatible with my new one, partly because it was used (and probably exclusively written) for 4.2. -- Christoph Mende Gentoo/AMD64 Operational Lead and Release Engineering GPG: EE2A 454A 6A3B A2D8 E43B FF45 2A19 C3B3 6DA0 C1AF signature.asc Description: PGP signature
Re: [gentoo-dev] Keyword amd64 - x86_64
On Wed, 20 Feb 2008 12:59:11 -0500 William L. Thomson Jr. [EMAIL PROTECTED] wrote: Unless the work to do that is greater than the value of the change. It most likely is. And beside of that: amd64 is the technically correct term. :p signature.asc Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, 12 Jun 2007 12:59:42 +0200 cilly [EMAIL PROTECTED] wrote: On Jun 12, 2007, at 12:53 PM, cilly wrote: Additional: Sometimes the chance for the users to place the ebuild comfortably into overlay is simply taken, since the ebuild has been removed and doesn't exist after a sync anymore. It's not, CVS keeps every ebuild around, just go to sources.gentoo.org and hit Show X dead files in the dir of the ebuild you want ;) signature.asc Description: PGP signature
Re: [gentoo-dev] New Developer: Christoph Mende (angelos)
On Tue, 5 Jun 2007 00:11:54 +0300 Aggelos Orfanakos [EMAIL PROTECTED] wrote: On Mon, 04 Jun 2007 20:19:28 +0300 Christian Heim wrote: It's my pleasure to introduce to you Christoph Mende (also known as angelos on IRC), our latest addition joining the AMD64 and XFCE herd. Hiya angelos! Your nickname is my first name, so this feels kinda strange! :-) Any relation to Greece? Welcome to Gentoo! Thanks and no, I've stolen that nick from some TV show :P I've seen many people talking in greece to me though, so you're not the first signature.asc Description: PGP signature
Re: [gentoo-dev] Deskzilla license for Gentoo Bugzilla for everyone
On Fri, 20 Apr 2007 14:26:08 -0700 Ned Ludd [EMAIL PROTECTED] wrote: You sent this to -dev vs -core.. Pretty sure they are going to need to revoke this license now. Hmm, it was sent to both lists, looks intended to me, besides that, here's a snippet from the original email: Feel free to share the license key with anyone interested or post it on the web. signature.asc Description: PGP signature
Re: [gentoo-dev] net-dialup/pppoed pending for removal
On Sun, 15 Apr 2007 13:13:24 + Catalin Zamfir Alexandru [EMAIL PROTECTED] wrote: So how are we going to connect to PPP after the removal? I'm using the 2.6 kernel, but stil use /usr/sbin/pppoe-start Well? [N] net-dialup/rp-pppoe (3.8-r1): A user-mode PPPoE client and server suite for Linux And I guess that's already what you're using ; signature.asc Description: PGP signature
Re: [gentoo-dev] How to move packages?
You could release the new version under the old name as a meta package that installs the package with the new name On Thu, 2006-10-26 at 14:53 +0400, Peter Volkov (pva) wrote: Hello. One of packages I maintain changed its name. What shall be done, so users of the package were aware about package name change and upgraded flawlessly? Thank you, Peter. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X.Org 7.1 is Stable
On Mon, 2006-10-16 at 07:37 -0400, Caleb Cushing wrote: is evdev (for 7.1) stable now? and by stable I mean can I use it without it crashing xorg? I should probably test this because I don't recall it getting updated which means it is still broken. I was running evdev under Xorg 7.0 and 7.1 for my mouse without problems. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: default USE flags in profiles (oss)
No game I've installed here needs any package with the oss USE flag, those packages that use OSS are fine the ALSA OSS Emulation.2006/9/24, Ryan Hill [EMAIL PROTECTED]:Mike Frysinger wrote: oss is dead, why bother going with it in default USE anymore ?alsa forever ! i think the standard argument is games.i've never needed it though.--de.
Re: [gentoo-dev] Re: default USE flags in profiles (oss)
Well ok, I don't use alsa-driver ;)2006/9/24, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED]: On Sunday 24 September 2006 00:13, Christoph Mende wrote: No game I've installed here needs any package with the oss USE flag, those packages that use OSS are fine the ALSA OSS Emulation.That requires oss useflag on alsa-driver. --Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
