Re: Fedora on Macs, removing the release criterion

[Kevin Kofler]

Josh Boyer wrote:
> What I cannot get my head around though is how we've essentially made
> a decision based on perceived marketing value of those target users at
> the expense of every other platform we support.

How is it "at the expense of every other platform we support"? It's not like 
the fix is going to stop them from working. It is not a catastrophe to ship 
one week later.

I don't use a Mac, I also don't dual-boot, but still I fail to see why this 
issue should be rejected as a blocker just to ship a week earlier. Fedora 
really needs to decrease the pressure to not slip, in order to ensure a 
reasonable quality of our releases. Blockers must be fixed no matter how 
long it takes.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rpm vs --compress-debug-sections=zlib

[Kevin Kofler]

Tom Hughes wrote:
> I'd say remove it - compressing the debug sections is horrible because
> it forces anything that wants to access the debug data to load it all in
> and decompress it rather than just reading what it needs.

In addition, it actually increases download sizes because RPMs and live 
images are xz-compressed, and xz compresses uncompressed data better than 
zlib-compressed data. The zlib compression is much poorer than xz 
compression, it just keeps xz from compressing things well.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: time to retire some kde4/smoke-based language bindings?

[Kevin Kofler]

Peter Robinson wrote:
> Is qt3 stuff going with them?

No.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Kevin Kofler]

Neal Gompa wrote:
> They *could* if people built 32-bit UEFI loader stuff for it. And
> there have been efforts in the past for it. I wouldn't completely rule
> this out, though it is uncommon.

32-bit grub2-efi is actually available. You should be able to install on 32-
bit UEFI with Calamares, if you remix the image to include grub2-efi and 
grub2-efi-modules ON the image. (Calamares itself can either be included too 
or installed with "dnf install calamares", but grub2-efi needs to be on the 
image itself.) But I have NOT tested it.

You may or may not also have to mess with the live media creation tools to 
add EFI stuff to the 32-bit image so that you can boot it. (For livecd-
tools, if needed, I take pull requests into my fork that I ported to dnf.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libkpmcore soname bump in rawhide

[Kevin Kofler]

Mattia Verga wrote:
> I will update kpmcore in rawhide to latest development version, so there
> will be a soname bump.
> 
> Packages affected are kde-partitionmanager (which I will rebuild) and
> calamares.

OK, I can update Calamares in Rawhide to master.

Shall we take commit access to each other's packages in the stack (kpmcore, 
kde-partitionmanager, calamares) to coordinate this kind of updates? Also so 
that we will also be able to push them to stable releases (at least F25, 
which will be out by then) when the new versions get officially released? I 
can give you commit access to calamares if you want it. (That said, I am 
probably the one who knows best what changes, if any, are needed to the 
config files from one release to another, so it's probably best if I take 
care of the Rawhide package.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Kevin Kofler]

Tomasz Torcz wrote:
>   I'm not sure is it 100% correct, but my knowledge may be outdated.
> Both macOS and Ubuntu asks for first user during the installation.
> Then both suggest hostname, created by combining entered user name
> and form factor of machine being installed.  Ubuntu even incorporates
> specific model name, read from DMI data.
> 
>   Thus, macOS and Ubuntu on my laptop would suggest hostnames as
> “tomasz-laptop” or “tomasz-thinkpad-t400”.

For the record, Calamares (https://calamares.io/ – packaged as "calamares" 
in Fedora) does something similar, but even simpler, it just always uses
"-pc", e.g., it would suggest "tomasz-pc" to you.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libpeas-gtk is in separate subpackage for Rawhide

[Kevin Kofler]

Igor Gnatenko wrote:
> I pushed commit[0] which separates libpeas-gtk.so.* out of the main
> package. Reason is that in future libdnf will be dependent on
> libpeas[1] and we don't want to have minimal system with GTK+ stuff ;)

Yeah, that would really suck! :-) Thank you for splitting the package, this 
is appreciated. (It will save me from having to file yet another bug ;-) ).

Kevin Kofler
Maintainer of the Kannolo pure KDE Fedora Remix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Announcement: DNF port of livecd-creator

[Kevin Kofler]

Hi,

remix authors rejoice: I have ported the old livecd-creator from yum to dnf 
(in one night):
https://github.com/kkofler/livecd-tools
(The other tools in the package were also ported away from yum and its 
rpmUtils to dnf, but livecd-creator was the main user of yum stuff.)

So, if you are unhappy with livemedia-creator for whatever reason, e.g.:
* because of its heavy weight, requiring the whole Anaconda,
* because of its lack of persistent caching (which was the dealbreaker for
  me),
* because of more stringent requirements on the kickstart (in particular,
  livemedia-creator requiring more changes to your existing kickstarts),
* because livecd-creator "is more friendly when kickstarts are broken or
  packages are missing" (quote from a Korora commit message),
or whatever, you will probably appreciate it.

Some caveats:
* It works for me, but of course there is only so much testing you can do in
  only a few hours of work including the porting.
* It is still using Python 2, and thus needs python2-dnf (which nothing else
  needs). If somebody feels like porting it to Python 3, that should be easy
  now that it uses dnf, so please feel free. I would be happy to take a pull
  request for that.
* The switch to dnf may change the dependency resolving in a way that may or
  may not be an improvement.
* In particular, you will probably have to explicitly add these packages:
  kernel-modules
  kernel-modules-extra
  to your kickstart to avoid getting the kernel-debug* versions dragged in.
  For my KDE Fedora Remix Kannolo, I also had to explicitly add pinentry-qt
  to my kickstart to avoid having pinentry-gnome3 dragged in instead.
  These changes are completely backwards-compatible with the original yum
  version of livecd-tools. (They should not have any effect there.)

Enjoy,
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Scott Schmit]

On Sat, Nov 12, 2016 at 03:33:10PM +1030, Glen Turner wrote:
> > RFC 2606[1]  reserves several TLDs that may never be registered for
> > public usage. Out of those, going with
> > Fedora-.localhost
> > seems like the best bet.
> 
> The *reason* localhost is a reserved name is to discourage its use in
> DNS names.  Your proposal is the opposite to that intended by RFC2606,
> something which the casual reader of your message may have missed.

Setting a hostname has nothing to do with what names are in the DNS, so
I have no idea how you came to that conclusion.

Perhaps you can explain further?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Glen Turner]

> RFC 2606[1]  reserves several TLDs that may never be registered for
> public usage. Out of those, going with
> Fedora-.localhost
> seems like the best bet.

The *reason* localhost is a reserved name is to discourage its use in
DNS names.  Your proposal is the opposite to that intended by RFC2606,
something which the casual reader of your message may have missed.

-glen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 11, 2016 at 01:20:26PM -0500, Stephen Gallagher wrote:
> On 11/11/2016 12:17 PM, Andrew Lutomirski wrote:
> > /me dons crypto hat.
> > 
> > SHA(x || k) has three problems, one of which is bad enough to be an absolute
> > showstopper.
> > 
> > 1. Specify *which* SHA.  SHA-1 should not be used for new applications.
> > 
> > 2. Concatenation without some additional property preventing collisions of 
> > the
> > hashed data is problematic.  In particular, if you shorten x by a byte and
> > prepend the same byte to k, you get the same output.  This is probably
> > irrelevant for this particular use case, but it's still a sign that the
> > construction is bad.
> > 
> > 3.  The SHA hashes, like all Merkle-Damgård hashes, is subject to
> > length-extension attacks.  In particular, if x is a multiple (or slightly 
> > above
> > a multiple) of the block length, then anyone who learns SHA(x) can 
> > efficiently
> > derive SHA(x || k).  This basically removes all security from this scheme.
> > 
> > HMAC(k, x) would be much better.
Thanks, that's something to take into consideration.

> > But I think this protocol is generally more fragile then needed.  How about
> > generating a per-app-installation random value and HMAC-ing *that* with the
> > machine id?
> 
> I think this is extreme overkill for something that doesn't need to be
> cryptographically sound. It literally just needs to be eight characters with a
> sensible random distribution. I considered using some non-reversible
> transformation of machine-id for this simply because I wanted to avoid trying 
> to
> consume any of the entropy in /dev/random since we'd be doing this early in 
> the
> installer (when entropy tends to be at a premium). Maybe that was overkill 
> and I
> should just pull from /dev/random.

There's one advantage to deriving the hostname from machine-id: it is
predictable and will always be generated the same. Usually this will not
matter, but if /etc is readonly we might no be able to save the hostname.

> I can't think of a reason why we'd need a cryptographically secure
> transformation just to generate a random hostname.

We want it cryptographically secure to preserve the machine-id. It's
probably not too important in itself, but it's a good idea to keep
it hidden because other hashes might be generated from it.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 11, 2016 at 12:46:43PM -0600, Chris Adams wrote:
> Once upon a time, Andrew Lutomirski  said:
> > NetworkManager already has the ability to randomize MAC addresses to keep
> > them from leaking.
> 
> "has the ability" is not "on by default".  If you want that level of
> anonymity, you have to turn it on.  Also then changing your hostname,
> enabling an option to not send it, etc. is not a big deal (or could even
> be part of a combined "anonymize me" checkbox).
Yes, I think it makes a lot of sense to expose both under the same
configuration switch. Sending the hostname while randomizing MAC address or
vice versa just isn't useful.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1394433] perl-Compress-Bzip2-2.25 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Patches were not touched. All were applied properly

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1394433] perl-Compress-Bzip2-2.25 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Created attachment 1219899
  --> https://bugzilla.redhat.com/attachment.cgi?id=1219899=edit
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper
https://github.com/phracek/rebase-helper/issues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1394433] New: perl-Compress-Bzip2-2.25 is available

[bugzilla]

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

Bug ID: 1394433
   Summary: perl-Compress-Bzip2-2.25 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Compress-Bzip2
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 2.25
Current version/release in rawhide: 2.24-4.fc25
URL: http://search.cpan.org/dist/Compress-Bzip2/

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

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

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2709/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1394433] perl-Compress-Bzip2-2.25 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-Compress-Bzip2-2.24 failed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-11 10:04 GMT+01:00 Fabio Alessandro Locati :
> On Fri, Nov 11, 2016 at 09:20:08AM +0100, Andreas Tunek wrote:
>> As a mac owner (although one that is not very well supported by
>> Linux*) I really appreciate the fact that Fedora works. And saying you
>> do not want to support that hardware anymore just because you found a
>> regression/bug is kind of lame.
>
> Hi,
>
> No one is saying that we should not support Macs, only that if Mac
> support is broken, this should not block a whole release.
>

If you can't actually install Fedora on a system you do not support
it. What is your suggestion, should there be a special image created
just for macs at a later date?

/Andreas

> Best,
> Fale
> --
> Fabio Alessandro Locati
> Red Hat - Senior Consultant
>
> PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1393421] perl-Error broke the most of perl apps.

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-5.24.0-380.fc26|perl-5.24.0-380.fc26
   ||perl-5.22.2-364.fc24
 Resolution|--- |ERRATA
Last Closed||2016-11-11 15:52:09



--- Comment #15 from Fedora Update System  ---
perl-5.22.2-364.fc24 has been pushed to the Fedora 24 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 19:19 +, Peter Robinson wrote:
> On Fri, Nov 11, 2016 at 12:55 PM, Josh Boyer  
> wrote:
> > On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro  
> > wrote:
> > > My $0.02 is that none of the reasons we requested the blocker criterion
> > > have changed. Dual boot with macOS is very important to attracting new
> > > users -- we're explicitly targeting macOS users, that's the user group
> > > where we think we have real potential for significant growth -- and I
> > > continue to prefer we block the release indefinitely if it's not
> > > working. We can't afford for our next Ars review to say "the installer
> > > is broken, try again next year."
> > 
> > Then we, as a project, need to back that up with sufficient hardware
> > and test resources.  Otherwise it is nothing more than a wish and will
> > continue to lead to problems like this.
> 
> And multi boot issues, which can be quite complex and nuanced, should
> then I believe also be a beta blocker (or at least well tested in the
> lead up to beta) to ensure issues get enough attention early enough in
> the release so as to not block GA.

The question of how early we should test things (ideally we should test
everything all the time, but you know how that goes) is really quite
separate from the question of which release they should block.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 09:41 -0800, Richard Johnson wrote:
> I'm very new to this but I'd like to help out.  I actually saw the
> problem a little while back, when I tried to mount an HFS+ FS onto my
> Fedora mac.  It mounted ro.

That in itself is not a bug (except in the sense of 'missing feature').
It's intended to do that, because the Linux HFS+ support cannot safely
write to journalled HFS+. So when the HFS+ filesystem has journalling
enabled, it's intentionally mounted read-only.

The actual issue in the blocker bug is basically that blivet (the
storage module anaconda uses) misidentifies the macOS partition as
being an existing 'macefi' partition and tries to re-use it.

