Remove bundled libraries from a Qt package TexStudio

[Johannes Lips]

Hello,

I have some problems removing bundled libraries from a package of mine. 
I recently filed a Review Request due to a name change of the package 
and during that process the bundled libs were found. [1]
Namely the package contains:
- hunspell
- qtsingleapplication
- qcodeedit (although I recently packaged it, it is too heavily patched 
by the Texstudio devs, so I will file a request for an exception)

Since Texstudio was/is a fork of Texmaker I tried to apply the patch 
from it, but I haven't had much success. Most of the functions and or 
the location of the functions already changed. [2]

I would really like to ask if someone could take a look at it and help 
me out.


Thanks in advance!

Johannes

[1]https://bugzilla.redhat.com/show_bug.cgi?id=724878
[2]http://hannes.fedorapeople.org/texmaker-tools.patch
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Kamil Paral]

 Miloslav Trmač wrote: 
 I can't really see who is the expected user of ~/.local/bin . From my
 POV the whole point of ~/.local is to store data that is hidden from
 users - it is application data, not user data.

I am. I'm using that for years and I'm very happy that bin/ doesn't clutter my 
$HOME.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RPM version goes backward in Rawhide

[Michael Schwendt]

On Wed, 27 Jul 2011 18:51:12 -0700, AW (Adam) wrote:

 On Wed, 2011-07-27 at 20:39 +0200, Michael Schwendt wrote:
 
  Take off your pink glasses. Rawhide *is* a dumping ground. It breaks
  users' installations regularly because of package maintainers using it
  as exactly that, a dumping ground for potentially untested builds.
 
 And how would we stop that? by...encouraging people not to use it as a
 dumping ground. What's the best way to achieve that? Try and change the
 perception of it as a dumping ground...

Communication, education, guidelines, policies. Start there?

Not even Fedora's official Wiki page is ''trying very hard to kill the
notion that rawhide may eat babies'' (quoting Jesse).

http://fedoraproject.org/wiki/Releases/Rawhide

| End users should not use Rawhide as their main day-to-day workstation.
| Because Rawhide is a development branch, many changes are not heavily
| tested (or tested at all) before being released to Rawhide, and packages
| in Rawhide can and do break without warning. It is even possible that
| bugs in Rawhide could cause data loss.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Michal Hlavinka]

On 07/27/2011 04:05 PM, Miloslav Trmač wrote:
 On Wed, Jul 27, 2011 at 4:01 PM, Lennart Poettering
 mzerq...@0pointer.de  wrote:
 I think the right approach here is to prep a patch for the spec and make
 the dir official given that a) it probably makes sense to have a
 standardized dir like this,
 I can't really see who is the expected user of ~/.local/bin .  From my
 POV the whole point of ~/.local is to store data that is hidden from
 users - it is application data, not user data.

 Programs within the home directory were, presumably, explicitly
 installed and created by the user, so they are user data - and
 should be visible.
  Mirek

I disagree. If you want to use extra programs, you should be skilled 
enough to use ~/.local/bin directory, it's not that hard to use it. So 
called hidden directories are not trying to be invisible. They are 
hidden just so they don't pollute users Open file or Save as... 
dialogs, we have hidden .config, .gconf and even .wine so your 
~/.wine/drive_c is hidden. bin directory is not directory for random 
files, files are not stored there frequently, those files are not 
removed nor modified frequently. Don't forget to tell your users do not 
store random files in ~/bin and things like that. Also if you want 
something bigger than just one executable, where would do you put 
other files? Another directory in in $HOME ? ~/.local prefix is much 
better, you can add there other directories and keep your $HOME clean.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Michal Hlavinka]

On 07/27/2011 10:09 PM, Reindl Harald wrote:


 Am 27.07.2011 21:59, schrieb Marc-André Lureau:
 I don't understand the security risks. If something is allowed to
 write to ~/.local/bin (or ~/bin etc..), then surely it's able to read
 elsewhere or do something else nasty. Could someone detail it?

 Depends on the PATH-Order

yes, and if attacker wants to do something, there are better options 
than putting 'ls' file in ~/.local/bin or ~/bin, which will be executed 
only if global ls is missing. If he can put file somewhere, why don't 
just write ~/.bash_profile with own content? you can change PATH, 
aliases, add there 'ls' function or anything else you want...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/07/11 16:24, Miloslav Trmač wrote:
 On Wed, Jul 27, 2011 at 4:13 PM, Lennart Poettering
 mzerq...@0pointer.de wrote:
 On Wed, 27.07.11 16:05, Miloslav Trmač (m...@volny.cz) wrote:
 On Wed, Jul 27, 2011 at 4:01 PM, Lennart Poettering
[...snip...]
 d) there is point in having a standardized dir for this
 *shrug* Anyone knowledgeable enough to install software in $HOME is
 able to configure $PATH, and with some probability has strong opinions
 on where the $prefix should be.

Agreed that having standards is great.  Unfortunately, it so often seems
that everyone wants their own standards.

 hence: let's just change the xdg basedir spec to standardize it.
 IMHO the ~/.local/bin place is a mistake, and it's still not too late
 to stop making this mistake irreversible.

I'm torn.  I've been using ~/bin for over a decade already, which is
probably why I don't like ~/.local/bin.

I also don't like the fact that an application can easily install
scripts/binaries into a directory I will most likely forget to check - and
have this in my path.  I do know exactly which files I have in ~/bin - I
know so because I placed them there.  However, my workaround will most
likely be:

