RE: Orphaning and seeking comaintainers of some packages

[مصعب الزعبي]

Alot taked ... 

Mosaab

> Date: Tue, 17 Feb 2015 17:19:38 +0800
> Subject: Orphaning and seeking comaintainers of some packages
> From: cicku...@gmail.com
> To: devel@lists.fedoraproject.org
> 
> Hi,
> 
> There are some packages I don't use anymore, feel free to take them:
> 
> libntlm
> python-durus
> barry
> spambayes
> rblcheck
> tokyocabinet
> jaxodraw
> flterm
> libquvi
> libquvi-scripts
> quvi
> python-django-socialregistration
> dayplanner
> gengetopt
> code2html
> elementary-icon-theme
> drehatlas-widelands-fonts
> pycryptopp
> drehatlas-xaporho-fonts
> qdevelop
> kawa
> perl-BDB
> txt2rss
> scanssh
> mimetex
> perl-Date-HolidayParser
> perl-Email-Find
> python-pymtp(epel7)
> 
> These below are packages I seldom use, feel free to comaintain them:
> 
> NetPIPE
> PyMca
> roxterm
> autoconf-archive
> freetalk
> unhide
> firehol
> npth
> exaile
> flickcurl
> jwm
> elektra
> dmenu
> profile-sync-daemon
> python-eyed3
> oyranos
> 
> Thanks.
> -- 
> 
> Yours sincerely,
> Christopher Meng
> 
> http://cicku.me
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
  -- 
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: So everything in Rawhide must be compiled with -fPIC?

[Ralf Corsepius]

On 02/20/2015 07:55 PM, Till Maas wrote:


than the technical change to implement it, there's no mention that it
will have an impact on performance, with numbers to back it up, across
the three primary architectures.


So how much performance impact is acceptable?


None - Seriously, people will be complaining about any performance 
impact and press will make headlines from it when it is measurable or 
sensible and can not be compensated otherwise.


Also consider, security always will have to be a compromise and security 
demands vary on the use-case.


Ralf




--
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: nonresponsive maintainer - Axel Thimm

[مصعب الزعبي]

Also I can help in some packages. Access Asked

fakechroot,fakeroot,freenx-server,greylistd,synaptic,fedora-package-config-apt,apt
Mosaab


> From: fdc-li...@fcami.net
> Date: Wed, 18 Feb 2015 10:24:04 +0100
> Subject: Re: nonresponsive maintainer - Axel Thimm
> To: devel@lists.fedoraproject.org
> CC: axel.th...@atrpms.net
> 
> On Wed, Feb 18, 2015 at 5:20 AM, Orion Poplawski  wrote:
> > I'm continuing the nonresponsive maintainer process for Axel Thimm
> > https://bugzilla.redhat.com/show_bug.cgi?id=1186467
> 
> +1
> 
> > I've been effectively maintaining a number of Axel's packages for years now.
> > Time to get them properly owned.
> 
> Does anyone know how to contact Axel?
> 
> I can help maintain vtk/vtkdata/fail2ban and possibly others if needed.
> 
> François
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
  -- 
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: Self introduction: Taylor Braun-Jones

[Orion Poplawski]

On 02/20/2015 08:17 PM, Taylor Braun-Jones wrote:

Hi everyone,

I am going through the process of becoming a Fedora Package Collection
maintainer and wanted to say hi and introduce myself.

I've been a Linux user since 2000, extensively since about 2002. I
currently work in software R&D for a medical device company and am a big
proponent of using open source software to accomplish what we do. Qt,
ITK, VTK, MITK, cmake are some of the packages work with the most. I've
maintained a private YUM repos for RHEL6 and RHEL7 packages that we use
but a lot of these packages make more sense in the public Fedora repos
so I'd like to start contributing and maintaining them there.

I look forward to working/playing with you all.


Welcome!  I'm the current maintainer for VTK and cmake and would welcome 
any and all help maintaining any of my packages.  I'm current in the 
process of working on the VTK 6.2.0 update and staging builds here:


https://copr.fedoraproject.org/coprs/orion/VTK/

- Orion

--
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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Changes in the f22 workstation

[Ray Strode]

Hi,

On Fri, Feb 20, 2015 at 7:00 PM, Pete Travis  wrote:
> I'm nervous about GDM on Wayland; Wayland has never worked well on my
> systems.  Can you talk about fallback strategies a bit?  Can GDM detect when
> Wayland isn't working well enough to be usable, and cleanly fall back?
It tries to.  We do start X in a different way now when falling back
(as part of the user session, instead of as root outside of the user
session), so there may be bugs that need to get ironed out.  It worked
okay in my limited testing though (putting nomodeset on the kernel
commandline on my intel based laptop)

> That's probably a big ask, though; presumably this can be set one way or
> another by the user?
Right you can put WaylandEnable=false in the [daemon] section of
/etc/gdm/custom.conf to skip wayland altogether.

--Ray
-- 
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: [Proposal] Ring-based Packaging Policies

[Lars Seipel]

On Thu, Feb 12, 2015 at 01:32:04PM -0500, Stephen Gallagher wrote:
> === Core Packages ===
> Any package that is provided on a release-blocking medium (which at
> present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora
> Workstation, the KDE Spin and several ARM images) must comply exactly
> with the packaging guidelines as they are written today.
[...]
> === Ring Packages ===
> Any new package that is *not* going to be part of the install media set
> is required to pass a lighter review and is permitted to carry bundled
> libraries, with caveats to be listed below.

What would be the place for higher-quality packages that aren't on any
install media (and are also not required to create those)? I think a
broad collection of reviewed and guideline-conforming packages is a
useful thing to have. Just mixing them together in a single repo with
the lower-quality stuff would diminish their value in significant ways.
-- 
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: Taylor Braun-Jones

[Taylor Braun-Jones]

Hi everyone,

I am going through the process of becoming a Fedora Package Collection
maintainer and wanted to say hi and introduce myself.

I've been a Linux user since 2000, extensively since about 2002. I
currently work in software R&D for a medical device company and am a big
proponent of using open source software to accomplish what we do. Qt, ITK,
VTK, MITK, cmake are some of the packages work with the most. I've
maintained a private YUM repos for RHEL6 and RHEL7 packages that we use but
a lot of these packages make more sense in the public Fedora repos so I'd
like to start contributing and maintaining them there.

I look forward to working/playing with you all.

Cheers,
Taylor

http://taylor.braun-jones.org/meet-me/
-- 
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: Changes in the f22 workstation

[Pádraig Brady]

On 20/02/15 21:09, Matthias Clasen wrote:
> I wanted to give a heads-up to the wider audience about a number of 
> workstation changes that are landing in the f22 branch (and rawhide) 
> this week, in time for the alpha freeze next week:
> 
> - The message tray at the bottom is gone, notifications are now shown 
> at the top, and can be reviewed in the calendar popup (
> https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications)

This does seem like an improvement, following the general improvement
in notifications with each release.

However I'm surprised that there is still no mention of a permanent indicator
in the top bar, that notifications are present. This can be achieved with an
extension, but with large changes to notifications happening now, it would
seem like an ideal time to also introduce that change.
If you drill down through the comments at the above URL, you get to this:
https://bugzilla.gnome.org/show_bug.cgi?id=641723

thanks,
Pádraig.
-- 
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] 2015-02-23 @ 1700 UTC ** Blocker Review Meeting

[Mike Ruckman]

# F22 Blocker Review meeting
# Date: 2015-02-23
# Time: 1700 UTC
# Location: #fedora-blocker-review on irc.freenode.net

It's that time of the week again! After another week of testing we
have 4 proposed Alpha blockers and 2 proposed for final.

If you want to take a look at the proposed or accepted blockers, the
full list can be found here: https://qa.fedoraproject.org/blockerbugs/

Make sure to click through the milestones to see how many we have before
the meeting!

We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F22 can be found on the
wiki [0].

For more information about the Blocker and Freeze exception process,
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

See you Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria

-- 
// Mike 
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
___
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

[Test-Announce] Proposal to CANCEL: 2015-02-23 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm tentatively suggesting we cancel the QA meeting on 
Monday, but that's assuming we do a blocker review meeting. I think 
it'd be good to check in on the status of 22 Alpha in general, but we 
can do that within the blocker review meeting assuming we have one.

I don't think we have any other big topics to discuss, but I'm making 
sure to get this email out several days ahead so we can change our 
minds and have a meeting if necessary. So did I miss anything? Anyone 
have anything we should talk about? Just reply to this mail and we can 
set up the meeting. Thanks!
-- 
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: [Test-Announce] Fedora 22 Branched 20150218 nightly compose nominated for testing

[Alexander Ploumistos]

On Sat, Feb 21, 2015 at 3:13 AM, Adam Williamson
 wrote:
> Because https://bugzilla.redhat.com/show_bug.cgi?id=1194494 .