'macefi' partitions are a slightly odd thing we invented basically to
trick Macs into showing Fedora on their nice graphical boot menu. I can
explain in more detail if you like, but you don't really need to know,
all you need to know is that anaconda thinks the macOS partition (which
it absolutely shouldn't do anything at all to) is something else
entirely, and tries to mount it and write stuff to it. Which means
that:

i) Fedora won't boot, because for Fedora to boot we need to find or
create a *real* macefi partition and write to it

ii) If the macOS partition could be mounted read-write we would
probably nuke your macOS install very badly, but fortunately, it almost
never will be (only if you'd explicitly disabled journalling on it for
some reason)
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Peter Robinson]

On Fri, Nov 11, 2016 at 12:55 PM, Josh Boyer  wrote:
> On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro  
> wrote:
>> My $0.02 is that none of the reasons we requested the blocker criterion
>> have changed. Dual boot with macOS is very important to attracting new
>> users -- we're explicitly targeting macOS users, that's the user group
>> where we think we have real potential for significant growth -- and I
>> continue to prefer we block the release indefinitely if it's not
>> working. We can't afford for our next Ars review to say "the installer
>> is broken, try again next year."
>
> Then we, as a project, need to back that up with sufficient hardware
> and test resources.  Otherwise it is nothing more than a wish and will
> continue to lead to problems like this.

And multi boot issues, which can be quite complex and nuanced, should
then I believe also be a beta blocker (or at least well tested in the
lead up to beta) to ensure issues get enough attention early enough in
the release so as to not block GA.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Stephen John Smoogen]

On 11 November 2016 at 13:23, Stephen Gallagher  wrote:

>> I still believe we should stick to a generic hostname by default,
>> (though I'd rather use "localhost" than "localhost.localdomain" in
>> order to drop the redhatism that "localdomain" is), and make the IPA
>> client-side enrollment code automatically update to a more "unique"
>> hostname if the hostname is found to be unset or be "localhost".
>>
>> I am also pretty sure that DHCP clients should suppress sending local
>> hostname information if the local hostname is unset or "localhost".
>>
>
>
> I realize that some of this is coming from my old-school sensibilities, but I
> still remember a time when changing the hostname of a running system caused 
> lots
> of things to fail, including NFS and sendmail.
>
> Changing the enrolling code to modify the machine's hostname would be very
> unexpected from an end-user perspective, don't you think?
>

Doesn't an AD environment do that though through group policies. I can
call my machine 'screw-the-boss' and after it gets registered into the
AD it becomes whatever the corporate policy says it will be
'windows-1138' [Or at least the place I had AD had something in their
system to do that so that students who thought that having hostnames
of curse words or worse couldn't keep them if they enrolled the system
into AD]

And yes certain things might fail because the hostname changes.. but
you restart them or reboot. We all like rebooting don't we :)?

>
>
>>> * I like Zbigniew and Lennart's thoughts on how to generate the "random" 
>>> suffix.
>>> the implementation I'd likely use is to take the first eight characters of 
>>> an
>>> md5 (or SHA) hash of /etc/machine-id and use those. That should make it both
>>> repeatable and unique.
>>
>> Please do not use MD5 anymore. And please calculate your ID as
>>
>>SHA(x || k)
>>
>
> See child reply. I was trying to spare us some entropy during early setup, 
> but I
> can't think of any reason this needs to be any more complicated than something
> fed from /dev/random if we aren't going to try to generate it early in the
> install process.

Just use /dev/urandom. If you use /dev/random then someone is going to
assume you meant it to be cryptographically secure and come up with a
method which is better.





-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Chris Adams]

Once upon a time, Andrew Lutomirski  said:
> NetworkManager already has the ability to randomize MAC addresses to keep
> them from leaking.

"has the ability" is not "on by default".  If you want that level of
anonymity, you have to turn it on.  Also then changing your hostname,
enabling an option to not send it, etc. is not a big deal (or could even
be part of a combined "anonymize me" checkbox).

This is about the default hostname; that configuration should be at the
same level as other default options.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Lennart Poettering]

On Fri, 11.11.16 13:23, Stephen Gallagher (sgall...@redhat.com) wrote:

> > I still believe we should stick to a generic hostname by default,
> > (though I'd rather use "localhost" than "localhost.localdomain" in
> > order to drop the redhatism that "localdomain" is), and make the IPA
> > client-side enrollment code automatically update to a more "unique"
> > hostname if the hostname is found to be unset or be "localhost".
> > 
> > I am also pretty sure that DHCP clients should suppress sending local
> > hostname information if the local hostname is unset or "localhost".
> 
> 
> I realize that some of this is coming from my old-school sensibilities, but I
> still remember a time when changing the hostname of a running system caused 
> lots
> of things to fail, including NFS and sendmail.

Well, we support changing hostnames dynamically through DHCP just fine
these days. The kernel has a proper API to be notified about hostname
changes these days (just poll() on /proc/sys/kernel/hostname), and
because of nss-myhostname it always stays resolvable, instantaneously
when you change it.

I am pretty sure most things should work just fine, at least in the
base OS. Sure, some higher level services might be broken still, but
I'd suggest to fix that instead of never changing the hostname...

> Changing the enrolling code to modify the machine's hostname would be very
> unexpected from an end-user perspective, don't you think?

I don't think so... I mean, enrollment is interactive anyway, no? it
could display a warning "your hostname is crap, will now change it for
you to xyz, unless you have something better which you can type in
here"... or so?

> See child reply. I was trying to spare us some entropy during early setup, 
> but I
> can't think of any reason this needs to be any more complicated than something
> fed from /dev/random if we aren't going to try to generate it early in the
> install process.

Well, deriving this from the machine ID automatically has the benefit
that you don't have to store your ID anywhere. And that's actually a
very important property if you want your stuff to work properly in
environments where systems are installed via disk images instead of
anaconda (which I'd claim is pretty often done in the wild these days,
and is the basic concept up container bundles after all): many
provisioning tools these days are smart enough to reset the machine ID
before deploying an image, but patching through all of them to also
reset the IPA ID is going to be hard (and honestly: I doubt this would
even be desirable).

I am pretty sure: if local services need unique IDs somewhere, then
please base them on /etc/machine-id, so that resetting the machine-id
will reset them too, and knowing the machine-id is enough to know all
app-specific IDs of the system too. However, never expose
/etc/machine-id as-is on any untrusted place, please always derive the
ID you use in a cryptographically secure way from it, which cannot be
reversed...

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Japheth Cleaver]

On 11/11/2016 9:08 AM, Lennart Poettering wrote:

I still believe we should stick to a generic hostname by default,
(though I'd rather use "localhost" than "localhost.localdomain" in
order to drop the redhatism that "localdomain" is), and make the IPA
client-side enrollment code automatically update to a more "unique"
hostname if the hostname is found to be unset or be "localhost".

I am also pretty sure that DHCP clients should suppress sending local
hostname information if the local hostname is unset or "localhost".


Given the text of RFC6761 
[https://tools.ietf.org/html/rfc6761#section-6.3], something like 
"fedora-XX.localhost" would also be an option, if we absolutely 
needed a domain component. ("localdomain." seems like a not-invisible 
number of root TLD lookups at http://stats.dns.icann.org/hedgehog/). But 
a simple "localhost" seems a sufficient default over this localdomain. 
redhatism.



On 11/11/2016 6:50 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Nov 11, 2016 at 12:13:48PM -, fred...@rambris.com wrote:

I like Fedora- for default hostname. If I don't care to set a hostname 
it would be an ok hostname for my machine. I would however like if the hostname 
setting would be more prominent in the installer. Possibly generating based on 
my name along the lines of:  fredriks-laptop.rambris.lan

Making the choice it more prominent is probably not necessary, if we
provide a nice default. Although it probably wouldn't hurt. The hostname
could be displayed in the summary or maybe the user creation dialogue
('Create user "user1@Fedora-123345"'?).


Anaconda having a distinct panel explicitly for setting the hostname, 
along with some knobs for setting the default, depending, for example, 
on if we've already gotten an IP during PXE, would be a good thing IMO.


Prompts and options would help with some kickstart situations, where one 
would like a chance to permanently specify it during install regardless 
of user accounts or install-time networking, and before we reboot for 
the first time.


-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Stephen Gallagher]

On 11/11/2016 12:08 PM, Lennart Poettering wrote:
> On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@redhat.com) wrote:
> 
>> The hostname may always be set manually and the result will (for the vast
>> majority of people) be unique within their environment. This means that if we
>> are concerned with hostname leakage being a privacy issue, we need to address
>> that at the leakage point, not at the hostname point.
>>
>> Also, there are cases where hostname leakage may be used specifically 
>> *because*
>> it may be unique, such as one of several cues to the DHCP server. 
>> Unfortunately,
>> we cannot know in advance whether a DHCP server is going to be on a trusted 
>> or
>> untrusted network (we might be able to guess from the SSID of a WiFI 
>> connection,
>> but those are remarkably easy to fake).
>>
>> In short, I really don't think that the hostname is the right place to solve
>> this problem. If transmission of individually-identifying information is a
>> concern, then we really have to solve it at the transmission points and not 
>> at
>> the source.
>>
>> Yes, an argument could be made that a user who sets her own hostname is
>> "opting-in" to that uniqueness, but I think that's setting an unrealistic
>> expectation on all of our users that they fully understand the consequences 
>> of
>> that action.
> 
> I still believe we should stick to a generic hostname by default,
> (though I'd rather use "localhost" than "localhost.localdomain" in
> order to drop the redhatism that "localdomain" is), and make the IPA
> client-side enrollment code automatically update to a more "unique"
> hostname if the hostname is found to be unset or be "localhost".
> 
> I am also pretty sure that DHCP clients should suppress sending local
> hostname information if the local hostname is unset or "localhost".
>


I realize that some of this is coming from my old-school sensibilities, but I
still remember a time when changing the hostname of a running system caused lots
of things to fail, including NFS and sendmail.

Changing the enrolling code to modify the machine's hostname would be very
unexpected from an end-user perspective, don't you think?



>> * I like Zbigniew and Lennart's thoughts on how to generate the "random" 
>> suffix.
>> the implementation I'd likely use is to take the first eight characters of an
>> md5 (or SHA) hash of /etc/machine-id and use those. That should make it both
>> repeatable and unique.
> 
> Please do not use MD5 anymore. And please calculate your ID as
> 
>SHA(x || k)
> 

See child reply. I was trying to spare us some entropy during early setup, but I
can't think of any reason this needs to be any more complicated than something
fed from /dev/random if we aren't going to try to generate it early in the
install process.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Stephen Gallagher]

On 11/11/2016 12:17 PM, Andrew Lutomirski wrote:
> /me dons crypto hat.
> 
> SHA(x || k) has three problems, one of which is bad enough to be an absolute
> showstopper.
> 
> 1. Specify *which* SHA.  SHA-1 should not be used for new applications.
> 
> 2. Concatenation without some additional property preventing collisions of the
> hashed data is problematic.  In particular, if you shorten x by a byte and
> prepend the same byte to k, you get the same output.  This is probably
> irrelevant for this particular use case, but it's still a sign that the
> construction is bad.
> 
> 3.  The SHA hashes, like all Merkle-Damgård hashes, is subject to
> length-extension attacks.  In particular, if x is a multiple (or slightly 
> above
> a multiple) of the block length, then anyone who learns SHA(x) can efficiently
> derive SHA(x || k).  This basically removes all security from this scheme.
> 
> HMAC(k, x) would be much better.
> 
> But I think this protocol is generally more fragile then needed.  How about
> generating a per-app-installation random value and HMAC-ing *that* with the
> machine id?


I think this is extreme overkill for something that doesn't need to be
cryptographically sound. It literally just needs to be eight characters with a
sensible random distribution. I considered using some non-reversible
transformation of machine-id for this simply because I wanted to avoid trying to
consume any of the entropy in /dev/random since we'd be doing this early in the
installer (when entropy tends to be at a premium). Maybe that was overkill and I
should just pull from /dev/random.

I can't think of a reason why we'd need a cryptographically secure
transformation just to generate a random hostname.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2016-11-04)

[Dominik 'Rathann' Mierzejewski]

On Friday, 11 November 2016 at 15:03, Parag Nemade wrote:
> On Fri, Nov 11, 2016 at 7:12 PM, Stephen Gallagher  
> wrote:
> > On 11/11/2016 08:38 AM, Jared K. Smith wrote:
> >>
> >> On Fri, Nov 4, 2016 at 12:14 PM, Jared K. Smith  >> > wrote:
> >>
> >> For the second week in a row, we didn't have enough FESCo members to 
> >> reach a
> >> quorum.  We'll push the agenda to next week's meeting.
> >>
> >> I won't be able to make today's meeting, and since we haven't had a quorum 
> >> for
> >> the last two weeks, we don't have a volunteer to run today's meeting.  
> >> I'll vote
> >> in the tickets from last week's agenda.
> >>
> >
> > I have a conflicting appointment during the meeting as well. I think I've
> > already voted in all of the tickets.
> 
> I think I can chair the meeting today. All other members please come
> at usual time 16:00 UTC that is 2 hours from now.
> We will have the same agenda that Jared posted in this thread.