mv ~/bin/* ~/.local/bin
ln -fs ~/.local/bin ~/bin
restorecon ~/.local/bin

But I'm far from convinced ~/.local/bin is clever.  So far I've only seen
oh this is nice to have! arguments.  I haven't seen anything which brings
the strong need to have argument.

However, I find ~/.local an odd name.  To whom or what is it 'local'?  If
you have home directories mounted via NFS and log into two different remote
hosts via SSH - the only base is local to, is the user.  But if you start
a program which is installed on server but lacks global libraries on the
other server, then this program is suddenly local to a particular server
in addition.  My point is that local is very ambiguous and its name is
poorly chosen.  But I realise it's way too late to change ~/.local to
anything now.

And this leads to why I'd like to see a much broader discussion on the
topic about ~/.local/bin, also bringing it outside of Fedora's core.

Lets rather move forward with more caution.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4xNxkACgkQIIWEatLf4HeK/wCfcM2koOSYuAD5E+OPNzLnjzGM
KTgAoIm/+qZPqIQWaVgzN5pfo6v9c1+7
=uNOh
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Bryn M. Reeves]

On 07/27/2011 03:14 PM, Bernd Stramm wrote:
 On Wed, 27 Jul 2011 15:54:09 +0200
 Lennart Poettering mzerq...@0pointer.de wrote:
 If you don't hide ~/.local and ~/.config then users who are less savvy
 than us might wonder what thzat stuff is and delete it and nothing
 will stop them and then all their configuration is lost.
 
 Hiding configuration is one thing, hiding executables is another. Hiding
 executables is a security risk, and should not be done just because 
 a single person asked for it in a BZ.

There are already quite a few things that may place executables under . prefixed
paths in home. Java web start (javaws) for instance will install an entire jre
under .java/deployment/cache, wine has for many years installed Windows
executables (that can be executed by the system) under .wine, browser plugins
may be installed to .mozilla/plugins and are just as capable of performing
evil actions as an executable (e.g. drop a malicious plugin that hijacks some
common MIME types, do your $evil and then wrap the intended plugin).

There are various other examples - on an older release I find 171 such files
under ~/:

$ find $(l. | egrep -v '\.$|\.\.$') -type f -perm /111 | wc -l
171

Some of these aren't actually binaries/scripts - e.g. .desktop files and others
just appear to have wrong mode on creation but it's still clear that this is
nothing new.

I think the security aspects of this change are being overstated in this thread.

If something has already obtained the ability to create executable files under a
user's home directory then your men are already dead; The sophistication
needed to exploit it might vary a little but that's not something that gives me
great comfort.

Regards,
Bryn.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/07/11 15:54, Lennart Poettering wrote:
[..snip..]
 If you don't hide ~/.local and ~/.config then users who are less savvy
 than us might wonder what thzat stuff is and delete it and nothing will
 stop them and then all their configuration is lost.

If a user lists out (even via Nautilus) hidden files and folders.  What
would stop that user from seeing .local and then wonder what thzat stuff
is and delete it?

We cannot stop any users from doing stupid things, no matter what the name
of a file or directory is, if it is hidden or not.  Sure hidden dirs is
more difficult to find for new rookies, but sooner or later people will
find such hidden stuff.  But they will most likely only delete such a
directory once, regret bitterly and never touch it again.

We must stop thinking that the users are plain drop-dead-stupid and will
never become as clever as you, me or any other claiming to be a computer
guru.  Users can be taught to do things the right way.  Sometimes through
experience, sometimes by others telling them what to do or not to do, other
times we can have software popping up an alert saying: What you're about
to do now is most likely crazy, silly and stupid.  Are you sure you really
want to do this?  You might regret bitterly if you proceed!

Just like what Firefox has done with the about:config warning.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4xO5EACgkQIIWEatLf4HctOwCghw0BfvSnyWDefyg8I65TTnTP
2aoAn3ekLsoFaCTgk3CzNM89M1xydaM7
=Bj6j
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/07/11 17:40, Roman Rakus wrote:
 Hi all,
 from the discussion here, I'm tempted to revert the change. Any objections?

+1 ... at least the there is some common consensus, also across distributions.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4xPNQACgkQIIWEatLf4Hfr3wCfVybYeo7M7eGXWrDqPnceiY4W
h8kAnj4zOUQ5egtXmA6KOYGOU5z4vgcu
=swRS
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Genes MailLists]

On 07/28/2011 06:17 AM, David Sommerseth wrote:

 
 However, I find ~/.local an odd name.  To whom or what is it 'local'?  If
 you have home directories mounted via NFS and log into two different remote
 hosts via SSH - the only base is local to, is the user.  But if you start
 a program which is installed on server but lacks global libraries on the
 other server, then this program is suddenly local to a particular server
 in addition.  My point is that local is very ambiguous and its name is
 poorly chosen.  But I realise it's way too late to change ~/.local to
 anything now.
 

  This is a good point. Especially when you start on a 64 bit box and
login to a 32 bit (or other arch) - bin now makes now sense at all. You
need arch specific bins (bin, bin64 etc).



gene/


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File RPM-VersionCompare-v0.1.1.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-RPM-VersionCompare:

ff00cb097c8aec91b03e1514838d0614  RPM-VersionCompare-v0.1.1.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-RPM-VersionCompare] Correct changelog

[Petr Pisar]

commit c93703221f60fd90deb59bb6c7e54077b70d85c7
Author: Petr Písař ppi...@redhat.com
Date:   Thu Jul 28 13:54:03 2011 +0200

Correct changelog

 perl-RPM-VersionCompare.spec |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-RPM-VersionCompare.spec b/perl-RPM-VersionCompare.spec
index bbf0735..a36cc41 100644
--- a/perl-RPM-VersionCompare.spec
+++ b/perl-RPM-VersionCompare.spec
@@ -52,10 +52,10 @@ make test
 %changelog
 * Thu Jul 28 2011 Petr Pisar ppi...@redhat.com - 0.1.1-1
 - 0.1.1 bump
+- Fixes parsing epoch longer than one character (bug #725608)
 
 * Fri Jun 17 2011 Marcela Mašláňová mmasl...@redhat.com - 0.1.0-2
 - Perl mass rebuild
-- Fixes parsing epoch longer than one character (bug #725608)
 
 * Fri May 27 2011 Petr Pisar ppi...@redhat.com 0.1.0-1
 - Specfile autogenerated by cpanspec 1.78.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Adding ~/.local/bin to default PATH

[Bernd Stramm]

On Thu, 28 Jul 2011 11:24:48 +0100
Bryn M. Reeves b...@redhat.com wrote:

 On 07/27/2011 03:14 PM, Bernd Stramm wrote:
  On Wed, 27 Jul 2011 15:54:09 +0200
  Lennart Poettering mzerq...@0pointer.de wrote:
  If you don't hide ~/.local and ~/.config then users who are less
  savvy than us might wonder what thzat stuff is and delete it and
  nothing will stop them and then all their configuration is lost.
  
  Hiding configuration is one thing, hiding executables is another.
  Hiding executables is a security risk, and should not be done just
  because a single person asked for it in a BZ.
 
 There are already quite a few things that may place executables
 under . prefixed paths in home. Java web start (javaws) for instance
 will install an entire jre under .java/deployment/cache, wine has for
 many years installed Windows executables (that can be executed by the
 system) under .wine, browser plugins may be installed
 to .mozilla/plugins and are just as capable of performing evil
 actions as an executable (e.g. drop a malicious plugin that hijacks
 some common MIME types, do your $evil and then wrap the intended
 plugin).
 
 There are various other examples - on an older release I find 171
 such files under ~/:
 
 $ find $(l. | egrep -v '\.$|\.\.$') -type f -perm /111 | wc -l
 171

This is no excuse to add to a bad habit.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Bryn M. Reeves]

On 07/28/2011 12:54 PM, Bernd Stramm wrote:
 On Thu, 28 Jul 2011 11:24:48 +0100
 Bryn M. Reeves b...@redhat.com wrote:
 There are already quite a few things that may place executables
 under . prefixed paths in home. Java web start (javaws) for instance
 will install an entire jre under .java/deployment/cache, wine has for
 many years installed Windows executables (that can be executed by the
 system) under .wine, browser plugins may be installed
 to .mozilla/plugins and are just as capable of performing evil
 actions as an executable (e.g. drop a malicious plugin that hijacks
 some common MIME types, do your $evil and then wrap the intended
 plugin).

 There are various other examples - on an older release I find 171
 such files under ~/:

 $ find $(l. | egrep -v '\.$|\.\.$') -type f -perm /111 | wc -l
 171
 
 This is no excuse to add to a bad habit.

I'm not using it as an excuse for anything but I do think it is evidence that
the security implications being bandied around in this thread are rather
overblown; as others have said an attacker that can write to these locations is
/already/ a problem.

Using ~/.local (or any other path in home) doesn't make that any better or 
worse.

Regards,
Bryn.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 725608] Module does not parse epoch correctly

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=725608

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-RPM-VersionCompare-0.1
   ||.1-1.fc17

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Adding ~/.local/bin to default PATH

[Bernd Stramm]

On Thu, 28 Jul 2011 13:00:28 +0100
Bryn M. Reeves b...@redhat.com wrote:

 On 07/28/2011 12:54 PM, Bernd Stramm wrote:
  On Thu, 28 Jul 2011 11:24:48 +0100
  Bryn M. Reeves b...@redhat.com wrote:
  There are already quite a few things that may place executables
  under . prefixed paths in home. Java web start (javaws) for
  instance will install an entire jre under .java/deployment/cache,
  wine has for many years installed Windows executables (that can be
  executed by the system) under .wine, browser plugins may be
  installed to .mozilla/plugins and are just as capable of
  performing evil actions as an executable (e.g. drop a malicious
  plugin that hijacks some common MIME types, do your $evil and then
  wrap the intended plugin).
 
  There are various other examples - on an older release I find 171
  such files under ~/:
 
  $ find $(l. | egrep -v '\.$|\.\.$') -type f -perm /111 | wc -l
  171
  
  This is no excuse to add to a bad habit.
 
 I'm not using it as an excuse for anything but I do think it is
 evidence that the security implications being bandied around in this
 thread are rather overblown; as others have said an attacker that can
 write to these locations is /already/ a problem.
 
 Using ~/.local (or any other path in home) doesn't make that any
 better or worse.


It is nevertheless an *added* avenue to do some phishing. And for what
benefit?

Adding a hidden directory to $PATH will cause people do filter it out
from their $PATH. This leads to more messy use environments, not to
cleaner ones as is the original purpose of this whole thing.

No, hidden directories should not be in $PATH. If somebody put that in
their standard, those folks should change their standard. Standards can
define things that are wrong, and this is one such case.

What is also wrong is the way this supposedly got into the standard - a
few casual remarks by a grand total of 2 people in a BZ, and all of a
sudden it is part of a standard. That seems sloppy.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Genes MailLists]

On 07/28/2011 07:53 AM, Bryn M. Reeves wrote:
 On 07/28/2011 12:46 PM, Genes MailLists wrote:

   This is a good point. Especially when you start on a 64 bit box and
 login to a 32 bit (or other arch) - bin now makes now sense at all. You
 need arch specific bins (bin, bin64 etc).
 
 Currently Fedora only separates out the /lib* directories in multilib
 installations - you'll find a mix of 32 and 64 bit binaries in the system 
 binary
 paths on these systems.
 

 which is fine for a 'system' which is 64 bit and may support 32 bit as
well - its not fine for a 'user'  who logs in to a 32 bit machine from a
64 bit machine and now his binaries wont work.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Genes MailLists]

On 07/28/2011 08:41 AM, Genes MailLists wrote:
 On 07/28/2011 07:53 AM, Bryn M. Reeves wrote:
 On 07/28/2011 12:46 PM, Genes MailLists wrote:
 
   This is a good point. Especially when you start on a 64 bit box and
 login to a 32 bit (or other arch) - bin now makes now sense at all. You
 need arch specific bins (bin, bin64 etc).

 Currently Fedora only separates out the /lib* directories in multilib
 installations - you'll find a mix of 32 and 64 bit binaries in the system 
 binary
 paths on these systems.

 
  which is fine for a 'system' which is 64 bit and may support 32 bit as
 well - its not fine for a 'user'  who logs in to a 32 bit machine from a
 64 bit machine and now his binaries wont work.


  In the same way as an NFS mounted /usr/local/bin which only had 64 bit
binaries would not be a lot of use on a 32 bit machine. It can be dealth
with of course - what I've seen in this case, is either 2 different
mounts or making both available and having the PATH adjust as needed.
Add to that different architectures and the PATH way gets nasty fast. My
preference is for the machine to mount the right one under /usr/local
(or /usr/share or whatever.

  For user level .local/bin[64] there are different approaches I imagine
- for one its not hard to adjust the PATH in this case based on uname -m
or similar.

  However, having .local/bin under NFS home is a more complicated case
for sure and probably is just plain wrong without some architecture
recognition - so the standard looks ill conceived from this regard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Chris Adams]

Once upon a time, Bryn M. Reeves b...@redhat.com said:
 I just assumed it was by analogy to /usr/local - a per-user directory for 
 local
 installation with a structure mimicking /usr.

But the user already has the whole home directory.  On RPM-managed
systems, the different between /usr and /usr/local is that /usr is RPM
managed and /usr/local is not.  ~/ is already not RPM-managed.  ~/bin
has been in the default PATH for many years; why do we need a second
such directory?

The source of /usr/local was NFS-mounted /usr, with /usr/local being on
the local system.  ~/ would typically be NFS mounted in that type of
setup (users don't get space on the local drive except /tmp), so
~/.local would be meaningless.

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Bryn M. Reeves]

On 07/28/2011 01:41 PM, Genes MailLists wrote:
 On 07/28/2011 07:53 AM, Bryn M. Reeves wrote:
 On 07/28/2011 12:46 PM, Genes MailLists wrote:
 
   This is a good point. Especially when you start on a 64 bit box and
 login to a 32 bit (or other arch) - bin now makes now sense at all. You
 need arch specific bins (bin, bin64 etc).

 Currently Fedora only separates out the /lib* directories in multilib
 installations - you'll find a mix of 32 and 64 bit binaries in the system 
 binary
 paths on these systems.

 
  which is fine for a 'system' which is 64 bit and may support 32 bit as
 well - its not fine for a 'user'  who logs in to a 32 bit machine from a
 64 bit machine and now his binaries wont work.

Separating bin paths like this would not solve the problem; anything that's only
present in one path or the other would still fail in the scenario you suggest.
You could equally install foo/foo64 or vice versa into the same directory.

Regards,
Bryn.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Starting a SIG for package reviews

[Stanislav Ochotnicky]

Excerpts from Jason L Tibbitts III's message of Thu Jul 28 02:03:21 +0200 2011:
 So, that was pretty good response; only one reply here, but several
 names were added to the wiki page.  There seem to be enough people
 interested to begin moving forward.

Yeah, it would be nice to make our lives easier and more organized :-)

[snip]
 I think it would be productive to have at least some meetings on IRC.  I
 don't have any illusions about being able to get everyone all together
 at once but I've been involved here for long enough to know that some
 things just don't get done on a mailing list.  Folks who want to attend
 are welcome to fill out http://whenisgood.net/43qkixx and we'll try to
 find something that works.  (The only hard conflict I have is the FPC
 meeting.)

I believe you forgot to set whenisgood to use timezones :-) I realized
this only after filling out the info, so if you can edit the event so
I can fix my times.


--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Ralf Corsepius]

On 07/28/2011 03:07 PM, Chris Adams wrote:

 The source of /usr/local was NFS-mounted /usr, with /usr/local being on
 the local system.
This only partially applies - The source of /usr/local was to override 
system programs and system libraries in /usr with locally installed 
files (below /usr/local), without damaging the vendor supplied binaries 
in /usr (esp. on -*nix systems).

Ralf

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Marian Ganisin]

On Wed, Jul 27, 2011 at 10:36:08AM -0400, Bernd Stramm wrote:
  c) there's a spec about ~/.local/bin already accepted by a friendly
  project
 
 This is STILL a security risk, even if somebody calls it a standard.

This is STILL a claim without any proof, even if somebody repeats it
every time.

Does everybody calling this security risk check periodically his $PATH
for a dot? (what does $PATH contain? don't look at it before answering)
Are you periodically checking your ~/bin (do you know what's inside
without looking there right now)? Are you periodically checking your
~/.bash* startup files for suspicious aliases and functions, includes?

If you are _not_ watching really carefully your $HOME, this will not
bring new security risk for your machine (all are already there). On the
other way if you do so, again this will not bring new security risk to
your machine.

-- 
Regards,
Marian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Bryn M. Reeves]

On 07/28/2011 01:22 PM, Bernd Stramm wrote:
 On Thu, 28 Jul 2011 13:00:28 +0100
 Bryn M. Reeves b...@redhat.com wrote:
 It is nevertheless an *added* avenue to do some phishing. And for what
 benefit?

No, it's not; at the very most it's making something very slightly less
noticeable but even that is a weak and flawed argument.

If your security relies on spotting that a malicious user has placed a rogue
binary in ~/bin you're already hosed.

 Adding a hidden directory to $PATH will cause people do filter it out
 from their $PATH. This leads to more messy use environments, not to
 cleaner ones as is the original purpose of this whole thing.
 
 No, hidden directories should not be in $PATH. If somebody put that in
 their standard, those folks should change their standard. Standards can
 define things that are wrong, and this is one such case.

I'm not especially attached to ~/.local/bin being in PATH (although I do happen
to think the approach used by python for --user installations is an elegant
solution).

What I disagree with is the use of bogus security handwaving to support an
argument against it.

Regards,
Bryn.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: XDG and default directories (Re: Adding ~/.local/bin to default PATH)

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2011 10:52 AM, Stijn Hoop wrote:
 Hi,
 
 On Wed, 27 Jul 2011 12:43:09 +0200 Nicolas Mailhot
 nicolas.mail...@laposte.net wrote:
 Le mercredi 27 juillet 2011 à 12:26 +0200, Stijn Hoop a écrit :
 and even better is the fact that I can now put that area 
 somewhere else than on our default stupidly-expensive backupped
 NFS filesystem.
 
 And what will happen to your users when selinux starts enforcing 
 download jails and the directory it applies settings to is not the
 one you use? Do you really thinks that's hypothetical? Browsers
 are looking hard at sandboxing nowadays. Note that other security 
 frameworks do not even have the path/label separation they work 
 directly on paths.
 
 Why would selinux / apparmor NOT respect the same environment that
 is used for the live user?
 
 If the root cause is because selinux / apparmor is technically not
 able to use per-user environment variables for non-standard
 subdirectories of /home, I submit that I simply need to be capable to
 not only set the environment variable, but also modify our selinux
 configuration to match.
 
 I already accepted the premise that having an NFS mounted /home
 (where I preferably do not want to store the newest HQ movies) is not
 a standard Linux environment anymore, by having to set the variable
 in the first place.
 
 Really if there was a need (for nfs users for example) for the 
 download area to reside on a different root it should have been 
 defined on a different root from the start up (like the rest of
 the filesystem layout was done) instead of trying to variabilize
 the layout.
 
 I agree, that would also work in this specific case. However I note 
 that the defaults make sense in a personal workstation case, which
 is fine by me. Having /home and /localhome (examples) for a single 
 workstation is more confusing.
 
 Now the default locations are just going to be hardcoded right and
 left with subtle difficult to debug failures when one tries to move
 one of them like proposed by the spec.
 
 Exactly my point as well, let's get those fixed.
 
 --Stijn

SELinux will work with variable paths, as long as you setup the labeling
correctly.  SELinux really does not care about the paths, other then if
you relabel the system.

So if you want to move files around within a homedir, and we care about
securing the content differently you can change the label.

Most of the labels in the users homedir are for System Services that
need to use content in the home dir.  (~/.ssh, ~/public_html,
~/public_git)  Or setuid apps like gnome-sandbox, nsplugin that need to
use directories in the homedir.  Then we are doing some experimental
stuff like confining telepathy apps, but those are turned off for most
users.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4xZqsACgkQrlYvE4MpobPGiwCgkXoWbuzP/Y5ay3T/LtxG5URz
3LQAn38gToz+Lu6fFmP7BUHnIDm8dF/4
=4dF4
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Bernd Stramm]

On Thu, 28 Jul 2011 14:35:27 +0100
Bryn M. Reeves b...@redhat.com wrote:

 On 07/28/2011 01:22 PM, Bernd Stramm wrote:
  On Thu, 28 Jul 2011 13:00:28 +0100
  Bryn M. Reeves b...@redhat.com wrote:
  It is nevertheless an *added* avenue to do some phishing. And for
  what benefit?
 
 No, it's not; at the very most it's making something very slightly
 less noticeable but even that is a weak and flawed argument.

It is one additional avenue. Hence added.
 
 If your security relies on spotting that a malicious user has placed
 a rogue binary in ~/bin you're already hosed.

My security does not rely on it, but my security does include looking
there if something funny is going on. Now I am suppose to look in
an additinal place, that was added quietly. Someone decided to change
where to look for executables in my $HOME. That is uncalled for.

 
  Adding a hidden directory to $PATH will cause people do filter it
  out from their $PATH. This leads to more messy use environments,
  not to cleaner ones as is the original purpose of this whole thing.
  
  No, hidden directories should not be in $PATH. If somebody put that
  in their standard, those folks should change their standard.
  Standards can define things that are wrong, and this is one such
  case.
 
 I'm not especially attached to ~/.local/bin being in PATH (although I
 do happen to think the approach used by python for --user
 installations is an elegant solution).

This whole thread is about ~/.local/bin. I see it adding to the mess
found in $HOME, as opposed to cleaning things up. Shoving the mess
under a rug is not cleaning.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Genes MailLists]

On 07/28/2011 09:09 AM, Bryn M. Reeves wrote:
 On 07/28/2011 01:41 PM, Genes MailLists wrote:
 On 07/28/2011 07:53 AM, Bryn M. Reeves wrote:
 On 07/28/2011 12:46 PM, Genes MailLists wrote:

   This is a good point. Especially when you start on a 64 bit box and
 login to a 32 bit (or other arch) - bin now makes now sense at all. You
 need arch specific bins (bin, bin64 etc).

 Currently Fedora only separates out the /lib* directories in multilib
 installations - you'll find a mix of 32 and 64 bit binaries in the system 
 binary
 paths on these systems.


  which is fine for a 'system' which is 64 bit and may support 32 bit as
 well - its not fine for a 'user'  who logs in to a 32 bit machine from a
 64 bit machine and now his binaries wont work.
 
 Separating bin paths like this would not solve the problem; anything that's 
 only
 present in one path or the other would still fail in the scenario you suggest.
 You could equally install foo/foo64 or vice versa into the same directory.
 

  I don't follow your thought here - if you have a bin64/ and a bin/
etc and you have your shell initscripts decide (e.g. using uname -m)
which of those to include in your PATH I think it does work ... provided
you have (obviously) both (all) populated with whats needed...

  gene
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RPM version goes backward in Rawhide

[Przemek Klosowski]

On 07/28/2011 04:54 AM, Michael Schwendt wrote:
 On Wed, 27 Jul 2011 18:51:12 -0700, AW (Adam) wrote:

 And how would we stop that? by...encouraging people not to use it as a
 dumping ground. What's the best way to achieve that? Try and change the
 perception of it as a dumping ground...

 Communication, education, guidelines, policies. Start there?

 Not even Fedora's official Wiki page is ''trying very hard to kill the
 notion that rawhide may eat babies'' (quoting Jesse).

 http://fedoraproject.org/wiki/Releases/Rawhide


Maybe a more nuanced logo, e.g.

rawhide: tries hard to NOT eat babies
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Braden McDaniel]

On Thu, 2011-07-28 at 08:41 -0400, Genes MailLists wrote: 
 On 07/28/2011 07:53 AM, Bryn M. Reeves wrote:
  On 07/28/2011 12:46 PM, Genes MailLists wrote:
 
This is a good point. Especially when you start on a 64 bit box and
  login to a 32 bit (or other arch) - bin now makes now sense at all. You
  need arch specific bins (bin, bin64 etc).
  
  Currently Fedora only separates out the /lib* directories in multilib
  installations - you'll find a mix of 32 and 64 bit binaries in the system 
  binary
  paths on these systems.
  
 
  which is fine for a 'system' which is 64 bit and may support 32 bit as
 well - its not fine for a 'user'  who logs in to a 32 bit machine from a
 64 bit machine and now his binaries wont work.

Really, sharing of $HOME can (and does) happen among much *more*
disparate architectures than x86 and x86_64.  We don't have to think
about this as much these days now that MIPS and SPARC have waned in
popularity; but the idea that we might start seeing a lot more
consumer-oriented ARM devices running Linux isn't exactly far-fetched.
I typically use ~/`config.guess`/bin.

As it stands, ~/bin and ~/.local/bin are only appropriate for binaries
that are not arch-specific. Any standard that doesn't take that into
account needs some improvement.

-- 
Braden McDaniel bra...@endoframe.com

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Compress-Raw-Zlib/f16] bump and rebuild as it got compiled with the old perl on ppc

[Karsten Hopp]

Summary of changes:

  ac3976a... bump and rebuild as it got compiled with the old perl on pp (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Adding ~/.local/bin to default PATH

[Bryn M. Reeves]

On 07/28/2011 03:50 PM, Braden McDaniel wrote:
 My understanding of the history of /usr/local's nomenclature is that it
 was intended to be local to the machine (and thus not NFS mounted).

I always understood it to be site local rather than machine local - the FHS
states that it may be used for programs and data shareable amongst a group of
hosts (but again, NFS mounted /usr, /usr/local or even separate (but local) /usr
has some problems today).

 Your point applies just as well to /usr; but I think the intent was for
 NFS-mounted /usr to accommodate a single point of installation in
 homogeneous environments; supporting heterogeneous environments just
 wasn't the point.
 
 My impression is that NFS-mounted /usr is pretty uncommon these
 days--and perhaps unheard-of using Linux.

It's not unheard of historically but see for e.g.:

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

 NFS-mounted $HOME, however, continues to be relatively common and
 certainly warrants consideration.

Agreed.

Regards,
Bryn.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Java 7 for Fedora 16

[Deepak Bhole]

* Marek Goldmann mgold...@redhat.com [2011-07-28 10:41]:
 
 On 25 lip 2011, at 17:30, Deepak Bhole wrote:
 
  I created an unfinished, skeletal feature page here:
  http://fedoraproject.org/wiki/Features/Java7
  Unfortunately, I don't have the knowledge to help build it. I'm
  announcing it here in case whoever maintains Java 6 in Fedora, or
  someone else, is interested.
  
  
  I was planning to do this myself .. glad you started it :) I can take
  over the Feature and doing all the work if you're fine with it...
 
 Anything new in this topic?
 
 As I'm trying to include JBoss AS7 in Fedora:
 
   https://fedoraproject.org/wiki/JBossAS7
 
 I'm very interested in having JDK7 packaged because it is required to build 
 one of JBoss AS7 dependencies (XNIO). 
 

Hi Marek,

Yes, we are just sorting out some stuff on the team side (to figure out
most feasible/maintainable approach). As soon as that is done, I will push a
java-1.7.0-openjdk package.

The alpha deadline is on Tuesday and I hope (.. :) ) to have it built and in
before then.

Cheers,
Deepak
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Reindl Harald]

Am 28.07.2011 15:34, schrieb Marian Ganisin:
 On Wed, Jul 27, 2011 at 10:36:08AM -0400, Bernd Stramm wrote:
 c) there's a spec about ~/.local/bin already accepted by a friendly
 project

 This is STILL a security risk, even if somebody calls it a standard.
 
 This is STILL a claim without any proof, even if somebody repeats it
 every time.
 
 Does everybody calling this security risk check periodically his $PATH
 for a dot? (what does $PATH contain? don't look at it before answering)
 Are you periodically checking your ~/bin (do you know what's inside
 without looking there right now)? Are you periodically checking your
 ~/.bash* startup files for suspicious aliases and functions, includes?
 
 If you are _not_ watching really carefully your $HOME, this will not
 bring new security risk for your machine (all are already there). On the
 other way if you do so, again this will not bring new security risk to
 your machine.

mhh and adding another place as default makes things better?

PATH should as small as possible for PEFRORMANCE AND SECURITY
reasons and everybody who believes to need a additional one
is free to edit HIS profile but there is nothing which speaks
for another DEFAULT!



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Remove bundled libraries from a Qt package TexStudio

[80]

Hi,

i cooked few patches for you:
* remove hunspell == basically, you just need to remove all
references to the bundled hunspell in texstudio.pro and use system
headers instead of bundled ones.
* force the use of xdg-open for viewers, this patch should be
upstreamed or at least, fix function x11desktop_env() to recognize
more desktops than just KDE (most desktop sets DESKTOP_SESSION
environment variable which comes from freesdesktop). But using
xdg-open is more flexible and allow users choosing their preferred
viewer.
* for qtsingleapplication, it provides a features configuration file,
so qmake will automagically configure this for you if you add
qtsingleapplication to CONFIG variable

Btw, you should drop BuildRequires: gcc-objc++ as it's completely useless.
best regards,
H.
From 2ae917fad7cd4e5d3043e3ab3f1cfe4faa63f532 Mon Sep 17 00:00:00 2001
From: Haikel Guemar haikel.gue...@sysfera.com
Date: Thu, 28 Jul 2011 16:55:32 +0200
Subject: [PATCH 1/3] viewers: use xdg-open

---
 buildmanager.cpp |   22 +-
 1 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/buildmanager.cpp b/buildmanager.cpp
index 1441564..d8986bb 100644
--- a/buildmanager.cpp
+++ b/buildmanager.cpp
@@ -460,23 +460,11 @@ QString BuildManager::guessCommandName(LatexCommand cmd) {
 // kdvi file:%.dvi#src:@ %.tex
 	switch (cmd) {
 	case CMD_VIEWDVI:
-		switch (x11desktop_env()) {
-		case 3:	return kdvi %.dvi  /dev/null;
-		case 4:	return okular %.dvi  /dev/null;
-		default:return evince %.dvi  /dev/null;
-		};
+return xdg-open %.dvi  /dev/null;
 	case CMD_VIEWPS:
-		switch (x11desktop_env()) {
-		case 3: return kghostview %.ps  /dev/null;
-		case 4:	return okular %.ps  /dev/null;
-		default:return evince %.ps  /dev/null;
-		};
+		return xdg-open %.ps  /dev/null;
 	case CMD_VIEWPDF:
-		switch (x11desktop_env()) {
-		case 3: return kpdf %.pdf  /dev/null;
-		case 4:	return okular %.pdf  /dev/null;
-		default:return evince %.pdf  /dev/null;
-		};
+		return xdg-open %.pdf  /dev/null;
 	default:;
 	}
 #endif
@@ -610,7 +598,7 @@ void BuildManager::setLatexCommand(LatexCommand cmd, const QString cmdString){
 		((unquote == baseName) ||
 		 (   (unquote.endsWith(QDir::separator() + baseName) || unquote.endsWith(/ + baseName))
 		   (!unquote.contains( ) || (!unquote.contains('')  unquote != trimmed)) //spaces mean options, if not everything is quoted
-		   (QFileInfo(unquote).exists())		  
+		   (QFileInfo(unquote).exists())
 		  )
 		 ))
 			commands[cmd] = cmdString +   + defaultCommandOptions(cmd);
@@ -619,7 +607,7 @@ void BuildManager::setLatexCommand(LatexCommand cmd, const QString cmdString){
 	}
 }
 
-QString BuildManager::getLatexCommand(LatexCommand cmd){ 
+QString BuildManager::getLatexCommand(LatexCommand cmd){
 	return commands[cmd];
 }
 QString BuildManager::getLatexCommandForDisplay(LatexCommand cmd){
-- 
1.7.4.4

From e14c4085029e89da0006a83e72e20e8da29092fd Mon Sep 17 00:00:00 2001
From: Haikel Guemar haikel.gue...@sysfera.com
Date: Thu, 28 Jul 2011 17:01:34 +0200
Subject: [PATCH 2/3] use system hunspell instead of bundled one

---
 spellerutility.h |2 +-
 texstudio.pro|   38 +++---
 2 files changed, 8 insertions(+), 32 deletions(-)

diff --git a/spellerutility.h b/spellerutility.h
index 730920e..bb996e2 100644
--- a/spellerutility.h
+++ b/spellerutility.h
@@ -13,7 +13,7 @@
 
 #include mostQtHeaders.h
 
-#include hunspell/hunspell.hxx
+#include hunspell.hxx
 class SpellerUtility: public QObject {
 	Q_OBJECT
 public:
diff --git a/texstudio.pro b/texstudio.pro
index 437a376..c0b67da 100644
--- a/texstudio.pro
+++ b/texstudio.pro
@@ -55,24 +55,6 @@ HEADERS += texmaker.h \
 codesnippet.h \
 thesaurusdialog.h \
 xmltagslistwidget.h \
-hunspell/affentry.hxx \
-hunspell/affixmgr.hxx \
-hunspell/atypes.hxx \
-hunspell/baseaffix.hxx \
-hunspell/csutil.hxx \
-hunspell/dictmgr.hxx \
-hunspell/hashmgr.hxx \
-hunspell/htypes.hxx \
-hunspell/hunspell.hxx \
-hunspell/hunspell.h \
-hunspell/langnum.hxx \
-hunspell/license.hunspell \
-hunspell/phonet.hxx \
-hunspell/suggestmgr.hxx \
-hunspell/license.myspell \
-hunspell/filemgr.hxx \
-hunspell/hunzip.hxx \
-hunspell/w_char.hxx \
 qcodeedit/lib/qeditorinputbinding.h \
 qcodeedit/lib/qeditorinputbindinginterface.h \
 randomtextgenerator.h \
@@ -88,7 +70,6 @@ HEADERS += texmaker.h \
 latexdocument.h \
 unicodeinsertion.h \
 universalinputdialog.h \
-hunspell/replist.hxx \
 scriptengine.h \
 insertgraphics.h \
 tmxtabwidget.h \
@@ -142,18 +123,6 @@ SOURCES += main.cpp \
 codesnippet.cpp \
 thesaurusdialog.cpp \
 xmltagslistwidget.cpp \
-hunspell/affentry.cxx \
-hunspell/affixmgr.cxx \
-hunspell/csutil.cxx \
-hunspell/dictmgr.cxx \
-hunspell/hashmgr.cxx \
-hunspell/hunspell.cxx \
-hunspell/phonet.cxx \
-hunspell/replist.cxx 

Re: RPM version goes backward in Rawhide

[James Antill]

On Wed, 2011-07-27 at 09:19 -0700, Jesse Keating wrote:
 On 7/27/11 2:03 AM, Michael Schwendt wrote:
  In this case, the bad rpm-build broke koji builds, and since Rawhide
  may eat babies, it can happen that Rawhide users need downgrade manually
  while they have to wait for the fixed rpm-build.

 distro-sync also helps, and is a bit more generic.

 We are trying very hard to kill the notion that rawhide may eat 
 babies.  It's non-productive.

 Sisyphean task ... IMO.

   There are multiple ways to throw 
 baby-eating updates over the wall for testing before they get into 
 rawhide.  Stop treating it like a dumping ground.

 But at some point you have to commit. You have to have a place all the
updates go first, currently that's rawhide. It's been rawhide for ~20
years, it seems like a better idea for it to continue to be rawhide and
just create a tanned repo. (or multiple ones) that eats less babies.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Starting a SIG for package reviews

[Jason L Tibbitts III]

 SO == Stanislav Ochotnicky sochotni...@redhat.com writes:

SO I believe you forgot to set whenisgood to use timezones :-)

My understanding is that you have to log in in order to set your
timezone, or that choosing a timezone was something the responder had to
do.  When I created the form, Use timezones was checked.

Not that I'm at all an expert at using that system.

 - J

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Starting a SIG for package reviews

[Jon Ciesla]

Jason L Tibbitts III wrote:
 SO == Stanislav Ochotnicky sochotni...@redhat.com writes:
 

 SO I believe you forgot to set whenisgood to use timezones :-)

 My understanding is that you have to log in in order to set your
 timezone, or that choosing a timezone was something the responder had to
 do.  When I created the form, Use timezones was checked.

 Not that I'm at all an expert at using that system.

  - J

   
I just assumed, that since I'm an American, that everyone used my 
timezone.  Right?

;)

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RPM version goes backward in Rawhide

[Jesse Keating]

On 7/28/11 8:41 AM, James Antill wrote:
   Sisyphean task ... IMO.

So was moving us off of CVS.  *shrug*

  There are multiple ways to throw
   baby-eating updates over the wall for testing before they get into
   rawhide.  Stop treating it like a dumping ground.
   But at some point you have to commit. You have to have a place all the
 updates go first, currently that's rawhide. It's been rawhide for ~20
 years, it seems like a better idea for it to continue to be rawhide and
 just create a tanned repo. (or multiple ones) that eats less babies.

Actually the plan log ago was to involve AutoQA as a filter between I 
built this package for rawhide and this build showed up in buildroots 
and the public rawhide repo.

At first the autoQA tests were going to be very simplistic, like does 
it break every dep in the world, or things like that.  It would also 
allow developers to manually override the test results and push a 
package anyway if they knew what they were doing.  Then as that got 
mature we could start introducing package specific functional testing as 
well.

Since much of this rests on the shoulders of AutoQA, it is not 
surprising that it isn't documented much in the wiki.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)

[Till Maas]

On Tue, Jul 26, 2011 at 09:29:40AM -0700, Jesse Keating wrote:
 On 7/26/11 8:48 AM, Till Maas wrote:
  I hereby propose to change this in the future and explicitly CC
  comaintainers to make them aware that their package is orphaned.
 
 This can easily be done by just mailing 
 package-ow...@fedoraproject.org  It will get to all co-maintainers.

This might not work for orphaned packages, because I tried it for Miro
but the mail bounced.

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)

[Jesse Keating]

On 7/28/11 9:02 AM, Till Maas wrote:
 On Tue, Jul 26, 2011 at 09:29:40AM -0700, Jesse Keating wrote:
 On 7/26/11 8:48 AM, Till Maas wrote:
 I hereby propose to change this in the future and explicitly CC
 comaintainers to make them aware that their package is orphaned.

 This can easily be done by just mailing
 package-ow...@fedoraproject.org  It will get to all co-maintainers.

 This might not work for orphaned packages, because I tried it for Miro
 but the mail bounced.

 Regards
 Till

Sounds like a bug in the alias generator.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Till Maas]

On Wed, Jul 27, 2011 at 02:00:28PM -0700, Jesse Keating wrote:
 On 7/27/11 1:09 PM, Reindl Harald wrote:
  Depends on the PATH-Order
 
  if something is intended to be first in PATH and any attacker is able
  to write there his ls would win against /bin/ls
 
 So, the attacker can write a compromised ls into .local/bin/, but isn't 
 able to modify your .bash_profile ?  Seems like a stretch.

Such vulnerabilities/exploits existed in the past, e.g. I remember one
that allowed to create new world readable files at an arbitrary
location. It was not possible to change existing files with that
exploit.

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RPM version goes backward in Rawhide

[Nalin Dahyabhai]

On Thu, Jul 28, 2011 at 11:41:47AM -0400, James Antill wrote:
 On Wed, 2011-07-27 at 09:19 -0700, Jesse Keating wrote:
  On 7/27/11 2:03 AM, Michael Schwendt wrote:
   In this case, the bad rpm-build broke koji builds, and since Rawhide
   may eat babies, it can happen that Rawhide users need downgrade manually
   while they have to wait for the fixed rpm-build.
 
  distro-sync also helps, and is a bit more generic.
 
  We are trying very hard to kill the notion that rawhide may eat 
  babies.  It's non-productive.
 
  Sisyphean task ... IMO.
 
There are multiple ways to throw 
  baby-eating updates over the wall for testing before they get into 
  rawhide.  Stop treating it like a dumping ground.
 
  But at some point you have to commit. You have to have a place all the
 updates go first, currently that's rawhide. It's been rawhide for ~20
 years, it seems like a better idea for it to continue to be rawhide and
 just create a tanned repo. (or multiple ones) that eats less babies.

Raw Hide's only existed since 1998 [1], but anyway.

I'd lean more toward reminding package maintainers who put updates into
Raw Hide that what they put there impacts everyone else who's trying to
put updates into Raw Hide -- _one_ person breaking Raw Hide makes it
harder for _all_ package maintainers to get things done.

I'm probably understating just how frustrating that is (for me, at
least), but using harsher words would probably undermine my point.

Nalin

[1] http://www.redhat.com/about/news/prarchive/1998/press_rolling.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Starting a SIG for package reviews

[Iain Arnell]

On Thu, Jul 28, 2011 at 5:55 PM, Jon Ciesla l...@jcomserv.net wrote:
 Jason L Tibbitts III wrote:
 SO == Stanislav Ochotnicky sochotni...@redhat.com writes:


 SO I believe you forgot to set whenisgood to use timezones :-)

 My understanding is that you have to log in in order to set your
 timezone, or that choosing a timezone was something the responder had to
 do.  When I created the form, Use timezones was checked.

 Not that I'm at all an expert at using that system.

 I just assumed, that since I'm an American, that everyone used my
 timezone.  Right?

 ;)

Except in the summer (which is pretty much all the time) in most of
Arizona (or Hawaii) where you're on American Daylight Spending Time
and the rest of the country has to drive ~1000 miles east to catch up
(which is why Hawaii's on the list - at least until they finish
building I10 west of LA).



-- 
Iain.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/07/11 15:46, Genes MailLists wrote:
 On 07/28/2011 09:09 AM, Bryn M. Reeves wrote:
 On 07/28/2011 01:41 PM, Genes MailLists wrote:
 On 07/28/2011 07:53 AM, Bryn M. Reeves wrote:
 On 07/28/2011 12:46 PM, Genes MailLists wrote:

   This is a good point. Especially when you start on a 64 bit box and
 login to a 32 bit (or other arch) - bin now makes now sense at all. You
 need arch specific bins (bin, bin64 etc).

 Currently Fedora only separates out the /lib* directories in multilib
 installations - you'll find a mix of 32 and 64 bit binaries in the system 
 binary
 paths on these systems.


  which is fine for a 'system' which is 64 bit and may support 32 bit as
 well - its not fine for a 'user'  who logs in to a 32 bit machine from a
 64 bit machine and now his binaries wont work.

 Separating bin paths like this would not solve the problem; anything that's 
 only
 present in one path or the other would still fail in the scenario you 
 suggest.
 You could equally install foo/foo64 or vice versa into the same directory.

 
   I don't follow your thought here - if you have a bin64/ and a bin/
 etc and you have your shell initscripts decide (e.g. using uname -m)
 which of those to include in your PATH I think it does work ... provided
 you have (obviously) both (all) populated with whats needed...

But that is still going to be a convoluted mess.  For those poor users who
then have access to arm, ia32, ppc64, s390x and x86_64, you suddenly need 5
different ~/.local/bin directories ... And I've probably forgotten some arches.

~/.local/bin (or even ~/bin for that matter) as default in $PATH is going
to be a mess, no matter how you twist it.  Because of the architecture
issues.  For scripts it will of course work fine in most cases, but in the
moment programs begins to get installed in ~/.local/bin (or ~/bin), then
we're definitely on the wrong track.

Binaries are related to the hardware it's running on, and should not be
related to $HOME at all.  In my opinion, $HOME must be arch agnostic.

I begin to fear that not being stricter on the pure original purpose of the
directory separation from the original Unix days is going to bite us hard
soon.  /home is for *user data*, and not binaries to start with.  Advanced
users understands this, and understands what will happen when their
binaries are attempted started on a different arch via NFS mounts.  They
most likely also know what they're doing when creating ~/bin or similar
directories and updating their .*shrc.  Average user John Doe, doesn't
really need know this, and shouldn't really be bothered to care about
binaries in his $HOME directory.

So often the road to hell is paved with good intentions.  To have
~{/.local,}/bin in default $PATH is indeed a good intention at first
glance.  However, it might not be the best solution for everybody.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4xj/oACgkQIIWEatLf4Hem+QCgqEuDYWw2G+BMxNYuFxHoRnY7
6SUAn33zcXqwudsrVJEv4iQu0vQ0Kurm
=B1HH
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Remove bundled libraries from a Qt package TexStudio

[Johannes Lips]

Awesome, works great!

Thanks a lot!

johannes
On 07/28/2011 05:36 PM, 80 wrote:
 Hi,

 i cooked few patches for you:
 * remove hunspell ==  basically, you just need to remove all
 references to the bundled hunspell in texstudio.pro and use system
 headers instead of bundled ones.
 * force the use of xdg-open for viewers, this patch should be
 upstreamed or at least, fix function x11desktop_env() to recognize
 more desktops than just KDE (most desktop sets DESKTOP_SESSION
 environment variable which comes from freesdesktop). But using
 xdg-open is more flexible and allow users choosing their preferred
 viewer.
 * for qtsingleapplication, it provides a features configuration file,
 so qmake will automagically configure this for you if you add
 qtsingleapplication to CONFIG variable

 Btw, you should drop BuildRequires: gcc-objc++ as it's completely useless.
 best regards,
 H.




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Genes MailLists]

On 07/28/2011 12:36 PM, David Sommerseth wrote:

 
   I don't follow your thought here - if you have a bin64/ and a bin/
 etc and you have your shell initscripts decide (e.g. using uname -m)
 which of those to include in your PATH I think it does work ... provided
 you have (obviously) both (all) populated with whats needed...
 
 But that is still going to be a convoluted mess.  For those poor users who
 then have access to arm, ia32, ppc64, s390x and x86_64, you suddenly need 5
 different ~/.local/bin directories ... And I've probably forgotten some 
 arches.

 I concur - I voted against this proposal :-) - the arch stuff just
reinforces why its not a good design whenever there are any binaries
involved ..
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

gmime maintainer unresponsive

[Clemens Buchacher]

Hi,

I filed a report for what I believe to be a rather obvious but
serious bug concerning the gmime package [1]. Unfortunately, the
package does not seem to get any attenation from maintainers. I
have tried to contact Alexsander Larsson by email, offering to
co-maintain the package, but no luck so far. Do I have to exercise
the non-responsive maintainer policy or can you guys help me out?

TIA,
Clemens

[1] https://bugzilla.redhat.com/show_bug.cgi?id=723835
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RPM version goes backward in Rawhide

[Dennis Gilmore]

On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
 On 7/26/11 1:14 PM, Michael Schwendt wrote:
  Yes, It got untagged. See last week's thread on this list:
  Subject: rpm builds failing with Installed (but unpackaged) file(s)
  found
 
 I thought there was a hard rule about not having nvrs go backwards, and
 if a bad build was put out, it should be fixed with epoch or other such
 NVR things to make sure the upgrade path continues.  (that is once a
 build makes it out in the nightly repos)

I untagged the rpm build and we do have that rule, I could have sworn that it 
had only been built that day and not made it into rawhide. if i had realised 
that it had made it to rawhide i would have bumped the epoch on the old build 
to ensure that updating was correctly handled.

Dennis


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide openssh-server update kills sshd

[Lennart Poettering]

On Wed, 27.07.11 16:56, James Antill (ja...@fedoraproject.org) wrote:

It looks more like the first victim of systemd using cgroups as a
   replacement for setsid() etc. ... pam_systemd being the first return
   volley in that war. *sigh*.
  
  systemd is not using cgroups as replacement for setsid().
 
  And then you go on to explain how pam_systemd is required so that it
 can do the setsid() like remove me from the session call ... and thus.
 not get hit with the kill() sent to the previous session.
  I'm not saying that cgroups doesn't do _other_ things as well ... but
 using it as a shiner setsid() is just doomed to a war where everyone
 puts cgroup calls where setsid() calls currently are.

setsid() is primarily a call to implement job control in shells.

systemd is not involved in job control in shells. Never has, never will
be.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding ~/.local/bin to default PATH

[Lennart Poettering]

On Wed, 27.07.11 21:59, Marc-André Lureau (marcandre.lur...@gmail.com) wrote:

 
 Hi
 
 2011/7/27 Miloslav Trmač m...@volny.cz:
  (And of course, the thing to standardize would not be bin, but a
  subdirectory structure as defined by the GNU standards for --prefix.)
 
 I agree, it is precisely what I would like to see in a standard, a
 home GNU prefix for installing projects locally (that is, /opt and
 /usr/local are not an option).

You can read XDG basedir as spec that defines ~/.local as such a
directory if you wish, with the exception of ~/.config used as
replacement for etc.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning pdfedit

[Orion Poplawski]

I intend to orphan and dead.package pdfedit.  If anyone wants to take it feel 
free.  It has a unmaintained and buggy qt3 interface.  Perhaps someday 
upstream will create a new qt4 one, but I'm done holding my breath.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RPM version goes backward in Rawhide

[Kalev Lember]

On 07/28/2011 08:48 PM, Dennis Gilmore wrote:
 On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
 I thought there was a hard rule about not having nvrs go backwards, and
 if a bad build was put out, it should be fixed with epoch or other such
 NVR things to make sure the upgrade path continues.  (that is once a
 build makes it out in the nightly repos)
 
 I untagged the rpm build and we do have that rule, I could have sworn that it 
 had only been built that day and not made it into rawhide. if i had realised 
 that it had made it to rawhide i would have bumped the epoch on the old build 
 to ensure that updating was correctly handled.

Bumping epoch in rpm would have made it harder for all other packages to
depend on a particular rpm version. Instead of having e.g.
Requires: rpm = 4.9.1, they would now also have to remember the put the
correct epoch in there.

I think it's reasonable to have a broken package pulled from rawhide for
a little while, if it's going to be properly fixed up in a few days.
Yes, we should try to avoid such things, but having a hard rule here
would be counter-productive.

Also, we have a much worse case of versions going backwards. After each
Alpha release, lots of people are going to install Branched pre-releases
and they automatically get enabled updates-testing repos. And in that
updates-testing repo, packages are often pulled out and versions go
backwards. Why is such practice allowed in Branched, but not in rawhide?


-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RPM version goes backward in Rawhide

[Adam Williamson]

On Fri, 2011-07-29 at 02:29 +0300, Kalev Lember wrote:
 On 07/28/2011 08:48 PM, Dennis Gilmore wrote:
  On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
  I thought there was a hard rule about not having nvrs go backwards, and
  if a bad build was put out, it should be fixed with epoch or other such
  NVR things to make sure the upgrade path continues.  (that is once a
  build makes it out in the nightly repos)
  
  I untagged the rpm build and we do have that rule, I could have sworn that 
  it 
  had only been built that day and not made it into rawhide. if i had 
  realised 
  that it had made it to rawhide i would have bumped the epoch on the old 
  build 
  to ensure that updating was correctly handled.
 
 Bumping epoch in rpm would have made it harder for all other packages to
 depend on a particular rpm version. Instead of having e.g.
 Requires: rpm = 4.9.1, they would now also have to remember the put the
 correct epoch in there.
 
 I think it's reasonable to have a broken package pulled from rawhide for
 a little while, if it's going to be properly fixed up in a few days.
 Yes, we should try to avoid such things, but having a hard rule here
 would be counter-productive.
 
 Also, we have a much worse case of versions going backwards. After each
 Alpha release, lots of people are going to install Branched pre-releases
 and they automatically get enabled updates-testing repos. And in that
 updates-testing repo, packages are often pulled out and versions go
 backwards. Why is such practice allowed in Branched, but not in rawhide?

Indeed; and remember we have yum distro-sync which fixes that problem
quite nicely, I don't see why it shouldn't also work for quick reverts
in Rawhide.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-FileHandle-Unget] Tweak provides filter for rpm 4.9 compatibility

[Paul Howarth]

commit df78db29835f1f0c84b0624937bcd05a7a62779b
Author: Paul Howarth p...@city-fan.org
Date:   Thu Jul 28 11:17:25 2011 +0100

Tweak provides filter for rpm 4.9 compatibility

- Tweak provides filter for rpm 4.9 compatibility
- Nobody else likes macros for commands
- Use DESTDIR rather than PERL_INSTALL_ROOT

 perl-FileHandle-Unget.spec |   38 +-
 1 files changed, 25 insertions(+), 13 deletions(-)
---
diff --git a/perl-FileHandle-Unget.spec b/perl-FileHandle-Unget.spec
index 4d1e505..ddc8fce 100644
--- a/perl-FileHandle-Unget.spec
+++ b/perl-FileHandle-Unget.spec
@@ -1,16 +1,19 @@
+# Need to tweak provides filter differently if we have rpm 4.9 onwards
+%global rpm49 %(rpm --version | perl -pi -e 's/^.* 
(\\d+)\\.(\\d+)\\.(\\d+).*/sprintf(%d.%03d%03d,$1,$2,$3) ge 4.009 ? 1 : 0/e')
+
 Summary:   A FileHandle that supports ungetting of multiple bytes
 Name:  perl-FileHandle-Unget
 Version:   0.1623
