date:20140110

On Sat, 2014-01-11 at 00:49 +0900, Mamoru TASAKA wrote:
 Chuck Anderson wrote, at 01/10/2014 11:56 PM +9:00:
  On Thu, Jan 09, 2014 at 10:42:33AM -0800, Adam Williamson wrote:
  On Thu, 2014-01-09 at 10:13 -0500, Chuck Anderson wrote:
  This appears to have also broken Fedora 19 updates-testing, which is
  even less acceptable than breaking rawhide.
 
  Eh, I'd suggest not. updates-testing is actually explicitly meant as a
  place to catch this kind of problem, whereas we're trying to keep
  Rawhide rolling and especially try not to break nightly image
  generation. At least we can vote broken things in updates-testing down.
 
  Wow, really?  updates-testing is allowed to be more broken than
  rawhide?  So why don't we just do all development in updates-testing,
  and don't push these changes to rawhide until they pass the
  updates-testing karma?
 
  This is not how I understand these things should work.  I think this
  attitude will push even fewer people to run with updates-testing
  enabled.
 
 
 Exactly.  Such possibly-breaking tests must be done on rawhide first,
 not after on testing on stable branch,
 and at least the package maintainer must get confident that enough tests are
 done on rawhide before pushing such packages into testing on stable branch.
 That testing on stable branch is more broken than rawhide is not Fedora users
 or developers expect.

Things don't really work out this neatly in practice. Most packages
diverge between rawhide and stable at some point. Especially a change
like the one under discussion doesn't necessarily work fine in one
branch just because it did in another.

I was just disagreeing with Chuck's belief that it's massively worse to
cause a relatively minor problem - it's not like this broke anyone's
system - in updates-testing than in Rawhide. I don't see a major
difference, really.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

On Thu, 2014-01-09 at 16:16 -0500, Przemek Klosowski wrote:
 On 01/09/2014 01:58 PM, Ian Malone wrote:
  Latest installed is almost exactly not what you want, I've had plenty
  (where plenty in this case is probably 5) of cases where a kernel
  update broke something, in quite a few of those cases to a state where
  the system wouldn't boot. If the most recent one is retained then
  you've still got a kernel, but not one that will actually run. With
  current behaviour I can still let my system update until a fix appears
  because I know it won't remove the good kernel. If updates can remove
  the running kernel then you have to watch each one carefully. 
 Right, so if you run into a situation where you need to run an old
 kernel-0.99, you'd protect it 
 with /etc/yum/protected.d/kernel-0.99.conf , assuming that yum allows
 specifying package version as well as the name.
 
 By the way, currently the protected list seems to be  'yum, systemd
 and running kernel'. I don't have a system to try it on, so I just
 hope that one can't delete their dependencies either (glibc? what
 else?).

No, you can't. Any operation that results in the removal of a protected
package is rejected.

  I think you can still brick the system with careless yum erases: for
 instance, deleting grub. 

Ooh, fun experiment. Let's see.

yum happily lets me remove grub2, but I don't think it breaks
boot: /boot/grub2/grub.cfg still exists after the removal, and it won't
have deleted the copy in the MBR. I'll see what happens when I reboot.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Should /usr/bin/Xorg (still) be setuid-root?

2014-01-10 Thread Hans de Goede


Hi,

On 01/09/2014 09:52 PM, Andrew Lutomirski wrote:

On Thu, Jan 9, 2014 at 11:43 AM, Hans de Goede hdego...@redhat.com wrote:

Hi,


On 01/09/2014 12:09 AM, Andrew Lutomirski wrote:


On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:


On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote:


/usr/bin/Xorg is, and has been, setuid-root just about forever.  I'm
wondering whether there's any good reason for it to remain
setuid-root.



http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights



This isn't actually the same thing.  That proposal suggests running
Xorg as a non-root user.  I'm proposing dropping the setuid bit on the
binary, which will have no effect on the uid of the running server.
(Of course, my suggestion will interact w/ that change, since the
process that starts Xorg will no longer be root.)



I don't think that that will be very useful, it will likely cause more
breakage then you think, as various display-managers may already start
Xorg inside the user session, at which point the suid bit is needed,
and as you already said it will break xinit and friends.


This is an empirical question :)  gdm on F20, at least, can still
switch users with the setuid bit cleared.  I'll try to test some more
display managers.


Well starting X inside the user session is necessary for the systemd-logind
integration I'm working on, which in turn is necessary to be able to completely
run X without any root rights at all. So this quite likely is going to be how
X will be started in F-21.


I hope it clears the bit -- I really don't like the fact that 'X :1'
screws with the display.


I'm not sure yet if it will clear the bit, I'm pretty sure I can get things
to work without any root rights for kms drivers (not 100% sure yet), but
ums drivers will fail hard without the suid bit, the ums part of this
needs some thinking (and needs me to dig up a card actually using it).

I might end up deciding to just kill ums support and then see what happens,
but I would rather not, and if I get enough pushback I might revert on
such a decision :)

Regards,

Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2013-12-18)

