[gentoo-dev] Make inotify a global USE flag?
These packages have inotify as local USE flag: app-editors/emacs-vcs app-misc/recoll app-misc/strigi dev-libs/ecore dev-vcs/git-annex media-sound/mpd net-im/ekg2 net-misc/mediatomb sys-fs/aufs2 sys-fs/aufs3 sys-process/cronie Should we make it a global flag? What description is better: inotify - Enable inotify filesystem monitoring support inotify - Enable inotify file change notification support BTW, half of the local flag descriptions are "Enable inotify support". Imagine that! ;-) Ulrich
Re: [gentoo-dev] Make inotify a global USE flag?
On 21/03/13 12:29, Ulrich Mueller wrote: These packages have inotify as local USE flag: app-editors/emacs-vcs app-misc/recoll app-misc/strigi dev-libs/ecore dev-vcs/git-annex media-sound/mpd net-im/ekg2 net-misc/mediatomb sys-fs/aufs2 sys-fs/aufs3 sys-process/cronie Should we make it a global flag? What description is better: inotify - Enable inotify filesystem monitoring support inotify - Enable inotify file change notification support +1, ... ... despite that most of these shouldn't even have a USE flag for inotify, instead it should always be enabled with 'kernel_linux' and let the application itself do a runtime check if inotify is available or not since these have no external dependencies (other than virtual/os-headers) not everything should be put behind USE flag :-/ - Samuli
Re: [gentoo-dev] Make inotify a global USE flag?
Ulrich Mueller wrote: > Should we make it a global flag? Sure. > What description is better: > >inotify - Enable inotify filesystem monitoring support >inotify - Enable inotify file change notification support The former is more correct, because inotify provides notifications for more than just file changes. Samuli Suominen wrote: > it should always be enabled with 'kernel_linux' and let the > application itself do a runtime check if inotify is available or not I think it's great if you are working on such patches for upstreams! //Peter
Re: [gentoo-dev] Make inotify a global USE flag?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/03/13 11:29, Ulrich Mueller wrote: > Should we make it a global flag? Sure. > What description is better: > > inotify - Enable inotify filesystem monitoring support inotify - > Enable inotify file change notification support > > BTW, half of the local flag descriptions are "Enable inotify > support". Imagine that! ;-) Why not just make it "Enable inotify support", and write more detailed local flags? The local description should tell you what that particular ebuild uses the flag for. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlFK844ACgkQRtClrXBQc7UScQD+L0WBiRIIKTa4ifpXGzMK8FUK fqKpcb0PhKa5gb5KavQA/3CWydciFb75kDtrkUy6nlLpDaOOoE6jB74+1yAQ+uos =hgwR -END PGP SIGNATURE-
Re: [gentoo-dev] Make inotify a global USE flag?
On 21/03/13 13:43, Peter Stuge wrote: Ulrich Mueller wrote: Should we make it a global flag? Sure. What description is better: inotify - Enable inotify filesystem monitoring support inotify - Enable inotify file change notification support The former is more correct, because inotify provides notifications for more than just file changes. Samuli Suominen wrote: it should always be enabled with 'kernel_linux' and let the application itself do a runtime check if inotify is available or not I think it's great if you are working on such patches for upstreams! no, i'm talking from experience -- every package I've seen/touched/... with IUSE="inotify" has had code that made it safe to use also for non-inotify'd kernels i'm referring to the mistakes done by maintainers by adding unnecessarily the flag cut the sarcasm :-) - Samuli
Re: [gentoo-dev] Make inotify a global USE flag?
Samuli Suominen wrote: >> Samuli Suominen wrote: >>> it should always be enabled with 'kernel_linux' and let the >>> application itself do a runtime check if inotify is available or not >> >> I think it's great if you are working on such patches for upstreams! > > no, i'm talking from experience -- every package I've seen/touched/... > with IUSE="inotify" has had code that made it safe to use also for > non-inotify'd kernels > i'm referring to the mistakes done by maintainers by adding > unnecessarily the flag That was not at all clear, but that's great! Then you could fix those ebuilds. Except there's that rule to not fix bugs in others' ebuilds, so even though you've found a bug you're not allowed to fix it.. :\ //Peter
[gentoo-dev] Packages up for grabs
Hi, The PHP herd currently contains a few packages that were added for historical reasons, but do not belong in the herd. dev-db/cdb dev-db/libiodbc dev-db/odbtp dev-libs/libxdiff cdb and odbtp will be dropped to maintainer-needed. libiodbc and libxdiff I can take on myself if no one else wants them. -- Ole Markus
Re: [gentoo-dev] Make inotify a global USE flag?
21.03.2013 16:10, Peter Stuge wrote: > That was not at all clear, but that's great! Then you could fix those > ebuilds. Except there's that rule to not fix bugs in others' ebuilds, > so even though you've found a bug you're not allowed to fix it.. :\ To be honest - last statement is not correct, but, please, do not start this useless discussion about common sense in touching others' packages again. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make inotify a global USE flag?
On 21/03/13 14:10, Peter Stuge wrote: Samuli Suominen wrote: Samuli Suominen wrote: it should always be enabled with 'kernel_linux' and let the application itself do a runtime check if inotify is available or not I think it's great if you are working on such patches for upstreams! no, i'm talking from experience -- every package I've seen/touched/... with IUSE="inotify" has had code that made it safe to use also for non-inotify'd kernels i'm referring to the mistakes done by maintainers by adding unnecessarily the flag That was not at all clear, but that's great! Then you could fix those ebuilds. Yes, I could, or I could just let other maintainers know about it, like on the ML, wait... that's what I just did Except there's that rule to not fix bugs in others' ebuilds, so even though you've found a bug you're not allowed to fix it.. :\ You cut down the important bit from my last post about 'cutting the sarcasm' We really don't need this in the ML Can we stop it before it begins? I hope so - Samuli
[gentoo-dev] Add HEXCHAT_PLUGINS to USE_EXPAND
Hello, I'd want to ask if it's possible and a good idea to add HEXCHAT_PLUGINS to the global USE_EXPAND var. HEXCHAT_PLUGINS has been created as a user (and maintainer) request in bug 461972 [1] to handle easily the net-irc/hexchat plugins that this package offers, which are: checksum, doat, fishlim and sysinfo. The purposed ebuild can be found on the bug's attached files list. Regards, Denis M. (Phr33d0m) [1] https://bugs.gentoo.org/show_bug.cgi?id=461972 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-libs/dv{acm4,net,ssl,thread,util}
# Tiziano Müller (21 Mar 2013) # Masked for removal in 30 days (bug #462590). Open bugs: # #310217, #339477, #343807, #439110 # Recent test failures in dvutil show bugs in timezone handling. # No new release since >3 years, upstream is not responding. # Not recommended for new development. Use C++11, boost, poco, etc instead. dev-libs/dvacm4 dev-libs/dvnet dev-libs/dvssl dev-libs/dvthread dev-libs/dvutil
Re: [gentoo-dev] Make inotify a global USE flag?
Samuli Suominen wrote: >>> i'm referring to the mistakes done by maintainers by adding >>> unnecessarily the flag >> >> That was not at all clear, but that's great! Then you could fix those >> ebuilds. > > Yes, I could, or I could just let other maintainers know about it, like > on the ML, wait... that's what I just did ..using the mailing list as bugtracker? I completely understand and agree that submitting a bug takes certain effort, sometimes too much for simple things. I'm just ridiculing the fact that rules are chilling bugfixes. Maybe it inspires someone, even if it isn't following the rules for how to express opinion on rules. >> Except there's that rule to not fix bugs in others' ebuilds, >> so even though you've found a bug you're not allowed to fix it.. :\ > > You cut down the important bit from my last post about 'cutting the > sarcasm' > We really don't need this in the ML > Can we stop it before it begins? I hope so The emperor was naked all along. ;) //Peter
Re: [gentoo-dev] Make inotify a global USE flag?
> On Thu, 21 Mar 2013, Alexander Berntsen wrote: >> BTW, half of the local flag descriptions are "Enable inotify >> support". Imagine that! ;-) > Why not just make it "Enable inotify support", and write more > detailed local flags? The point is that this so-called description adds no useful information whatsoever. Most of the time USE="foo" will enable some "foo" feature. Ulrich
Re: [gentoo-dev] Make inotify a global USE flag?
On Thu, 21 Mar 2013 14:33:50 +0100 Peter Stuge wrote: > ..using the mailing list as bugtracker? No. In this context we are using the mailing list to discuss a patch to a bug; this is completely normal use of the mailing list, you can also see this behavior on other mailing lists, eg. the Linux kernel ML. > I completely understand and agree that submitting a bug takes certain > effort, sometimes too much for simple things. All it takes is a single command line, check out PyBugz... > I'm just ridiculing the fact that rules are chilling bugfixes. > > Maybe it inspires someone, even if it isn't following the rules for > how to express opinion on rules. If this bothers you so much, then please start a new separate thread on it. Bringing this irrelevant matter to several threads is pointless. 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Make inotify a global USE flag?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/03/13 15:14, Ulrich Mueller wrote: > Most of the time USE="foo" will enable some "foo" feature. Most of the time is not all of the time, but I see your point. Maybe "Enable inotify to notice filesystem changes". Or one of your suggestions, both of which look adequate. As long as the local descriptions say whether they are monitoring IN_ACCESS, IN_DELETE, IN_MODIFY or whatever. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlFLMfgACgkQRtClrXBQc7VlJwD/RzcgbJGicmjwWqOREbEswrQK yaf8yupQVLbDw2NaDdYA/1WYUfIqYEaxEMbO62kq21gq8f7xOLYPtlw/ypqZDAQ/ =JKsx -END PGP SIGNATURE-
Re: [gentoo-dev] Make inotify a global USE flag?
On Thu, 21 Mar 2013 12:32:31 +0200 Samuli Suominen wrote: > On 21/03/13 12:29, Ulrich Mueller wrote: > > These packages have inotify as local USE flag: > > > > app-editors/emacs-vcs > > app-misc/recoll > > app-misc/strigi > > dev-libs/ecore > > dev-vcs/git-annex > > media-sound/mpd > > net-im/ekg2 > > net-misc/mediatomb > > sys-fs/aufs2 > > sys-fs/aufs3 > > sys-process/cronie > > > > Should we make it a global flag? What description is better: > > > > inotify - Enable inotify filesystem monitoring support > > inotify - Enable inotify file change notification support > > +1, ... > > ... despite that most of these shouldn't even have a USE flag for > inotify, instead it should always be enabled with 'kernel_linux' and let > the application itself do a runtime check if inotify is available or not > since these have no external dependencies (other than virtual/os-headers) > not everything should be put behind USE flag :-/ net-im/ekg2 fixed. But you should seriously consider opening a bug, at least a common one CC-ing all the remaining maintainers. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Sorry to bother you again, but I still cannot do signed commits. I don't
know what else to try.
On Thu, 14 Mar 2013, Robin H. Johnson wrote:
On Thu, Mar 14, 2013 at 10:50:00AM +0700, gro...@gentoo.org wrote:
But my first attempt to do a signed commit has failed:
Your GPG agent is broken/missing.
These are steps I have done:
elrond ~ # eselect pinentry list
Available pinentry binary implementations:
[1] pinentry-gtk-2
[2] pinentry-qt4 *
[3] pinentry-curses
In /etc/kde/startup/agent-startup.sh:
if [ -x /usr/bin/gpg-agent ]; then
eval "$(/usr/bin/gpg-agent --daemon)"
fi
In /etc/kde/shutdown/agent-shutdown.sh:
if [ -n "${GPG_AGENT_INFO}" ]; then
kill $(echo ${GPG_AGENT_INFO} | cut -d':' -f 2) >/dev/null 2>&1
fi
grozin@elrond ~/.gnupg $ cat gpg-agent.conf
pinentry-program /usr/bin/pinentry-qt4
no-grab
default-cache-ttl 10
In ~/.gnupg/gpg.conf:
use-agent
Then I exited a kde session, and said startx again. Now
grozin@elrond ~ $ echo ${GPG_AGENT_INFO}
/tmp/gpg-oJuN4k/S.gpg-agent:14103:1
Looks like gpg-agent is running. Now an attempt to commit:
grozin@elrond /home/gentoo-x86/media-gfx/fotoxx $ repoman commit -m 'Fix
linking with gold (bug #462286), thanks to adrian.bass...@hotmail.co.uk'
RepoMan scours the neighborhood...
Creating Manifest for /home/gentoo-x86/media-gfx/fotoxx
Note: use --include-dev (-d) to check dependencies for 'dev' profiles
* 2 files being committed... 1 have headers that will change.
* Files with headers will cause the manifests to be changed and committed
separately.
Using commit message:
--
Fix linking with gold (bug #462286), thanks to
adrian.bass...@hotmail.co.uk
(Portage version: 2.2.0_alpha169/cvs/Linux i686, signed Manifest commit
with key 00C6DAB1!)
--
Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/ChangeLog,v <-- ChangeLog
new revision: 1.49; previous revision: 1.48
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/files/fotoxx-13.03.patch,v <--
files/fotoxx-13.03.patch
new revision: 1.2; previous revision: 1.1
Creating Manifest for /home/gentoo-x86/media-gfx/fotoxx
gpg: no default secret key: No secret key
gpg: /home/gentoo-x86/media-gfx/fotoxx/Manifest: clearsign failed: No
secret key
!!! !!! gpg exited with '2' status
!!! Disabled FEATURES='sign'
Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0
/var/cvsroot/gentoo-x86/media-gfx/fotoxx/Manifest,v <-- Manifest
new revision: 1.50; previous revision: 1.49
Commit complete.
RepoMan sez: "If everyone were like you, I'd be out of business!"
grozin@elrond /home/gentoo-x86/media-gfx/fotoxx $
My understanding was that I'll be asked for the pass phrase. But this does
not happen. And I don't know what else I have to configure.
Desperate,
Andrey