I'm terribly sorry I missed the meeting. I somehow thought the time was
moved to 17:00 UTC just like the FPC meeting. With the DST change in
Europe two weeks ago, 16:00 UTC became less convenient for me.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Richard Johnson]

I'm very new to this but I'd like to help out.  I actually saw the problem a 
little while back, when I tried to mount an HFS+ FS onto my Fedora mac.  It 
mounted ro.  I would definitely be interested in helping out on "fedora on Mac" 
testing.  I'm currently looking through bugzilla to see if there's something on 
which I can help out.  Any other pointers to how to get involved more would be 
greatly appreciated.

/raj


> On Nov 11, 2016, at 8:46 AM, Stephen John Smoogen  wrote:
> 
> On 11 November 2016 at 03:20, Andreas Tunek  wrote:
>> 
>> 
>> As a mac owner (although one that is not very well supported by
>> Linux*) I really appreciate the fact that Fedora works. And saying you
>> do not want to support that hardware anymore just because you found a
>> regression/bug is kind of lame.
> 
> You are reading that wrong. The problem isn't that we don't want to
> support Mac hardware, we are finding we can't support Mac hardware to
> the level that it blocks a release because there are not enough people
> testing the hardware in a fashion that finds blocker level bugs.
> 
> This is where you and other Mac users can and MUST help out. Fedora is
> a stone soup. Unless people bring some amount of work to the pot, what
> they get out is water flavoured gravel.  You can bring the spice and
> aroma of a Mac hardware.. but if you don't then it doesn't mean that
> we can wait until someone else does.
> 
> -- 
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Andrew Lutomirski]

On Fri, Nov 11, 2016 at 8:47 AM, Chris Adams  wrote:

> Once upon a time, Stephen Gallagher  said:
> > The thread on Fedora Devel revealed some other issues which need to be
> > considered carefully. One of these is that of privacy: for example, the
> DHCP
> > client will send the machine's hostname as one of the cues to the DHCP
> server
> > for acquiring a lease. While this is fine on private networks, there's a
> valid
> > concern that this might be undesirable on a public hotspot.
>
> I manage several DHCP servers for service providers and public venues.
> While it is true that the client-provided hostname is logged, I would
> say it is of little value to someone trying to use that information (the
> number of "Jeff's iPhone" and such is very high).
>
> Also, if someone was trying to identify you from DHCP, they have your
> MAC address to tie everything together with (so they know if you have a
> Dell notebook or a Samsung tablet for example), and they can also narrow
> down OS and such by requested options or their absence (and that can
> start narrowing it down to releases as well).
>

> I think concerns about "leaking" a generated hostname are pretty
> minimal.  If someone is concerned about that, there are a number of
> other changes they'll probably be making, and they can set a non-default
> hostname in that process.
>

I thoroughly disagree.

NetworkManager already has the ability to randomize MAC addresses to keep
them from leaking.  DHCP options and such will, at most, identify your
distro and maybe some installed packages.  The fact that some
NetworkManager settings will leak the MAC address is *not* an excuse to
leak a hostname.  Privacy and security issues are never solved by saying
"well, there's already a problem, so let's add a new problem".

Right now, if you leave your hostname at the "localhost" default, randomize
your MAC, and route everything over a VPN, you're actually doing quite
well.  Let's not make it worse, please.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Andrew Lutomirski]

On Fri, Nov 11, 2016 at 9:08 AM, Lennart Poettering 
wrote:

> On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@redhat.com) wrote:
>
> > The hostname may always be set manually and the result will (for the vast
> > majority of people) be unique within their environment. This means that
> if we
> > are concerned with hostname leakage being a privacy issue, we need to
> address
> > that at the leakage point, not at the hostname point.
> >
> > Also, there are cases where hostname leakage may be used specifically
> *because*
> > it may be unique, such as one of several cues to the DHCP server.
> Unfortunately,
> > we cannot know in advance whether a DHCP server is going to be on a
> trusted or
> > untrusted network (we might be able to guess from the SSID of a WiFI
> connection,
> > but those are remarkably easy to fake).
> >
> > In short, I really don't think that the hostname is the right place to
> solve
> > this problem. If transmission of individually-identifying information is
> a
> > concern, then we really have to solve it at the transmission points and
> not at
> > the source.
> >
> > Yes, an argument could be made that a user who sets her own hostname is
> > "opting-in" to that uniqueness, but I think that's setting an unrealistic
> > expectation on all of our users that they fully understand the
> consequences of
> > that action.
>
> I still believe we should stick to a generic hostname by default,
> (though I'd rather use "localhost" than "localhost.localdomain" in
> order to drop the redhatism that "localdomain" is), and make the IPA
> client-side enrollment code automatically update to a more "unique"
> hostname if the hostname is found to be unset or be "localhost".
>
> I am also pretty sure that DHCP clients should suppress sending local
> hostname information if the local hostname is unset or "localhost".
>
> > * I like Zbigniew and Lennart's thoughts on how to generate the "random"
> suffix.
> > the implementation I'd likely use is to take the first eight characters
> of an
> > md5 (or SHA) hash of /etc/machine-id and use those. That should make it
> both
> > repeatable and unique.
>
> Please do not use MD5 anymore. And please calculate your ID as
>
>SHA(x || k)
>
> x refers to the machine id, "||" refers to concatenation and "k"
> refers to some app-specific key (which is OK to be publically
> known). It's important to concatenate the app-specific key, so that it
> is not possible to map the machine IDs used by one app to the machine
> IDs used by another..
>

/me dons crypto hat.

SHA(x || k) has three problems, one of which is bad enough to be an
absolute showstopper.

1. Specify *which* SHA.  SHA-1 should not be used for new applications.

2. Concatenation without some additional property preventing collisions of
the hashed data is problematic.  In particular, if you shorten x by a byte
and prepend the same byte to k, you get the same output.  This is probably
irrelevant for this particular use case, but it's still a sign that the
construction is bad.

3.  The SHA hashes, like all Merkle-Damgård hashes, is subject to
length-extension attacks.  In particular, if x is a multiple (or slightly
above a multiple) of the block length, then anyone who learns SHA(x) can
efficiently derive SHA(x || k).  This basically removes all security from
this scheme.

HMAC(k, x) would be much better.

But I think this protocol is generally more fragile then needed.  How about
generating a per-app-installation random value and HMAC-ing *that* with the
machine id?

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Lennart Poettering]

On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@redhat.com) wrote:

> The hostname may always be set manually and the result will (for the vast
> majority of people) be unique within their environment. This means that if we
> are concerned with hostname leakage being a privacy issue, we need to address
> that at the leakage point, not at the hostname point.
> 
> Also, there are cases where hostname leakage may be used specifically 
> *because*
> it may be unique, such as one of several cues to the DHCP server. 
> Unfortunately,
> we cannot know in advance whether a DHCP server is going to be on a trusted or
> untrusted network (we might be able to guess from the SSID of a WiFI 
> connection,
> but those are remarkably easy to fake).
> 
> In short, I really don't think that the hostname is the right place to solve
> this problem. If transmission of individually-identifying information is a
> concern, then we really have to solve it at the transmission points and not at
> the source.
> 
> Yes, an argument could be made that a user who sets her own hostname is
> "opting-in" to that uniqueness, but I think that's setting an unrealistic
> expectation on all of our users that they fully understand the consequences of
> that action.

I still believe we should stick to a generic hostname by default,
(though I'd rather use "localhost" than "localhost.localdomain" in
order to drop the redhatism that "localdomain" is), and make the IPA
client-side enrollment code automatically update to a more "unique"
hostname if the hostname is found to be unset or be "localhost".

I am also pretty sure that DHCP clients should suppress sending local
hostname information if the local hostname is unset or "localhost".

> * I like Zbigniew and Lennart's thoughts on how to generate the "random" 
> suffix.
> the implementation I'd likely use is to take the first eight characters of an
> md5 (or SHA) hash of /etc/machine-id and use those. That should make it both
> repeatable and unique.

Please do not use MD5 anymore. And please calculate your ID as

   SHA(x || k)

x refers to the machine id, "||" refers to concatenation and "k"
refers to some app-specific key (which is OK to be publically
known). It's important to concatenate the app-specific key, so that it
is not possible to map the machine IDs used by one app to the machine
IDs used by another..

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to do when you have a bundled library that has no upstream and you don't know the version?

[Orion Poplawski]

On 11/11/2016 08:59 AM, Randy Barlow wrote:

Hello Friends!

Igor and I were having a discussion on a package review ticket[0] about
how to handle a bundled library that seems to have no upstream that
either of us can find, and for which we don't know its version!

According to the packaging guidelines, it is OK to bundle the library
in certain circumstances, but the package must use Provides:
bundled() =  in the spec file.

Since we don't know the version, it's difficult to know what to do
here. Also, since we don't know the upstream, it would be difficult to
get the package packaged separately to do it the "nice" way.

What should we do? Is it OK to pass the review with just Provides:
bundled() in this edge case?


yes, that's fine.


--
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GitPython update blocked by rpkg - how can this be resolved?

[Barry]

> On 10 Nov 2016, at 14:07, Josh Boyer  wrote:
> 
>> On Thu, Nov 10, 2016 at 8:42 AM, Barry Scott  wrote:
>> In this bug
>> 
>>https://bugzilla.redhat.com/show_bug.cgi?id=1360797
>> 
>> It is implied that rpkg has an unspecified problem with GitPython 2.0.
>> 
>> This is preventing the maintainer from updating to the any GitPython 2
>> release.
>> 
>> I'd like to know if there is in fact a problem with rpkg with GitPython 2.0.
>> 
>> If there is a problem it would be nice if the rpkg people could comment on 
>> the
>> difficult of supporting GitPython 2. The python2.6 support question I suspect
>> can be handled by version checking in any conflicting code.
>> 
>> It seems wrong that rpkg is blocking updating to the latest GitPython,
>> preventing user of GitPython getting the bugs fixes and (as far as I am 
>> aware)
>> backwards compatible improvements.
> 
> Why does it seem wrong?

May be surprising is a better description.

> 
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GitPython update blocked by rpkg - how can this be resolved?

[Barry]

Barry

> On 10 Nov 2016, at 15:21, Chenxiong Qi  wrote:
> 
> 
> 
>> On 11/10/2016 09:42 PM, Barry Scott wrote:
>> In this bug
>> 
>>https://bugzilla.redhat.com/show_bug.cgi?id=1360797
>> 
>> It is implied that rpkg has an unspecified problem with GitPython 2.0.
>> 
>> This is preventing the maintainer from updating to the any GitPython 2
>> release.
>> 
>> I'd like to know if there is in fact a problem with rpkg with GitPython 2.0.
>> 
> 
> Import error here.
> 
>  File "/root/code/rpkg/pyrpkg/__init__.py", line 14, in 
>import git
>  File "/root/rpkg-env/lib/python2.6/site-packages/git/__init__.py", line 38, 
> in 
>from git.config import GitConfigParser  # @NoMove @IgnorePep8
>  File "/root/rpkg-env/lib/python2.6/site-packages/git/config.py", line 25, in 
> 
>from git.util import LockFile
>  File "/root/rpkg-env/lib/python2.6/site-packages/git/util.py", line 18, in 
> 
>from unittest.case import SkipTest
> ImportError: No module named case
> 
> GitPython >= 2 cannot work with Python 2.6 at all.

So on a system where you want to use rpkg with python 2.6 use GitPython 1.

But that is no reason to stop updating GitPython 2 for Fedora 24 where python 
2.7
Is used for rpkg right?

Barry


> 
>> If there is a problem it would be nice if the rpkg people could comment on 
>> the
>> difficult of supporting GitPython 2. The python2.6 support question I suspect
>> can be handled by version checking in any conflicting code.
>> 
>> It seems wrong that rpkg is blocking updating to the latest GitPython,
>> preventing user of GitPython getting the bugs fixes and (as far as I am 
>> aware)
>> backwards compatible improvements.
>> 
>> Barry
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> 
> 
> -- 
> Regards,
> Chenxiong Qi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Matthew Miller]

On Fri, Nov 11, 2016 at 10:47:47AM -0600, Chris Adams wrote:
> I think concerns about "leaking" a generated hostname are pretty
> minimal.  If someone is concerned about that, there are a number of
> other changes they'll probably be making, and they can set a non-default
> hostname in that process.

Continuing what Stephen Smoogen just said in another thread about "stone
soup", what I'd *really* like to see is people who are interested in
improving Fedora's network privacy footprint make a Remix — or even a
Spin with greater-than-usual modifications — with that as the goal.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Self Introduction: Tummala Dhanvi (c0mrad3)

[Tummala Dhanvi]

Hi guys,

I am Tummala Dhanvi (dhanvi is my given name) I go by the nick c0mrad3
in IRC. You might have noticed me lurking around the IRC channels.
More details about me can be found here[0]

I am currently trying to package python-pintail-asciidoc[1] and
rubygem-asciidoctor-mallard[2] so that the docs team can do move to
the newer tool-chain[3]