On Fri, 2013-12-20 at 10:49 +0100, Michael Scherer wrote:
 Le mercredi 18 décembre 2013 à 21:40 +, Jóhann B. Guðmundsson a
 écrit :
  On mið 18.des 2013 21:20, Reindl Harald wrote:
   who do you think you are to claim whatever people are outside the 
   community?
  
  Individual that tells that truth and shed's light how RH operates.
 
 Shed light on RH decide on its own how to spend their money without
 asking to others ? 
 Or the truth of having job title not decided by the community ?
 
  Since you are not aware of it Red Hat invented the position of Fedora QA 
  Community Manager ( I dont know who but I would very much like to meet 
  that person ) and placed Adam in that position.
 
 Community manager != manager. Yes, the title doesn't express it
 quite well, create some confusions and I would suggest to people in
 similar position to use community gardener as Dave Neary told me once
 to emphasise the difference.

*looks meaningfully at sig, which definitely does not contain the word
manager*
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2013-12-18)

On Fri, 2013-12-20 at 07:12 -0700, Kevin Fenzi wrote:
 This thread is no longer productive and is closed. 
 
 I urge everyone to re-read our code of conduct: 
 http://fedoraproject.org/code-of-conduct 

Sorry, missed that.

If I can address the topic a bit, since someone seemed interested in my
opinion: I see it much the way Kevin does - the process was documented
in the Bugzappers space on the wiki, but even when Bugzappers was active
it was usually actually performed by the Program Manager, and when
Bugzappers went dormant, no-one in QA made any effort to look after the
EOL process. I don't see it as something that's 'intrinsically' in QA's
domain - in fact it makes more sense to me that it's something the
program manager takes care of in a practical sense, and in a policy
sense, it would seem to be split across multiple groups, as Kevin notes.
It's certainly not just of interest to QA.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

2014-01-10 Thread Matthew Miller

On Fri, Jan 10, 2014 at 11:41:03AM -0800, Adam Williamson wrote:
  By the way, currently the protected list seems to be  'yum, systemd
  and running kernel'. I don't have a system to try it on, so I just
  hope that one can't delete their dependencies either (glibc? what
  else?).
 No, you can't. Any operation that results in the removal of a protected
 package is rejected.

And, for whatever it may be worth, that was very much part of the original
design intention -- to protect against carelessly removing things which are
part of the dep chain for something critical, even though they look like
they might be harmless to get rid of.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

2014-01-10 Thread Reindl Harald


Am 10.01.2014 20:55, schrieb Matthew Miller:
 On Fri, Jan 10, 2014 at 11:41:03AM -0800, Adam Williamson wrote:
 By the way, currently the protected list seems to be  'yum, systemd
 and running kernel'. I don't have a system to try it on, so I just
 hope that one can't delete their dependencies either (glibc? what
 else?).
 No, you can't. Any operation that results in the removal of a protected
 package is rejected.
 
 And, for whatever it may be worth, that was very much part of the original
 design intention -- to protect against carelessly removing things which are
 part of the dep chain for something critical, even though they look like
 they might be harmless to get rid of

anybody who managed to forcibly remove nss-softokn wile try to solve
dependency problems with a hammer and after that find out that nearly
*anything* on the system needs this package knows why

* rpm is dead
* yum is dead
* sshd is dead

in my case i managed it on that time by samba having a hidden root account*
and restore each file manually because boot from live media and chroot did
also no longer work (after chroot the same problems)

after that you understand why things are protected and that you should
hardly avoid try to bypass them until you are 1000% sure what you are
doing and there is no other way

*
yes this is many years ago and these days i would setup a
smb-root acccount only over my dead body



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Should /usr/bin/Xorg (still) be setuid-root?

2014-01-10 Thread Andrew Lutomirski

On Fri, Jan 10, 2014 at 11:44 AM, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 01/09/2014 09:52 PM, Andrew Lutomirski wrote:

 On Thu, Jan 9, 2014 at 11:43 AM, Hans de Goede hdego...@redhat.com
 wrote:

 Hi,


 On 01/09/2014 12:09 AM, Andrew Lutomirski wrote:


 On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer
 peter.hutte...@who-t.net
 wrote:


 On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote:


 /usr/bin/Xorg is, and has been, setuid-root just about forever.  I'm
 wondering whether there's any good reason for it to remain
 setuid-root.



 http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights



 This isn't actually the same thing.  That proposal suggests running
 Xorg as a non-root user.  I'm proposing dropping the setuid bit on the
 binary, which will have no effect on the uid of the running server.
 (Of course, my suggestion will interact w/ that change, since the
 process that starts Xorg will no longer be root.)



 I don't think that that will be very useful, it will likely cause more
 breakage then you think, as various display-managers may already start
 Xorg inside the user session, at which point the suid bit is needed,
 and as you already said it will break xinit and friends.


 This is an empirical question :)  gdm on F20, at least, can still
 switch users with the setuid bit cleared.  I'll try to test some more
 display managers.


 Well starting X inside the user session is necessary for the systemd-logind
 integration I'm working on, which in turn is necessary to be able to
 completely
 run X without any root rights at all. So this quite likely is going to be
 how
 X will be started in F-21.


 I hope it clears the bit -- I really don't like the fact that 'X :1'
 screws with the display.


 I'm not sure yet if it will clear the bit, I'm pretty sure I can get things
 to work without any root rights for kms drivers (not 100% sure yet), but
 ums drivers will fail hard without the suid bit, the ums part of this
 needs some thinking (and needs me to dig up a card actually using it).

 I might end up deciding to just kill ums support and then see what happens,
 but I would rather not, and if I get enough pushback I might revert on
 such a decision :)