Oh, thanks. This is the second bug I've managed to miss in BZ this
week, I think I need to catch up on my sleep.
-- 
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: [Test-Announce] Fedora 22 Branched 20150218 nightly compose nominated for testing

[Adam Williamson]

On Sat, 2015-02-21 at 02:35 +0200, Alexander Ploumistos wrote:
> I downloaded the generic x86_64 boot iso from
> https://kojipkgs.fedoraproject.org/mash/branched-20150218/22/x86_64/os/images/boot.iso
> which was linked to from
> https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150218_Installation
> 
> and went on to install it in a vm on a fedora 21 host. After 3-4 
> unsuccessful installation attempts and a lot of tweaking in virt-
> manager, I managed to get it going. After it was done and rebooted, I
> got to a gdm screen without any users listed, I was unable to switch 
> to another vt and when the lock screen appeared, I couldn't make it 
> go away whether I typed on the keyboard or rolled the scroll wheel 
> on my mouse. I could ssh to the vm, which I did and found that 
> probably wayland is to blame for not being able to log in. However, 
> what struck me as odd was this:
> # uname -a
> Linux localhost.localdomain 3.20.0-0.rc0.git9.1.fc23.x86_64 #1 SMP 
> Wed Feb 18 22:01:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> 
> Why would I end up with an f23 kernel?

Because https://bugzilla.redhat.com/show_bug.cgi?id=1194494 .
-- 
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: [Test-Announce] Fedora 22 Branched 20150218 nightly compose nominated for testing

[Alexander Ploumistos]

I downloaded the generic x86_64 boot iso from
https://kojipkgs.fedoraproject.org/mash/branched-20150218/22/x86_64/os/images/boot.iso
which was linked to from
https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150218_Installation
and went on to install it in a vm on a fedora 21 host. After 3-4
unsuccessful installation attempts and a lot of tweaking in
virt-manager, I managed to get it going. After it was done and
rebooted, I got to a gdm screen without any users listed, I was unable
to switch to another vt and when the lock screen appeared, I couldn't
make it go away whether I typed on the keyboard or rolled the scroll
wheel on my mouse. I could ssh to the vm, which I did and found that
probably wayland is to blame for not being able to log in. However,
what struck me as odd was this:
# uname -a
Linux localhost.localdomain 3.20.0-0.rc0.git9.1.fc23.x86_64 #1 SMP Wed
Feb 18 22:01:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Why would I end up with an f23 kernel?
-- 
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: Changes in the f22 workstation

[Pete Travis]

On Feb 20, 2015 2:09 PM, "Matthias Clasen"  wrote:
>
> I wanted to give a heads-up to the wider audience about a number of
> workstation changes that are landing in the f22 branch (and rawhide)
> this week, in time for the alpha freeze next week:
>
> - The message tray at the bottom is gone, notifications are now shown
> at the top, and can be reviewed in the calendar popup (
> https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications)
>
> - The gnome-shell theme has been refreshed
>
> - The login screen is using Wayland (
> https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland)
>
> - Codec installation has been integrated in gnome-software (currently
> this is hooked up in totem)
>
> - Nautilus has received a number of improvements (
> https://fedoraproject.org/wiki/Changes/Nautilus_Improvements)
>
> Please let us know if you see any fallout from these changes.
>
>
> Thanks! Matthias
>
> --

I'm nervous about GDM on Wayland; Wayland has never worked well on my
systems.  Can you talk about fallback strategies a bit?  Can GDM detect
when Wayland isn't working well enough to be usable, and cleanly fall
back?   That's probably a big ask, though; presumably this can be set one
way or another by the user?

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

Strange issues with octave+swig+UTF8 in rawhide

[Orion Poplawski]

The check in the plplot package for the octave bindings are failing in
rawhide.  I point my finger at gcc :), but I have no idea what is going on so
just putting this out there.

plplot uses a swig generated interface for the octave wrapper.  By the time
the swig wrapper is calling the plplot C function I'm seeing UTF8 string
pointers pointing to garbage (or perhaps just off by a byte, who knows).

I've rebuilt swig, then octave, but no avail.  So, if anyone sees anything
strange in this regard and fixes it, let me know.

- Orion

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Changes in the f22 workstation

[Matthias Clasen]

I wanted to give a heads-up to the wider audience about a number of 
workstation changes that are landing in the f22 branch (and rawhide) 
this week, in time for the alpha freeze next week:

- The message tray at the bottom is gone, notifications are now shown 
at the top, and can be reviewed in the calendar popup (
https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications)

- The gnome-shell theme has been refreshed

- The login screen is using Wayland (
https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland)

- Codec installation has been integrated in gnome-software (currently 
this is hooked up in totem)

- Nautilus has received a number of improvements (
https://fedoraproject.org/wiki/Changes/Nautilus_Improvements)

Please let us know if you see any fallout from these changes.


Thanks! Matthias

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

New Upstream Release Monitoring Systems

[Ralph Bean]

I'm proud to announce that the Infrastructure team has finished deploying the
first iteration of our replacement for the older, wiki-based Upstream Release
Monitoring tools this week.  You can read about the details of the trio of
systems[1] now used to coordinate upstream release monitoring on the same old
wiki page.

Names of systems:

- pkgdb is the familiar Fedora Package DB https://admin.fedoraproject.org/pkgdb
  It provides some flags used by the other systems.
- anitya is the web app running at https://release-monitoring.org
  It is responsible for scraping upstream release sites looking for new
  releases.
- the-new-hotness is a backend daemon that responds to fedmsg messages about
  upstream releases.

The bugs filed in bugzilla look much the same as they did before, but for
packagers there is one thing to note:  the process of getting your package(s)
registered for upstream release monitoring has changed.  Please see the
instructions[2] on the wiki page.

Old packages that were listed on the wiki page have been imported to
release-monitoring.org and have had their monitoring flag set in pkgdb.  New
packages added to Fedora now have their monitoring flag set to True by default
and a script attempts to map them to an upstream project in
release-monitoring.org automatically.

If you want new upstream releases monitored for your package(s), you must:

- Add the upstream project to anitya[3].
- Map the upstream project to a Fedora package in anitya[3].
- Enable the monitoring flag for that Fedora package in pkgdb2[4].

Note also that it is now possible to get notifications about upstream releases
without bugs being filed in bugzilla.  To do this, add your projects to
release-monitoring.org and configure your Fedora Notifications (FMN)[5] account
while leaving the monitor flag set to False in pkgdb[4].

If you encounter bugs or have requests for enhancement, as always please do
file them[6][7][8].. and if you're having problems with a particular package
there is a place to list those[8] also on the wiki page.

[1] https://fedoraproject.org/wiki/Upstream_release_monitoring#Details
[2] 
https://fedoraproject.org/wiki/Upstream_release_monitoring#TLDR.3B_Get_Packages_Monitored
[3] https://release-monitoring.org
[4] https://admin.fedoraproject.org/pkgdb
[5] https://apps.fedoraproject.org/notifications
[6] https://github.com/fedora-infra/anitya
[7] https://github.com/fedora-infra/pkgdb2
[8] https://github.com/fedora-infra/the-new-hotness
[9] https://fedoraproject.org/wiki/Upstream_release_monitoring#Requesting_Help


signature.asc
Description: PGP signature
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-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: [Test-Announce] Fedora 22 Branched 20150218 nightly compose nominated for testing

[Orion Poplawski]

On 02/19/2015 07:38 AM, Michael Cronenworth wrote:

On 02/18/2015 01:21 PM, adamw...@fedoraproject.org wrote:


https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150218_Installation



Text-mode installation does not work - noted in the matrix.

The installation source spoke does not work. No matter what I choose,
even specifying a repo URL, anaconda says it cannot find a valid
installation source.

I'm not a normal tester of Fedora n+1 so I cannot say when this broke.


Could be the kernel issue:


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

Newer kernel worked for me.

--
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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: So everything in Rawhide must be compiled with -fPIC?

[Reindl Harald]

Am 20.02.2015 um 20:28 schrieb Peter Robinson:

On Fri, Feb 20, 2015 at 6:55 PM, Till Maas  wrote:

So how much performance impact is acceptable?


Well you've not documented any of the impact so how can we discuss
that? We have no idea if the impact is going to be 0.1% 1% or 10% so
how can the discussion happen without numbers? Numbers speak?


the other side around

if someone *notices* a *feelable* performance impact that's what have to 
be discussed - until that don't happen *any* change improve security 
(and if it is only the 1 out of 10 exploits not working) is woth a 
not noticeable performance impact




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: So everything in Rawhide must be compiled with -fPIC?

[Peter Robinson]

On Fri, Feb 20, 2015 at 6:55 PM, Till Maas  wrote:
> On Fri, Feb 20, 2015 at 05:21:59PM +, Peter Robinson wrote:
>> >> I've never argumented against the goal that web browser or all network 
>> >> aware
>> >> services should be PIEs, after all, why would we (Ulrich Drepper and 
>> >> myself)
>> >> add the PIE support into the toolchain otherwise?
>> >> I'm just not convinced most of the unpriviledged programs should be PIEs.
>> >
>> > Thanks to e.g. e-mail about any program can be made to run untrusted
>> > data, e.g. PDF readers, office suites, image viewers, if you open an
>> > attachment of the respective type. Therefore it makes a sane default
>> > IMHO. It is also something to attract users that care about security
>> > very much to Fedora.
>>
>> So your saying here that this is miraculously going to stop people
>> from running random binaries that are being emailed to them? Or is
>> just going stop people from running random non PIC/PIE binaries? I
>> don't buy that this is a miracle fix to that problem. How then does it
>> affect other third party binaries not compiled with PIC/PIE that
>> people might wish to run?
>
> No, am am saying I can open PDF documents knowing that I did what I
> could to be secure when open it etc. Also I know that if recommend
> people Fedora and give basic guidelines, that they are as good protected
> as possible.

How is a PDF with a binary payload any different? Sounds like we need
to be running pdf readers in a selinux container?

>> More over in the Change request [1] I don't see any evidence with
>> examples, links to research papers etc on how this makes things more
>> secure all I see is basically "because SECURITY man!!!" . The
>> feature says "our users less likely become victims of attacks" but
>> which sort of attacks, how does it improve security. I understand why
>
> There were a lot of details given in several tickets and discussions,
> since this is nothing new. As with other Changes there was a public
> discussion on this list and the FESCo discussions were public as well.

It would be useful to provide those details in the Change for easy
reference to those reading it :-)