I need get sponsored to the packagers group to check in and build
these packages, I am looking foreword to join the team.

[0]fedoraproject.org/wiki/User:Dhanvi
[1]https://bugzilla.redhat.com/show_bug.cgi?id=1346060
[2]https://bugzilla.redhat.com/show_bug.cgi?id=1343977
[3]https://dhanvi1.wordpress.com/2016/06/23/example-of-newer-document-writing-for-fedora-docs/
-- 
Regards
Tummala Dhanvi

https://www.dhanvi.org
"Only thing that can never be 'RE-CYCLED' is 'WASTED TIME' ".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Chris Adams]

Once upon a time, Stephen Gallagher  said:
> The thread on Fedora Devel revealed some other issues which need to be
> considered carefully. One of these is that of privacy: for example, the DHCP
> client will send the machine's hostname as one of the cues to the DHCP server
> for acquiring a lease. While this is fine on private networks, there's a valid
> concern that this might be undesirable on a public hotspot.

I manage several DHCP servers for service providers and public venues.
While it is true that the client-provided hostname is logged, I would
say it is of little value to someone trying to use that information (the
number of "Jeff's iPhone" and such is very high).

Also, if someone was trying to identify you from DHCP, they have your
MAC address to tie everything together with (so they know if you have a
Dell notebook or a Samsung tablet for example), and they can also narrow
down OS and such by requested options or their absence (and that can
start narrowing it down to releases as well).

I think concerns about "leaking" a generated hostname are pretty
minimal.  If someone is concerned about that, there are a number of
other changes they'll probably be making, and they can set a non-default
hostname in that process.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 11 November 2016 at 03:20, Andreas Tunek  wrote:
>
>
> As a mac owner (although one that is not very well supported by
> Linux*) I really appreciate the fact that Fedora works. And saying you
> do not want to support that hardware anymore just because you found a
> regression/bug is kind of lame.

You are reading that wrong. The problem isn't that we don't want to
support Mac hardware, we are finding we can't support Mac hardware to
the level that it blocks a release because there are not enough people
testing the hardware in a fashion that finds blocker level bugs.

This is where you and other Mac users can and MUST help out. Fedora is
a stone soup. Unless people bring some amount of work to the pot, what
they get out is water flavoured gravel.  You can bring the spice and
aroma of a Mac hardware.. but if you don't then it doesn't mean that
we can wait until someone else does.

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

RFC (round 2): Change the default hostname for Fedora 26+

[Stephen Gallagher]

The original thread is getting rather long and I'd like to attempt to summarize
the discussion thus far and see if we can find a way forward from there.

First, some clarifications for preconditions that some people were unaware of
(either on this thread or the ones that popped up on other lists/forums):

1) Fedora has always allowed the hostname to be changed in Anaconda. It's
perhaps not in the most obvious of places (the networking spoke), but it's
there. It can also be set via kickstart, of course.

2) The default today is to use a name provided by the DHCP server if it offers a
name for that device, otherwise it will fall back to localhost.localdomain (the
common case for most personal networks).

3) My original proposal was: change the fallback name to Fedora- by
default, while of course retaining the ability to set it manually.

4) The specific issue relating to FreeIPA and Active Directory is one of
uniqueness: you can only have one machine named "localhost" enrolled in a
domain. A user who is unaware of the hostname at all will not know to change it
ahead of time.

The thread on Fedora Devel revealed some other issues which need to be
considered carefully. One of these is that of privacy: for example, the DHCP
client will send the machine's hostname as one of the cues to the DHCP server
for acquiring a lease. While this is fine on private networks, there's a valid
concern that this might be undesirable on a public hotspot. (This is only one
such example; there may be other places where the system transmits the 
hostname).

With machines commonly defaulting to localhost.localdomain, getting this
information tells the recipient little more than that a Fedora-derived machine
is connecting (since it's the only known ecosystem that uses this specific
default). However, the more unique we make the name, the easier it becomes to
isolate it to a single system (such as for tracking purposes). It is an open
question whether this is an actual problem to worry about or whether it's a drop
in the proverbial bucket.

It's also worth noting of course that any manually-chosen hostname will have
this same problem, which begs the question of whether it's worthwhile to do
anything about it at all. (Or perhaps that the focus should be on not leaking
the hostname itself elsewhere, regardless of how it was created).

I hope this frames the discussion better.






My thoughts from here:

The hostname may always be set manually and the result will (for the vast
majority of people) be unique within their environment. This means that if we
are concerned with hostname leakage being a privacy issue, we need to address
that at the leakage point, not at the hostname point.

Also, there are cases where hostname leakage may be used specifically *because*
it may be unique, such as one of several cues to the DHCP server. Unfortunately,
we cannot know in advance whether a DHCP server is going to be on a trusted or
untrusted network (we might be able to guess from the SSID of a WiFI connection,
but those are remarkably easy to fake).

In short, I really don't think that the hostname is the right place to solve
this problem. If transmission of individually-identifying information is a
concern, then we really have to solve it at the transmission points and not at
the source.

Yes, an argument could be made that a user who sets her own hostname is
"opting-in" to that uniqueness, but I think that's setting an unrealistic
expectation on all of our users that they fully understand the consequences of
that action.







Further, from a purely technical perspective, I think I've been swayed by
arguments around the generation of the hostname:

* I'm fine with the lowercase "fedora-" prefix. It makes sense since hostnames
are generally normalized to lower-case in common usage.

* I like Zbigniew and Lennart's thoughts on how to generate the "random" suffix.
the implementation I'd likely use is to take the first eight characters of an
md5 (or SHA) hash of /etc/machine-id and use those. That should make it both
repeatable and unique.



For Anaconda folks: would it be possible to have the currently-selected hostname
be visible next to the "Networking" spoke on the main hub page? You show the
selected environment group beside the "Software Selection" spoke and the
connected network device, so it might be useful to let people know what the
hostname is as well. (This would also be handy if it turns out that DHCP is
trying to assign a hostname; the user may not want or expect that)



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 08:33 -0500, Stephen Gallagher wrote:
> Just to address this specifically, I am referring to Apple's penchant for
> stuffing their machines with hardware from vendors that don't play well with
> open-source (for example, switching to wifi-only devices and shipping Broadcom
> chipsets with no open-source drivers). Then also playing games with their
> bootloader system so that we have to go through lots of hoops to trick it into
> letting us install.

The whole 'you're only allowed to use OS X in virtualization on top of
real OS X' thing is fairly actively hostile too.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

What to do when you have a bundled library that has no upstream and you don't know the version?

[Randy Barlow]

Hello Friends!

Igor and I were having a discussion on a package review ticket[0] about
how to handle a bundled library that seems to have no upstream that
either of us can find, and for which we don't know its version!

According to the packaging guidelines, it is OK to bundle the library
in certain circumstances, but the package must use Provides:
bundled() =  in the spec file.

Since we don't know the version, it's difficult to know what to do
here. Also, since we don't know the upstream, it would be difficult to
get the package packaged separately to do it the "nice" way.

What should we do? Is it OK to pass the review with just Provides:
bundled() in this edge case?