Once you add logind integration, there's another way -- write a tiny
setuid wrapper (or use some existing polkit mechanism) to allow users
in a console session to start Xorg as euid==0.  That wrapper could
even be called /usr/bin/Xorg :).  Presumably something like this (or
just real nonroot X support) will be needed for sane multi-seat
support anyway.

IOW, I don't think that Xorg needs to be any more special than, say, udisks.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Server PRD Draft and call for participation

2014-01-10 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The first deliverable that the Fedora Server Working Group was tasked
with was the production of a Product Requirements Document. This
document is intended to provide a high-level view of the goals and
primary deliverables of the Fedora Server distribution. A great deal
of discussion has gone on during the weekly Working Group meetings as
well as on the mailing list.

At this time, the deadline for the delivery of the PRD is rapidly
approaching. Originally it was due to be delivered for ratification on
Monday, January 13th, but at the FESCo meeting on Wednesday, it was
agreed to delay this deadline by a single week. The primary reason for
this delay was so that the Fedora Cloud and Fedora Server groups could
have some last discussions about overlap and respective areas of
responsibility.

This past Tuesday, we had an all-day PRD hackfest in IRC and have come
up with a fairly strong draft[1]. It is not yet complete (notably,
there remains a FIXME under Misc. Concerns and some ambiguity around
the Use Cases), but I believe that it is close enough to its final
form (as envisioned by those people that have contributed to it), that
we should expose this document to the wider world and ask for input
before submitting it to the Fedora Engineering Steering Committee and
Fedora Advisory Board a week from Monday.

Please read through the PRD draft and provide feedback of any sort. If
you see that we have missed or misrepresented any of our statements,
we would very much like to hear this soon.

[1]
https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_Document_Draft
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLQUp4ACgkQeiVVYja6o6O8IwCcCIaNJEr919QgyB3XJC+2Ynqf
6PcAoJ2BpgMwi1NzdG2XBZ0nyEzlh9XZ
=DINq
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

2014-01-10 Thread Chris Murphy


On Jan 10, 2014, at 8:04 AM, Przemek Klosowski przemek.klosow...@nist.gov 
wrote:

 On 01/09/2014 07:23 PM, Reindl Harald wrote:
 Am 09.01.2014 22:16, schrieb Przemek Klosowski:
 I think you can still brick the system with careless yum erases: for 
 instance, deleting grub
 how would this delete the bootloader in the MBR?
 you do not need the grub-package installed to have a bootloader
 MBR is just first stage loader---not enough to bring up the system, 
 necessarily. This is tricky: the second stage is owned by grub2 in 
 /usr/lib/grub, and somehow transferred to /boot/grub2 but I am not sure how

The necessary modules to support display, drawing menus, reading the file 
system in question, is all baked into core.img. The core.img is essentially 
custom, created by anaconda at install time by calling grub2-install. That is 
found in /boot/grub2/i386-pc along with other grub modules, not all of which 
are put into core.img. The core.img is then embedded in the MBR gap. And a 
small bit of jump code, called boot.img, is placed in the MBR boot strap region 
(first 440 bytes of LBA 0) to jump to core.img.

However, on UEFI this isn't necessarily the case, where the package contains a 
prebaked core.img that has a pile of modules already in it, because it's 
intended to be a one size fits all. This core.img takes the form of 
/boot/efi/EFI/fedora/grubx64.efi. It's prebaked this way because it's a signed 
binary, necessary for Secure Boot. If the grub package is yum erased, I'm 
virtually certain grubx64.efi is also removed, and the system would not be 
bootable. You'd get some message from shim.efi, and possibly fallback.efi, both 
of which would still be installed.



Chris Murphy

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Unresponsive maintainer: Mark Chappell

2014-01-10 Thread Jerry James

On Dec. 5, 2013, I sent private email to Mark Chappell (tremble) about a
change I need to the normaliz package in order to update to a more recent
version of polymake.

On Dec. 11, 2013, I opened
https://bugzilla.redhat.com/show_bug.cgi?id=1040627 to ask for the same
change.

On Dec. 19, 2013, I applied for comaintainer privileges in pkgdb.

I waited through the holiday season, in case Mark is on vacation, then
asked for a response on Jan. 3, 2014 (comment 3 on that bug).  It has now
been 1 week since the request for a response, with no reply to the original
email, the pkgdb request, or to the bug.

Mark is not listed on the vacation page; fedora-active-user says:

email trem...@tremble.org.uk
FAS password for jjames:
Last login in FAS:
   tremble 2013-08-19
Last action on koji:
   Mon, 30 Dec 2013 package list entry created: perl-Class-Trigger in