>> we'd want it on remotely accessible daemons and long running back
>> ground processes, even things like mail clients that connect to the
>> internet. There is absolutely no technical detail in the change, other
>
> There are already packaging guidelines with clear MUST criteria that are
> not followed and SHOULD criteria that are usually ignored. If you look
> at exploits happening in the Windows world, it is not just things that
> do network communication themselves, but also tools that process data
> that came from the Internet. And if you think about it, there is hardly
> anything that might not process untrusted data.

And if you think about it Fedora is already widely different to the
world of Windows. I'm well aware of the packaging criteria and the
would of network communications, security and even windows.

>> than the technical change to implement it, there's no mention that it
>> will have an impact on performance, with numbers to back it up, across
>> the three primary architectures.
>
> So how much performance impact is acceptable?

Well you've not documented any of the impact so how can we discuss
that? We have no idea if the impact is going to be 0.1% 1% or 10% so
how can the discussion happen without numbers? Numbers speak?

In an uber secure environment if it was going to be 10% they'd likely
just throw more money at it, but 10% in Fedora even people on the
highest spec of hardware would probably complain. I know it's not
going to be that but you as the feature owner haven't presented
anything as yet.

>> Given that the person who actually wrote the code to implement the
>> actual functionality has grave concerns about it's usefulness and
>> impact to end users and packagers. I'm also concerned that he will be
>> the person that will need to fix problems are likely going to be seen
>> by packagers and not you as the person proposing the change? Do you
>> have the time and ability to deal with these problems? Having dealt
>> with these issues across a number of architectures and having had to
>> ask Jakob nicely for his time and assistance when there's been issues
>> from his response I'm not sure you've got his buy in to deal with
>> this.
>
> So because I proposed the change, I will have to do everything alone?

No, you won't be doing the mass rebuild for example. But you do need
to do enough to back up your proposal. Just like the people proposing
gcc5 did a mass rebuild test with details.

> There were already several people that supported this and if there are
> problems, I will deal with them. However, the proposal was accepted and
> I do not see that this is a requirement that other Changes or Features
> needed to fulfill. And I as a package maintainer also do work that

Other Changes or Features don't impact every single package. Those
that do, see the 

Re: So everything in Rawhide must be compiled with -fPIC?

[Peter Robinson]

On Fri, Feb 20, 2015 at 6:40 PM, Josh Boyer  wrote:
> On Fri, Feb 20, 2015 at 12:21 PM, Peter Robinson  wrote:
>> Also I've seen no performance analysis across all three architectures
>> to see the impact. I'll happily send you an XO-1 to test on (our
>> lowest supported device on i686 and also one of our most widely
>> deployed Fedora device) and ARM hardware if you've not got access to
>> test.
>
> Side tangent.  Maybe we should stop holding ourselves accountable to the XO-1.

I don't necessarily disagree, I don't believe we should be holding the
distro back for the device but at the same time it's a good example of
a widely deployed device running Fedora.

> OLPC doesn't produce these any longer.  I don't even think you can get
> a XO-1.5 and the information on XO-1.75 makes it appear to be limited.
> Efforts appear to have shifted to ARM based laptop/tablet devices
> (XO-4).  There's the whole Android angle now to, which frankly makes a
> lot of sense for them.  Even the latest OLPC OS development release is
> based on Fedora 20 and is targeted at the XO-4 hardware.

You are correct as can be seen from the release notes [1] but then it
was in development from mid last year when F-20 was "stable" and there
are Community releases [2] that support all of the devices. There are
also people using and testing F-21 and even F-22.

> I understand the underlying OS on the XO-1 is Fedora based.  However,
> the latest recommended update is Fedora 17 based and the latest
> available update (which is already noted as slow) is Fedora 18 based.
> It was a major downstream Fedora remix and somewhat a successful one
> at that.  But the likelihood of OLPC XO-1 actually being impacted by
> changes made in Fedora 23 seems to be small.  They've moved on.  So
> should we.

Actually it wasn't very divergent from mainline Fedora at all.
Primarily kernel and sugar specifics actually, I was on the OS dev
team :-)

It was used as an example of supported hardware that should be
considered in the impact of the changes we make. I can use a eeePC
netbook, a beagle bone black or any number of other low powered
devices if it would make you more comfortable. You as one of the
Fedora kernel people know the old hardwarw that people use.

The point that I was making was not that we should stop change for the
tailing end of the hardware that we currently support but to be aware
of the impact of the changes that are made and that not every use can
afford to have a nice shiny core i7 Asus/Lenovo/Mac device sitting on
their desk. You could probably use some crappy bottom of the line
cloud instance with 256Mb of RAM, shared CPU and dreadful disk IO as a
decent bottom end baseline actually, and yes I'm aware you wouldn't be
running the desktop apps we're discussing here on said platform.

> If you want to bring up arguments about ARM impacts to the XO-4, fine.
> At least that seems somewhat relevant.

I wouldn't as we don't currently support them as their kernel isn't
currently upstream, but substitute a beaglebone black, I'll happily
send both  you can substitute any number of low end devices and my
point still remains the same!

Peter

[1] wiki.laptop.org/go/Release_notes/14.1.0
[2] http://lists.laptop.org/pipermail/devel/2015-February/038700.html
-- 
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: So everything in Rawhide must be compiled with -fPIC?

[Till Maas]

On Fri, Feb 20, 2015 at 01:40:30PM -0500, Josh Boyer wrote:

> (XO-4).  There's the whole Android angle now to, which frankly makes a
> lot of sense for them.  Even the latest OLPC OS development release is
> based on Fedora 20 and is targeted at the XO-4 hardware.

Android already uses ASLR, see eg the first Google hit:
https://www.duosecurity.com/blog/exploit-mitigations-in-android-jelly-bean-4-1

Regards
Till
-- 
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: So everything in Rawhide must be compiled with -fPIC?

[Till Maas]

On Fri, Feb 20, 2015 at 05:21:59PM +, Peter Robinson wrote:
> >> I've never argumented against the goal that web browser or all network 
> >> aware
> >> services should be PIEs, after all, why would we (Ulrich Drepper and 
> >> myself)
> >> add the PIE support into the toolchain otherwise?
> >> I'm just not convinced most of the unpriviledged programs should be PIEs.
> >
> > Thanks to e.g. e-mail about any program can be made to run untrusted
> > data, e.g. PDF readers, office suites, image viewers, if you open an
> > attachment of the respective type. Therefore it makes a sane default
> > IMHO. It is also something to attract users that care about security
> > very much to Fedora.
> 
> So your saying here that this is miraculously going to stop people
> from running random binaries that are being emailed to them? Or is
> just going stop people from running random non PIC/PIE binaries? I
> don't buy that this is a miracle fix to that problem. How then does it
> affect other third party binaries not compiled with PIC/PIE that
> people might wish to run?

No, am am saying I can open PDF documents knowing that I did what I
could to be secure when open it etc. Also I know that if recommend
people Fedora and give basic guidelines, that they are as good protected
as possible.

> More over in the Change request [1] I don't see any evidence with
> examples, links to research papers etc on how this makes things more
> secure all I see is basically "because SECURITY man!!!" . The
> feature says "our users less likely become victims of attacks" but
> which sort of attacks, how does it improve security. I understand why

There were a lot of details given in several tickets and discussions,
since this is nothing new. As with other Changes there was a public
discussion on this list and the FESCo discussions were public as well.