[0] https://bugzilla.redhat.com/show_bug.cgi?id=1382859
[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Du
plication_of_system_libraries

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 09:08 +, Fabio Alessandro Locati wrote:
> I think VM testing on Mac would not produce any more insights than VM
> testing on PC.

VM testing on PCs produces plenty of insights, it's how we do *most*
testing now. It's perfectly fine for testing bootloader stuff, for
instance, so long as the firmware used by the VM decently approximates
the behaviour of real system firmware (I don't know if that's the case
for 'approved' Apple virtualization things, admittedly).
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25-20161111.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/101 (x86_64), 1/17 (i386)

New failures (same test did not fail in 25-20161110.n.0):

ID: 47289   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/47289
ID: 47290   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/47290
ID: 47303   Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/47303

Old failures (same test failed in 25-20161110.n.0):

ID: 47301   Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/47301
ID: 47352   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/47352
ID: 47393   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/47393

Passed openQA tests: 96/101 (x86_64), 16/17 (i386), 2/2 (arm)

New passes (same test did not pass in 25-20161110.n.0):

ID: 47278   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/47278
ID: 47280   Test: x86_64 Workstation-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/47280
ID: 47281   Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/47281
ID: 47282   Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/47282
ID: 47283   Test: x86_64 Workstation-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/47283
ID: 47284   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/47284
ID: 47285   Test: x86_64 Workstation-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/47285
ID: 47286   Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/47286
ID: 47288   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/47288
ID: 47292   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/47292
ID: 47302   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/47302
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent call for testing: OS X dual boot

[White, Langdon]

Does this still need testing? I have a MacBook pro I could try it on.

Langdon

On Thu, Nov 10, 2016, 13:33 Mauricio Tavares  wrote:

> How old can the OSX box be? I have in a box an old Mac mini (Dual core
> and can only officially supported to 10.7) I have no issues to put to
> service.
>
> On Thu, Nov 10, 2016 at 11:05 AM, Adam Williamson
>  wrote:
> > Hi, folks! We've had an F25 blocker proposed for failure to install as
> > a dual boot with OS X:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1393846
> >
> > is there anyone who has an OS X system they can run this kind of test
> > on (i.e. one they don't mind getting messed up if something goes
> > wrong)? We would like more testing data so we can figure out if this is
> > a system-specific issue or if all OS X dual boot is broken.
> > --
> > 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
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 11, 2016 at 12:13:48PM -, fred...@rambris.com wrote:
> I like Fedora- for default hostname. If I don't care to set a 
> hostname it would be an ok hostname for my machine. I would however like if 
> the hostname setting would be more prominent in the installer. Possibly 
> generating based on my name along the lines of:  fredriks-laptop.rambris.lan

Those are two separate issues really:

Making the choice it more prominent is probably not necessary, if we
provide a nice default. Although it probably wouldn't hurt. The hostname
could be displayed in the summary or maybe the user creation dialogue
('Create user "user1@Fedora-123345"'?).

Generating the name from the user name matches what Windows does, but
it seems like a bigger privacy leak that the randomly generated
"Fedora" name. It'd probably be less unique globally, while being more
personally identifiable in small environments. This means that it
wouldn't solve the freeipa case. So "Fedora-XX" sounds like a better
tradeoff.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: File managers compete for desktop domination in F25

[Alexander Ploumistos]

On Fri, Nov 11, 2016 at 4:38 PM, Hans de Goede  wrote:
> Hmm, what happens if you remove ~/.config/autostart/org.kde.dolphin.desktop;
> or add OnlyShowIn=KDE there ?

No change.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: File managers compete for desktop domination in F25

[Hans de Goede]

Hi,

On 11-11-16 14:29, Alexander Ploumistos wrote:

On Fri, Nov 11, 2016 at 2:53 PM, Hans de Goede  wrote:

I remember seeing something similar a while back. To figure out what the
problem is, check all kde related files under /etc/xdg/autostart, they
should all have a: "OnlyShowIn=KDE;" in there, last time for me the
problem was one was missing this.


Hi Hans,

I did not have a dolphin desktop file in /etc/xdg/autostart, but for
good measure I copied my ~/.config/autostart/org.kde.dolphin.desktop
there, which already contained X-GNOME-Autostart-enabled=false and I


Hmm, what happens if you remove ~/.config/autostart/org.kde.dolphin.desktop;
or add OnlyShowIn=KDE there ?

Regards,

Hans




added OnlyShowIn=KDE (isn't that only to hide an application from a
DE's menus?), but dolphin still takes over on the desktop.

I think that there is a mix-up with dbus services, because when I open
a desktop folder I am seeing

dbus-daemon[1881]: [session uid=1000 pid=1881] Activating service
name='org.freedesktop.FileManager1' requested by ':1.70' (uid=1000
pid=2321 comm="nautilus-desktop "
label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
dbus-daemon[1881]: [session uid=1000 pid=1881] Successfully activated
service 'org.freedesktop.FileManager1'

whereas opening the same folder from the Places menu, I get:

dbus-daemon[1881]: [session uid=1000 pid=1881] Activating service
name='org.gnome.Nautilus' requested by ':1.36' (uid=1000 pid=2111
comm="/usr/bin/gnome-shell "
label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
dbus-daemon[1881]: [session uid=1000 pid=1881] Successfully activated
service 'org.gnome.Nautilus'

So, for some reason Nautilus != FileManager1 in dbus speak and I'm
guessing that's how nemo took over on the original reporter's system.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25 compose report: 20161111.n.0 changes

[Fedora Branched Report]

OLD: Fedora-25-20161110.n.0
NEW: Fedora-25-2016.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   7
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   109.45 MiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   19.18 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  fedora-release-notes-25.01-1.fc25
Old package:  fedora-release-notes-24.01-1.fc25
Summary:  Release Notes
RPMs: fedora-release-notes
Size: 379750 bytes
Size change:  82196 bytes
Changelog:
  * Tue Nov 08 2016 Nick Bebout <n...@fedoraproject.org> - 25.01-1
  - Update for F25


Package:  gtk3-3.22.2-2.fc25
Old package:  gtk3-3.22.2-1.fc25
Summary:  The GIMP ToolKit (GTK+), a library for creating GUIs for X
RPMs: gtk-update-icon-cache gtk3 gtk3-devel gtk3-devel-docs 
gtk3-immodule-xim gtk3-immodules gtk3-tests
Size: 41526760 bytes
Size change:  340 bytes
Changelog:
  * Tue Nov 08 2016 Matthias Clasen <mcla...@redhat.com> - 3.22.2-2
  - Fix #1376471


Package:  mutter-3.22.1-8.fc25
Old package:  mutter-3.22.1-6.fc25
Summary:  Window and compositing manager based on Clutter
RPMs: mutter mutter-devel mutter-tests
Size: 8423278 bytes
Size change:  2380 bytes
Changelog:
  * Mon Nov 07 2016 Rui Matos <rma...@redhat.com> - 3.22.1-7
  - Add upstream fix for mutter side of rhbz#1390607
Resolves: #1390607

  * Tue Nov 08 2016 Matthias Clasen <mcla...@redhat.com> 0 3.22.1-8
  - Add upstream patch for mutter size of rhbz#1376471


Package:  pacemaker-1.1.15-3.fc25
Old package:  pacemaker-1.1.15-2.fc25
Summary:  Scalable High-Availability cluster resource manager
RPMs: pacemaker pacemaker-cli pacemaker-cluster-libs pacemaker-cts 
pacemaker-doc pacemaker-libs pacemaker-libs-devel 
pacemaker-nagios-plugins-metadata pacemaker-remote
Size: 29581866 bytes
Size change:  20002048 bytes
Changelog:
  * Tue Jul 19 2016 Fedora Release Engineering 
<rel-...@lists.fedoraproject.org> - 1.1.15-2.1
  - 
https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Packages

  * Thu Nov 03 2016 Jan Pokorn?? <jpokorny+rpm-pacema...@redhat.com> - 1.1.15-3
  - Apply fix for CVE-2016-7035 (improper IPC guarding)


Package:  sddm-0.14.0-6.fc25
Old package:  sddm-0.14.0-1.fc25
Summary:  QML based X11 desktop manager
RPMs: sddm sddm-themes
Size: 4676480 bytes
Size change:  4428 bytes
Changelog:
  * Mon Oct 03 2016 Rex Dieter <rdie...@fedoraproject.org> - 0.14.0-2
  - make 02-fedora theme, fedora only

  * Mon Oct 03 2016 Rex Dieter <rdie...@fedoraproject.org> - 0.14.0-3
  - drop deps used for fedora-only theme

  * Fri Oct 07 2016 Rex Dieter <rdie...@fedoraproject.org> - 0.14.0-4
  - sddm.conf default: Current=01-breeze-fedora

  * Wed Nov 02 2016 Rex Dieter <rdie...@fedoraproject.org> - 0.14.0-5
  - pull in upstream fixes

  * Tue Nov 08 2016 Adam Williamson <awill...@redhat.com> - 0.14.0-6
  - backport PR #735 to fix RHBZ #1392654


Package:  selinux-policy-3.13.1-222.fc25
Old package:  selinux-policy-3.13.1-220.fc25
Summary:  SELinux policy configuration
RPMs: selinux-policy selinux-policy-devel selinux-policy-doc 
selinux-policy-minimum selinux-policy-mls selinux-policy-sandbox 
selinux-policy-targeted
Size: 30094294 bytes
Size change:  16820 bytes
Changelog:
  * Wed Nov 02 2016 Lukas Vrabec  <lvra...@redhat.com> - 3.13.1-222
  - Allow abrt_dump_oops_t to drop capabilities. bz(1391040)
  - Add named_t domain net_raw capability bz(1389240)
  - Allow geoclue to read system info. bz(1389320)
  - Make openfortivpn_t as init_deamon_domain. bz(1159899)
  - Allow nfsd domain to create nfsd_unit_file_t files. bz(1382487)
  - Merge branch 'rawhide-contrib' of github.com:fedora-selinux/selinux-policy 
into rawhide-contrib
  - Add interace lldpad_relabel_tmpfs
  - Merge pull request #155 from rhatdan/sandbox_nfs
  - Add pscsd_t wake_alarm capability2
  - Allow sandbox domains to mount fuse file systems
  - Add boolean to allow sandbox domains to mount nfs
  - Allow hypervvssd_t to read all dirs.
  - Allow isnsd_t to connect to isns_port_t
  - Merge branch 'rawhide-contrib' of github.com:fedora-selinux/selinux-policy 
into rawhide-contrib
  - Allow GlusterFS with RDMA transport to be started correctly. It requires 
ipc_lock capability together with rw permission on rdma_cm device.
  - Make tor_var_lib_t and tor_var_log_t as mountpoints.
  - Allow systemd-rfkill to write to /proc/kmsg bz(1388669)
  - Allow init_t to relabel /dev/shm/lldpad.state
  - Merge pull request #168 from rhatdan/docker
  - Label tcp 51954 as isns_port_

Re: Fedora on Macs, removing the release criterion

[Paul W. Frields]

On Fri, Nov 11, 2016 at 07:55:06AM -0500, Josh Boyer wrote:
> On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro  
> wrote:
> > My $0.02 is that none of the reasons we requested the blocker criterion
> > have changed. Dual boot with macOS is very important to attracting new
> > users -- we're explicitly targeting macOS users, that's the user group
> > where we think we have real potential for significant growth -- and I
> > continue to prefer we block the release indefinitely if it's not
> > working. We can't afford for our next Ars review to say "the installer
> > is broken, try again next year."
> 
> Then we, as a project, need to back that up with sufficient hardware
> and test resources.  Otherwise it is nothing more than a wish and will
> continue to lead to problems like this.

Adam W pinpointed an issue with "burner" Macs.  I have a MBP myself
that I treat as an appliance.  I use it for Pro Tools and my non-FOSS
related creative pursuits.  I'm well aware of Apple's tactics when it
comes to tight integration and OS/HW integrity.  I don't mess with it
at a low level, and don't test bare-metal installation on it (although
I do test the live OS from USB).

Also Michael pointed out something about a certain big company ;-)
needing to provide hardware for the QA team.  To the best of my
knowledge, that company doesn't have a stake in putting products on
e.g. Mac laptops.  This is a community project, so let's see how we
can handle this as a community, starting with the Workstation WG (as
opposed to QA).

That being said, I arranged to get an additional drive with some small
$$ available from said company.  I can use it to help with testing,
since I happen to have hardware.  My hope is other Workstation WG
members will join me.  Else we *do* look at removing criteria, not
just throw them over the wall and expect QA to deal with it.

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2016-11-11)

[Josh Boyer]

On Fri, Nov 11, 2016 at 9:14 AM, Parag Nemade  wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Friday at 16:00UTC in #fedora-meeting on
> irc.freenode.net.
>
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
>
> or run:
>   date -d '2016-11-11 16:00 UTC'
>
>
> Links to all issues below can be found at:
> https://pagure.io/fesco/report/meeting_agenda
>
> = Followups =
>
> none
>
> = New business =
> #topic #1641 F26 System Wide Change: Retire Synaptics Driver
> .fesco 1641
> https://pagure.io/fesco/issue/1641
>
> #topic #1637 F26 System Wide Change: AARCH64 - 48-bit VA
> .fesco 1637
> https://pagre.io/fesco/issue/1637
>
> #topic #1635 F26 Self Contained Changes
> .fesco 1635
> https://pagure.io/fesco/issue/1635
> #link https://fedoraproject.org/wiki/Changes/AnacondaBlivetGUI

I'll be missing the meeting.

I'd suggest counting votes in tickets and making progress that way.
None of these seem controversial at all, so they can likely all be
approved without a meeting.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Friday's FESCo Meeting (2016-11-11)

[Parag Nemade]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2016-11-11 16:00 UTC'


Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Followups =

none

= New business =
#topic #1641 F26 System Wide Change: Retire Synaptics Driver
.fesco 1641
https://pagure.io/fesco/issue/1641

#topic #1637 F26 System Wide Change: AARCH64 - 48-bit VA
.fesco 1637
https://pagre.io/fesco/issue/1637

#topic #1635 F26 Self Contained Changes
.fesco 1635
https://pagure.io/fesco/issue/1635
#link https://fedoraproject.org/wiki/Changes/AnacondaBlivetGUI


= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2016-11-04)

[Parag Nemade]

On Fri, Nov 11, 2016 at 7:12 PM, Stephen Gallagher  wrote:
> On 11/11/2016 08:38 AM, Jared K. Smith wrote:
>>
>> On Fri, Nov 4, 2016 at 12:14 PM, Jared K. Smith > > wrote:
>>
>> For the second week in a row, we didn't have enough FESCo members to 
>> reach a
>> quorum.  We'll push the agenda to next week's meeting.
>>
>>
>>
>> I won't be able to make today's meeting, and since we haven't had a quorum 
>> for
>> the last two weeks, we don't have a volunteer to run today's meeting.  I'll 
>> vote
>> in the tickets from last week's agenda.
>>
>
> I have a conflicting appointment during the meeting as well. I think I've
> already voted in all of the tickets.


I think I can chair the meeting today. All other members please come
at usual time 16:00 UTC that is 2 hours from now.
We will have the same agenda that Jared posted in this thread.

Regards,
Parag
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 613  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 375  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  94  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  78  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  20  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-03fb3c1531   
banshee-2.6.2-11.el7 dbus-sharp-0.7.0-15.el7 dbus-sharp-glib-0.5.0-13.el7 
gdata-sharp-1.4.0.2-18.el7 gio-sharp-0.3-14.el7 gkeyfile-sharp-0.1-19.el7 
gnome-sharp-2.24.2-12.el7 gtk-sharp-beans-2.14.0-17.el7 
gtk-sharp2-2.12.26-3.el7 gtk-sharp3-2.99.3-16.el7 gudev-sharp-0.1-18.el7 
libappindicator-12.10.0-11.el7 libgpod-0.8.3-14.el7 libyui-bindings-1.1.0-7.el7 
mono-4.2.4-7.el7 mono-addins-1.1-3.el7 mono-cecil-0.9.6-6.el7 
mono-zeroconf-0.9.0-16.el7 notify-sharp-0.4.0-0.26.20100411svn.el7 
notify-sharp3-3.0.3-2.el7 nunit-3.5-1.el7 nunit2-2.6.4-14.el7 pinta-1.6-5.el7 
taglib-sharp-2.1.0.0-3.el7
  20  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-181efcf9c4   
tre-0.8.0-18.20140228gitc2f5d13.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e26faf9489   
python-simplejson-3.5.3-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2fcbc39837   
chromium-54.0.2840.90-3.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-88e8651e7f   
mingw-gnutls-3.3.24-2.el7 mingw-nettle-3.3-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

dpm-dsi-1.9.10-2.el7
erlang-R16B-03.18.el7
fedfind-2.7.1-1.el7
fedmsg-0.18.0-1.el7
gfal2-2.12.3-1.el7
globus-authz-3.15-1.el7
globus-common-16.8-1.el7
globus-ftp-client-8.33-1.el7
globus-ftp-control-7.7-1.el7
globus-gass-cache-9.10-1.el7
globus-gass-copy-9.23-1.el7
globus-gatekeeper-10.12-1.el7
globus-gram-audit-4.6-1.el7
globus-gram-client-13.16-1.el7
globus-gram-client-tools-11.10-1.el7
globus-gram-job-manager-14.35-1.el7
globus-gram-job-manager-fork-2.6-1.el7
globus-gram-job-manager-scripts-6.9-1.el7
globus-gram-protocol-12.15-1.el7
globus-gridftp-server-11.8-1.el7
globus-gridmap-eppn-callout-1.13-1.el7
globus-gridmap-verify-myproxy-callout-2.9-1.el7
globus-gsi-callback-5.12-1.el7
globus-gsi-cert-utils-9.15-2.el7
globus-gsi-credential-7.11-1.el7
globus-gsi-openssl-error-3.7-1.el7
globus-gsi-proxy-core-8.6-1.el7
globus-gsi-proxy-ssl-5.10-1.el7
globus-gsi-sysconfig-6.11-1.el7
globus-gss-assist-10.20-1.el7
globus-gssapi-gsi-12.12-1.el7
globus-io-11.8-1.el7
globus-net-manager-0.16-1.el7
globus-openssl-module-4.8-1.el7
globus-proxy-utils-6.18-1.el7
globus-simple-ca-4.24-1.el7
globus-xio-5.14-1.el7
globus-xio-gridftp-driver-2.17-1.el7
globus-xio-udt-driver-1.25-1.el7
lynis-2.4.0-1.el7
php-horde-Horde-Mime-2.10.2-1.el7
php-horde-Horde-Service-Weather-2.5.1-1.el7
php-horde-nag-4.2.13-1.el7
php-udan11-sql-parser-3.4.12-1.el7
pulledpork-0.7.2-1.el7
python-assimulo-2.9-6.el7
python-crypto-2.6.1-10.el7
python-moksha-hub-1.4.8-1.el7
python-wikitcms-2.1.7-1.el7
python34-3.4.5-3.el7
qpid-proton-0.14.0-2.el7
relval-2.1.7-1.el7