dist-6E-epel-build by ausil [still active]
Last package update on bodhi:
   2013-01-14 14:38:59 on package nrpe-2.13-2.fc18
Last actions performed according to fedmsg:
ERROR:active-user:'raw_messages'

Well, there's a comprehensible error message!  Anyway, does anybody have an
alternate means of contacting Mark?
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unresponsive maintainer: Mark Chappell

2014-01-10 Thread Michael Scherer

Le vendredi 10 janvier 2014 à 13:54 -0700, Jerry James a écrit :
 On Dec. 5, 2013, I sent private email to Mark Chappell (tremble) about
 a change I need to the normaliz package in order to update to a more
 recent version of polymake.
 
 
 On Dec. 11, 2013, I
 opened https://bugzilla.redhat.com/show_bug.cgi?id=1040627 to ask for
 the same change.
 
 
 On Dec. 19, 2013, I applied for comaintainer privileges in pkgdb.
 
 
 I waited through the holiday season, in case Mark is on vacation, then
 asked for a response on Jan. 3, 2014 (comment 3 on that bug).  It has
 now been 1 week since the request for a response, with no reply to the
 original email, the pkgdb request, or to the bug.
 
 
 Mark is not listed on the vacation page; fedora-active-user says:
 
 
 email trem...@tremble.org.uk
 FAS password for jjames: 
 Last login in FAS:
tremble 2013-08-19
 Last action on koji:
Mon, 30 Dec 2013 package list entry created: perl-Class-Trigger in
 dist-6E-epel-build by ausil [still active]
 Last package update on bodhi:
2013-01-14 14:38:59 on package nrpe-2.13-2.fc18
 Last actions performed according to fedmsg:
 ERROR:active-user:'raw_messages'
 
 
 Well, there's a comprehensible error message!  Anyway, does anybody
 have an alternate means of contacting Mark?

Yep, I forward him the email

-- 
Michael Scherer

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction

2014-01-10 Thread Matt Robinson

Hi, I've been going through the process of becoming a package 
maintainer, and thought it would be a good time to introduce myself. My 
name is Matt Robinson and I'm currently working at Rutgers University. I 
build a lot of RPMs there (and use mock and koji as well), and with a 
recent switch to Fedora on our personal workstations, I thought it would 
be good to contribute. I've only got one RPM built right now, but I'll 
no doubt be doing more in the future once I get a hang of the whole 
process.


--
-Matt

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Grub installation. First potential Fedora killer

On Thu, 2014-01-09 at 14:30 +0100, Harald Hoyer wrote:
On 01/02/2014 11:32 PM, Jean François Martinez wrote:
I have a nice booter setup and a nice _main_ Linux installation. Last thing
I would want is a distribution I am _testing_, that is Fedora 20 forces on
me it will be my main installation and forces me to choose between
installing
Grub on the MBR or not at all.

In addition it didn't detect my other Linux installation so at first boot I
was only able to choose between Fedora 20 and Fedora 20. Fortunately
running
grub-install fixed it (ie this time my other installations were detected).
Sort of. First of all because Fedora 20, ie a ditribution I was _testing_
was now the default and second of all because every time I upgrade the
kernel
of my _main_ distribution I am supposed to reboot on F20 and run
grub-install. Great. Nothing I can't fix but your average Ubuntu or Suse
user will just cancel installation as soon he notices F20 is going to force
itself on his MBR. And if the road is a one way one between Fedora and
Ubintu then it is doomed.

That's the reason we came up with
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

and even have a patch for grub2
http://pkgs.fedoraproject.org/cgit/grub2.git/tree/0460-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch

If all bootloaders would follow the spec, nothing has to be configured
manually
and would just use the dropin directories.

So what's the hold-up?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

On Thu, 2014-01-09 at 11:32 +0100, Maros Zatko wrote:
 Dear guys and ladies,
 So it seems like livecd-creator is silently disabling selinux.
 Proof: vim $(which livecd-creator) ; line 150
 Fact, that it's re-enabled afterwards doesn't ease silent disablement of
 security feature.
 
 I'd love to know the reason and if it's possible to do something about it.

Because live images don't work properly if it's either disabled or
enforcing while the image is being generated. Why *that* is I don't
know, but before bcl made the livecd-creator script do this, we just had
a bit in the livecd-creator instructions which said you have to run
setenforce Permissive before starting to build a live image.

If you try building a live image with SELinux either disabled or
enforcing on the build host, you wind up either with a compose that
fails, or an image that can't be booted in enforcing mode.

livecd-creator is a string-and-duct-tape hack, it does quite a lot of
ugly things. bcl's been trying to replace it with livemedia-creator for
a while, but that effort seems to keep running into roadblocks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