> we'd want it on remotely accessible daemons and long running back
> ground processes, even things like mail clients that connect to the
> internet. There is absolutely no technical detail in the change, other

There are already packaging guidelines with clear MUST criteria that are
not followed and SHOULD criteria that are usually ignored. If you look
at exploits happening in the Windows world, it is not just things that
do network communication themselves, but also tools that process data
that came from the Internet. And if you think about it, there is hardly
anything that might not process untrusted data.

> than the technical change to implement it, there's no mention that it
> will have an impact on performance, with numbers to back it up, across
> the three primary architectures.

So how much performance impact is acceptable?

> Given that the person who actually wrote the code to implement the
> actual functionality has grave concerns about it's usefulness and
> impact to end users and packagers. I'm also concerned that he will be
> the person that will need to fix problems are likely going to be seen
> by packagers and not you as the person proposing the change? Do you
> have the time and ability to deal with these problems? Having dealt
> with these issues across a number of architectures and having had to
> ask Jakob nicely for his time and assistance when there's been issues
> from his response I'm not sure you've got his buy in to deal with
> this.

So because I proposed the change, I will have to do everything alone?
There were already several people that supported this and if there are
problems, I will deal with them. However, the proposal was accepted and
I do not see that this is a requirement that other Changes or Features
needed to fulfill. And I as a package maintainer also do work that
results from other people proposing changes. So what is different here?
I am actually uncomfortable to discuss what Jakub is willing to do.
Obviously I will ask him for help if needed and from the discussions
about this Change I made only good experiences, but obviously with all
volunteer effort in Fedora, I know I cannot demand anything. But I do
not see much value in discussions ifs and whens, when there are no
issues.

> Also I've seen no performance analysis across all three architectures
> to see the impact. I'll happily send you an XO-1 to test on (our
> lowest supported device on i686 and also one of our most widely
> deployed Fedora device) and ARM hardware if you've not got access to
> test.

What do you want to have tested and how much performance impact is
acceptable? Since we are early in the Fedora 23 development process,
there is still a lot of time to do tests.

> Fedora users tend to keep hardware around for longer time than a lot
> of enterprises, it's also a distro used a lot in the developing world
> on low end cheap hardware because the rest of the world isn't
> necessarily so privileged as to be able afford the latest and greatest
> and I think we need to consider that along side "possible" security
> improvements!

I know, I bought myself hardware that I cannot us

Re: So everything in Rawhide must be compiled with -fPIC?

[Josh Boyer]

On Fri, Feb 20, 2015 at 12:21 PM, Peter Robinson  wrote:
> Also I've seen no performance analysis across all three architectures
> to see the impact. I'll happily send you an XO-1 to test on (our
> lowest supported device on i686 and also one of our most widely
> deployed Fedora device) and ARM hardware if you've not got access to
> test.

Side tangent.  Maybe we should stop holding ourselves accountable to the XO-1.

OLPC doesn't produce these any longer.  I don't even think you can get
a XO-1.5 and the information on XO-1.75 makes it appear to be limited.
Efforts appear to have shifted to ARM based laptop/tablet devices
(XO-4).  There's the whole Android angle now to, which frankly makes a
lot of sense for them.  Even the latest OLPC OS development release is
based on Fedora 20 and is targeted at the XO-4 hardware.

I understand the underlying OS on the XO-1 is Fedora based.  However,
the latest recommended update is Fedora 17 based and the latest
available update (which is already noted as slow) is Fedora 18 based.
It was a major downstream Fedora remix and somewhat a successful one
at that.  But the likelihood of OLPC XO-1 actually being impacted by
changes made in Fedora 23 seems to be small.  They've moved on.  So
should we.

If you want to bring up arguments about ARM impacts to the XO-4, fine.
At least that seems somewhat relevant.

josh
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Colin Walters]

On Fri, Feb 20, 2015, at 12:48 PM, Dennis Gilmore wrote:
>
> communication would have avoided some of the discussion in
> https://bugzilla.redhat.com/show_bug.cgi?id=1149568 

Which btw, caused

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

Could you review?
I'm fixing this in OSTree too, https://github.com/GNOME/ostree/pull/59
but it'd be nice to fix it two ways, and relative symlinks are generally
nicer than absolute.
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Dennis Gilmore]

On Fri, 20 Feb 2015 18:12:29 +0100
Lennart Poettering  wrote:

> On Fri, 20.02.15 11:07, Dennis Gilmore (den...@ausil.us) wrote:
> 
> > On Fri, 20 Feb 2015 11:04:13 -0600
> > Dennis Gilmore  wrote:
> > 
> > > On Fri, 20 Feb 2015 17:36:17 +0100
> > > Lennart Poettering  wrote:
> > > 
> > > > On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com)
> > > > wrote:
> > > > 
> > > > > >> > Sorry for the inconvenience and feel free to add bugs to
> > > > > >> > the tracker, which are caused by systemd changes and
> > > > > >> > have to be fixed in other components.
> > > > > >>
> > > > > >> Are you going to start notifying deve@ of upcoming changes
> > > > > >> that may impact other areas of the distro too rather than
> > > > > >> just land them without notification or discussion?
> > > > > >
> > > > > > Oh god, stop this, will you?
> > > > > 
> > > > > No, I mean the above in general for general changes you make
> > > > > that affect the distro as a whole. You generally land them
> > > > > without notification.
> > > > 
> > > > I "generally" do that? Can you be more precise?
> > > 
> > > A recent example, systemd decided that os-release needed to be
> > > moved to /usr/lib/ I did not see any notification on devel@ nor
> > > was i contacted directly. the first I heard of it was a third
> > > party person filing a bug against fedora-release
> > 
> > I should add that changing it broke the compose process and was
> > quickly fixed. wider communication means that other effected
> > components have some visibility into things that may effect them.
> 
> You cannot really blame me for breakages for things I neither asked
> for nor was involved with at all in Fedora.
> 
> Lennart
> 

I am not blaming you for anything here, merely pointing out that if
there was better communications we could have likely avoided the
breakage while the change was made altogether.

Dennis
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Dennis Gilmore]

On Fri, 20 Feb 2015 18:11:38 +0100
Lennart Poettering  wrote:

> On Fri, 20.02.15 11:04, Dennis Gilmore (den...@ausil.us) wrote:
> 
> > On Fri, 20 Feb 2015 17:36:17 +0100
> > Lennart Poettering  wrote:
> > 
> > > On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com)
> > > wrote:
> > > 
> > > > >> > Sorry for the inconvenience and feel free to add bugs to
> > > > >> > the tracker, which are caused by systemd changes and have
> > > > >> > to be fixed in other components.
> > > > >>
> > > > >> Are you going to start notifying deve@ of upcoming changes
> > > > >> that may impact other areas of the distro too rather than
> > > > >> just land them without notification or discussion?
> > > > >
> > > > > Oh god, stop this, will you?
> > > > 
> > > > No, I mean the above in general for general changes you make
> > > > that affect the distro as a whole. You generally land them
> > > > without notification.
> > > 
> > > I "generally" do that? Can you be more precise?
> > 
> > A recent example, systemd decided that os-release needed to be moved
> > to /usr/lib/ I did not see any notification on devel@ nor was i
> > contacted directly. the first I heard of it was a third party person
> > filing a bug against fedora-release
> 
> While moving it is great, it's not really that important to move it. 
> 
> I mean, moving it is useful in the context of stateless systems that
> can boot up with empty /etc. However, Fedora is so far away from that,
> that we have tons of other things to fix first, before the os-release
> move would start to matter.
> 
> We haven't posted a feature to make Fedora stateless in this sense,
> and hence also didn't ask for /etc/os-release to be moved. There are
> some upstream things to work on before we can propose such a Fedora
> change.
> 
> So, thank you very much for moving it! But this is neither a change
> that would really need coordination, nor something we pushed for from
> our side.


communication would have avoided some of the discussion in
https://bugzilla.redhat.com/show_bug.cgi?id=1149568 and likely avoided
having the bug altogether. regardless of your reasons for making a
change or how unimportant you consider it, others follow things that are
done and follow up on them when you do not. I for one would appreciate
knowing when the allowable fields change in os-release because the
first I ever hear is when people file bugs asking for them to be added
to Fedora. I then have to chase things down to catch up. 

Dennis
-- 
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: So everything in Rawhide must be compiled with -fPIC?

[Reindl Harald]

Am 20.02.2015 um 18:21 schrieb Peter Robinson:

I've never argumented against the goal that web browser or all network aware
services should be PIEs, after all, why would we (Ulrich Drepper and myself)
add the PIE support into the toolchain otherwise?
I'm just not convinced most of the unpriviledged programs should be PIEs.


Thanks to e.g. e-mail about any program can be made to run untrusted
data, e.g. PDF readers, office suites, image viewers, if you open an
attachment of the respective type. Therefore it makes a sane default
IMHO. It is also something to attract users that care about security
very much to Fedora.