Details about builds:



 dpm-dsi-1.9.10-2.el7 (FEDORA-EPEL-2016-630cd43f9a)
 Disk Pool Manager (DPM) plugin for the Globus GridFTP server

Update Information:

Globus Toolkit update.




 erlang-R16B-03.18.el7 (FEDORA-EPEL-2016-b1ea7893a7)
 General-purpose programming language and runtime environment

Update Information:

 - Respect -proto_dist switch while connecting to EPMD  - Cherry-picked fix for
OTP-13423. Mnesia transactions could hang while waitingon a response from a
node who had stopped. - Fix for doc generation with OpenJDK 1.8.0




 fedfind-2.7.1-1.el7 (FEDORA-EPEL-2016-50daa6738e)
 Fedora Finder finds Fedora

Update Information:

This update contains various fixes to fedfind, python-wikitcms and relval
related to how the GA milestone name for Fedora changed from 'Final' to 'RC'
with the switch to Pungi 4 (so, 

Re: Schedule for Friday's FESCo Meeting (2016-11-04)

[Stephen Gallagher]

On 11/11/2016 08:38 AM, Jared K. Smith wrote:
> 
> On Fri, Nov 4, 2016 at 12:14 PM, Jared K. Smith  > wrote:
> 
> For the second week in a row, we didn't have enough FESCo members to 
> reach a
> quorum.  We'll push the agenda to next week's meeting.
> 
> 
> 
> I won't be able to make today's meeting, and since we haven't had a quorum for
> the last two weeks, we don't have a volunteer to run today's meeting.  I'll 
> vote
> in the tickets from last week's agenda.
> 

I have a conflicting appointment during the meeting as well. I think I've
already voted in all of the tickets.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2016-11-04)

[Jared K. Smith]

On Fri, Nov 4, 2016 at 12:14 PM, Jared K. Smith 
wrote:

> For the second week in a row, we didn't have enough FESCo members to
> reach a quorum.  We'll push the agenda to next week's meeting.
>


I won't be able to make today's meeting, and since we haven't had a quorum
for the last two weeks, we don't have a volunteer to run today's meeting.
I'll vote in the tickets from last week's agenda.

-Jared
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

emacs patched for x2go on copr

[Neal Becker]

Many of us have experience that emacs cannot run under x2go.
https://bugzilla.redhat.com/show_bug.cgi?id=1349412

There is no actual fix, but we can't live without emacs, so I am putting up 
a version on copr which has a workaround (configure options).

It is named:
e.g., emacs-filesystem-25.1-2.x2go.fc24.noarch.rpm

I think this complies with naming conventions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: File managers compete for desktop domination in F25

[Alexander Ploumistos]

On Fri, Nov 11, 2016 at 3:20 PM, Rex Dieter  wrote:
> I'd expect mimetype default for inode/directory to handle this, and in f24
> at least, /usr/share/applications/mimeapps.list contains:
> inode/directory=org.gnome.Nautilus.desktop

It is. All mimeapps lists are as they should be and also:
$ xdg-mime query default inode/directory
org.gnome.Nautilus.desktop

xdg-open ~/Desktop or xdg-open ~Desktop/some/folder/ brings up nautilus.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen Gallagher]

On 11/10/2016 04:31 PM, Chris Murphy wrote:
> https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.log.html

 17:12:02  I've never understood why we would block on failures 
 to run on hardware that actively tries to make it difficult to run Linux 
 on.
> 
> Please elaborate on what this means. Specifically I have no idea what
> the word "actively" is referring to.
> 

Just to address this specifically, I am referring to Apple's penchant for
stuffing their machines with hardware from vendors that don't play well with
open-source (for example, switching to wifi-only devices and shipping Broadcom
chipsets with no open-source drivers). Then also playing games with their
bootloader system so that we have to go through lots of hoops to trick it into
letting us install.

Apple's entire business model is predicated on the idea that they know best and
you should only ever run software on their devices that they have provided to
you... at a substantial percentage for themselves. They do whatever they can at
a technical level to enable this.

(Note: I'm not attempting to vilify Apple here. Their devices are usually
sturdy, well-constructed and certainly attractive. They are however a company
trying to make money and they have a certain business model that is largely
dependent on *not* enabling us.)



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Matthew Miller]

On Thu, Nov 10, 2016 at 07:09:39PM -0800, Adam Williamson wrote:
> It's also worth noting that there's a possible scenario where we could
> completely nerf the OS X install here. It's a fairly *unlikely*
> scenario - the user would have to manually disable journalling on the
> macOS partition - but it is *possible*. For instance, they may have
> disabled it so they could write to the partition in Linux, for some
> reason, and then forgotten to re-enable it. So this bug, at least in
> that case, can be even worse than just 'Fedora doesn't boot'. It can be
> 'the Fedora installer ate my OS X kernel'.

Yeah -- that's what pushed me over the edge on this.

That and I'm not *super* keen on the practice of removing blocker
criteria whenever we hit them

> I don't really *like* the thing where we suddenly decide at the end of
> the release cycle that we don't like a criterion that *just happens* to
> be standing in the way of release after all, and magically say it's not
> a criterion any more. It's crappy process. But we have done it before

Yeah, that :)



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: File managers compete for desktop domination in F25

[Alexander Ploumistos]

On Fri, Nov 11, 2016 at 2:53 PM, Hans de Goede  wrote:
> I remember seeing something similar a while back. To figure out what the
> problem is, check all kde related files under /etc/xdg/autostart, they
> should all have a: "OnlyShowIn=KDE;" in there, last time for me the
> problem was one was missing this.

Hi Hans,

I did not have a dolphin desktop file in /etc/xdg/autostart, but for
good measure I copied my ~/.config/autostart/org.kde.dolphin.desktop
there, which already contained X-GNOME-Autostart-enabled=false and I
added OnlyShowIn=KDE (isn't that only to hide an application from a
DE's menus?), but dolphin still takes over on the desktop.

I think that there is a mix-up with dbus services, because when I open
a desktop folder I am seeing

dbus-daemon[1881]: [session uid=1000 pid=1881] Activating service
name='org.freedesktop.FileManager1' requested by ':1.70' (uid=1000
pid=2321 comm="nautilus-desktop "
label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
dbus-daemon[1881]: [session uid=1000 pid=1881] Successfully activated
service 'org.freedesktop.FileManager1'

whereas opening the same folder from the Places menu, I get:

dbus-daemon[1881]: [session uid=1000 pid=1881] Activating service
name='org.gnome.Nautilus' requested by ':1.36' (uid=1000 pid=2111
comm="/usr/bin/gnome-shell "
label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
dbus-daemon[1881]: [session uid=1000 pid=1881] Successfully activated
service 'org.gnome.Nautilus'

So, for some reason Nautilus != FileManager1 in dbus speak and I'm
guessing that's how nemo took over on the original reporter's system.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: File managers compete for desktop domination in F25

[Rex Dieter]

Alexander Ploumistos wrote:

> Hello all,
> 
> After upgrading a computer with multiple DEs to F25 from F23, folders
> on GNOME's desktop are managed by dolphin, which runs daemonized and
> cannot be killed, unless I also kill kded5 and kdeinit5. There was
> already a similar bug about nemo replacing nautilus on the desktop
> after a F24→F25 upgrade:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1384788
> 
> In both cases, our settings seem to be in order. Does anyone have any
> clue as to which component (e.g. nautilus, dbus, dolphin or whatever)
> might be causing this confusion?

I'd expect mimetype default for inode/directory to handle this, and in f24 
at least, /usr/share/applications/mimeapps.list contains:
inode/directory=org.gnome.Nautilus.desktop

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: time to retire some kde4/smoke-based language bindings?

[Rex Dieter]

Petr Pisar wrote:

> On 2016-11-09, Rex Dieter  wrote:
>> I was looking at rawhide (ppc64) broken deps, and was reminded of some
>> pretty old and unmaintained (upstream) kde4/smoke-based language bindings
>> (csharp, perl, ruby), affected packages include:
>>
>> kdebindings
>> kimono
>> perl-Qt
>> ruby-korundum
>> ruby-qt
>> smokeqt
>> smokekde
>> qyoto

> What are their replacements? I.e. how will users write Qt applications
> in C#, Perl, Ruby after removing those packages?

No replacements that I'm aware of.

Fact is, this is old/unsupported(by upstream) code... and offering to orphan 
them means anyone still interested in these can step in to keep them alive 
as new package maintainer(s).

-- rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: time to retire some kde4/smoke-based language bindings?

[Rex Dieter]

Peter Robinson wrote:

> On Wed, Nov 9, 2016 at 2:42 PM, Rex Dieter  wrote:
>> I was looking at rawhide (ppc64) broken deps, and was reminded of some
>> pretty old and unmaintained (upstream) kde4/smoke-based language bindings
>> (csharp, perl, ruby), affected packages include:
>>
>> kdebindings
>> kimono
>> perl-Qt
>> ruby-korundum
>> ruby-qt
>> smokeqt
>> smokekde
>> qyoto
>>
>> Of these, I can see *maybe* keeping perl-Qt (and dep smokeqt), primarily
>> because it is the only one in this list that's not a leaf package
>> (debconf- kde depends on it).
>>
>> Any comments or objection to orphaning these for f26+ ?
> 
> Is qt3 stuff going with them?

Not my call, kde-sig (for the most part) dropped support for qt3/kde3 stuff 
a few releases ago... it's maintained (mostly) by Kevin Kofler these days.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fwd: Re: [Fedora-packaging] Re: why the Group tag is obsolete ?]

[Rex Dieter]

Sérgio Basto wrote:

> On Ter, 2016-11-08 at 04:04 +0100, Kevin Kofler wrote:
>> PackageKit-yum
>> never used RPM groups, always comps
> 
> So, (if we want the package have a group ) all packages should be
> enumerated in comps, or not ? .

Yes (in comps)

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro  wrote:
> My $0.02 is that none of the reasons we requested the blocker criterion
> have changed. Dual boot with macOS is very important to attracting new
> users -- we're explicitly targeting macOS users, that's the user group
> where we think we have real potential for significant growth -- and I
> continue to prefer we block the release indefinitely if it's not
> working. We can't afford for our next Ars review to say "the installer
> is broken, try again next year."

Then we, as a project, need to back that up with sufficient hardware
and test resources.  Otherwise it is nothing more than a wish and will
continue to lead to problems like this.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: File managers compete for desktop domination in F25

[Hans de Goede]

Hi,

On 11-11-16 13:32, Alexander Ploumistos wrote:

Hello all,

After upgrading a computer with multiple DEs to F25 from F23, folders
on GNOME's desktop are managed by dolphin, which runs daemonized and
cannot be killed, unless I also kill kded5 and kdeinit5. There was
already a similar bug about nemo replacing nautilus on the desktop
after a F24→F25 upgrade:

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

In both cases, our settings seem to be in order. Does anyone have any
clue as to which component (e.g. nautilus, dbus, dolphin or whatever)
might be causing this confusion?


I remember seeing something similar a while back. To figure out what the
problem is, check all kde related files under /etc/xdg/autostart, they
should all have a: "OnlyShowIn=KDE;" in there, last time for me the
problem was one was missing this.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Michael Catanzaro]

My $0.02 is that none of the reasons we requested the blocker criterion
have changed. Dual boot with macOS is very important to attracting new
users -- we're explicitly targeting macOS users, that's the user group
where we think we have real potential for significant growth -- and I
continue to prefer we block the release indefinitely if it's not
working. We can't afford for our next Ars review to say "the installer
is broken, try again next year."

On Fri, 2016-11-11 at 00:34 -0800, Adam Williamson wrote:
> We could, I suppose, try to get a few Mac users to look into testing
> in
> VMs on their Macs. But beyond that we need people with 'burner' Macs,
> and there aren't very many of them. We (Fedora QA) have just one old
> Mac Mini.

You work for a multibillion dollar corporation where the QA team cannot
afford to buy a laptop?

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

File managers compete for desktop domination in F25

[Alexander Ploumistos]

Hello all,

After upgrading a computer with multiple DEs to F25 from F23, folders
on GNOME's desktop are managed by dolphin, which runs daemonized and
cannot be killed, unless I also kill kded5 and kdeinit5. There was
already a similar bug about nemo replacing nautilus on the desktop
after a F24→F25 upgrade:

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

In both cases, our settings seem to be in order. Does anyone have any
clue as to which component (e.g. nautilus, dbus, dolphin or whatever)
might be causing this confusion?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[fredrik]

> For as long as I can recall, Fedora has shipped with a default hostname of
> "localhost.localdomain"[1]. This default was "safe" for a very long
> time because
> we also shipped an /etc/hosts entry that routed this hostname to the loopback
> device for the benefit of some older system services (like sendmail).
> 
> However, having the default be the same on all systems introduces other
> problems, notably with regards to acting as a client to FreeIPA or Active
> Directory domain controllers.
> 
> When enrolling with one of these DCs, the machine's current hostname (up to 
> the
> first dot) is used to uniquely identify the machine into the domain. If the
> machine's hostname is not unique in that domain, the enrollment will either 
> fail
> or the machine will take over that name (depending on the server-side
> implementation). Neither case is likely to be what the user intended.
> 
> 
> Some information on competing platforms:
> 
> Windows deals with this on for its systems by assigning all new machines a
> random hostname of the form WIN-XXX (that's a strict count of 11 
> random
> characters of either capital letters or decimal numerals after the WIN- 
> prefix).
> This is because there is a 15-character maximum limit on the machine-name in
> Active Directory, after which it is simply truncated (which is a bad behavior,
> but one we have to deal with).
> 
> Mac OS X and Ubuntu both require the user to pick a machine name at install 
> time
> explicitly. They do not autogenerate one at all.
> 
> SUSE generates a random name of the format linux-XX (I'm not sure how many
> random characters).
> 
> 
> My proposal is that we should consider changing the default hostname for 
> Fedora
> 26 to be either FED-XXX or FEDORA-. The former allows for a
> longer random string and therefore lower risk of collision in large
> environments, while the latter would also provide improved branding for
> Fedora[2]. Our default BASH shell prompt includes the current machine's 
> hostname.
> 
> 
> Thoughts on how to generate these random strings are of course up for
> discussion. Given that initial machine creation may have limited available
> entropy, we may want to avoid just calling out to /dev/random. Dusty Mabe
> suggested in on IRC that one option might be to use either the first or last
> 8/11 characters from /etc/machine-id, since presumably those would be
> sufficiently random.
> 
> 
> 
> 
> [1] Unless there is a DHCP-assigned hostname, in which case it will use that.
> 
> [2] There is an ongoing discussion on the desktop@ list about how to subtly
> brand the Workstation Edition such that when people are using it or showing it
> to others, it is clear that it is *Fedora* as opposed to any other GNOME
> distribution.

I like Fedora- for default hostname. If I don't care to set a hostname 
it would be an ok hostname for my machine. I would however like if the hostname 
setting would be more prominent in the installer. Possibly generating based on 
my name along the lines of:  fredriks-laptop.rambris.lan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Peter Robinson]