-Release:   7%{?dist}
+Release:   8%{?dist}
 License:   GPL+
 Group: Development/Libraries
 Url:   http://search.cpan.org/dist/FileHandle-Unget/
 Source0:   
http://search.cpan.org/CPAN/authors/id/D/DC/DCOPPIT/FileHandle-Unget-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildArch: noarch
 BuildRequires: perl(Scalar::Util) = 1.14
 BuildRequires: perl(Devel::Leak), perl(ExtUtils::MakeMaker), perl(Test::More)
-Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+Requires:  perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 Provides:  perl(FileHandle::Unget) = %{version}
 
 %description
@@ -22,26 +25,30 @@ string of bytes back on the input.
 %prep
 %setup -q -n FileHandle-Unget-%{version}
 
-# Auto provides aren't clever enough for what FileHandle::Unget does
-%global provfilt /bin/sh -c %{__perl_provides} | %{__grep} -v 
'^perl(FileHandle::Unget)'
+# Drop bogus autodetected provide
+%if %{rpm49}
+%global __provides_exclude ^perl\\(FileHandle::Unget\\)
+%else
+%global provfilt /bin/sh -c %{__perl_provides} | grep -v 
'^perl(FileHandle::Unget)'
 %define __perl_provides %{provfilt}
+%endif
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-%{__make} %{?_smp_mflags}
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
 
 %install