So your saying here that this is miraculously going to stop people
from running random binaries that are being emailed to them?


nobody said that

but it may stop a otherwise successful exploit in the application 
opening the malicious attachment targeting a unknown or unfixed security 
hole



just going stop people from running random non PIC/PIE binaries? I
don't buy that this is a miracle fix to that problem. How then does it
affect other third party binaries not compiled with PIC/PIE that
people might wish to run?


you can't fix and protect every binary on the world

but you can raise the bar for distribution packages
without PIC/PIE ASLR won't work



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: So everything in Rawhide must be compiled with -fPIC?

[Peter Robinson]

>> I've never argumented against the goal that web browser or all network aware
>> services should be PIEs, after all, why would we (Ulrich Drepper and myself)
>> add the PIE support into the toolchain otherwise?
>> I'm just not convinced most of the unpriviledged programs should be PIEs.
>
> Thanks to e.g. e-mail about any program can be made to run untrusted
> data, e.g. PDF readers, office suites, image viewers, if you open an
> attachment of the respective type. Therefore it makes a sane default
> IMHO. It is also something to attract users that care about security
> very much to Fedora.

So your saying here that this is miraculously going to stop people
from running random binaries that are being emailed to them? Or is
just going stop people from running random non PIC/PIE binaries? I
don't buy that this is a miracle fix to that problem. How then does it
affect other third party binaries not compiled with PIC/PIE that
people might wish to run?

More over in the Change request [1] I don't see any evidence with
examples, links to research papers etc on how this makes things more
secure all I see is basically "because SECURITY man!!!" . The
feature says "our users less likely become victims of attacks" but
which sort of attacks, how does it improve security. I understand why
we'd want it on remotely accessible daemons and long running back
ground processes, even things like mail clients that connect to the
internet. There is absolutely no technical detail in the change, other
than the technical change to implement it, there's no mention that it
will have an impact on performance, with numbers to back it up, across
the three primary architectures.

Given that the person who actually wrote the code to implement the
actual functionality has grave concerns about it's usefulness and
impact to end users and packagers. I'm also concerned that he will be
the person that will need to fix problems are likely going to be seen
by packagers and not you as the person proposing the change? Do you
have the time and ability to deal with these problems? Having dealt
with these issues across a number of architectures and having had to
ask Jakob nicely for his time and assistance when there's been issues
from his response I'm not sure you've got his buy in to deal with
this.

Also I've seen no performance analysis across all three architectures
to see the impact. I'll happily send you an XO-1 to test on (our
lowest supported device on i686 and also one of our most widely
deployed Fedora device) and ARM hardware if you've not got access to
test.

Fedora users tend to keep hardware around for longer time than a lot
of enterprises, it's also a distro used a lot in the developing world
on low end cheap hardware because the rest of the world isn't
necessarily so privileged as to be able afford the latest and greatest
and I think we need to consider that along side "possible" security
improvements!

Peter

[1] 
https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Lennart Poettering]

On Fri, 20.02.15 11:04, Dennis Gilmore (den...@ausil.us) wrote:

> On Fri, 20 Feb 2015 17:36:17 +0100
> Lennart Poettering  wrote:
> 
> > On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote:
> > 
> > > >> > Sorry for the inconvenience and feel free to add bugs to the
> > > >> > tracker, which are caused by systemd changes and have to be
> > > >> > fixed in other components.
> > > >>
> > > >> Are you going to start notifying deve@ of upcoming changes that
> > > >> may impact other areas of the distro too rather than just land
> > > >> them without notification or discussion?
> > > >
> > > > Oh god, stop this, will you?
> > > 
> > > No, I mean the above in general for general changes you make that
> > > affect the distro as a whole. You generally land them without
> > > notification.
> > 
> > I "generally" do that? Can you be more precise?
> 
> A recent example, systemd decided that os-release needed to be moved
> to /usr/lib/ I did not see any notification on devel@ nor was i
> contacted directly. the first I heard of it was a third party person
> filing a bug against fedora-release

While moving it is great, it's not really that important to move it. 

I mean, moving it is useful in the context of stateless systems that
can boot up with empty /etc. However, Fedora is so far away from that,
that we have tons of other things to fix first, before the os-release
move would start to matter.

We haven't posted a feature to make Fedora stateless in this sense,
and hence also didn't ask for /etc/os-release to be moved. There are
some upstream things to work on before we can propose such a Fedora
change.

So, thank you very much for moving it! But this is neither a change
that would really need coordination, nor something we pushed for from
our side.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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 1194637] perl-constant-defer-6 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-constant-defer-6-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/perl-constant-defer-6-1.fc20

-- 
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=9lGcRbikSE&a=cc_unsubscribe
--
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: systemd-219 issues with 22 and Rawhide composes

[Paul W. Frields]

On Fri, Feb 20, 2015 at 04:52:20PM +, Peter Robinson wrote:
> >> >> > Sorry for the inconvenience and feel free to add bugs to the tracker, 
> >> >> > which are
> >> >> > caused by systemd changes and have to be fixed in other components.
> >> >>
> >> >> Are you going to start notifying deve@ of upcoming changes that may
> >> >> impact other areas of the distro too rather than just land them
> >> >> without notification or discussion?
> >> >
> >> > Oh god, stop this, will you?
> >>
> >> No, I mean the above in general for general changes you make that
> >> affect the distro as a whole. You generally land them without
> >> notification.
> >
> > I "generally" do that? Can you be more precise?
> >
> >> > The folks in question knew I would drop the patch. In the original bug
> >> > I even said I would remove the work-around from systemd.rpm after TC1
> >> > of the last cycle. I was nice, left it in for the whole cycle, only
> >> > dropped it now.
> >>
> >> Yes, and it looks like it affects dhcpd too... just because you
> >> notified one dev team on a single bug it's not the same as a wider
> >> announcement to the wider community. There's all sorts of things that
> >> this can affect, and while yes it may be a bug in their software, it
> >> should be as widely notified as possible. People have priorities that
> >> may not be the same as yours.
> >
> > Hey! Come on. Everything that systemd does is create a symlink for
> > /etc/resolv.conf if nothing else has created on for that. If something
> > else created and owned that file, it leaves the thing alone. That's
> > all. It's very defensively written. Anaconda's file copy routine
> > tripped up on it though, since it follows symlinks on the destination
> > (which is a really bad idea, and needs to be fixed).
> >
> >> > There is no news in all of this, I just removed the work-around now, as
> >> > indicated back then.
> >>
> >> Again, I'm not just referring to this single incident, it would be
> >> nice if you notified people widely of changes. It's a community,
> >> people don't all follow closely the upstream development of all
> >> upstream components.
> >
> > Ok, then please list all those numerous incidents please.
> >
> >> > How many months would you like me to notify people in advance of a
> >> > simple change like this? Isn't 6 month *ample* time?
> >>
> >> Likely not, not everyone has the same schedule as upstream systemd, in
> >> a lot of cases they don't know it's broken until things land and teams
> >> have other priorities.
> >
> > OK, got it, will let everybody know now of changes 5 years in
> > advance. Would that suit your needs?
> 
> Not what I'm saying at all. There's no need to throw toys to the
> extreme just because someone is asking for a certain level of reason
> and engagement.
> 
> > Anyway, I have the suspicion you just want to make a fuss, and this is
> > where it ends for me hence.
> 
> Nope, I don't, I just want engagement, generally and overall I'm
> actively positive for systemd and a big advocate for it. You just need
> to engage in the community and if something isn't done in six months
> because another team has other priorities and other deadlines and
> people push back because it's actually breaking other areas of the
> distribution there's no need to throw toys from the pram and storm
> off. It's a large distro of moving parts and we need flexibility as a
> result, things get pushed due to delays. It's not the end of the
> world!

I think we can do better than this level of communication.  Yes, it
would have been good to avoid a surprise here.  There are issues on
both sides.  Blaming the situation on either impatience or sloth
doesn't do any justice to the good efforts everyone makes.

On one side, it may not be reasonable to expect that all teams track
or follow up on every bug.  It's right to expect some explicit notice
and, more importantly, collaboration across teams -- talking to each
other, not just filing a bug without clear expectations.

On the other hand, Fedora is supposed to be innovative and we need to
take a positive approach to change.  When teams see a change coming up
they know will cause them work or breakage, they can proactively reach
out to engage.  In fact, anyone can facilitate such a conversation.

Also, a side note: A book I read on communication in relationships
once (I think it was "That's Not What I Meant" by Deborah Tannen) said
that when one universalizes statements, e.g. "you usually do " or
"you always do ," it's unlikely to yield any positive results in a
discussion.  I've seen nothing in open source communication that gives
evidence to the contrary. :-) The important thing is that we try to
deal constructively with this specific situation, and in learning from
it, we can mitigate similar situations in the future.