>> > On Fri, Nov 11, 2016 at 12:34:20AM -0800, Adam Williamson wrote:
>> >> One thing I forgot to mention in my original reply to jwb (it was
>> >> getting long) is that there's a conundrum that applies quite
>> >> specifically to Mac support, and it's this: there are quite a lot of
>> >> people who want to run Fedora on Macs (seemingly, at least) but very
>> >> few in a position to test installs for new releases.
>> >
>> > Hi,
>> >
>> > I think this is a big problem.
>> > If we have a "class" of users that have special needs (aka: very
>> > specific hardware/software/bios/...) and they never tests things, I see
>> > this more as their problem than other people problem.
>>
>> I see it as everyone's problem. A bad user experience for an entire
>> class of users is not good for the project as a whole. I don't see the
>> them and us
>
> Hi,
>
> I see the "them and us" only in the sense that the people outside that
> class can not perform testing and therefore the number of tester is very
> limited.
> Same can apply to other kind of setup that have very specific hardware
> compatibilities (ie: secondary arch).

I think you mean Alternate Architectures. We have primary and
secondary release artifacts which can be any architecture including
x86_64.

> Obviously if a company wants to test and support this actively can do so,
> but imho this burden should not be on the wider community.

Often those companies also bring a broad set of resources that benefit
the rest of the community on x86_64 as much, or often even more than
the benefit they get. You might not be aware but the alternate
architectures and their associated "companies" contribute a lot of
resources (both human and other) to Fedora to improve it as a whole.
Like everything else in a community it's give and take.

>> I generally haven't seen that trend. The mac users I know often keep
>> their devices as long as they are usable as they cost so much or they
>> upgrade every time there's a new model and sell the old one ASAP to
>> recoup some of the costs. For corp use this is often different but
>> then it is with all laptops.
>
> This is true. Often Mac users that upgrade frequently sell their old Macs,
> while this is less common in the PC world.
>
> Best,
> Fale
> --
> Fabio Alessandro Locati
> Red Hat - Senior Consultant
>
> PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Fabio Alessandro Locati]

On Fri, Nov 11, 2016 at 10:23:34AM +, Peter Robinson wrote:
> On Fri, Nov 11, 2016 at 9:08 AM, Fabio Alessandro Locati
>  wrote:
> > On Fri, Nov 11, 2016 at 12:34:20AM -0800, Adam Williamson wrote:
> >> One thing I forgot to mention in my original reply to jwb (it was
> >> getting long) is that there's a conundrum that applies quite
> >> specifically to Mac support, and it's this: there are quite a lot of
> >> people who want to run Fedora on Macs (seemingly, at least) but very
> >> few in a position to test installs for new releases.
> >
> > Hi,
> >
> > I think this is a big problem.
> > If we have a "class" of users that have special needs (aka: very
> > specific hardware/software/bios/...) and they never tests things, I see
> > this more as their problem than other people problem.
> 
> I see it as everyone's problem. A bad user experience for an entire
> class of users is not good for the project as a whole. I don't see the
> them and us

Hi,

I see the "them and us" only in the sense that the people outside that
class can not perform testing and therefore the number of tester is very
limited.
Same can apply to other kind of setup that have very specific hardware
compatibilities (ie: secondary arch).
Obviously if a company wants to test and support this actively can do so,
but imho this burden should not be on the wider community.
 
> I generally haven't seen that trend. The mac users I know often keep
> their devices as long as they are usable as they cost so much or they
> upgrade every time there's a new model and sell the old one ASAP to
> recoup some of the costs. For corp use this is often different but
> then it is with all laptops.

This is true. Often Mac users that upgrade frequently sell their old Macs,
while this is less common in the PC world.

Best,
Fale
-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 System Wide Change: GHC 8.0

[Jan Kurik]

= Proposed System Wide Change: GHC 8.0 =
https://fedoraproject.org/wiki/Changes/GHC_8.0

Change owner(s):
* Jens Petersen 
* Haskell_SIG

Update the GHC Haskell compiler in Fedora from version 7.10 to the
current stable version 8.0, with much improved support for aarch64,
ppc64, and ppc64le.


== Detailed Description ==
GHC 8.0 contains many new features, fixes, and improvements including
performance. Other distros are already moving to it and Fedora users
will benefit from it too. This will require updating some and
rebuilding all of the Haskell packages in Fedora.


== Scope ==
* Proposal owners: all building work will be done in f26-ghc

* Other developers: Negligible work outside Haskell SIG, but the SIG
can try to help resolve any issues which should arise.

* Release engineering: f26-ghc needs to be created and once all
rebuilding there is completed the builds need to be tagged into f26

* List of deliverables: mostly just version bumps

* Policies and guidelines: no Haskell Packaging changes currently
planned (except possibly explicit `%files` lists)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Peter Robinson]

On Fri, Nov 11, 2016 at 9:08 AM, Fabio Alessandro Locati
 wrote:
> On Fri, Nov 11, 2016 at 12:34:20AM -0800, Adam Williamson wrote:
>> One thing I forgot to mention in my original reply to jwb (it was
>> getting long) is that there's a conundrum that applies quite
>> specifically to Mac support, and it's this: there are quite a lot of
>> people who want to run Fedora on Macs (seemingly, at least) but very
>> few in a position to test installs for new releases.
>
> Hi,
>
> I think this is a big problem.
> If we have a "class" of users that have special needs (aka: very
> specific hardware/software/bios/...) and they never tests things, I see
> this more as their problem than other people problem.

I see it as everyone's problem. A bad user experience for an entire
class of users is not good for the project as a whole. I don't see the
them and us

>> The reason is pretty simple: very few people have a disposable Mac.
>> About 90% of the time, the Mac people want to install Fedora on is
>> their personal laptop. So of course they're not willing to test
>> installing some random pre-Beta nightly snapshot and tell us if
>> everything explodes. We also can't i) easily or ii) legally (AFAIK)
>> install OS X into a VM on non-Apple hardware for testing.
>
> I don't see why people should not have a disposable Macs but is "normal"
> to have a disposable PC.

Cost, they're not the cheapest in the world, and often people just
don't need a disposable device

> Also, AFAIK, Mac users tend to substitute their machines more often than
> PC users (at least statistically speaking), so many of them should have
> a 2-3 years old machine laying around.

I generally haven't seen that trend. The mac users I know often keep
their devices as long as they are usable as they cost so much or they
upgrade every time there's a new model and sell the old one ASAP to
recoup some of the costs. For corp use this is often different but
then it is with all laptops.

>> We could, I suppose, try to get a few Mac users to look into testing in
>> VMs on their Macs. But beyond that we need people with 'burner' Macs,
>> and there aren't very many of them. We (Fedora QA) have just one old
>> Mac Mini.
>
> I think VM testing on Mac would not produce any more insights than VM
> testing on PC.

Well running a VM on a Mac allows you to also run OSX virtually which
means you could easily and legally do dual OS testing without a
dedicated device.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 System Wide Change: GHC 8.0

[Jan Kurik]

= Proposed System Wide Change: GHC 8.0 =
https://fedoraproject.org/wiki/Changes/GHC_8.0

Change owner(s):
* Jens Petersen 
* Haskell_SIG

Update the GHC Haskell compiler in Fedora from version 7.10 to the
current stable version 8.0, with much improved support for aarch64,
ppc64, and ppc64le.


== Detailed Description ==
GHC 8.0 contains many new features, fixes, and improvements including
performance. Other distros are already moving to it and Fedora users
will benefit from it too. This will require updating some and
rebuilding all of the Haskell packages in Fedora.


== Scope ==
* Proposal owners: all building work will be done in f26-ghc

* Other developers: Negligible work outside Haskell SIG, but the SIG
can try to help resolve any issues which should arise.

* Release engineering: f26-ghc needs to be created and once all
rebuilding there is completed the builds need to be tagged into f26

* List of deliverables: mostly just version bumps

* Policies and guidelines: no Haskell Packaging changes currently
planned (except possibly explicit `%files` lists)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 491  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 485  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 417  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 375  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 347  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
  78  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a886ace670   
tomcat-7.0.72-1.el6
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cb5398893b   
nodejs-0.10.48-3.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e69bdefcde   
pdns-3.3.3-2.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-dc75157b92   
ansible-2.2.0.0-3.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

dpm-dsi-1.9.10-2.el6
fedfind-2.7.1-1.el6
gfal2-2.12.3-1.el6
globus-authz-3.15-1.el6
globus-common-16.8-1.el6
globus-ftp-client-8.33-1.el6
globus-ftp-control-7.7-1.el6
globus-gass-cache-9.10-1.el6
globus-gass-copy-9.23-1.el6
globus-gatekeeper-10.12-1.el6
globus-gram-audit-4.6-1.el6
globus-gram-client-13.16-1.el6
globus-gram-client-tools-11.10-1.el6
globus-gram-job-manager-14.35-1.el6
globus-gram-job-manager-fork-2.6-1.el6
globus-gram-job-manager-scripts-6.9-1.el6
globus-gram-protocol-12.15-1.el6
globus-gridftp-server-11.8-1.el6
globus-gridmap-eppn-callout-1.13-1.el6
globus-gridmap-verify-myproxy-callout-2.9-1.el6
globus-gsi-callback-5.12-1.el6
globus-gsi-cert-utils-9.15-2.el6
globus-gsi-credential-7.11-1.el6
globus-gsi-openssl-error-3.7-1.el6
globus-gsi-proxy-core-8.6-1.el6
globus-gsi-proxy-ssl-5.10-1.el6
globus-gsi-sysconfig-6.11-1.el6
globus-gss-assist-10.20-1.el6
globus-gssapi-gsi-12.12-1.el6
globus-io-11.8-1.el6
globus-net-manager-0.16-1.el6
globus-openssl-module-4.8-1.el6
globus-proxy-utils-6.18-1.el6
globus-simple-ca-4.24-1.el6
globus-xio-5.14-1.el6
globus-xio-gridftp-driver-2.17-1.el6
globus-xio-udt-driver-1.25-1.el6
lynis-2.4.0-1.el6
php-horde-Horde-Mime-2.10.2-1.el6
php-horde-Horde-Service-Weather-2.5.1-1.el6
php-horde-nag-4.2.13-1.el6
pulledpork-0.7.2-1.el6
qpid-proton-0.14.0-2.el6

Details about builds:



 dpm-dsi-1.9.10-2.el6 (FEDORA-EPEL-2016-b409621b84)
 Disk Pool Manager (DPM) plugin for the Globus GridFTP server

Update Information:

Globus Toolkit update.




 fedfind-2.7.1-1.el6 (FEDORA-EPEL-2016-820fb39bb8)
 Fedora Finder finds Fedora