-%{__rm} -rf %{buildroot}
-%{__make} pure_install PERL_INSTALL_ROOT=%{buildroot}
-/usr/bin/find %{buildroot} -type f -name .packlist -exec %{__rm} -f {} ';'
-/usr/bin/find %{buildroot} -depth -type d -exec /bin/rmdir {} ';' 2/dev/null
+rm -rf %{buildroot}
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} ';' 2/dev/null
 %{_fixperms} %{buildroot}
 
 %check
-%{__make} test
+make test
 
 %clean
-%{__rm} -rf %{buildroot}
+rm -rf %{buildroot}
 
 %files
 %defattr(-,root,root,-)
@@ -50,6 +57,11 @@ string of bytes back on the input.
 %{_mandir}/man3/FileHandle::Unget.3pm*
 
 %changelog
+* Thu Jul 28 2011 Paul Howarth p...@city-fan.org 0.1623-8
+- Tweak provides filter for rpm 4.9 compatibility
+- Nobody else likes macros for commands
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+
 * Sun Jun 19 2011 Marcela Mašláňová mmasl...@redhat.com - 0.1623-7
 - Perl mass rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-FileHandle-Unget/f16] Tweak provides filter for rpm 4.9 compatibility

[Paul Howarth]

Summary of changes:

  df78db2... Tweak provides filter for rpm 4.9 compatibility (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-FileHandle-Unget] Created tag perl-FileHandle-Unget-0.1623-8.fc16