-- 
Paul W. Frields  
Manager, Fedora Engineering - Emerging Platform
http://redhat.com  --  http://opensource.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://

Re: systemd-219 issues with 22 and Rawhide composes

[Lennart Poettering]

On Fri, 20.02.15 11:07, Dennis Gilmore (den...@ausil.us) wrote:

> On Fri, 20 Feb 2015 11:04:13 -0600
> Dennis Gilmore  wrote:
> 
> > On Fri, 20 Feb 2015 17:36:17 +0100
> > Lennart Poettering  wrote:
> > 
> > > On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote:
> > > 
> > > > >> > Sorry for the inconvenience and feel free to add bugs to the
> > > > >> > tracker, which are caused by systemd changes and have to be
> > > > >> > fixed in other components.
> > > > >>
> > > > >> Are you going to start notifying deve@ of upcoming changes that
> > > > >> may impact other areas of the distro too rather than just land
> > > > >> them without notification or discussion?
> > > > >
> > > > > Oh god, stop this, will you?
> > > > 
> > > > No, I mean the above in general for general changes you make that
> > > > affect the distro as a whole. You generally land them without
> > > > notification.
> > > 
> > > I "generally" do that? Can you be more precise?
> > 
> > A recent example, systemd decided that os-release needed to be moved
> > to /usr/lib/ I did not see any notification on devel@ nor was i
> > contacted directly. the first I heard of it was a third party person
> > filing a bug against fedora-release
> 
> I should add that changing it broke the compose process and was quickly
> fixed. wider communication means that other effected components have
> some visibility into things that may effect them.

You cannot really blame me for breakages for things I neither asked
for nor was involved with at all in Fedora.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Dennis Gilmore]

On Fri, 20 Feb 2015 11:04:13 -0600
Dennis Gilmore  wrote:

> On Fri, 20 Feb 2015 17:36:17 +0100
> Lennart Poettering  wrote:
> 
> > On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote:
> > 
> > > >> > Sorry for the inconvenience and feel free to add bugs to the
> > > >> > tracker, which are caused by systemd changes and have to be
> > > >> > fixed in other components.
> > > >>
> > > >> Are you going to start notifying deve@ of upcoming changes that
> > > >> may impact other areas of the distro too rather than just land
> > > >> them without notification or discussion?
> > > >
> > > > Oh god, stop this, will you?
> > > 
> > > No, I mean the above in general for general changes you make that
> > > affect the distro as a whole. You generally land them without
> > > notification.
> > 
> > I "generally" do that? Can you be more precise?
> 
> A recent example, systemd decided that os-release needed to be moved
> to /usr/lib/ I did not see any notification on devel@ nor was i
> contacted directly. the first I heard of it was a third party person
> filing a bug against fedora-release

I should add that changing it broke the compose process and was quickly
fixed. wider communication means that other effected components have
some visibility into things that may effect them.

Dennis
-- 
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: setup needed for building from src rpms ?

[Reindl Harald]

Am 20.02.2015 um 17:59 schrieb Fulko Hew:

I'm not sure if this is the right list for the question, but...


not really, at least the subject is on-topic


I now have the time and opportunity to migrate my main dev machine
from Fedora 8 to something current, namely F21.  But in the intervening
years, there have been lots of changes to KDE, and most of the visual
aspects don't suit my way of thinking, especially about usability.
Personally I found the older everything to be easer and faster to use.
ie. less mouse movements and fewer clicks, etc.
But I won't turn this into a rant.  Rather I want to patch some of
my major pain points to re-introduce some of the options and flexibility
that seems to have been removed since then.

I thought I'd start with enhancing some of the items in kdetoys,
so I fetched the source RPM and tried installing it with yum and dnf.
Yum complains about 'Not a compatible architecture: src'
DNF complains about 'Will not install a source rpm package"
RPM tries to work but warns about: missing user and group mockbuild.


a src.rpm is a SOURCE package to install it in a *build environment* or 
"rpmbuild ---rebuild package.src.rpm" and "rpm -ivh" just unpacks it in 
the build environment (SPECS, SOURCES..) to use rpmbuild


https://fedoraproject.org/wiki/How_to_create_an_RPM_package



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: systemd-219 issues with 22 and Rawhide composes

[Dennis Gilmore]

On Fri, 20 Feb 2015 17:36:17 +0100
Lennart Poettering  wrote:

> On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote:
> 
> > >> > Sorry for the inconvenience and feel free to add bugs to the
> > >> > tracker, which are caused by systemd changes and have to be
> > >> > fixed in other components.
> > >>
> > >> Are you going to start notifying deve@ of upcoming changes that
> > >> may impact other areas of the distro too rather than just land
> > >> them without notification or discussion?
> > >
> > > Oh god, stop this, will you?
> > 
> > No, I mean the above in general for general changes you make that
> > affect the distro as a whole. You generally land them without
> > notification.
> 
> I "generally" do that? Can you be more precise?

A recent example, systemd decided that os-release needed to be moved
to /usr/lib/ I did not see any notification on devel@ nor was i
contacted directly. the first I heard of it was a third party person
filing a bug against fedora-release

Dennis
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Dan Williams]

On Fri, 2015-02-20 at 17:43 +0100, Florian Weimer wrote:
> On 02/20/2015 05:11 PM, Lennart Poettering wrote:
> 
> > Also, NM fixed a similar issue with /etc/resolve.conf in their code a
> > long time ago, to my knowledge. Am I so misguided to assume that
> > Anaconda can fix a fricking file copy too, in all those months?
> 
> Maybe it is time to step back and consider if replacing /etc/resolv.conf
> with a symbolic link is something that can be reasonably implemented
> from a backwards compatibility perspective?
> 
> Usually, if we face this much trouble within Fedora itself, it's a good
> indicator of the pain that we'll have to deal with downstream.

I would love to know the outcome of this discussion, since we just made
a change to NetworkManager git master (will be version 1.2, target
Fedora 23) to make /etc/resolv.conf a symlink when it's under NM's
control.  If there are problems here, we want to know too.

* NM won't replace a symlinked /etc/resolv.conf that doesn't point to
NM's copy in /var
* You can disable this behavior with "dns=none"
in /etc/NetworkManager/NetworkManager.conf and manage resolv.conf on
your own too

Dan

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

setup needed for building from src rpms ?

[Fulko Hew]

I'm not sure if this is the right list for the question, but...

I now have the time and opportunity to migrate my main dev machine
from Fedora 8 to something current, namely F21.  But in the intervening
years, there have been lots of changes to KDE, and most of the visual
aspects don't suit my way of thinking, especially about usability.
Personally I found the older everything to be easer and faster to use.
ie. less mouse movements and fewer clicks, etc.
But I won't turn this into a rant.  Rather I want to patch some of
my major pain points to re-introduce some of the options and flexibility
that seems to have been removed since then.

I thought I'd start with enhancing some of the items in kdetoys,
so I fetched the source RPM and tried installing it with yum and dnf.
Yum complains about 'Not a compatible architecture: src'
DNF complains about 'Will not install a source rpm package"
RPM tries to work but warns about: missing user and group mockbuild.

Can someone point me to a guide for installing/configing the
prerequisites for building from source?
(It doesn't seem as easy as it used to be.)

Thanks

Fulko
-- 
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: Proposal to (formally/easily) allowing multiple versions of the same library installable

[Andrew Haley]

On 02/16/2015 04:17 PM, Ralf Corsepius wrote:
> I don't buy this argument wrt. Fedora.
> 
> Fedora is a rapid moving, forward looking distro, in which such 
> regressions should be fixed and not be worked around by compat-libs.

That rather assumes that the only use for Fedora libraries is running
programs that are part of Fedora rather than programs that a user
installs from elsewhere.  While this may be true, it's not necessarily
a good thing.

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

File constant-defer-6.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-constant-defer:

6af9912fa420340e9e171ac81f450492  constant-defer-6.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

Re: systemd-219 issues with 22 and Rawhide composes

[Peter Robinson]

>> >> > Sorry for the inconvenience and feel free to add bugs to the tracker, 
>> >> > which are
>> >> > caused by systemd changes and have to be fixed in other components.
>> >>
>> >> Are you going to start notifying deve@ of upcoming changes that may
>> >> impact other areas of the distro too rather than just land them
>> >> without notification or discussion?
>> >
>> > Oh god, stop this, will you?
>>
>> No, I mean the above in general for general changes you make that
>> affect the distro as a whole. You generally land them without
>> notification.
>
> I "generally" do that? Can you be more precise?
>
>> > The folks in question knew I would drop the patch. In the original bug
>> > I even said I would remove the work-around from systemd.rpm after TC1
>> > of the last cycle. I was nice, left it in for the whole cycle, only
>> > dropped it now.
>>
>> Yes, and it looks like it affects dhcpd too... just because you
>> notified one dev team on a single bug it's not the same as a wider
>> announcement to the wider community. There's all sorts of things that
>> this can affect, and while yes it may be a bug in their software, it
>> should be as widely notified as possible. People have priorities that
>> may not be the same as yours.
>
> Hey! Come on. Everything that systemd does is create a symlink for
> /etc/resolv.conf if nothing else has created on for that. If something
> else created and owned that file, it leaves the thing alone. That's
> all. It's very defensively written. Anaconda's file copy routine
> tripped up on it though, since it follows symlinks on the destination
> (which is a really bad idea, and needs to be fixed).
>
>> > There is no news in all of this, I just removed the work-around now, as
>> > indicated back then.
>>
>> Again, I'm not just referring to this single incident, it would be
>> nice if you notified people widely of changes. It's a community,
>> people don't all follow closely the upstream development of all
>> upstream components.
>
> Ok, then please list all those numerous incidents please.
>
>> > How many months would you like me to notify people in advance of a
>> > simple change like this? Isn't 6 month *ample* time?
>>
>> Likely not, not everyone has the same schedule as upstream systemd, in
>> a lot of cases they don't know it's broken until things land and teams
>> have other priorities.
>
> OK, got it, will let everybody know now of changes 5 years in
> advance. Would that suit your needs?

Not what I'm saying at all. There's no need to throw toys to the
extreme just because someone is asking for a certain level of reason
and engagement.

> Anyway, I have the suspicion you just want to make a fuss, and this is
> where it ends for me hence.

Nope, I don't, I just want engagement, generally and overall I'm
actively positive for systemd and a big advocate for it. You just need
to engage in the community and if something isn't done in six months
because another team has other priorities and other deadlines and
people push back because it's actually breaking other areas of the
distribution there's no need to throw toys from the pram and storm
off. It's a large distro of moving parts and we need flexibility as a
result, things get pushed due to delays. It's not the end of the
world!

Peter
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Florian Weimer]