Update Information:

This update contains various fixes to fedfind, python-wikitcms and relval
related to how the GA milestone name for Fedora changed from 'Final' to 'RC'
with the switch to Pungi 4 (so, for Fedora 24 onwards). This had various
consequences mainly for all the CLIs; all the automated stuff tends to use
compose IDs and labels which mostly weren't affected by this, but the CLIs all
had issues with it. `fedfind images` could not find RC composes, `relval size-
check` could not check image sizes for them, `relval report-results` could not
report results for an RC compose besides the auto-detected current one, etc.
The update also contains a couple of other fixes for `relval size-check`: it now
properly catches the case where it couldn't find any images for a variant, and
it includes the arch in the comment for oversized images (so we can tell which
image is actually oversize when the same image exists for multiple arches).




 gfal2-2.12.3-1.el6 (FEDORA-EPEL-2016-ae65d079a4)
 Grid file access library 2.0

Update Information:

New upstream release 2.12.3




 globus-authz-3.15-1.el6 (FEDORA-EPEL-2016-b409621b84)
 Globus Toolkit - Globus authz library

Update Information:

Globus Toolkit update.

[EPEL-devel] Fedora EPEL 5 updates-testing report

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 732  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 375  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 347  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5


The following builds have been pushed to Fedora EPEL 5 updates-testing

dpm-dsi-1.9.10-2.el5
gfal2-2.12.3-1.el5
globus-authz-3.15-1.el5
globus-common-16.8-1.el5
globus-ftp-client-8.33-1.el5
globus-ftp-control-7.7-1.el5
globus-gass-cache-9.10-1.el5
globus-gass-copy-9.23-1.el5
globus-gatekeeper-10.12-1.el5
globus-gram-audit-4.6-1.el5
globus-gram-client-13.16-1.el5
globus-gram-client-tools-11.10-1.el5
globus-gram-job-manager-14.35-1.el5
globus-gram-job-manager-fork-2.6-1.el5
globus-gram-job-manager-scripts-6.9-1.el5
globus-gram-protocol-12.15-1.el5
globus-gridftp-server-11.8-1.el5
globus-gridmap-eppn-callout-1.13-1.el5
globus-gridmap-verify-myproxy-callout-2.9-1.el5
globus-gsi-callback-5.12-1.el5
globus-gsi-cert-utils-9.15-2.el5
globus-gsi-credential-7.11-1.el5
globus-gsi-openssl-error-3.7-1.el5
globus-gsi-proxy-core-8.6-1.el5
globus-gsi-proxy-ssl-5.10-1.el5
globus-gsi-sysconfig-6.11-1.el5
globus-gss-assist-10.20-1.el5
globus-gssapi-gsi-12.12-1.el5
globus-io-11.8-1.el5
globus-net-manager-0.16-1.el5
globus-openssl-module-4.8-1.el5
globus-proxy-utils-6.18-1.el5
globus-simple-ca-4.24-1.el5
globus-xio-5.14-1.el5
globus-xio-gridftp-driver-2.17-1.el5

Details about builds:



 dpm-dsi-1.9.10-2.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Disk Pool Manager (DPM) plugin for the Globus GridFTP server

Update Information:

Globus Toolkit update.




 gfal2-2.12.3-1.el5 (FEDORA-EPEL-2016-3e91b202df)
 Grid file access library 2.0

Update Information:

New upstream release 2.12.3




 globus-authz-3.15-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Globus authz library

Update Information:

Globus Toolkit update.




 globus-common-16.8-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Common Library

Update Information:

Globus Toolkit update.




 globus-ftp-client-8.33-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - GridFTP Client Library

Update Information:

Globus Toolkit update.




 globus-ftp-control-7.7-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - GridFTP Control Library

Update Information:

Globus Toolkit update.




 globus-gass-cache-9.10-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Globus Gass Cache

Update Information:

Globus Toolkit update.




 globus-gass-copy-9.23-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Globus Gass Copy

Update Information:

Globus Toolkit update.




 globus-gatekeeper-10.12-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Globus Gatekeeper

pkgdb_updater updated: description of perl-XML-LibXML-Devel-SetLineNumber

[notifications]

pkgdb_updater updated: description of perl-XML-LibXML-Devel-SetLineNumber

https://admin.fedoraproject.org/pkgdb/package/perl-XML-LibXML-Devel-SetLineNumber/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of perl-DBICx-AutoDoc

[notifications]

pkgdb_updater updated: description of perl-DBICx-AutoDoc
https://admin.fedoraproject.org/pkgdb/package/perl-DBICx-AutoDoc/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of perl-Parallel-Pipes

[notifications]

pkgdb_updater updated: description of perl-Parallel-Pipes
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of perl-Safe-Isa

[notifications]

pkgdb_updater updated: description of perl-Safe-Isa
https://admin.fedoraproject.org/pkgdb/package/perl-Safe-Isa/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of perl-Geo-Distance

[notifications]

pkgdb_updater updated: description of perl-Geo-Distance
https://admin.fedoraproject.org/pkgdb/package/perl-Geo-Distance/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description, upstream_url of perl-HTTP-Entity-Parser

[notifications]

pkgdb_updater updated: description, upstream_url of perl-HTTP-Entity-Parser
https://admin.fedoraproject.org/pkgdb/package/perl-HTTP-Entity-Parser/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of perl-Module-Install-DOAP

[notifications]

pkgdb_updater updated: description of perl-Module-Install-DOAP
https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-DOAP/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Fabio Alessandro Locati]

On Fri, Nov 11, 2016 at 12:34:20AM -0800, Adam Williamson wrote:
> One thing I forgot to mention in my original reply to jwb (it was
> getting long) is that there's a conundrum that applies quite
> specifically to Mac support, and it's this: there are quite a lot of
> people who want to run Fedora on Macs (seemingly, at least) but very
> few in a position to test installs for new releases.

Hi,

I think this is a big problem.
If we have a "class" of users that have special needs (aka: very
specific hardware/software/bios/...) and they never tests things, I see
this more as their problem than other people problem.
 
> The reason is pretty simple: very few people have a disposable Mac.
> About 90% of the time, the Mac people want to install Fedora on is
> their personal laptop. So of course they're not willing to test
> installing some random pre-Beta nightly snapshot and tell us if
> everything explodes. We also can't i) easily or ii) legally (AFAIK)
> install OS X into a VM on non-Apple hardware for testing.

I don't see why people should not have a disposable Macs but is "normal"
to have a disposable PC.
Also, AFAIK, Mac users tend to substitute their machines more often than
PC users (at least statistically speaking), so many of them should have
a 2-3 years old machine laying around.
 
> We could, I suppose, try to get a few Mac users to look into testing in
> VMs on their Macs. But beyond that we need people with 'burner' Macs,
> and there aren't very many of them. We (Fedora QA) have just one old
> Mac Mini.

I think VM testing on Mac would not produce any more insights than VM
testing on PC.

Best,
Fale
-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Fabio Alessandro Locati]

On Fri, Nov 11, 2016 at 09:20:08AM +0100, Andreas Tunek wrote:
> As a mac owner (although one that is not very well supported by
> Linux*) I really appreciate the fact that Fedora works. And saying you
> do not want to support that hardware anymore just because you found a
> regression/bug is kind of lame.

Hi,

No one is saying that we should not support Macs, only that if Mac
support is broken, this should not block a whole release.

Best,
Fale
-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 09:20 +0100, Andreas Tunek wrote:
> 
> As a mac owner (although one that is not very well supported by
> Linux*) I really appreciate the fact that Fedora works. And saying you
> do not want to support that hardware anymore just because you found a
> regression/bug is kind of lame.
> 
> Of course, if the people who are doing the work decide that they do
> not want to support installing to a mac anymore, that is perfectly OK.
> But I do not think you should make that decision a week before
> release.

One thing I forgot to mention in my original reply to jwb (it was
getting long) is that there's a conundrum that applies quite
specifically to Mac support, and it's this: there are quite a lot of
people who want to run Fedora on Macs (seemingly, at least) but very
few in a position to test installs for new releases.

The reason is pretty simple: very few people have a disposable Mac.
About 90% of the time, the Mac people want to install Fedora on is
their personal laptop. So of course they're not willing to test
installing some random pre-Beta nightly snapshot and tell us if
everything explodes. We also can't i) easily or ii) legally (AFAIK)
install OS X into a VM on non-Apple hardware for testing.

We could, I suppose, try to get a few Mac users to look into testing in
VMs on their Macs. But beyond that we need people with 'burner' Macs,
and there aren't very many of them. We (Fedora QA) have just one old
Mac Mini.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-11 4:09 GMT+01:00 Adam Williamson :
> On Thu, 2016-11-10 at 21:44 -0500, Josh Boyer wrote:
>> On Thu, Nov 10, 2016 at 5:09 PM, Adam Williamson
>>  wrote:
>> > On Thu, 2016-11-10 at 13:31 -0800, Chris Murphy wrote:
>> > > https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.log.html
>> > >
>> > > > > > 17:10:26  i can't really vote -1 on this under the current 
>> > > > > > criteria unless someone tries on a newer mac and it works. but 
>> > > > > > given 
>> > > > > > https://www.happyassassin.net/testcase_stats/25/Installation/QA_Testcase_dualboot_with_OSX_Miscellaneous.html
>> > > > > >  , i am entirely open to dropping the criterion on the basis of 
>> > > > > > failure to test.
>> > >
>> > >
>> > > I think it's specious to drop the criterion on this basis. There are
>> > > plenty of other things that don't get tested and their criterion don't
>> > > get dropped.
>> >
>> > I am actually planning to propose precisely this.
>>
>> My sincere apologies for not being in the meeting.  I could not attend
>> due to a conflict with a different meeting.
>>
>> I am somewhat befuddled at the decision to block the entire release
>> for this issue.  We seem to have created a criteria under the premise
>> that "lots of people have Macs and want to run Linux/Fedora on them",
>> yet our empirical data seems to have shown a distinct lack of testing
>> that would bear that premise out.
>
> The premise under which the criterion was created was basically
> that "the Workstation technical specification included it". Here's the
> whole paper trail for the criterion:
>
> Workstation tech spec - 
> https://fedoraproject.org/wiki/Workstation/Technical_Specification :
>
> "One aspect of storage configuration that will be needed is support for
> dual-boot setups (preserving preexisting Windows or OS X
> installations), since e.g. students may be required to run software on
> those platforms for their coursework."
>
> This led to:
>
> desktop@ discussion - 
> https://lists.fedoraproject.org/pipermail/desktop/2014-June/009932.html :
>
> "1a. Does preserve preexisting include providing a working menu entry
> in the boot manager (e.g. in the GRUB menu)?
> 1b. Or is it sufficient to just preserve the installation data —
> meaning it's permissible for its bootability to be either non-obvious
> or broken?"
>
> Excursions and alarums, etc. etc. followed, till eventually mcatanzaro
> posted a...
>
> test@ list proposal - 
> https://lists.fedoraproject.org/pipermail/test/2014-August/122496.html :
>
> "Since our Mac support is very poor and has no prospect of near term
> improvement -- in particular, we have concerns that running Fedora on a
> Mac has caused at least one Mac to overheat and die -- the consensus
> seems to be that dual booting with OS X should not be a requirement."
>
> There was an initial wording proposal, some more discussion, and then I
> posted a...
>
> final proposal - 
> https://lists.fedoraproject.org/pipermail/test/2014-September/123012.html :
>
> "The installer must be able to install into free space alongside an
> existing OS X installation, install and configure a bootloader that will
> boot Fedora; if the boot menu presents OS X entries, they should boot OS
> X."
>
> which is the wording that remains. Note that it specifically does not
> require that OS X keeps working, but it *does* require that the Fedora
> installation actually boots.
>
>> I agree 100% that lots of people have Macs.  I agree in part that
>> people want to run Linux/Fedora on them.  I agree that a subset of
>> those that want to run Linux on a Mac also want to dual-boot OS X.
>> What I cannot get my head around though is how we've essentially made
>> a decision based on perceived marketing value of those target users at
>> the expense of every other platform we support.  Our engineering and
>> testing resources are clearly not sufficient to cover this case.  If
>> they are, then we have a fairly large communication problem
>> illustrated here.  Or if that wasn't the reason, and it was simply
>> "because we have a criteria written down" that also seems somewhat
>> myopic.
>
> It's important to note that we may not have the full story on testing
> here. At the meeting I said that no-one had tested this throughout the
> cycle; this was based on the fact that no-one has filled out a result
> for the test in the wiki pages throughout the cycle. However, since the
> meeting, Chris Murphy has said in the bug that he *has* tested dual
> boot install during the Fedora 25 cycle and found that it worked.
>
> Given my analysis of the bug I find that a bit surprising, but I can
> see (I think) one possible scenario in which the install might possibly
> work (if there was an existing Fedora install on the system). So that
> might be what happened there.
>
> Anyway, point is, we *do* have some testing resources. However, I do
> mean to try and