[Paul Howarth]

The lightweight tag 'perl-FileHandle-Unget-0.1623-8.fc16' was created pointing 
to:

 df78db2... Tweak provides filter for rpm 4.9 compatibility
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-FileHandle-Unget] Created tag perl-FileHandle-Unget-0.1623-8.fc17

[Paul Howarth]

The lightweight tag 'perl-FileHandle-Unget-0.1623-8.fc17' was created pointing 
to:

 df78db2... Tweak provides filter for rpm 4.9 compatibility
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 726348] New: perl-POE-1.311 is available

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: perl-POE-1.311 is available

https://bugzilla.redhat.com/show_bug.cgi?id=726348

   Summary: perl-POE-1.311 is available
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
 Component: perl-POE
AssignedTo: cw...@alumni.drew.edu
ReportedBy: upstream-release-monitor...@fedoraproject.org
 QAContact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu,
fedora-perl-devel-l...@redhat.com
Classification: Fedora
  Story Points: ---
  Type: ---


Latest upstream release: 1.311
Current version in Fedora Rawhide: 1.289
URL: http://search.cpan.org/dist/POE/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 715559] perl-Mojolicious-1.67 is available

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=715559

Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 
changed:

   What|Removed |Added

Summary|perl-Mojolicious-1.66 is|perl-Mojolicious-1.67 is
   |available   |available