2014-01-10 Thread Dennis Gilmore

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Fri, 10 Jan 2014 15:26:38 -0800
Adam Williamson awill...@redhat.com escribió:
 On Thu, 2014-01-09 at 11:32 +0100, Maros Zatko wrote:
  Dear guys and ladies,
  So it seems like livecd-creator is silently disabling selinux.
  Proof: vim $(which livecd-creator) ; line 150
  Fact, that it's re-enabled afterwards doesn't ease silent
  disablement of security feature.
  
  I'd love to know the reason and if it's possible to do something
  about it.
 
 Because live images don't work properly if it's either disabled or
 enforcing while the image is being generated. Why *that* is I don't
 know, but before bcl made the livecd-creator script do this, we just
 had a bit in the livecd-creator instructions which said you have to
 run setenforce Permissive before starting to build a live image.
 
 If you try building a live image with SELinux either disabled or
 enforcing on the build host, you wind up either with a compose that
 fails, or an image that can't be booted in enforcing mode.

Adam this is not true, All Offical Fedora images for years were built
on hosts with selinux disabled. F20 was the first time images were
built with the host in permissive mode, but then they are built in a
mock chroot which has selinux disabled in the chroot

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJS0IM5AAoJEH7ltONmPFDR0g4QAI6klWhJfx3rNdtYX5k+5CZy
jYGsPMyv7SE2N20p0WNj7v0SNA1jo3wcqsugHTsyGME1G72n15zL3PIqaYUuq4rJ
RmHQDxfUugq66n5iNnfw7lsJ/N2sqCd86wR1TTnWHKYypqf5XmKx6tBOY6A+uEEF
MmOTaoDHVbtFM9bKZGKkfqorhFJH16mNleS1mC/sC/+a5xuGKbVBDYM2Pt+7/H1T
YNPTZQhyEUR6k40vTV642yFxkSE/chltBswE9ZXTErey2JUuPLOdrRbppd9tj7vu
Lcbxm7NPpXTJA9fKeBlNwIlXq25wVHu98NlyCfawNE6fNZzqWm03tP7If0PHy7x7
KG3M6EUQy+aLm+vRRa/H7iEH/USGe8wgTDY1IizDShuJQeKfAmVtUyXijvGNcGer
K3z3BURivWvvXjuZ8sIfZTCq6IDkWC7MQh4X6gPj58t4ZVj3/p5nnxBhVwh1Nksn
pumS3/mtUz/c+Rw5JtwWKS2QuUTG4U9ywspjkz7oGqEWDm/Th67t/1zmhof/LT0T
lVmJWM6gyz9lhWBGNZhkGfNqcTvNdTo9TJ8nu4eCTKIGQRS7ODk6u/m1sBFxg8/i
0IrxHfW6Od0wrglxwh695G9liRVctLfmrwzTcnmiee/KQRVNa0TTDq7RdvU6Nsp+
zzNex8J/09Vj73TLmg9B
=JLdx
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
 El Fri, 10 Jan 2014 15:26:38 -0800
 Adam Williamson awill...@redhat.com escribió:
  On Thu, 2014-01-09 at 11:32 +0100, Maros Zatko wrote:
   Dear guys and ladies,
   So it seems like livecd-creator is silently disabling selinux.
   Proof: vim $(which livecd-creator) ; line 150
   Fact, that it's re-enabled afterwards doesn't ease silent
   disablement of security feature.
   
   I'd love to know the reason and if it's possible to do something
   about it.
  
  Because live images don't work properly if it's either disabled or
  enforcing while the image is being generated. Why *that* is I don't
  know, but before bcl made the livecd-creator script do this, we just
  had a bit in the livecd-creator instructions which said you have to
  run setenforce Permissive before starting to build a live image.
  
  If you try building a live image with SELinux either disabled or
  enforcing on the build host, you wind up either with a compose that
  fails, or an image that can't be booted in enforcing mode.
 
 Adam this is not true, All Offical Fedora images for years were built
 on hosts with selinux disabled. F20 was the first time images were
 built with the host in permissive mode, but then they are built in a
 mock chroot which has selinux disabled in the chroot

Hum, I'm sure back before the script tried to take care of it for you,
I'd had multiple failures with both 'enforcing' and 'disabled'. But if
you say so...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaning few java packages

2014-01-10 Thread Ismael Olea

On Fri, Jan 10, 2014 at 10:22 AM, Aleksandar Kurtakov
akurt...@redhat.comwrote:


  I've just taken sqljet (as a dependency of OmegaT) before reading this.
 Which
  build problem svnkit has? It's another BR for OmegaT.


 So svnkit was fine for java usage but not for being used in
 eclipse-subclipse.


thaks for the info :)

-- 

Ismael Olea

http://olea.org/diario/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F20 bug fixes: thanks!

I just did an update run on the F20 Common Bugs page, and I was pleased
to note the number of prominent issues that has been resolved with
updates since F20 shipped. There are now 13 issues under 'resolved
issues' on Common Bugs, which is pretty good compared historically. Just
wanted to pass along thanks to all the devs who've spent time on fixing
up these bugs. We've fixed crashes in several apps, a hang-on-shutdown
bug in CUPS, several issues in 389 directory server, and several more.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] 2014-01-13 @ 16:00 UTC - Fedora QA Meeting

# Fedora Quality Assurance Meeting
# Date: 2014-01-13
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's meeting time again on Monday! There are a couple of topics that
have come up in the past week, although FESCo gave the WGs another week
to report in, so we still don't have any movement on the F21 schedule /
planning front.