On 02/20/2015 05:11 PM, Lennart Poettering wrote:

> Also, NM fixed a similar issue with /etc/resolve.conf in their code a
> long time ago, to my knowledge. Am I so misguided to assume that
> Anaconda can fix a fricking file copy too, in all those months?

Maybe it is time to step back and consider if replacing /etc/resolv.conf
with a symbolic link is something that can be reasonably implemented
from a backwards compatibility perspective?

Usually, if we face this much trouble within Fedora itself, it's a good
indicator of the pain that we'll have to deal with downstream.

-- 
Florian Weimer / Red Hat Product Security
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Rahul Sundaram]

Hi

On Fri, Feb 20, 2015 at 11:11 AM, Lennart Poettering  wrote:

> How many months would you like me to notify people in advance of a
> simple change like this? Isn't 6 month *ample* time?
>
> The problem isn't necessarily the speed of change but the amount of
caution and attention paid to inform folks affected by such changes.  It is
a fairly simple change in this case but it affects more than just one
component and not everyone is aware of the details in the first place.  A
simple announcement here or fedora devel announce list would go a long way.

Rahul
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Lennart Poettering]

On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote:

> >> > Sorry for the inconvenience and feel free to add bugs to the tracker, 
> >> > which are
> >> > caused by systemd changes and have to be fixed in other components.
> >>
> >> Are you going to start notifying deve@ of upcoming changes that may
> >> impact other areas of the distro too rather than just land them
> >> without notification or discussion?
> >
> > Oh god, stop this, will you?
> 
> No, I mean the above in general for general changes you make that
> affect the distro as a whole. You generally land them without
> notification.

I "generally" do that? Can you be more precise?

> > The folks in question knew I would drop the patch. In the original bug
> > I even said I would remove the work-around from systemd.rpm after TC1
> > of the last cycle. I was nice, left it in for the whole cycle, only
> > dropped it now.
> 
> Yes, and it looks like it affects dhcpd too... just because you
> notified one dev team on a single bug it's not the same as a wider
> announcement to the wider community. There's all sorts of things that
> this can affect, and while yes it may be a bug in their software, it
> should be as widely notified as possible. People have priorities that
> may not be the same as yours.

Hey! Come on. Everything that systemd does is create a symlink for
/etc/resolv.conf if nothing else has created on for that. If something
else created and owned that file, it leaves the thing alone. That's
all. It's very defensively written. Anaconda's file copy routine
tripped up on it though, since it follows symlinks on the destination
(which is a really bad idea, and needs to be fixed).

> > There is no news in all of this, I just removed the work-around now, as
> > indicated back then.
> 
> Again, I'm not just referring to this single incident, it would be
> nice if you notified people widely of changes. It's a community,
> people don't all follow closely the upstream development of all
> upstream components.

Ok, then please list all those numerous incidents please.

> > How many months would you like me to notify people in advance of a
> > simple change like this? Isn't 6 month *ample* time?
> 
> Likely not, not everyone has the same schedule as upstream systemd, in
> a lot of cases they don't know it's broken until things land and teams
> have other priorities.

OK, got it, will let everybody know now of changes 5 years in
advance. Would that suit your needs?

Anyway, I have the suspicion you just want to make a fuss, and this is
where it ends for me hence.

Good night,

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: [Base] Base Design WG agenda meeting 20 February 2015 15:00 UTC on #fedora-meeting

[Harald Hoyer]

On 20.02.2015 14:35, Harald Hoyer wrote:
> Agenda:
>  - Vote for new chairman of the Base Design WG to replace Phil Knirsch
>  - Open Floor
> 

Minutes:

Minutes (text):

Log:

-- 
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: systemd-219 issues with 22 and Rawhide composes

[Peter Robinson]

On Fri, Feb 20, 2015 at 4:11 PM, Lennart Poettering
 wrote:
> On Fri, 20.02.15 16:03, Peter Robinson (pbrobin...@gmail.com) wrote:
>
>> On Fri, Feb 20, 2015 at 3:47 PM, Harald Hoyer  wrote:
>> > To prevent surprises on the next systemd updates like in
>> > , we will not apply
>> > workarounds anymore in rawhide and track the issues on
>> >  so, 
>> > that
>> > they are not forgotten.
>> >
>> > We removed the change for /etc/resolv.conf in F22 again (like in F21), but 
>> > this
>> > time we keep the change for rawhide.
>> >
>> > Sorry for the inconvenience and feel free to add bugs to the tracker, 
>> > which are
>> > caused by systemd changes and have to be fixed in other components.
>>
>> Are you going to start notifying deve@ of upcoming changes that may
>> impact other areas of the distro too rather than just land them
>> without notification or discussion?
>
> Oh god, stop this, will you?

No, I mean the above in general for general changes you make that
affect the distro as a whole. You generally land them without
notification.

> The folks in question knew I would drop the patch. In the original bug
> I even said I would remove the work-around from systemd.rpm after TC1
> of the last cycle. I was nice, left it in for the whole cycle, only
> dropped it now.

Yes, and it looks like it affects dhcpd too... just because you
notified one dev team on a single bug it's not the same as a wider
announcement to the wider community. There's all sorts of things that
this can affect, and while yes it may be a bug in their software, it
should be as widely notified as possible. People have priorities that
may not be the same as yours.

> There is no news in all of this, I just removed the work-around now, as
> indicated back then.

Again, I'm not just referring to this single incident, it would be
nice if you notified people widely of changes. It's a community,
people don't all follow closely the upstream development of all
upstream components.

> How many months would you like me to notify people in advance of a
> simple change like this? Isn't 6 month *ample* time?

Likely not, not everyone has the same schedule as upstream systemd, in
a lot of cases they don't know it's broken until things land and teams
have other priorities.

> How much time do you think is appropriate for fixing a file copy
> routine in anaconda? 12 months? 18 months? 2 years?

I'm not just referring to *just* anaconda. This is *one* thing,
there's other things that might be broken by this. How long has
/etc/resolv.conf been a file in that location? How many things across
the distro expect it to be like it is? It's legacy and while I'm not
against changing it there may be impact that isn't take into account.
Bullying people/process/team just because "you've waited 6 months
already" isn't an appropriate response just because you're impatient
and want to move on. We're a community that doesn't revolved around
systemd... sorry!

> Also, NM fixed a similar issue with /etc/resolve.conf in their code a
> long time ago, to my knowledge. Am I so misguided to assume that
> Anaconda can fix a fricking file copy too, in all those months?

To my knowledge there also looks to be issues with dhcp due to this
change as of yesterday so maybe you don't have all the knowledge.
What else might be affected in the distro according "to your
knowledge"?

Peter
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Lennart Poettering]

On Fri, 20.02.15 16:03, Peter Robinson (pbrobin...@gmail.com) wrote:

> On Fri, Feb 20, 2015 at 3:47 PM, Harald Hoyer  wrote:
> > To prevent surprises on the next systemd updates like in
> > , we will not apply
> > workarounds anymore in rawhide and track the issues on
> >  so, that
> > they are not forgotten.
> >
> > We removed the change for /etc/resolv.conf in F22 again (like in F21), but 
> > this
> > time we keep the change for rawhide.
> >
> > Sorry for the inconvenience and feel free to add bugs to the tracker, which 
> > are
> > caused by systemd changes and have to be fixed in other components.
> 
> Are you going to start notifying deve@ of upcoming changes that may
> impact other areas of the distro too rather than just land them
> without notification or discussion?

Oh god, stop this, will you?

The folks in question knew I would drop the patch. In the original bug
I even said I would remove the work-around from systemd.rpm after TC1
of the last cycle. I was nice, left it in for the whole cycle, only
dropped it now.

There is no news in all of this, I just removed the work-around now, as
indicated back then.

How many months would you like me to notify people in advance of a
simple change like this? Isn't 6 month *ample* time?

How much time do you think is appropriate for fixing a file copy
routine in anaconda? 12 months? 18 months? 2 years?

Also, NM fixed a similar issue with /etc/resolve.conf in their code a
long time ago, to my knowledge. Am I so misguided to assume that
Anaconda can fix a fricking file copy too, in all those months?

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Peter Robinson]

On Fri, Feb 20, 2015 at 3:47 PM, Harald Hoyer  wrote:
> To prevent surprises on the next systemd updates like in
> , we will not apply
> workarounds anymore in rawhide and track the issues on
>  so, that
> they are not forgotten.
>
> We removed the change for /etc/resolv.conf in F22 again (like in F21), but 
> this
> time we keep the change for rawhide.
>
> Sorry for the inconvenience and feel free to add bugs to the tracker, which 
> are
> caused by systemd changes and have to be fixed in other components.

Are you going to start notifying deve@ of upcoming changes that may
impact other areas of the distro too rather than just land them
without notification or discussion?

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

systemd-219 issues with 22 and Rawhide composes

[Harald Hoyer]

To prevent surprises on the next systemd updates like in
, we will not apply
workarounds anymore in rawhide and track the issues on
 so, that
they are not forgotten.

We removed the change for /etc/resolv.conf in F22 again (like in F21), but this
time we keep the change for rawhide.

Sorry for the inconvenience and feel free to add bugs to the tracker, which are
caused by systemd changes and have to be fixed in other components.
-- 
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: Proposal to (formally/easily) allowing multiple versions of the same library installable

[Rahul Sundaram]

Hi

On Mon, Feb 16, 2015 at 11:17 AM, Ralf Corsepius  wrote:

> I don't buy this argument wrt. Fedora.
>
> Fedora is a rapid moving, forward looking distro, in which such
> regressions should be fixed and not be worked around by compat-libs.


In ideal conditions, this is fine but in the real world, people do have to
use older versions of libraries because debugging issues in newer versions
isn't a priority and won't be for a lot of users.

Rahul
-- 
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: Gnome in F22 not automouting sdcards / usb-sticks

[Peter Robinson]

On Fri, Feb 20, 2015 at 2:54 PM, Hans de Goede  wrote:
> Hi All,
>
> I've upgraded both my main workstation as well as my laptop to F22,
> and I've noticed that my stock Gnome desktop no longer automounts
> sdcards / usbsticks.
>
> If I start "files" it sees the device show up just fine, and
> double clicking mounts it, but it no longer gets mounted
> automatically, even if I plug it in after I login.
>
> Is this change deliberate ? If so is there an option to change
> back to the old behavior.
>
> If this is not deliberate, are other people seeing this ? And if
> no one else is seeing this how do I debug this ?

I'm seeing this too, on some devices I'm evening seeing the device
show up in dmesg etc but device nodes not being created for the device
even though it sees partitions etc so I'm wondering if it's actually
lower down the stack from gnome.

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

Gnome in F22 not automouting sdcards / usb-sticks

[Hans de Goede]

Hi All,

I've upgraded both my main workstation as well as my laptop to F22,
and I've noticed that my stock Gnome desktop no longer automounts
sdcards / usbsticks.

If I start "files" it sees the device show up just fine, and
double clicking mounts it, but it no longer gets mounted
automatically, even if I plug it in after I login.

Is this change deliberate ? If so is there an option to change
back to the old behavior.

If this is not deliberate, are other people seeing this ? And if
no one else is seeing this how do I debug this ?

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

[Base] Base Design WG agenda meeting 20 February 2015 15:00 UTC on #fedora-meeting

[Harald Hoyer]

Agenda:
 - Vote for new chairman of the Base Design WG to replace Phil Knirsch
 - Open Floor
-- 
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: Proposal to (formally/easily) allowing multiple versions of the same library installable

[Casey Jao]

On 02/16/2015 08:17 AM, Ralf Corsepius wrote:
> On 02/16/2015 05:10 PM, Martyn Foster wrote:
>>
>>
>> On 16 February 2015 at 15:12, Kevin Kofler > > wrote:
>>
>> Christopher Meng wrote:
>> > Maintaining several version of the same library is not easy as
>> you think,
>> > basically once a developer wants to install version X while then
>> another
>> > people want to deploy things based on version Y, how to crack
>> this nut?
>> > You can't just care about runtime.
>>
>> Then you need to patch one or the other package to work with the same
>> version. Only if that is not possible, a compatibility library can be
>> considered. But we should always first try to make everything work
>> with the
>> same version (if possible, the newer one).
>>
>>
>> The requirement to work with multiple versions of a package come up in
>> the scientific/HPC community very frequently. Its not always about API
>> compatibility, sometimes exact numerical reproduction is required which
>> isn't preserved even between minor versions (i.e. an OS update).
> I don't buy this argument wrt. Fedora.
> 
> Fedora is a rapid moving, forward looking distro, in which such
> regressions should be fixed and not be worked around by compat-libs.
> 
> Ralf
> 
> 

Since Fedora serves as a blueprint for RHEL, CentOS, and Scientific
Linux, which do get used in the scientific community and encounter the
issues Martyn mentioned, any technical framework that Fedora develops to
handle those issues would do the larger community quite a service, even
if it does not get used that often by Fedora users.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken already (was: Re: How to install Rawhide?)

[Michael Schwendt]

> Also the -02-18 one for Rawhide x86_64 Live Workstation, which started
> fine and managed to install, too. Haven't rebooted yet, though.

It has been broken already by the first bunch of updates (62 or 63 pkgs).
"Oh no! Something has gone wrong [Logout]" prior to GDM greeting screen
coming up.
-- 
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: Minutes from Env-and-Stacks WG meeting (2015-02-19)

[Tomas Tomecek]

Quoting Honza Horak (2015-02-19 19:48:59)
> * Dockerfiles recommended tips  (hhorak, 18:15:21)
>* LINK: https://fedoraproject.org/wiki/Env_and_Stacks/Tasklist
>  (hhorak, 18:15:45)
>* LINK:
>  https://fedoraproject.org/wiki/User:Hhorak/Draft/task-dockerfile-rules
>  (hhorak, 18:15:55)
>* ACTION: phracek to get in touch with marek, author of JBoss Docker
>  images best practices  (hhorak, 18:24:10)

I liked openshift's tips:

http://docs.openshift.org/latest/image_writers_guide/guidelines.html


Tomas

-- 
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: Proposal to (formally/easily) allowing multiple versions of the same library installable

[Hedayat Vatankhah]

/*Ralf Corsepius */ wrote on Mon, 16 Feb 2015 
17:17:32 +0100:

On 02/16/2015 05:10 PM, Martyn Foster wrote:



On 16 February 2015 at 15:12, Kevin Kofler mailto:kevin.kof...@chello.at>> wrote:

Christopher Meng wrote:
> Maintaining several version of the same library is not easy as 
you think,
> basically once a developer wants to install version X while 
then another
> people want to deploy things based on version Y, how to crack 
this nut?

> You can't just care about runtime.

Then you need to patch one or the other package to work with the 
same
version. Only if that is not possible, a compatibility library 
can be

considered. But we should always first try to make everything work
with the
same version (if possible, the newer one).


The requirement to work with multiple versions of a package come up in
the scientific/HPC community very frequently. Its not always about API
compatibility, sometimes exact numerical reproduction is required which
isn't preserved even between minor versions (i.e. an OS update).

I don't buy this argument wrt. Fedora.

Fedora is a rapid moving, forward looking distro, in which such 
regressions should be fixed and not be worked around by compat-libs.


Ralf




I guess the main point is missed completely. The main proposal is not 
mainly about compatibility. It's about providing latest development 
libraries in stable releases for *user* consumption (not for distro 
one). Also, the compatibility package is solely provided for user 
consumption; *no* Fedora package should be built against it (unless it 
happens already).


There are some arguments against providing such thing in Fedora, but if 
someone wants to install two versions of the same library (e.g. 
installing the latest version for development while having default 
version for Fedora packages); he'll do it anyway. So, if such packages 
are not provided by Fedora, he will install from source. So, the user 
will install multiple versions anyway. Do you want to support him, or not?


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