--- Comment #8 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org 2011-07-28 06:41:08 EDT ---
Latest upstream release: 1.67
Current version in Fedora Rawhide: 1.46
URL: http://search.cpan.org/dist/Mojolicious/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 726348] perl-POE-1.311 is available

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=726348

Petr Sabata psab...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||psab...@redhat.com
 AssignedTo|cw...@alumni.drew.edu   |psab...@redhat.com

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-RPM-VersionCompare] 0.1.1 bump

[Petr Pisar]

commit e7072eeb59ee110907128fd1f3256562a8822552
Author: Petr Písař ppi...@redhat.com
Date:   Thu Jul 28 13:48:36 2011 +0200

0.1.1 bump

 .gitignore   |1 +
 perl-RPM-VersionCompare.spec |8 ++--
 sources  |2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5a189c8..3a76b27 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /RPM-VersionCompare-v0.1.0.tar.gz
+/RPM-VersionCompare-v0.1.1.tar.gz
diff --git a/perl-RPM-VersionCompare.spec b/perl-RPM-VersionCompare.spec
index de1a087..bbf0735 100644
--- a/perl-RPM-VersionCompare.spec
+++ b/perl-RPM-VersionCompare.spec
@@ -1,6 +1,6 @@
 Name:   perl-RPM-VersionCompare