This is a reminder of the upcoming QA meeting. Please reply to this mail
with any suggestions for additions to the agenda.

The current proposed agenda is included below. If no topics beyond the
standard Previous meeting follow-up and Open floor topics are
present or proposed, the meeting will be cancelled.

== Proposed Agenda Topics ==
1. Previous meeting follow-up
* adamw to send a mail to test@ about the ten year t-shirt thing
2. EOL process handling
* Do we want to stake a clear claim on this process?
3. 10 year anniversary t-shirt
* Work on the list of people who should get one
4. Open floor

Note that there will be a follow-up to Wednesday's qa-devel meeting
immediately after the QA meeting, I imagine Tim will send out an
announcement for that shortly.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

2014-01-10 Thread Tim Flink

On Fri, 10 Jan 2014 15:35:59 -0800
Adam Williamson awill...@redhat.com wrote:

 On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
  El Fri, 10 Jan 2014 15:26:38 -0800
  Adam Williamson awill...@redhat.com escribió:
   On Thu, 2014-01-09 at 11:32 +0100, Maros Zatko wrote:
Dear guys and ladies,
So it seems like livecd-creator is silently disabling selinux.
Proof: vim $(which livecd-creator) ; line 150
Fact, that it's re-enabled afterwards doesn't ease silent
disablement of security feature.

I'd love to know the reason and if it's possible to do something
about it.
   
   Because live images don't work properly if it's either disabled or
   enforcing while the image is being generated. Why *that* is I
   don't know, but before bcl made the livecd-creator script do
   this, we just had a bit in the livecd-creator instructions which
   said you have to run setenforce Permissive before starting to
   build a live image.
   
   If you try building a live image with SELinux either disabled or
   enforcing on the build host, you wind up either with a compose
   that fails, or an image that can't be booted in enforcing mode.
  
  Adam this is not true, All Offical Fedora images for years were
  built on hosts with selinux disabled. F20 was the first time images
  were built with the host in permissive mode, but then they are
  built in a mock chroot which has selinux disabled in the chroot
 
 Hum, I'm sure back before the script tried to take care of it for you,
 I'd had multiple failures with both 'enforcing' and 'disabled'. But if
 you say so...

I've also run into problems with livecd-creator and was told the same
thing: for best results, run with SELinux in permissive mode - not
disabled and not enforcing.

It was a while ago but I don't think that it was something I hit for
every build. This leads me to suspect that whatever the issue is, it
doesn't happen every time and the releng setup must be able to avoid
whatever it is that people can (and do) hit with SELinux disabled or
enforcing.

Also, I think that until F20 releng was building livecds in mock
chroots on el boxes (dennis, please correct me if I'm wrong) where both
you and I were building livecds on fedora installs.

Tim


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

2014-01-10 Thread Dennis Gilmore

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Fri, 10 Jan 2014 18:31:13 -0700
Tim Flink tfl...@redhat.com escribió:
 On Fri, 10 Jan 2014 15:35:59 -0800
 Adam Williamson awill...@redhat.com wrote:
 
  On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
   El Fri, 10 Jan 2014 15:26:38 -0800
   Adam Williamson awill...@redhat.com escribió:
On Thu, 2014-01-09 at 11:32 +0100, Maros Zatko wrote:
 Dear guys and ladies,
 So it seems like livecd-creator is silently disabling selinux.
 Proof: vim $(which livecd-creator) ; line 150
 Fact, that it's re-enabled afterwards doesn't ease silent
 disablement of security feature.
 
 I'd love to know the reason and if it's possible to do
 something about it.

Because live images don't work properly if it's either disabled
or enforcing while the image is being generated. Why *that* is I
don't know, but before bcl made the livecd-creator script do
this, we just had a bit in the livecd-creator instructions which
said you have to run setenforce Permissive before starting to
build a live image.

If you try building a live image with SELinux either disabled or
enforcing on the build host, you wind up either with a compose
that fails, or an image that can't be booted in enforcing mode.
   
   Adam this is not true, All Offical Fedora images for years were
   built on hosts with selinux disabled. F20 was the first time
   images were built with the host in permissive mode, but then they
   are built in a mock chroot which has selinux disabled in the
   chroot
  
  Hum, I'm sure back before the script tried to take care of it for
  you, I'd had multiple failures with both 'enforcing' and
  'disabled'. But if you say so...
 
 I've also run into problems with livecd-creator and was told the same
 thing: for best results, run with SELinux in permissive mode - not
 disabled and not enforcing.
 
 It was a while ago but I don't think that it was something I hit for
 every build. This leads me to suspect that whatever the issue is, it
 doesn't happen every time and the releng setup must be able to avoid
 whatever it is that people can (and do) hit with SELinux disabled or
 enforcing.
 
 Also, I think that until F20 releng was building livecds in mock
 chroots on el boxes (dennis, please correct me if I'm wrong) where
 both you and I were building livecds on fedora installs.

Tim,

F20 images were built in f20 chroots on f19 boxes. but selinux on the
host was permissive. prior to f20 it was the target os chroot on el

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJS0L7UAAoJEH7ltONmPFDRcRkQAMmepLraNTt5/r8IPRU8tos5
pRs1c7a0h+IR0Dn1zZigVmgJzr42ST38X2eKqOJGHZj1Fh48TaJ8wjjTbsI8jhYz
iEa8mjbGpJz0qoUw2C6Ah8vjO/isetM2qAniFBX58mG1V3fPrMe51M9KWtzI7pSt
304yO7Eqzf7Wb00MGzD+EWXDLRjlZXW6ekSUXOz1cfxzExDaVmMcIGE59hoh1HNa
rPEPmSrU87i1EEcHyT1NHdaQ17KoM2yuqbchjtw4vcHFkdAXcSqeLyvOr8JkE39s
CeNH+11wcPKfK7YxcNyBOX679jk9us2kov7t+fnNCglrh1qiAcSUgy3QT+p/qmVP
/xYOjm6gy1a3FkWbQAvQ723RBDKJJ8GQ19LSUcByOc9rRrkKKnQQfYNK7as/J2b7
vVBlLIJMPpjMl081JQYI8sxEDvDFrQ8MVniHJFsDomvZjtBXNdxu7nofhiIUNx0A
VwfJ1GvReNnIgRLcN1X2i/cDOn736tvilhLFQFdZMcB9bNF7C6xYSeEbERqA8QCI
c1JlTtrSnHzpx8XN6yLxl5nM9e/XMBdcpxh5zxihNPQKngCDZ5KtspdTWo/NbpSk
g27HBgiKm1Oo/zSFmFHQ+sG2eKqnGDT6EzqsT1IZUdrSfQkzR7q5ad/FWtN2CbKf
Lpnl7HtI3f4zIWT+yA81
=mJNO
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1049139] Please apply upstream case sensitivity patch

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

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

   Fixed In Version|perl-Syntax-Highlight-Engin |perl-Syntax-Highlight-Engin
   |e-Kate-0.08-2.fc19  |e-Kate-0.08-4.fc20



--- Comment #7 from Fedora Update System upda...@fedoraproject.org ---
perl-Syntax-Highlight-Engine-Kate-0.08-4.fc20 has been pushed to the Fedora 20
stable repository.  If problems still persist, please make note of it in this
bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=KNUbYOePKGa=cc_unsubscribe
--
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 1051106] perl-PlRPC: weak crypto

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



--- Comment #3 from Petr Pisar ppi...@redhat.com ---
(In reply to Vincent Danen from comment #2)
 The actual proposed patch to upstream is here:
 
 *
 https://rt.cpan.org/Public/Ticket/Attachment/1289399/683202/0001-Security-
 notice-for-Proxy.patch
 
No. This is wrong patch which should belong to different perl package. Current
latter one is the https://rt.cpan.org/Public/Bug/Display.html?id=90474 is
correct one and it'd already applied in perl-PlRPC-0.2020-16.fc21.

I guess applying the patch from Fedora 21 to all Fedoras is sufficient.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=S1ey43HGhMa=cc_unsubscribe
--
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 1051108] CVE-2013-7284 perl-PlRPC: pre-auth remote code execution

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

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

   What|Removed |Added

 CC||rat...@redhat.com
  Flags||needinfo?(rat...@redhat.com
   ||)



--- Comment #3 from Petr Pisar ppi...@redhat.com ---
(In reply to Vincent Danen from comment #2)
 The actual proposed patch to upstream is here:
 
 *
 https://rt.cpan.org/Public/Ticket/Attachment/1293961/685696/0001-Security-
 notice-on-Storable-and-reply-attack.patch
 
 Based on the discussion in bug #1030572, there is no real fix for this as
 it seems that Storable deserialization is exposed prior to password-based
 authentication (see how AcceptUser is called in the server code).
 
 MITRE assigned CVE-2013-7284 to this issue.

Is amending the PlRPC documentation with this patch sufficient to close this
bug, or should we keep this open until a real fix in the code (extension of
Storable module and utilizing it in PlRPC) will be available?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=0Io151sBRMa=cc_unsubscribe
--
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

Broken dependencies: perl-Catalyst-Controller-HTML-FormFu

2014-01-10 Thread buildsys



perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide 
tree:
On x86_64:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
On i386:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
On armhfp:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires 
perl(HTML::FormFu::MultiForm)
Please resolve this as soon as possible.


--
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

Broken dependencies: perl-Language-Expr

2014-01-10 Thread buildsys



perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


--
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

Broken dependencies: mojomojo

2014-01-10 Thread buildsys



mojomojo has broken dependencies in the rawhide tree:
On x86_64:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
On i386:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
On armhfp:
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
Please resolve this as soon as possible.


--
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 1051542] New: Please create EL6 branch for this package

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

Bug ID: 1051542
   Summary: Please create EL6 branch for this package
   Product: Fedora
   Version: rawhide
 Component: perl-Capture-Tiny
  Assignee: psab...@redhat.com
  Reporter: jan.pra...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com



Please request EL6 branch for perl-Capture-Tiny. If you are not willing to do
it I am volunteer to maintain the branch myself.