-Version:0.1.0
-Release:2%{?dist}
+Version:0.1.1
+Release:1%{?dist}
 Summary:Compare RPM version strings
 License:GPLv3+
 Group:  Development/Libraries
@@ -50,8 +50,12 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 28 2011 Petr Pisar ppi...@redhat.com - 0.1.1-1
+- 0.1.1 bump
+
 * Fri Jun 17 2011 Marcela Mašláňová mmasl...@redhat.com - 0.1.0-2
 - Perl mass rebuild
+- Fixes parsing epoch longer than one character (bug #725608)
 
 * Fri May 27 2011 Petr Pisar ppi...@redhat.com 0.1.0-1
 - Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e5b0cb9..6f7e4f1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-916c1eb744e86941b0d921ab80f511a7  RPM-VersionCompare-v0.1.0.tar.gz
+ff00cb097c8aec91b03e1514838d0614  RPM-VersionCompare-v0.1.1.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-RPM-VersionCompare/f16] 0.1.1 bump

[Petr Pisar]

Summary of changes:

  e7072ee... 0.1.1 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-RPM-VersionCompare/f16] Correct changelog

[Petr Pisar]

Summary of changes:

  c937032... Correct changelog (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-RPM-VersionCompare/f15] 0.1.1 bump

[Petr Pisar]