Thanks Jan Pradac

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=PN06tQgvHNa=cc_unsubscribe
--
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-Net-Amazon-EC2/el6: 15/15] Merge branch 'master' into el6

commit 5bb972ed993a7cf945ca7b6b2df4c21496c88bf5
Merge: 4b0d214 6799e49
Author: Lubomir Rintel lkund...@v3.sk
Date:   Fri Jan 10 15:52:49 2014 +0100

Merge branch 'master' into el6

 .gitignore   |2 +
 perl-Net-Amazon-EC2.spec |   87 +-
 sources  |2 +-
 3 files changed, 73 insertions(+), 18 deletions(-)
---
--
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 Net-Amazon-EC2-0.24.tar.gz uploaded to lookaside cache by lkundrak

A file has been added to the lookaside cache for perl-Net-Amazon-EC2:

558c1ae48e2c82dd49a8607cbc811a7e  Net-Amazon-EC2-0.24.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-Net-Amazon-EC2/el6] (15 commits) ...Merge branch 'master' into el6

Summary of changes:

  eb8f1f3... - 661697 rebuild for fixing problems with vendorach/lib (*)
  6791333... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*)
  d4f9cc1... Perl mass rebuild (*)
  2ebd09c... Perl mass rebuild (*)
  faae6ff... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*)
  29d708f... Perl 5.16 rebuild (*)
  6ceb0e0... - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass (*)
  1caf57d... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*)
  24ca145... Perl 5.18 rebuild (*)
  ed875e1... Specify all dependencies (*)
  22dc39a... Attempt at saner SPEC file formatting (*)
  fb2b8a0... Bump version (*)
  0fd0958... Add missing BRs (*)
  6799e49... Update to a new version (*)
  5bb972e... Merge branch 'master' into el6

(*) 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-Net-Amazon-EC2] Update to a new version

commit 6799e49a9db240d2820b1e403cc68de5527d4a49
Author: Lubomir Rintel lkund...@v3.sk
Date:   Fri Jan 10 15:51:58 2014 +0100

Update to a new version

 .gitignore   |1 +
 perl-Net-Amazon-EC2.spec |7 +--
 sources  |2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c43b789..6ba0610 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Net-Amazon-EC2-0.14.tar.gz
 /Net-Amazon-EC2-0.23.tar.gz
+/Net-Amazon-EC2-0.24.tar.gz
diff --git a/perl-Net-Amazon-EC2.spec b/perl-Net-Amazon-EC2.spec
index 0068ed2..b838518 100644
--- a/perl-Net-Amazon-EC2.spec
+++ b/perl-Net-Amazon-EC2.spec
@@ -1,11 +1,11 @@
 Summary: Perl interface to the Amazon Elastic Compute Cloud (EC2)
 Name: perl-Net-Amazon-EC2
-Version: 0.23
+Version: 0.24
 Release: 1%{?dist}
 License: GPL+ or Artistic
 Group: Development/Libraries
 URL: http://search.cpan.org/dist/Net-Amazon-EC2/
-Source0: 
http://search.cpan.org/CPAN/authors/id/M/MA/MALLEN/Net-Amazon-EC2-0.23.tar.gz
+Source0: 
http://search.cpan.org/CPAN/authors/id/M/MA/MALLEN/Net-Amazon-EC2-%{version}.tar.gz
 
 
 BuildArch: noarch
@@ -171,6 +171,9 @@ make test
 
 
 %changelog
+* Fri Jan 10 2014 Lubomir Rintel lkund...@v3.sk - 0.24-1
+- Update to a later upstream release
+
 * Mon Oct 28 2013 Lubomir Rintel lkund...@v3.sk - 0.23-1
 - Update to a later upstream release
 
diff --git a/sources b/sources
index 374fbe8..3e71674 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-678cf13562b3364b7fbb06bd120f5dc9  Net-Amazon-EC2-0.23.tar.gz
+558c1ae48e2c82dd49a8607cbc811a7e  Net-Amazon-EC2-0.24.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

[Bug 1051542] Please create EL6 branch for this package

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

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Petr Šabata psab...@redhat.com ---
Sure, no problem.  What's your FAS username, please?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=zmqgKWUWRAa=cc_unsubscribe
--
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

[389-devel] Please review lib389 ticket 47600 (follow up) :Replica/Agreement/Changelog not conform to the design

2014-01-10 Thread thierry bordaz


Hi,

Rich already reviewed the Replica/RA/Changelog code for lib389.
This follow up review is to:

 * add unit tests for Replica/RA
 * Fix some bugs found while running the unit tests

https://fedorahosted.org/389/attachment/ticket/47600/0001-Ticket-47600-follow-up-Replica-Agreement-Changelog-n.patch 

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

[389-devel] Please review (one line fix): [389 Project] #47660: config_set_allowed_to_delete_attrs: Valgrind reports Invalid read

2014-01-10 Thread Noriko Hosoi


https://fedorahosted.org/389/ticket/47660

https://fedorahosted.org/389/attachment/ticket/47660/0001-Ticket-47660-config_set_allowed_to_delete_attrs-Valg.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: 2013-01-09 @ 16:00 UTC - Fedora QA Devel Meeting Minutes