commit e31faaf92442c7d0cedd84410ad24af98b7e8c71
Author: Petr Písař ppi...@redhat.com
Date:   Thu Jul 28 13:48:36 2011 +0200

0.1.1 bump

 .gitignore   |1 +
 perl-RPM-VersionCompare.spec |6 +-
 sources  |2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5a189c8..3a76b27 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /RPM-VersionCompare-v0.1.0.tar.gz
+/RPM-VersionCompare-v0.1.1.tar.gz
diff --git a/perl-RPM-VersionCompare.spec b/perl-RPM-VersionCompare.spec
index 289f620..c8bd0b8 100644
--- a/perl-RPM-VersionCompare.spec
+++ b/perl-RPM-VersionCompare.spec
@@ -1,5 +1,5 @@
 Name:   perl-RPM-VersionCompare
-Version:0.1.0
+Version:0.1.1
 Release:1%{?dist}
 Summary:Compare RPM version strings
 License:GPLv3+
@@ -50,6 +50,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 28 2011 Petr Pisar ppi...@redhat.com - 0.1.1-1
+- 0.1.1 bump
+- Fixes parsing epoch longer than one character (bug #725608)
+
 * Fri May 27 2011 Petr Pisar ppi...@redhat.com 0.1.0-1
 - Specfile autogenerated by cpanspec 1.78.
 - Remove BuildRoot and defattr
diff --git a/sources b/sources
index e5b0cb9..6f7e4f1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-916c1eb744e86941b0d921ab80f511a7  RPM-VersionCompare-v0.1.0.tar.gz
+ff00cb097c8aec91b03e1514838d0614  RPM-VersionCompare-v0.1.1.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-RPM-VersionCompare/f14] 0.1.1 bump

[Petr Pisar]

Summary of changes:

  e31faaf... 0.1.1 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 725608] Module does not parse epoch correctly

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=725608

--- Comment #2 from Fedora Update System upda...@fedoraproject.org 2011-07-28 
08:16:13 EDT ---
perl-RPM-VersionCompare-0.1.1-1.fc16 has been submitted as an update for Fedora
16.
https://admin.fedoraproject.org/updates/perl-RPM-VersionCompare-0.1.1-1.fc16

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 725608] Module does not parse epoch correctly

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=725608

--- Comment #3 from Fedora Update System upda...@fedoraproject.org 2011-07-28 
08:16:37 EDT ---
perl-RPM-VersionCompare-0.1.1-1.fc15 has been submitted as an update for Fedora
15.
https://admin.fedoraproject.org/updates/perl-RPM-VersionCompare-0.1.1-1.fc15

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 725608] Module does not parse epoch correctly

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=725608

--- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-07-28 
08:16:53 EDT ---
perl-RPM-VersionCompare-0.1.1-1.fc14 has been submitted as an update for Fedora
14.
https://admin.fedoraproject.org/updates/perl-RPM-VersionCompare-0.1.1-1.fc14

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 718225] bad dependency: forgot %{_isa}

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=718225

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution||RAWHIDE
Last Closed||2011-07-28 11:26:55

--- Comment #6 from Petr Pisar ppi...@redhat.com 2011-07-28 11:26:55 EDT ---
Separate build root for Perl 5.14 has been merged to Fedora 16.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-NetPacket-SpanningTree] fixed license

[Jan Klepek]

commit f8b1b91545569fadafac1e90749a6369646a573b
Author: Jan Klepek jan.kle...@gmail.com
Date:   Thu Jul 28 20:16:40 2011 +0200

fixed license

 .gitignore   |1 +
 perl-NetPacket-SpanningTree.spec |   64 ++
 sources  |1 +
 3 files changed, 66 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..445e099 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/NetPacket-SpanningTree-0.01.tar.gz
diff --git a/perl-NetPacket-SpanningTree.spec b/perl-NetPacket-SpanningTree.spec
new file mode 100644
index 000..c2ea173
--- /dev/null
+++ b/perl-NetPacket-SpanningTree.spec
@@ -0,0 +1,64 @@
+Name:   perl-NetPacket-SpanningTree
+Version:0.01
+Release:3%{?dist}
+Summary:Assemble and disassemble IEEE 802.1D Spanning Tree protocol 
packets
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/NetPacket-SpanningTree/
+Source0:
http://www.cpan.org/authors/id/C/CG/CGANESAN/NetPacket-SpanningTree-%{version}.tar.gz
+# email from author with permissions to relicense sources under Artistic or GPL
+Source1:%{name}.email
+BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildArch:  noarch
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(NetPacket::Ethernet) = 0.04
+BuildRequires:  perl(NetPacket::LLC) = 0.01
+Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+
+%{?perl_default_filter}
+
+%description
+NetPacket::SpanningTree provides a set of routines for assembling and
+disassembling packets using the IEEE standard Spanning Tree Protocol.
+Spanning Tree is a layer 2 protocol defined by the IEEE 802.1D
+specification.
+
+%prep
+%setup -q -n NetPacket-SpanningTree-%{version}
+cp %{SOURCE1} .
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README %{name}.email
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Sat Jul 23 2011 Jan Klepek jan.klepek at, gmail.com - 0.01-3
+- fixed license
+
+* Tue Jan 11 2011 Jan Klepek jan.klepek at, gmail.com - 0.01-2
+- fixed license
+
+* Mon Mar 15 2010 Jan Klepek 0.01-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..85d8467 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+bd657ce34022611b22f1882413a74184  NetPacket-SpanningTree-0.01.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File NetPacket-SpanningTree-0.01.tar.gz uploaded to lookaside cache by hpejakle

[Jan Klepek]

A file has been added to the lookaside cache for perl-NetPacket-SpanningTree:

bd657ce34022611b22f1882413a74184  NetPacket-SpanningTree-0.01.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-NetPacket-SpanningTree/f15] fixed license

[Jan Klepek]

Summary of changes:

  f8b1b91... fixed license (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-NetPacket-SpanningTree/f14] fixed license

[Jan Klepek]

Summary of changes:

  f8b1b91... fixed license (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-NetPacket-SpanningTree/el5] fixed license

[Jan Klepek]

Summary of changes:

  f8b1b91... fixed license (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Compress-Raw-Bzip2/f16] bump and rebuild, got compiled with old perl on ppc

[Karsten Hopp]

commit 86306bbb77cf5c1ce75db6fa89a9eabe81f8d576
Author: Karsten Hopp kars...@redhat.com
Date:   Thu Jul 28 22:29:13 2011 +0200

bump and rebuild, got compiled with old perl on ppc

 perl-Compress-Raw-Bzip2.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Compress-Raw-Bzip2.spec b/perl-Compress-Raw-Bzip2.spec
index 8fc0c48..7c7bbd9 100644
--- a/perl-Compress-Raw-Bzip2.spec
+++ b/perl-Compress-Raw-Bzip2.spec
@@ -1,7 +1,7 @@
 Name:   perl-Compress-Raw-Bzip2
 Summary:Low-Level Interface to bzip2 compression library
 Version:2.037
-Release:2%{?dist}
+Release:3%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/P/PM/PMQS/Compress-Raw-Bzip2-%{version}.tar.gz
 
@@ -57,6 +57,9 @@ make test
 %{_mandir}/man3/Compress::Raw::Bzip2.3pm*
 
 %changelog
+* Thu Jul 28 2011 Karsten Hopp kars...@redhat.com 2.037-3
+- bump and rebuild, got compiled with old perl on ppc
+
 * Wed Jun 22 2011 Paul Howarth p...@city-fan.org - 2.037-2
 - Perl mass rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel