Re: iphone mount in nautilus on Fedora 24

[Bastien Nocera]

- Original Message -
> On Tue, 2016-10-11 at 09:52 -0400, Bastien Nocera wrote:
> > 
> > 
> > - Original Message -
> > > 
> > > 
> > > > 
> > > > 
> > > > - Original Message -
> > > > 
> > > > Yup. The "normal" mount contains nothing that normal users
> > > > should access.
> > > > Accessing the photos will leave ghosts on the device, and there
> > > > have been
> > > > no
> > > > ways to update the music database in Linux for a few iOS
> > > > releases.
> > > 
> > > I very much doubt that anyone would release any code to touch an
> > > idevice
> > > music database due to fear of
> > > legal action from the manufacturer. It may exist already.
> > > 
> > > The ability to sync contacts, calendars and events, meeting info,
> > > notes,
> > > pictures etc ( anything that would be considered the personal data
> > > entered
> > > by the idevice owner is another matter entirely. Anything that the
> > > law
> > > provides in most countries such as the IP to that person or the
> > > copyright of
> > > documents or photos etc, and yes it can be a very grey area
> > > between the laws
> > > in different countries. This is just the other side of the coin
> > > but this
> > > time from the owners perspective and legal rights.
> > 
> > What Linux applications support syncing those contacts? Are you sure
> > they actually
> > require the mounted filesystem?
> 
> These do not need the exposure of the mounted filesystem in nautilus.

Not sure that's worth mentioning in this thread then.

> 
> This is more to do about developing applications for linux
> to access the idevice that about iOS development on Fedora
> Workstation but it may just help this also.

Again, you don't need access to that particular filesystem to use sbmanager,
or sync contacts. Maybe we'll get to that use case at some point.

> > 
> > 
> > > 
> > > 
> > > While nautilus still exposes the pictures on an idevice
> > > through  gphoto2
> > > system does not seem to have changed.
> > 
> > I can't parse that.
> > 
> > > 
> > > 
> > > As far as I am aware it is possible to copy pictures from the
> > > idevice but
> > > transfers of pictures to the idevice will succeed, but will not be
> > > shown on
> > > the idevice by native apps without further hacking.
> 
> This is only because a camera roll management needs implementation to
> parse the file format.
> > 
> > 
> > So it doesn't work. Sure you could use, and you can still use, the
> > partition
> > as storage. But I don't see the point in doing that.
> 
> And it will stay that way if we do not allow developers easy access to
> these area on the idevice. So everyone looses.

It's still there, it's just not mounted by default.


> Actually it is not unrelated at all as supports the subject of the
> email.
> 
> 
> The fact that a properties dialogue is not available in nautilus
> in the side bar is a problem as it stops any user from displaying the
> extra properties of a idevice using the mentioned extension.

But that's not related to the disabling of the "main" partition mount.

> > > https://bugzilla.gnome.org/show_bug.cgi?id=741302
> > > 
> > > https://git.gnome.org/browse/nautilus-ideviceinfo/log/?ofs=100
> > > 
> > > http://blog.sukimashita.com/2015/01/09/gtk-3-support-for-nautilus-
> > > ideviceinfo/
> > > 
> > > I hope this can  be resolved in the short term as it provides all
> > > users of
> > > idevices with info that is expected today and further benefits
> > > the foss community and the goals of Fedora, Gnome and downstream
> > > distributions etc.
> > 
> > Showing all the possible partitions doesn't help anyone, that I can
> > see. Explain
> > how the data on that partition is useful to the large majority of
> > iOS/Linux users,
> > and we can investigate.
> The data from the idevice partition is useful for a developer not for
> a regular user.
> 
> 
> As I have explained above about the properties dialogue is not
> available for a mounted idevice means that all user cannot
> get this info easily without writing an application to get
> it.
> This info is convenient to know for all users.
> 
> It is available for other usb connected devices why not an idevice.

That's a different bug.

We're pretty much in agreement that the main partition we used to show for iOS
devices doesn't have any uses beyond fiddling with the internals of the device,
and that it would be nice if the nautilus properties tab could be made to work
again.

Let's continue the discussion about that last one in the bug.

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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 01:23 +0100, David Woodhouse wrote:
> On Mon, 2016-10-10 at 16:29 +0200, Tomas Mraz wrote:
> > 
> > 
> > We will work on porting the dependent packages to the new API. If
> > by
> > some reasonable deadline there are still some packages that are not
> > dead by other reasons and we are unable to port them we can add
> > -devel
> > to the compat package. Note though that small changes in such
> > packages
> > will be needed anyway as the include files of the compat package
> > will
> > have to be in non-default include directory. (If the package
> > doesn't
> > use pkgconfig to find the needed CFLAGS automatically.)
> Even if it uses pkgconfig, it's still going to need to look for
> openssl102.pc or whatever we call it, because just 'openssl' is going
> to get it OpenSSL 1.1.
> 
> And if we *are* going to ship a separate -devel package for 1.0.2 and
> 1.1 in parallel we are *really* going to need to make sure that
> *neither* of them live in /usr/include/openssl/ where they can be
> picked up by default.

I am against moving 1.1 into separate /usr/include. If we ship the
compat-openssl10-devel I will make it conflict with 1.1.0 openssl-
devel. Of course that won't allow compiling things against both
versions but that is something we do not want to allow anyway.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
> On Tue, 2016-10-11 at 16:46 +, Petr Pisar wrote:
> > 
> > On 2016-10-11, Remi Collet  wrote:
> > > 
> > > 
> > > It doesn't seem possible to use a compat library (else we will
> > > very
> > > probably going to encounter issues is both library versions are
> > > used in
> > > the same process, because of the numerous libraries linked to PHP
> > > or its
> > > extensions)
> > > 
> > That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
> > while the ported code build and passed all tests when built against
> > old
> > OpenSSL, it crashed when linked to the new OpenSSL. The reason
> > there
> > was another Perl package loaded into the process that was linked to
> > the old OpenSSL.
> Was the load using dlopen() or simply an indirect link?

Also what I would expect to crash is situation where the perl modules
linked to different OpenSSL versions try to pass the references to
OpenSSL data structures across the versions. That certainly won't work.

On the other hand the scenario where one library linked by an
application uses OpenSSL 1.1 for TLS and another library uses OpenSSL
1.0 for SHA256 hashing, should work - at least it worked for me when I
tested it.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Petr Pisar]

On 2016-10-12, Tomas Mraz  wrote:
> On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
>> Was the load using dlopen() or simply an indirect link?
>
Both Perl modules were dlopened. Each of the module linked to
different OpenSSL directly (DT_NEEDED).

> Also what I would expect to crash is situation where the perl modules
> linked to different OpenSSL versions try to pass the references to
> OpenSSL data structures across the versions. That certainly won't work.
>
Yes. It passed pointers to BIGNUM and EC_KEY between them.

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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Vít Ondruch]

Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
> On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
>> Tomas Mraz wrote:
>>> At worst if the patching of a package is highly non-trivial and the
>>> upstream is not responsive we might have to drop the package from
>>> Fedora.
>>>
>>> We do not want to keep 1.0.2 devel around as that could make it to
>>> look
>>> like the 1.0.2 is still fully "supported" in Fedora and there would
>>> be
>>> no incentive to switch to 1.1.0. Also to get any new features from
>>> upstream OpenSSL we have to move to newer versions as they are
>>> released
>>> as the old versions get only bug fixes.
>> IMHO, this is not acceptable. If the API of a library changes enough
>> to 
>> warrant a compat package, you have to provide the -devel for the
>> compat 
>> package as well. Dropping all the packages that don't build against
>> the new 
>> incompatible version from Fedora is not a reasonable plan.
> We will work on porting the dependent packages to the new API. If by
> some reasonable deadline there are still some packages that are not
> dead by other reasons and we are unable to port them we can add -devel
> to the compat package. Note though that small changes in such packages
> will be needed anyway as the include files of the compat package will
> have to be in non-default include directory. (If the package doesn't
> use pkgconfig to find the needed CFLAGS automatically.)
>

But what about stable versions of libraries applications? For example,
in current Rawhide, you won't be able to build any stable Ruby version
downloaded as tarball without the compat-openssl-devel. And it is
question, if upstream will be able to backport the OpenSSL 1.1.0 support
into stable Ruby versions [1]. Not mentioning all the older Ruby
versions which are unsupported, but up until now, you could build them
on your own (actually it should be possible to disable the OpenSSL
support, but that is not common scenario).

I personally don't care much about this scenario, but I am pretty sure
that others might care more 


Vít



[1] https://bugs.ruby-lang.org/issues/12830#note-2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Jan Kurik]

On Tue, Oct 11, 2016 at 3:51 PM, Matthew Miller
 wrote:
> On Tue, Oct 11, 2016 at 03:29:37PM +0200, Jan Kurik wrote:
>> very low. Just for an information: on Fedora we have every week
>> created approx. 400 - 500 new bugs. I can not imagine doing review of
>> such an amount of bugs on (bi-)weekly basic. Blocker bug meeting
>
> Oh my no. We wouldn't review all bugs, just ones which are nominated,
> and I am envisioning being quite strict with whether they meet the
> criterion I suggested:
>
>Issues eligible for this status would be those which do not
>necessarily fail a release criterion but which have critical impact
>on a Fedora Edition or on a council-approved Fedora Objective.
>
> with a possible additional:
>
>   Issues may also be nominated from the Common Bugs list when they are
>   deemed by QA to have critical impact.
>
> or something like that. If it becomes necessary, we could even restrict
> nominations to those submitted by QA, the Edition WGs, or Objective
> leads — but I'd rather start less formal and introduce that rule if it
> becomes a problem.

Thinking of it ... lets start to think of a process/policy how this
should work, to find possible frictions:


=Nomination=
- Anyone can propose a bug as "Important". In case the number of
nominated bugs will go over a limit we will be able to proceed during
the approval process, we will limit the nomination possibility to a
defined group of people.
- The proposal will be done by a modified application QE currently use
for Blocker bugs.
- The bug is assigned to a tracker collecting the nominated bugs.

=Approval=
- There will be (bi-)weekly meetings of a group of people doing a
review of nominated bugs and granting approvals.
- The group will be namely defined and needs quorum to approve a bug
as "Important".
- On the meeting, all the nominated bugs for the given period of time
need to be reviewed. The review process might end up with the
following statues:
- - Approved: the bug is approved as "Important" and it moves from the
nomination tracker to tracker for "Important" bugs
- - Rejected: the bug has not been approved as "Important" and will be
removed from the nomination tracker
- - Postponed: the decision has not been made (i.e.: need more info).
The bug stays on the nomination tracker till the next meeting

=Enforcement=
- After every Approval meeting a wiki page with approved "Important"
bugs will be generated (refreshed), to get people information what is
important to fix.
- We might integrate this bug list into
http://whatcanidoforfedora.org/ page, so new comers can start to help
in the area we consider as important
- We might publish some stats in regular blogposts on
https://communityblog.fedoraproject.org/ to have some overview which
area/component needs an attention
- We can grant badges once a developer fixes certain amount of
"Important" bugs (something like
https://badges.fedoraproject.org/badge/if-you-build-it...-koji-success-iii
)


@Matt: does it reflect your thoughts ?

@All: does any one think this activity is meaningful ? If so, do you
have any better proposal or would like to add something to the
proposal above ?


Regards,
Jan

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



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

F26 System Wide Change: AARCH64 - 48-bit VA

[Jan Kurik]

= Proposed System Wide Change: AARCH64 - 48-bit VA =
https://fedoraproject.org/wiki/Changes/aarch64-48bitVA


Change owner(s):
* Jeremy Linton < jeremy DOT linton AT arm DOT com >

Enable 48bit VA on AARCH64


== Detailed Description ==
The current aarch64 kernel is using a 42-bit process virtual address
(VA) space and due to the way aarch64 paging works this limits the max
physical address as well. This is fairly limiting for some
applications, but aarch64 processors also have support for 48-bit
VA's. This is actually 1-bit more than the "47-bit" VA's currently
used on x86_64. This change is a fairly minor kernel configuration but
it has caused problems with mozjs and luajit based projects because
they have stored tags in their pointers in the 48th address bit. The
upstream mozjs project has been fixed, and there are a set of changes
outstanding for luajit. Futher there, have been patches applied to
rawhide to support it (bug #1242326, bug #1375305. bug #1375547), but
the packages dependent on js185 require a rebuild due to an ABI
change.


== Scope ==
* Proposal owners:
The kernel config needs to be changed, and the core mozjs/luajit
tagging problems need to be resolved. This can either take the form of
patching the remaining mozjs packages that have not yet been patched
and rebuilding the affected js185 packages, or it can take the form of
moving dependent packages onto mozjs versions that have been patched.
Futher lua needs to either be updated to the latest mainline or the
critical patches need to be applied to the lua versions currently in
use.

* Release engineering:
Release engineering needs to assure the js185 packages are rebuilt.
Peter Robinson has volunteered to assist in this.

* Policies and guidelines: N/A

* 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

Re: RISC-V struggle (for GMP porting)

[Richard W.M. Jones]

On Wed, Oct 12, 2016 at 12:18:50AM +0200, Torbjörn Granlund wrote:
> PS. Does RISC-V have some sort of wait-for-interrupt instruction?  I
> mean, an instruction suitable for the kernel idle loop which waits for
> interrupt, allowing hardware and simulators to save energy.  If not, one
> should be proposed to the UCB folks.

The current privspec 1.9 (draft):

https://content.riscv.org/wp-content/uploads/2016/07/riscv-privileged-v1.9-1.pdf

defines a WFI instruction, literally Wait For Interrupt (section 3.2.2).

However IIRC the reason qemu-system-riscv busy-waits is nothing to do
with this, it's because the interim device model is a big hack.  Soon
to be replaced with virtio, we are all hoping.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 08:21 +, Petr Pisar wrote:
> On 2016-10-12, Tomas Mraz  wrote:
> > 
> > On St, 2016-10-12 at 08:22 +0200, Nikos Mavrogiannopoulos wrote:
> > > 
> > > Was the load using dlopen() or simply an indirect link?
> Both Perl modules were dlopened. Each of the module linked to
> different OpenSSL directly (DT_NEEDED).
> 
> > 
> > Also what I would expect to crash is situation where the perl
> > modules
> > linked to different OpenSSL versions try to pass the references to
> > OpenSSL data structures across the versions. That certainly won't
> > work.
> > 
> Yes. It passed pointers to BIGNUM and EC_KEY between them.

Now that surely won't work. But it should not be common scenario except
for language bindings where various modules using openssl are in
separate packages. I do not know if there are any other such languages
than perl. Usually all the bindings are in a single package or at worst
there are two packages - one for libcrypto bindings and one for libssl.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 10:28 +0200, Vít Ondruch wrote:
> 
> Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
> > 
> > On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
> > > 
> > > Tomas Mraz wrote:
> > > > 
> > > > At worst if the patching of a package is highly non-trivial and
> > > > the
> > > > upstream is not responsive we might have to drop the package
> > > > from
> > > > Fedora.
> > > > 
> > > > We do not want to keep 1.0.2 devel around as that could make it
> > > > to
> > > > look
> > > > like the 1.0.2 is still fully "supported" in Fedora and there
> > > > would
> > > > be
> > > > no incentive to switch to 1.1.0. Also to get any new features
> > > > from
> > > > upstream OpenSSL we have to move to newer versions as they are
> > > > released
> > > > as the old versions get only bug fixes.
> > > IMHO, this is not acceptable. If the API of a library changes
> > > enough
> > > to 
> > > warrant a compat package, you have to provide the -devel for the
> > > compat 
> > > package as well. Dropping all the packages that don't build
> > > against
> > > the new 
> > > incompatible version from Fedora is not a reasonable plan.
> > We will work on porting the dependent packages to the new API. If
> > by
> > some reasonable deadline there are still some packages that are not
> > dead by other reasons and we are unable to port them we can add
> > -devel
> > to the compat package. Note though that small changes in such
> > packages
> > will be needed anyway as the include files of the compat package
> > will
> > have to be in non-default include directory. (If the package
> > doesn't
> > use pkgconfig to find the needed CFLAGS automatically.)
> > 
> But what about stable versions of libraries applications? For
> example,
> in current Rawhide, you won't be able to build any stable Ruby
> version
> downloaded as tarball without the compat-openssl-devel. And it is
> question, if upstream will be able to backport the OpenSSL 1.1.0
> support
> into stable Ruby versions [1]. Not mentioning all the older Ruby
> versions which are unsupported, but up until now, you could build
> them
> on your own (actually it should be possible to disable the OpenSSL
> support, but that is not common scenario).
> 
> I personally don't care much about this scenario, but I am pretty
> sure
> that others might care more 

Yes, I am getting more and more inclined to ship compat-openssl10-
devel. However I will make it conflicting with openssl-devel and its
use for Fedora packages should be strongly discouraged.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Ralf Senderek]

I think your proposal is useful, and it should be tested how far it'll get us.

There's one more thing I'd like to be included. If approved, the bug should
be categorized with respect to its impact on Fedora based on the discussion
that led to its approval as "important". I think it would help to know why it is
seen as important and what is at stake if it isn't fixed.

This info should be visible on the web page to help focussing the efforts to 
those
bugs which may have the most impact.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 11, 2016 at 8:39 PM, Chris Murphy 
wrote:

> On Tue, Oct 11, 2016 at 6:33 PM, Gerald B. Cox  wrote:
> > On Tue, Oct 11, 2016 at 4:48 PM, Chris Murphy 
> > wrote:
>
> >
> > That may be, but all the articles I read suggested "be afraid, be very
> > afraid".
> > In addition, https://goo.gl/V2IyFq
> > basically just comes out and says, not to use it.
>
> That's stale and overstated but I'm fine with dire warnings because
> otherwise people use experimental stuff and flip out when it face
> plants. What's needed are people who can tediously gather an autopsy
> report so it can be made better. And that's pretty much what's
> happening.
>
> Well that link is from their wiki.  Then of course there is this thread
which
kind of steps through it all:  https://goo.gl/rIyJ0R
One of my favorite quotes:

"Wow. So it sees the data strip corruption, uses good parity on disk to

fix it, writes the fix to disk, recomputes parity for some reason but
does it wrongly, and then overwrites good parity with bad parity?
That's fucked."



> About the Fedora default, this recently came up on desktop@ so I'll
> just refer to that:
> https://lists.fedoraproject.org/archives/list/desktop@
> lists.fedoraproject.org/message/T6FNLLPJ7LICKSVTTPS4KSIDHOKUUPNC/


Yeah, and there was also this thread:  https://goo.gl/wWHLVA
Like I said, I believe that ship has pretty much sailed...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 11, 2016 at 8:52 PM, Chris Murphy 
wrote:

>
> About the rewrite comment: that did not come from a developer, and is
> definitely overstated. In any case, rewrites are not inherently bad
> news, there's a bunch of OpenZFS videos from last yearss summit in
> which the developers talk about various things being completely
> rewritten from scratch, some things more than twice. So kinda par for
> the course, and given enough time things get rewritten anyway. XFS has
> had substantial changes over its history including numerous on disk
> format changes even before it found its way onto Linux.


Could be, should be, may be... that's fine - but it all says the same
thing... they
don't know how much time it is going to take to fix - and who knows what
their
priority is to get around to it.  The advantages over what already is
available
don't appear to be that compelling, especially when weighed with the risks.


When all this started I did some searches and found Kent Overstreet's page
on
bcachefs:  https://goo.gl/U0UFfN

He had some words about the different filesystems - and had this to say
about btrfs:

btrfs, which was supposed to be Linux's next generation COW filesystem -
Linux's answer to zfs. Unfortunately, too much code was written too quickly
without focusing on getting the core design correct first, and now it has
too many design mistakes baked into the on disk format and an enormous,
messy codebase - bigger that xfs. It's taken far too long to stabilize as
well - poisoning the well for future filesystems because too many people
were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs
multiple times and had to switch at the last minute, and server vendors who
years ago hoped to one day roll out btrfs are now quietly migrating to xfs
instead).

Then there is this quote:
https://www.youtube.com/watch?v=79fvDDPaIoY&t=18m28s
"Software that is
designed/ intended to be reliable should not go through large periods of
instability only to be written off as "prepubescence"."
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Kamil Dudka]

On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote:
> Hi all,
> 
> the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will
> be also 1.0.2 compat package (compat-openssl10) so the dependencies are
> not broken and Rawhide should be installable. Also things that do not
> depend on openssl should be rebuildable without changes.
> 
> On the other hand due to the major API changes in 1.1.0 if your package
> uses OpenSSL it will not be possible to rebuild it without patching.
> Some upstreams already updated their code to work with 1.1.0 so if it
> is your case again there might not be any problems rebuilding it.

Is there any migration guide regarding the API changes introduced in 1.1.0?

Kamil

> I will be also working on patching and rebuilding the dependencies
> starting with minimal install and expanding to broader installs of
> Fedora. However there might be cases where the package is using some
> obscure features of the old 1.0.x API and the port might be non-trivial
> - I do not expect such packages to be common however cooperation with
> the respective package upstream might be needed in such cases.
> 
> At worst if the patching of a package is highly non-trivial and the
> upstream is not responsive we might have to drop the package from
> Fedora.
> 
> We do not want to keep 1.0.2 devel around as that could make it to look
> like the 1.0.2 is still fully "supported" in Fedora and there would be
> no incentive to switch to 1.1.0. Also to get any new features from
> upstream OpenSSL we have to move to newer versions as they are released
> as the old versions get only bug fixes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

Hi,

I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds


https://koji.fedoraproject.org/koji/getfile?taskID=16059122&name=build.log&offset=-4000

Yesterday (11 October) I downloaded and installed the current rawhide 
and built — successfully — from the same src.rpm that's failing in koji.


I tried again today and the koji f26 build is still failing.

The koji f26 build of the previous release of glusterfs (3.7.15, 
containing the same code) built fine approx five weeks ago.


What's the recommend action here, just wait a few days? Or something else?

Thanks,

--

Kaleb



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

Re: rawhide vs koji f26 builds

[Peter Robinson]

On Wed, Oct 12, 2016 at 1:47 PM, Kaleb S. KEITHLEY  wrote:
> Hi,
>
> I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds
>
>
> https://koji.fedoraproject.org/koji/getfile?taskID=16059122&name=build.log&offset=-4000

Can you reference the root task, can''t get that from the link above
so it's hard to tell all the details with just a snippet.

> Yesterday (11 October) I downloaded and installed the current rawhide and
> built — successfully — from the same src.rpm that's failing in koji.
>
> I tried again today and the koji f26 build is still failing.
>
> The koji f26 build of the previous release of glusterfs (3.7.15, containing
> the same code) built fine approx five weeks ago.
>
> What's the recommend action here, just wait a few days? Or something else?
>
> Thanks,
>
> --
>
> Kaleb
>
>
>
> ___
> 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: rawhide vs koji f26 builds

[Kalev Lember]

On 10/12/2016 02:47 PM, Kaleb S. KEITHLEY wrote:
> Hi,
> 
> I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds
> 
> 
> https://koji.fedoraproject.org/koji/getfile?taskID=16059122&name=build.log&offset=-4000
> 
> 
> Yesterday (11 October) I downloaded and installed the current rawhide
> and built — successfully — from the same src.rpm that's failing in koji.
> 
> I tried again today and the koji f26 build is still failing.
> 
> The koji f26 build of the previous release of glusterfs (3.7.15,
> containing the same code) built fine approx five weeks ago.
> 
> What's the recommend action here, just wait a few days? Or something else?

From the log:

keys.c:121:11: error: storage size of 'hctx' isn't known
  HMAC_CTX hctx;
   ^~~~

Probably needs patching for openssl 1.1 that just landed in rawhide.

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

where is /1 coming from?

[Matthew Miller]

Someone on Reddit noted that there's a zero-length file named `1` in /
on their F25 system. I just looked on mine, and I have one too. It's
not owned by any RPM. And I checked on an F24 box, and it's got that
too. Anyone know where this is coming from?

-- 
Matthew Miller

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

Re: where is /1 coming from?

[Neal Gompa]

On Wed, Oct 12, 2016 at 9:03 AM, Matthew Miller
 wrote:
> Someone on Reddit noted that there's a zero-length file named `1` in /
> on their F25 system. I just looked on mine, and I have one too. It's
> not owned by any RPM. And I checked on an F24 box, and it's got that
> too. Anyone know where this is coming from?
>

I believe it's gunk created by the Live ISO creation process. I've
seen it pop up from spinning ISOs using livecd-creator and
livemedia-creator. If you do an installation from netinstall or an install DVD,
the file isn't present.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: where is /1 coming from?

[Igor Gnatenko]

It was bug in binutils packaging. It's fixed.

-Igor Gnatenko

On Oct 12, 2016 3:04 PM, "Matthew Miller"  wrote:

> Someone on Reddit noted that there's a zero-length file named `1` in /
> on their F25 system. I just looked on mine, and I have one too. It's
> not owned by any RPM. And I checked on an F24 box, and it's got that
> too. Anyone know where this is coming from?
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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: where is /1 coming from?

[Chris Murphy]

On Wed, Oct 12, 2016 at 7:09 AM, Igor Gnatenko  wrote:
> It was bug in binutils packaging. It's fixed.
>
> -Igor Gnatenko
>
>
> On Oct 12, 2016 3:04 PM, "Matthew Miller"  wrote:
>>
>> Someone on Reddit noted that there's a zero-length file named `1` in /
>> on their F25 system. I just looked on mine, and I have one too. It's
>> not owned by any RPM. And I checked on an F24 box, and it's got that
>> too. Anyone know where this is coming from?
>>


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


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

Re: rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

On 10/12/2016 08:49 AM, Peter Robinson wrote:

On Wed, Oct 12, 2016 at 1:47 PM, Kaleb S. KEITHLEY  wrote:

Hi,

I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds


https://koji.fedoraproject.org/koji/getfile?taskID=16059122&name=build.log&offset=-4000


Can you reference the root task, can''t get that from the link above
so it's hard to tell all the details with just a snippet.




http://koji.fedoraproject.org/koji/taskinfo?taskID=16059121





Yesterday (11 October) I downloaded and installed the current rawhide and
built — successfully — from the same src.rpm that's failing in koji.

I tried again today and the koji f26 build is still failing.

The koji f26 build of the previous release of glusterfs (3.7.15, containing
the same code) built fine approx five weeks ago.

What's the recommend action here, just wait a few days? Or something else?

Thanks,

--

Kaleb



___
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 14:39 +0200, Kamil Dudka wrote:
> On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote:
> > 
> > Hi all,
> > 
> > the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> > will
> > be also 1.0.2 compat package (compat-openssl10) so the dependencies
> > are
> > not broken and Rawhide should be installable. Also things that do
> > not
> > depend on openssl should be rebuildable without changes.
> > 
> > On the other hand due to the major API changes in 1.1.0 if your
> > package
> > uses OpenSSL it will not be possible to rebuild it without
> > patching.
> > Some upstreams already updated their code to work with 1.1.0 so if
> > it
> > is your case again there might not be any problems rebuilding it.
> Is there any migration guide regarding the API changes introduced in
> 1.1.0?

Unfortunately not except for what's written here: https://wiki.openssl.
org/index.php/1.1_API_Changes#Major_Changes_so_far

Basically replacing direct access to structure members with use of
getters and setters should work. Also of course the structures cannot
be directly put into variables but allocated/destroyed via *_new *_free
functions.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: Cannot build live iso using livemedia-creator

[Sergio Belkin]

Thanks, by now I will go back to livecd-creator!

Greetings

2016-09-30 21:19 GMT-03:00 Brian C. Lane :

> Looks like this is similar to
> https://bugzilla.redhat.com/show_bug.cgi?id=1245960
>
> and probably depends on something unique in your environment. As adam
> said, running it inside a mock is safer, or if you have libvirt setup
> you could use that with a f24 boot.iso to further isolate things.
>
> --
> Brian C. Lane (PST8PDT)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: where is /1 coming from?

[Matthew Miller]

On Wed, Oct 12, 2016 at 07:15:39AM -0600, Chris Murphy wrote:
> > It was bug in binutils packaging. It's fixed.
> https://bugzilla.redhat.com/show_bug.cgi?id=1383266

Awesome. Thanks for the quick replies, Chris and Igor!

-- 
Matthew Miller

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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Matthew Miller]

On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote:
> @Matt: does it reflect your thoughts ?

Looks like a great place to start -- thanks. The one change I'd make is
adding a separate "Critical" level, for things that will have us pacing
the halls (figuratively) continually bugging people, pulling in favors,
etc.

-- 
Matthew Miller

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

Re: rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

On 10/12/2016 08:58 AM, Kalev Lember wrote:

On 10/12/2016 02:47 PM, Kaleb S. KEITHLEY wrote:

Hi,

I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds


https://koji.fedoraproject.org/koji/getfile?taskID=16059122&name=build.log&offset=-4000


Yesterday (11 October) I downloaded and installed the current rawhide
and built — successfully — from the same src.rpm that's failing in koji.

I tried again today and the koji f26 build is still failing.

The koji f26 build of the previous release of glusterfs (3.7.15,
containing the same code) built fine approx five weeks ago.

What's the recommend action here, just wait a few days? Or something else?


From the log:

keys.c:121:11: error: storage size of 'hctx' isn't known
  HMAC_CTX hctx;
   ^~~~

Probably needs patching for openssl 1.1 that just landed in rawhide.



Sure, but I just installed a rawhide box from 
Fedora-Server-netinst-x86_64-Rawhide-20161010.n.0.iso and it still has 
openssl-1.0.2j-1.fc26.x86_64 and a `dnf update openssl` is not giving me 
anything newer.


I guess I can go get 
Fedora-Server-netinst-x86_64-Rawhide-20161011.n.0.iso or install the 
rpms from http://koji.fedoraproject.org/koji/buildinfo?buildID=809049.


--

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

ppisar pushed to perl-CPAN (master). "2.14 bump"

[notifications]

From 1acab7f0c88e33bd2ec274374a4e268ea2f9d7c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 27 Jun 2016 10:13:21 +0200
Subject: 2.14 bump

---
 .gitignore |   1 +
 CPAN-2.10-Upgrade-to-2.11.patch|  40 -
 ...reate-site-library-directories-on-first-t.patch |  54 ---
 ...nfiguration-directory-string-with-a-marke.patch | 164 -
 ...reate-site-library-directories-on-first-t.patch |  54 +++
 ...nfiguration-directory-string-with-a-marke.patch | 164 +
 perl-CPAN.spec |  27 ++--
 sources|   2 +-
 8 files changed, 235 insertions(+), 271 deletions(-)
 delete mode 100644 CPAN-2.10-Upgrade-to-2.11.patch
 delete mode 100644 
CPAN-2.11-Attemp-to-create-site-library-directories-on-first-t.patch
 delete mode 100644 
CPAN-2.11-Replace-configuration-directory-string-with-a-marke.patch
 create mode 100644 
CPAN-2.14-Attemp-to-create-site-library-directories-on-first-t.patch
 create mode 100644 
CPAN-2.14-Replace-configuration-directory-string-with-a-marke.patch

diff --git a/.gitignore b/.gitignore
index 94563e5..ebf27f2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /CPAN-2.05.tar.gz
 /CPAN-2.10.tar.gz
+/CPAN-2.14.tar.gz
diff --git a/CPAN-2.10-Upgrade-to-2.11.patch b/CPAN-2.10-Upgrade-to-2.11.patch
deleted file mode 100644
index 857a701..000
--- a/CPAN-2.10-Upgrade-to-2.11.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From 4eddce7fa1d61c5f7e02132ae7a5d04101eb6a1c Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
-Date: Wed, 6 May 2015 14:22:13 +0200
-Subject: [PATCH] Upgrade to 2.11
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-perl sources are missing a lof CPAN tests. I did not removed them by
-this patch.
-
-Signed-off-by: Petr Písař 

- lib/CPAN.pm | 3 +--
- 1 file changed, 1 insertion(+), 2 deletions(-)
-
-diff --git a/lib/CPAN.pm b/lib/CPAN.pm
-index 93ad482..6096916 100644
 a/lib/CPAN.pm
-+++ b/lib/CPAN.pm
-@@ -2,7 +2,7 @@
- # vim: ts=4 sts=4 sw=4:
- use strict;
- package CPAN;
--$CPAN::VERSION = '2.10';
-+$CPAN::VERSION = '2.11';
- $CPAN::VERSION =~ s/_//;
- 
- # we need to run chdir all over and we would get at wrong libraries
-@@ -318,7 +318,6 @@ Enter 'h' for help.
- 
- },
-  $CPAN::VERSION,
-- $rl_avail
- )
- }
- my($continuation) = "";
--- 
-2.1.0
-
diff --git 
a/CPAN-2.11-Attemp-to-create-site-library-directories-on-first-t.patch 
b/CPAN-2.11-Attemp-to-create-site-library-directories-on-first-t.patch
deleted file mode 100644
index 5e14a43..000
--- a/CPAN-2.11-Attemp-to-create-site-library-directories-on-first-t.patch
+++ /dev/null
@@ -1,54 +0,0 @@
-From ba274427f5a508fbac034a4d39480ac4edbc9c19 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
-Date: Thu, 30 Oct 2014 13:19:16 +0100
-Subject: [PATCH] Attemp to create site library directories on first time
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Some vendors configures site library directories into /usr/local, but
-they do not provide the directory on their systems because an
-administrator can have a read-only network-mounted file system there.
-
-When running CPAN for the first time, CPAN cannot find the site
-directories and falls back to local::lib. To restore the user
-expectations with writable /usr/local, this patch tries to create the
-missing directories before checking for their presents.
-
-Signed-off-by: Petr Písař 

- lib/CPAN/FirstTime.pm | 18 ++
- 1 file changed, 18 insertions(+)
-
-diff --git a/lib/CPAN/FirstTime.pm b/lib/CPAN/FirstTime.pm
-index 918e009..7049513 100644
 a/lib/CPAN/FirstTime.pm
-+++ b/lib/CPAN/FirstTime.pm
-@@ -2058,6 +2058,24 @@ sub _print_urllist {
- }
- 
- sub _can_write_to_libdirs {
-+for ($Config{installsitelib}, $Config{installsitearch}) {
-+if (!-d $_) {
-+$CPAN::Frontend->mywarn(sprintf(
-+qq{Perl site library directory "%s" does not exist.\n},
-+$_));
-+File::Path::make_path($_, { error => \my $failure });
-+if (@$failure) {
-+$CPAN::Frontend->mywarn(sprintf(
-+qq{Perl site library directory "%s" } .
-+qq{could not been created: %s.\n},
-+$_, ${$$failure[0]}{$_}));
-+} else {
-+$CPAN::Frontend->mywarn(sprintf(
-+qq{Perl site library directory "%s" created.\n},
-+$_));
-+}
-+}
-+}
- return -w $Config{installprivlib}
- && -w $Config{installarchlib}
- && -w $Config{installsitelib}
--- 
-2.1.0
-
diff --git 
a/CPAN-2.11-Replace-configuration-direc

keyboard is partially honored in kickstart

[Sergio Belkin]

Hi,

I'm trying to remasterize a Fedora Spin, but keyboard options is not
working.

I've configured as follows:

keyboard --vckeymap=latam --xlayouts='latam'


The option " --vckeymap=latam" works fine. But --xlayouts='latam' is
ignored.

If I boot from LiveCD, in Xorg I get:

setxkbmap -query
rules:  evdev
model:  pc105
layout: us

Any ideas?

You may take a look at kickstart file here:

http://pastebin.com/vuQjXqi2

Thanks in advance!

-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: where is /1 coming from?

[Matthew Miller]

On Wed, Oct 12, 2016 at 09:39:23AM -0400, Matthew Miller wrote:
> On Wed, Oct 12, 2016 at 07:15:39AM -0600, Chris Murphy wrote:
> > > It was bug in binutils packaging. It's fixed.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1383266
> Awesome. Thanks for the quick replies, Chris and Igor!

And Neal :)

-- 
Matthew Miller

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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Josh Boyer]

On Wed, Oct 12, 2016 at 9:38 AM, Matthew Miller
 wrote:
> On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote:
>> @Matt: does it reflect your thoughts ?
>
> Looks like a great place to start -- thanks. The one change I'd make is
> adding a separate "Critical" level, for things that will have us pacing
> the halls (figuratively) continually bugging people, pulling in favors,
> etc.

I agree Jan's proposal looks like a good idea.  However, I can't but
help notice that its necessity is driven almost entirely by the fact
that we cannot use our existing bugzilla tool to do this job for us.
All of the extra app stuff could be avoided if we disallowed reporters
(or random people) to change the Severity and Priority fields.

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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On St, 2016-10-12 at 15:33 +0200, Tomas Mraz wrote:
> On St, 2016-10-12 at 14:39 +0200, Kamil Dudka wrote:
> > 
> > On Friday, October 07, 2016 14:49:49 Tomas Mraz wrote:
> > > 
> > > 
> > > Hi all,
> > > 
> > > the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> > > will
> > > be also 1.0.2 compat package (compat-openssl10) so the
> > > dependencies
> > > are
> > > not broken and Rawhide should be installable. Also things that do
> > > not
> > > depend on openssl should be rebuildable without changes.
> > > 
> > > On the other hand due to the major API changes in 1.1.0 if your
> > > package
> > > uses OpenSSL it will not be possible to rebuild it without
> > > patching.
> > > Some upstreams already updated their code to work with 1.1.0 so
> > > if
> > > it
> > > is your case again there might not be any problems rebuilding it.
> > Is there any migration guide regarding the API changes introduced
> > in
> > 1.1.0?
> Unfortunately not except for what's written here: https://wiki.openss
> l.
> org/index.php/1.1_API_Changes#Major_Changes_so_far
> 
> Basically replacing direct access to structure members with use of
> getters and setters should work. Also of course the structures cannot
> be directly put into variables but allocated/destroyed via *_new
> *_free
> functions.

Also there is https://github.com/patch-exchange/openssl-1.1-transition 
where you can take some inspiration.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: where is /1 coming from?

[Joachim Backes]

On 10/12/16 15:03, Matthew Miller wrote:

Someone on Reddit noted that there's a zero-length file named `1` in /
on their F25 system. I just looked on mine, and I have one too. It's
not owned by any RPM. And I checked on an F24 box, and it's got that
too. Anyone know where this is coming from?


Additionally I see a file called /null with zero length!

Kind regards

Joachim Backes

--

Fedora release 25 (Twenty Five)
Kernel-4.8.1-1.fc25.x86_64


Joachim Backes 
http://www-user.rhrk.uni-kl.de/~backes/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: where is /1 coming from?

[pete0verse]

MIME-Version: 1.0
Content-Type: multipart/alternative; 
boundary="--_com.samsung.android.email_1427992738156800"

_com.samsung.android.email_1427992738156800
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SSBoYWQgdGhpcyBpc3N1ZSBvZiAxIGluIC8gaW4gRjI0IEkgaGFkIHVwZ3JhZGVkIGZyb20gMjIu
wqAKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzcsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0
cGhvbmUKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IEpvYWNoaW0gQmFj
a2VzIDxqb2FjaGltLmJhY2tlc0ByaHJrLnVuaS1rbC5kZT4gRGF0ZTogMTAvMTIvMTYgIDEwOjM2
IEFNICAoR01ULTA1OjAwKSBUbzogRGV2ZWxvcG1lbnQgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBG
ZWRvcmEgPGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnPiBTdWJqZWN0OiBSZTogd2hlcmUg
aXMgLzEgY29taW5nIGZyb20/IApPbiAxMC8xMi8xNiAxNTowMywgTWF0dGhldyBNaWxsZXIgd3Jv
dGU6Cj4gU29tZW9uZSBvbiBSZWRkaXQgbm90ZWQgdGhhdCB0aGVyZSdzIGEgemVyby1sZW5ndGgg
ZmlsZSBuYW1lZCBgMWAgaW4gLwo+IG9uIHRoZWlyIEYyNSBzeXN0ZW0uIEkganVzdCBsb29rZWQg
b24gbWluZSwgYW5kIEkgaGF2ZSBvbmUgdG9vLiBJdCdzCj4gbm90IG93bmVkIGJ5IGFueSBSUE0u
IEFuZCBJIGNoZWNrZWQgb24gYW4gRjI0IGJveCwgYW5kIGl0J3MgZ290IHRoYXQKPiB0b28uIEFu
eW9uZSBrbm93IHdoZXJlIHRoaXMgaXMgY29taW5nIGZyb20/Cj4KQWRkaXRpb25hbGx5IEkgc2Vl
IGEgZmlsZSBjYWxsZWQgL251bGwgd2l0aCB6ZXJvIGxlbmd0aCEKCktpbmQgcmVnYXJkcwoKSm9h
Y2hpbSBCYWNrZXMKCi0tIAoKRmVkb3JhIHJlbGVhc2UgMjUgKFR3ZW50eSBGaXZlKQpLZXJuZWwt
NC44LjEtMS5mYzI1Lng4Nl82NAoKCkpvYWNoaW0gQmFja2VzIDxqb2FjaGltLmJhY2tlc0ByaHJr
LnVuaS1rbC5kZT4KaHR0cDovL3d3dy11c2VyLnJocmsudW5pLWtsLmRlL35iYWNrZXMvCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRldmVsIG1haWxpbmcg
bGlzdCAtLSBkZXZlbEBsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1bnN1YnNjcmliZSBzZW5k
IGFuIGVtYWlsIHRvIGRldmVsLWxlYXZlQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnCg==

_com.samsung.android.email_1427992738156800
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgaGFkIHRoaXMgaXNzdWUg
b2YgMSBpbiAvIGluIEYyNCBJIGhhZCB1cGdyYWRlZCBmcm9tIDIyLiZuYnNwOzwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2Vy
X3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9
ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTNywgYW4gQVQmYW1wO1QgNEcgTFRF
IHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNp
emU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0t
LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IEpvYWNoaW0gQmFj
a2VzICZsdDtqb2FjaGltLmJhY2tlc0ByaHJrLnVuaS1rbC5kZSZndDsgPC9kaXY+PGRpdj5EYXRl
OiAxMC8xMi8xNiAgMTA6MzYgQU0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IERldmVsb3Bt
ZW50IGRpc2N1c3Npb25zIHJlbGF0ZWQgdG8gRmVkb3JhICZsdDtkZXZlbEBsaXN0cy5mZWRvcmFw
cm9qZWN0Lm9yZyZndDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogd2hlcmUgaXMgLzEgY29taW5n
IGZyb20/IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pk9uIDEwLzEyLzE2IDE1OjAzLCBNYXR0
aGV3IE1pbGxlciB3cm90ZTo8YnI+Jmd0OyBTb21lb25lIG9uIFJlZGRpdCBub3RlZCB0aGF0IHRo
ZXJlJ3MgYSB6ZXJvLWxlbmd0aCBmaWxlIG5hbWVkIGAxYCBpbiAvPGJyPiZndDsgb24gdGhlaXIg
RjI1IHN5c3RlbS4gSSBqdXN0IGxvb2tlZCBvbiBtaW5lLCBhbmQgSSBoYXZlIG9uZSB0b28uIEl0
J3M8YnI+Jmd0OyBub3Qgb3duZWQgYnkgYW55IFJQTS4gQW5kIEkgY2hlY2tlZCBvbiBhbiBGMjQg
Ym94LCBhbmQgaXQncyBnb3QgdGhhdDxicj4mZ3Q7IHRvby4gQW55b25lIGtub3cgd2hlcmUgdGhp
cyBpcyBjb21pbmcgZnJvbT88YnI+Jmd0Ozxicj5BZGRpdGlvbmFsbHkgSSBzZWUgYSBmaWxlIGNh
bGxlZCAvbnVsbCB3aXRoIHplcm8gbGVuZ3RoITxicj48YnI+S2luZCByZWdhcmRzPGJyPjxicj5K
b2FjaGltIEJhY2tlczxicj48YnI+LS0gPGJyPjxicj5GZWRvcmEgcmVsZWFzZSAyNSAoVHdlbnR5
IEZpdmUpPGJyPktlcm5lbC00LjguMS0xLmZjMjUueDg2XzY0PGJyPjxicj48YnI+Sm9hY2hpbSBC
YWNrZXMgJmx0O2pvYWNoaW0uYmFja2VzQHJocmsudW5pLWtsLmRlJmd0Ozxicj5odHRwOi8vd3d3
LXVzZXIucmhyay51bmkta2wuZGUvfmJhY2tlcy88YnI+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+ZGV2ZWwgbWFpbGluZyBsaXN0IC0tIGRldmVsQGxp
c3RzLmZlZG9yYXByb2plY3Qub3JnPGJyPlRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwgdG8g
ZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmc8YnI+PC9ib2R5PjwvaHRtbD4=

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

Re: where is /1 coming from?

[Björn Esser]

Am 12.10.2016 um 16:36 schrieb Joachim Backes:

On 10/12/16 15:03, Matthew Miller wrote:

Someone on Reddit noted that there's a zero-length file named `1` in /
on their F25 system. I just looked on mine, and I have one too. It's
not owned by any RPM. And I checked on an F24 box, and it's got that
too. Anyone know where this is coming from?


Additionally I see a file called /null with zero length!

Kind regards

Joachim Backes



Same finding (/null) for me, too.

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

Re: where is /1 coming from?

[Chuck Anderson]

Am I the only one who can't see the email body below?

On Wed, Oct 12, 2016 at 10:44:00AM -0400, pete0verse wrote:
> 
> MIME-Version: 1.0
> Content-Type: multipart/alternative; 
> boundary="--_com.samsung.android.email_1427992738156800"
> 
> _com.samsung.android.email_1427992738156800
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: base64
> 
> SSBoYWQgdGhpcyBpc3N1ZSBvZiAxIGluIC8gaW4gRjI0IEkgaGFkIHVwZ3JhZGVkIGZyb20gMjIu
> wqAKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzcsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0
> cGhvbmUKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IEpvYWNoaW0gQmFj
> a2VzIDxqb2FjaGltLmJhY2tlc0ByaHJrLnVuaS1rbC5kZT4gRGF0ZTogMTAvMTIvMTYgIDEwOjM2
> IEFNICAoR01ULTA1OjAwKSBUbzogRGV2ZWxvcG1lbnQgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBG
> ZWRvcmEgPGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnPiBTdWJqZWN0OiBSZTogd2hlcmUg
> aXMgLzEgY29taW5nIGZyb20/IApPbiAxMC8xMi8xNiAxNTowMywgTWF0dGhldyBNaWxsZXIgd3Jv
> dGU6Cj4gU29tZW9uZSBvbiBSZWRkaXQgbm90ZWQgdGhhdCB0aGVyZSdzIGEgemVyby1sZW5ndGgg
> ZmlsZSBuYW1lZCBgMWAgaW4gLwo+IG9uIHRoZWlyIEYyNSBzeXN0ZW0uIEkganVzdCBsb29rZWQg
> b24gbWluZSwgYW5kIEkgaGF2ZSBvbmUgdG9vLiBJdCdzCj4gbm90IG93bmVkIGJ5IGFueSBSUE0u
> IEFuZCBJIGNoZWNrZWQgb24gYW4gRjI0IGJveCwgYW5kIGl0J3MgZ290IHRoYXQKPiB0b28uIEFu
> eW9uZSBrbm93IHdoZXJlIHRoaXMgaXMgY29taW5nIGZyb20/Cj4KQWRkaXRpb25hbGx5IEkgc2Vl
> IGEgZmlsZSBjYWxsZWQgL251bGwgd2l0aCB6ZXJvIGxlbmd0aCEKCktpbmQgcmVnYXJkcwoKSm9h
> Y2hpbSBCYWNrZXMKCi0tIAoKRmVkb3JhIHJlbGVhc2UgMjUgKFR3ZW50eSBGaXZlKQpLZXJuZWwt
> NC44LjEtMS5mYzI1Lng4Nl82NAoKCkpvYWNoaW0gQmFja2VzIDxqb2FjaGltLmJhY2tlc0ByaHJr
> LnVuaS1rbC5kZT4KaHR0cDovL3d3dy11c2VyLnJocmsudW5pLWtsLmRlL35iYWNrZXMvCl9fX19f
> X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRldmVsIG1haWxpbmcg
> bGlzdCAtLSBkZXZlbEBsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1bnN1YnNjcmliZSBzZW5k
> IGFuIGVtYWlsIHRvIGRldmVsLWxlYXZlQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnCg==
> 
> _com.samsung.android.email_1427992738156800
> Content-Type: text/html; charset=utf-8
> Content-Transfer-Encoding: base64
> 
> PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
> L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgaGFkIHRoaXMgaXNzdWUg
> b2YgMSBpbiAvIGluIEYyNCBJIGhhZCB1cGdyYWRlZCBmcm9tIDIyLiZuYnNwOzwvZGl2PjxkaXY+
> PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2Vy
> X3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9
> ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTNywgYW4gQVQmYW1wO1QgNEcgTFRF
> IHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNp
> emU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0t
> LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IEpvYWNoaW0gQmFj
> a2VzICZsdDtqb2FjaGltLmJhY2tlc0ByaHJrLnVuaS1rbC5kZSZndDsgPC9kaXY+PGRpdj5EYXRl
> OiAxMC8xMi8xNiAgMTA6MzYgQU0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IERldmVsb3Bt
> ZW50IGRpc2N1c3Npb25zIHJlbGF0ZWQgdG8gRmVkb3JhICZsdDtkZXZlbEBsaXN0cy5mZWRvcmFw
> cm9qZWN0Lm9yZyZndDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogd2hlcmUgaXMgLzEgY29taW5n
> IGZyb20/IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pk9uIDEwLzEyLzE2IDE1OjAzLCBNYXR0
> aGV3IE1pbGxlciB3cm90ZTo8YnI+Jmd0OyBTb21lb25lIG9uIFJlZGRpdCBub3RlZCB0aGF0IHRo
> ZXJlJ3MgYSB6ZXJvLWxlbmd0aCBmaWxlIG5hbWVkIGAxYCBpbiAvPGJyPiZndDsgb24gdGhlaXIg
> RjI1IHN5c3RlbS4gSSBqdXN0IGxvb2tlZCBvbiBtaW5lLCBhbmQgSSBoYXZlIG9uZSB0b28uIEl0
> J3M8YnI+Jmd0OyBub3Qgb3duZWQgYnkgYW55IFJQTS4gQW5kIEkgY2hlY2tlZCBvbiBhbiBGMjQg
> Ym94LCBhbmQgaXQncyBnb3QgdGhhdDxicj4mZ3Q7IHRvby4gQW55b25lIGtub3cgd2hlcmUgdGhp
> cyBpcyBjb21pbmcgZnJvbT88YnI+Jmd0Ozxicj5BZGRpdGlvbmFsbHkgSSBzZWUgYSBmaWxlIGNh
> bGxlZCAvbnVsbCB3aXRoIHplcm8gbGVuZ3RoITxicj48YnI+S2luZCByZWdhcmRzPGJyPjxicj5K
> b2FjaGltIEJhY2tlczxicj48YnI+LS0gPGJyPjxicj5GZWRvcmEgcmVsZWFzZSAyNSAoVHdlbnR5
> IEZpdmUpPGJyPktlcm5lbC00LjguMS0xLmZjMjUueDg2XzY0PGJyPjxicj48YnI+Sm9hY2hpbSBC
> YWNrZXMgJmx0O2pvYWNoaW0uYmFja2VzQHJocmsudW5pLWtsLmRlJmd0Ozxicj5odHRwOi8vd3d3
> LXVzZXIucmhyay51bmkta2wuZGUvfmJhY2tlcy88YnI+X19fX19fX19fX19fX19fX19fX19fX19f
> X19fX19fX19fX19fX19fX19fX19fX188YnI+ZGV2ZWwgbWFpbGluZyBsaXN0IC0tIGRldmVsQGxp
> c3RzLmZlZG9yYXByb2plY3Qub3JnPGJyPlRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwgdG8g
> ZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmc8YnI+PC9ib2R5PjwvaHRtbD4=
> 
> _com.samsung.android.email_1427992738156800--
> ___
> 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: where is /1 coming from?

[Alexander Ploumistos]

On Wed, Oct 12, 2016 at 5:58 PM, Chuck Anderson  wrote:
> Am I the only one who can't see the email body below?

No you are not.

After, squeezing it through base64, it reads:

I had this issue of 1 in / in F24 I had upgraded from 22.


Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
 Original message From: Joachim Backes
 Date: 10/12/16  10:36 AM  (GMT-05:00)
To: Development discussions related to Fedora
 Subject: Re: where is /1 coming from?
On 10/12/16 15:03, Matthew Miller wrote:
> Someone on Reddit noted that there's a zero-length file named `1` in /
> on their F25 system. I just looked on mine, and I have one too. It's
> not owned by any RPM. And I checked on an F24 box, and it's got that
> too. Anyone know where this is coming from?
>
Additionally I see a file called /null with zero length!

Kind regards

Joachim Backes

-- 

Fedora release 25 (Twenty Five)
Kernel-4.8.1-1.fc25.x86_64


Joachim Backes 
http://www-user.rhrk.uni-kl.de/~backes/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25-20161012.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/102 (x86_64), 1/17 (i386), 1/2 (arm)

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

ID: 40558   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/40558
ID: 40574   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/40574
ID: 40575   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/40575
ID: 40632   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/40632

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

ID: 40564   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/40564
ID: 40585   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/40585
ID: 40673   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/40673

Passed openQA tests: 89/102 (x86_64), 16/17 (i386)

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

ID: 40568   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/40568
ID: 40612   Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/40612
ID: 40634   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/40634
ID: 40652   Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/40652
ID: 40654   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/40654
ID: 40662   Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/40662
ID: 40676   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/40676
ID: 40677   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/40677
ID: 40678   Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/40678
ID: 40679   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/40679

Skipped openQA tests: 9 of 121
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Interactive builds

[Richard W.M. Jones]

We've noticed that some builds are interactive.  This combined
with a bug in our autobuilder so these builds were hanging.

However I can reproduce the same behaviour using 'fedpkg local'
(see below).

Obviously mock or Koji must be closing stdin.

Anyway is this a bug in the packaging?

Rich.

$ fedpkg clone -B perl-Audio-Beep
Cloning into bare repository '/home/rjones/d/fedora/perl-Audio-Beep/rpkg.git'...
cd perl-Audio-Beep/masteremote: Counting objects: 96, done.
remote: Compressing objects: 100% (74/74), done.
remote: Total 96 (delta 33), reused 47 (delta 17)
Receiving objects: 100% (96/96), 11.51 KiB | 0 bytes/s, done.
Resolving deltas: 100% (33/33), done.
Checking connectivity... done.

$ cd perl-Audio-Beep/master
$ fedpkg local
Downloading Audio-Beep-0.11.tar.gz
 100.0%


Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DDaXlx
+ umask 022
+ cd /home/rjones/d/fedora/perl-Audio-Beep/master
+ cd /home/rjones/d/fedora/perl-Audio-Beep/master
+ rm -rf Audio-Beep-0.11
+ /usr/bin/gzip -dc 
/home/rjones/d/fedora/perl-Audio-Beep/master/Audio-Beep-0.11.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd Audio-Beep-0.11
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ chmod -x music/beep_player.pl
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.1IrEhL
+ umask 022
+ cd /home/rjones/d/fedora/perl-Audio-Beep/master
+ cd Audio-Beep-0.11
+ /usr/bin/perl Makefile.PL INSTALLDIRS=vendor 'OPTIMIZE=-O2 -g -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic'
Would you like to install Japanese documentation? 
If you enter 'y' then i will try to install Japanese docs alongside 
English ones. On platforms using 'man' manpages (typically on UN*X)
Japanese documentation will be available transparently to users whose 
locale language is set to Japanese.
On other platforms the documentation will be available as Audio::Beep_jp
Default is to not install Japanese docs. [N/y]  <-- hangs here



-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: where is /1 coming from?

[Roger Wells]

On 10/12/2016 10:58 AM, Chuck Anderson wrote:
> Am I the only one who can't see the email body below?

no

> 
> On Wed, Oct 12, 2016 at 10:44:00AM -0400, pete0verse wrote:
>>
>> MIME-Version: 1.0
>> Content-Type: multipart/alternative; 
>> boundary="--_com.samsung.android.email_1427992738156800"
>>
>> _com.samsung.android.email_1427992738156800
>> Content-Type: text/plain; charset=utf-8
>> Content-Transfer-Encoding: base64
>>
>> SSBoYWQgdGhpcyBpc3N1ZSBvZiAxIGluIC8gaW4gRjI0IEkgaGFkIHVwZ3JhZGVkIGZyb20gMjIu
>> wqAKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzcsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0
>> cGhvbmUKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IEpvYWNoaW0gQmFj
>> a2VzIDxqb2FjaGltLmJhY2tlc0ByaHJrLnVuaS1rbC5kZT4gRGF0ZTogMTAvMTIvMTYgIDEwOjM2
>> IEFNICAoR01ULTA1OjAwKSBUbzogRGV2ZWxvcG1lbnQgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBG
>> ZWRvcmEgPGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnPiBTdWJqZWN0OiBSZTogd2hlcmUg
>> aXMgLzEgY29taW5nIGZyb20/IApPbiAxMC8xMi8xNiAxNTowMywgTWF0dGhldyBNaWxsZXIgd3Jv
>> dGU6Cj4gU29tZW9uZSBvbiBSZWRkaXQgbm90ZWQgdGhhdCB0aGVyZSdzIGEgemVyby1sZW5ndGgg
>> ZmlsZSBuYW1lZCBgMWAgaW4gLwo+IG9uIHRoZWlyIEYyNSBzeXN0ZW0uIEkganVzdCBsb29rZWQg
>> b24gbWluZSwgYW5kIEkgaGF2ZSBvbmUgdG9vLiBJdCdzCj4gbm90IG93bmVkIGJ5IGFueSBSUE0u
>> IEFuZCBJIGNoZWNrZWQgb24gYW4gRjI0IGJveCwgYW5kIGl0J3MgZ290IHRoYXQKPiB0b28uIEFu
>> eW9uZSBrbm93IHdoZXJlIHRoaXMgaXMgY29taW5nIGZyb20/Cj4KQWRkaXRpb25hbGx5IEkgc2Vl
>> IGEgZmlsZSBjYWxsZWQgL251bGwgd2l0aCB6ZXJvIGxlbmd0aCEKCktpbmQgcmVnYXJkcwoKSm9h
>> Y2hpbSBCYWNrZXMKCi0tIAoKRmVkb3JhIHJlbGVhc2UgMjUgKFR3ZW50eSBGaXZlKQpLZXJuZWwt
>> NC44LjEtMS5mYzI1Lng4Nl82NAoKCkpvYWNoaW0gQmFja2VzIDxqb2FjaGltLmJhY2tlc0ByaHJr
>> LnVuaS1rbC5kZT4KaHR0cDovL3d3dy11c2VyLnJocmsudW5pLWtsLmRlL35iYWNrZXMvCl9fX19f
>> X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRldmVsIG1haWxpbmcg
>> bGlzdCAtLSBkZXZlbEBsaXN0cy5mZWRvcmFwcm9qZWN0Lm9yZwpUbyB1bnN1YnNjcmliZSBzZW5k
>> IGFuIGVtYWlsIHRvIGRldmVsLWxlYXZlQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnCg==
>>
>> _com.samsung.android.email_1427992738156800
>> Content-Type: text/html; charset=utf-8
>> Content-Transfer-Encoding: base64
>>
>> PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
>> L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgaGFkIHRoaXMgaXNzdWUg
>> b2YgMSBpbiAvIGluIEYyNCBJIGhhZCB1cGdyYWRlZCBmcm9tIDIyLiZuYnNwOzwvZGl2PjxkaXY+
>> PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2Vy
>> X3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9
>> ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTNywgYW4gQVQmYW1wO1QgNEcgTFRF
>> IHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNp
>> emU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0t
>> LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IEpvYWNoaW0gQmFj
>> a2VzICZsdDtqb2FjaGltLmJhY2tlc0ByaHJrLnVuaS1rbC5kZSZndDsgPC9kaXY+PGRpdj5EYXRl
>> OiAxMC8xMi8xNiAgMTA6MzYgQU0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IERldmVsb3Bt
>> ZW50IGRpc2N1c3Npb25zIHJlbGF0ZWQgdG8gRmVkb3JhICZsdDtkZXZlbEBsaXN0cy5mZWRvcmFw
>> cm9qZWN0Lm9yZyZndDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogd2hlcmUgaXMgLzEgY29taW5n
>> IGZyb20/IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pk9uIDEwLzEyLzE2IDE1OjAzLCBNYXR0
>> aGV3IE1pbGxlciB3cm90ZTo8YnI+Jmd0OyBTb21lb25lIG9uIFJlZGRpdCBub3RlZCB0aGF0IHRo
>> ZXJlJ3MgYSB6ZXJvLWxlbmd0aCBmaWxlIG5hbWVkIGAxYCBpbiAvPGJyPiZndDsgb24gdGhlaXIg
>> RjI1IHN5c3RlbS4gSSBqdXN0IGxvb2tlZCBvbiBtaW5lLCBhbmQgSSBoYXZlIG9uZSB0b28uIEl0
>> J3M8YnI+Jmd0OyBub3Qgb3duZWQgYnkgYW55IFJQTS4gQW5kIEkgY2hlY2tlZCBvbiBhbiBGMjQg
>> Ym94LCBhbmQgaXQncyBnb3QgdGhhdDxicj4mZ3Q7IHRvby4gQW55b25lIGtub3cgd2hlcmUgdGhp
>> cyBpcyBjb21pbmcgZnJvbT88YnI+Jmd0Ozxicj5BZGRpdGlvbmFsbHkgSSBzZWUgYSBmaWxlIGNh
>> bGxlZCAvbnVsbCB3aXRoIHplcm8gbGVuZ3RoITxicj48YnI+S2luZCByZWdhcmRzPGJyPjxicj5K
>> b2FjaGltIEJhY2tlczxicj48YnI+LS0gPGJyPjxicj5GZWRvcmEgcmVsZWFzZSAyNSAoVHdlbnR5
>> IEZpdmUpPGJyPktlcm5lbC00LjguMS0xLmZjMjUueDg2XzY0PGJyPjxicj48YnI+Sm9hY2hpbSBC
>> YWNrZXMgJmx0O2pvYWNoaW0uYmFja2VzQHJocmsudW5pLWtsLmRlJmd0Ozxicj5odHRwOi8vd3d3
>> LXVzZXIucmhyay51bmkta2wuZGUvfmJhY2tlcy88YnI+X19fX19fX19fX19fX19fX19fX19fX19f
>> X19fX19fX19fX19fX19fX19fX19fX188YnI+ZGV2ZWwgbWFpbGluZyBsaXN0IC0tIGRldmVsQGxp
>> c3RzLmZlZG9yYXByb2plY3Qub3JnPGJyPlRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwgdG8g
>> ZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmc8YnI+PC9ib2R5PjwvaHRtbD4=
>>
>> _com.samsung.android.email_1427992738156800--
>> ___
>> 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
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@

Switching to NetworkManager dhcp=internal

[Colin Walters]

Hey, so as part of the discussion about NetworkManager vs systemd-networkd,
one thing that happened is networkd started exposing its DHCP code as
a shared library, and NetworkManager learned to use it if one specifies

```
[main]
dhcp=internal
```

in /etc/NetworkManager/NetworkManager.conf.  I have an open PR
to start doing this for Atomic Host:

https://pagure.io/fedora-atomic/pull-request/23

However, we still have to lug around the RPM because of the
hard Requires in NetworkManager.spec:

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

Since at the moment, Fedora editions come from the same pool
of binary RPMs, we don't have a real mechanism for me to ignore
that dependency just for Atomic Host.

And anyways, I don't see a reason not to do this across the board,
hence this thread.

The networkd DHCP code has gotten a fair amount of testing
in server environments, but I suspect it could use more battle
testing in two things:

1) Desktop systems with a wider variety of DHCP environments (from
  home routers, enterprise environments with unusual DHCP servers)
2) Cases where one wants to propagate various config options
  from the DHCP server; see e.g. 
https://bugzilla.gnome.org/show_bug.cgi?id=746911

Anyways, let's get some more testing of this; if you have a few minutes
and you feel your DHCP situation is unusual, try frobbing the config option,
and report any failures in https://bugzilla.redhat.com/show_bug.cgi?id=1204226

If things seem OK I can do a Change page.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Switching to NetworkManager dhcp=internal

[Matthew Miller]

On Wed, Oct 12, 2016 at 01:37:40PM -0400, Colin Walters wrote:
> And anyways, I don't see a reason not to do this across the board,
> hence this thread.

+1


> The networkd DHCP code has gotten a fair amount of testing
> in server environments, but I suspect it could use more battle
> testing in two things:
> 1) Desktop systems with a wider variety of DHCP environments (from
>   home routers, enterprise environments with unusual DHCP servers)

For one very small data point: I changed my laptop to use internal as
soon as I discovered it was an option (I dunno when exactly; more than
a year ago I think) and have not ever experienced any trouble. in > 2)
Cases where one wants to propagate various config options

-- 
Matthew Miller

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

Re: Switching to NetworkManager dhcp=internal

[stan]

On Wed, 12 Oct 2016 13:37:40 -0400
Colin Walters  wrote:

> Hey, so as part of the discussion about NetworkManager vs
> systemd-networkd, one thing that happened is networkd started
> exposing its DHCP code as a shared library, and NetworkManager
> learned to use it if one specifies
> 
> ```
> [main]
> dhcp=internal
> ```
> 
> in /etc/NetworkManager/NetworkManager.conf.

Did this.  Then turned off the ethernet link and restarted
NetworkManager to pick up the change.  Turned on the ethernet link.

> The networkd DHCP code has gotten a fair amount of testing
> in server environments, but I suspect it could use more battle
> testing in two things:
> 
> 1) Desktop systems with a wider variety of DHCP environments
>   home routers

Success, seems to be working fine (I haven't noticed any problems).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Switching to NetworkManager dhcp=internal

[Björn Esser]

Am 12.10.2016 um 20:14 schrieb stan:

On Wed, 12 Oct 2016 13:37:40 -0400
Colin Walters  wrote:


Hey, so as part of the discussion about NetworkManager vs
systemd-networkd, one thing that happened is networkd started
exposing its DHCP code as a shared library, and NetworkManager
learned to use it if one specifies

```
[main]
dhcp=internal
```

in /etc/NetworkManager/NetworkManager.conf.

Did this.  Then turned off the ethernet link and restarted
NetworkManager to pick up the change.  Turned on the ethernet link.


The networkd DHCP code has gotten a fair amount of testing
in server environments, but I suspect it could use more battle
testing in two things:

1) Desktop systems with a wider variety of DHCP environments
   home routers

Success, seems to be working fine (I haven't noticed any problems).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Looks fine here, too, using Cinnamon, MATE and Gnome 3 Desktops on 
Fedora 25.

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

Re: Copr && Rawhide -- no "rolling updates" workflow

[Kevin Fenzi]

On Tue, 11 Oct 2016 19:14:34 +0200
Pavel Raiskup  wrote:

> FYI:
> https://bugzilla.redhat.com/show_bug.cgi?id=1381790
> 
> Seems like the `fedora-rawhide-x86_64` chroot is not going to exist
> from now, which is IMO unnecessary change ... but what could be other
> than those "obvious" consequences for both Copr repo maintainers and
> users? Does this sound like acceptable change?

Well, its a bit confusing actually, but if I understand it right I
guess it should be ok. 

My understanding is that there will no longer be a 'rawhide'
target/repos. Instead right now they will all become 'f26' ones. Then,
when we branch f26, those will follow the branch and new f27 ones will
appear. 

Whats not at all clear is when/if there's going to be any mass adding
the new branch and rebuilding on it, or if that is up to the user? 

Personally, I would say we shouldn't do any mass rebuilding. 
If a project gets to the point where it has no builds for any active
targets we could move it to a 'archive' or just delete it as it would
indicate no one is driving/caring for the software. 

kevin




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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Kevin Fenzi]

On Wed, 12 Oct 2016 09:55:40 -0400
Josh Boyer  wrote:

> On Wed, Oct 12, 2016 at 9:38 AM, Matthew Miller
>  wrote:
> > On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote:  
> >> @Matt: does it reflect your thoughts ?  
> >
> > Looks like a great place to start -- thanks. The one change I'd
> > make is adding a separate "Critical" level, for things that will
> > have us pacing the halls (figuratively) continually bugging people,
> > pulling in favors, etc.  
> 
> I agree Jan's proposal looks like a good idea.  However, I can't but
> help notice that its necessity is driven almost entirely by the fact
> that we cannot use our existing bugzilla tool to do this job for us.
> All of the extra app stuff could be avoided if we disallowed reporters
> (or random people) to change the Severity and Priority fields.

We could request this from bugzilla folks (restrict those fields to
people in fedorabugs? Or should it be more restricted ?)

kevin


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

Re: Copr && Rawhide -- no "rolling updates" workflow

[Bowen Wang]

So it means that there will be no longer Rawhide version of Fedora, or
it is just a change of repo/target name.

Bowen

On Wed, Oct 12, 2016 at 01:11:42PM -0600, Kevin Fenzi wrote:
> On Tue, 11 Oct 2016 19:14:34 +0200
> Pavel Raiskup  wrote:
> 
> > FYI:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1381790
> > 
> > Seems like the `fedora-rawhide-x86_64` chroot is not going to exist
> > from now, which is IMO unnecessary change ... but what could be other
> > than those "obvious" consequences for both Copr repo maintainers and
> > users? Does this sound like acceptable change?
> 
> Well, its a bit confusing actually, but if I understand it right I
> guess it should be ok. 
> 
> My understanding is that there will no longer be a 'rawhide'
> target/repos. Instead right now they will all become 'f26' ones. Then,
> when we branch f26, those will follow the branch and new f27 ones will
> appear. 
> 
> Whats not at all clear is when/if there's going to be any mass adding
> the new branch and rebuilding on it, or if that is up to the user? 
> 
> Personally, I would say we shouldn't do any mass rebuilding. 
> If a project gets to the point where it has no builds for any active
> targets we could move it to a 'archive' or just delete it as it would
> indicate no one is driving/caring for the software. 
> 
> kevin
> 
> 



> ___
> 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: Copr && Rawhide -- no "rolling updates" workflow

[Kevin Fenzi]

On Wed, 12 Oct 2016 14:50:08 -0500
Bowen Wang  wrote:

> So it means that there will be no longer Rawhide version of Fedora, or
> it is just a change of repo/target name.

This is only about what/how copr is going to build against rawhide. 

Fedora rawhide is not going anywhere but onward. ;) 

kevin




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

Re: Copr && Rawhide -- no "rolling updates" workflow

[Matthew Miller]

On Wed, Oct 12, 2016 at 01:11:42PM -0600, Kevin Fenzi wrote:
> Personally, I would say we shouldn't do any mass rebuilding. 
> If a project gets to the point where it has no builds for any active
> targets we could move it to a 'archive' or just delete it as it would
> indicate no one is driving/caring for the software. 


I'd love to see non-active COPR projects automatically archived. I have
some that should be. :)


-- 
Matthew Miller

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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Matthew Miller]

On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote:
> > I agree Jan's proposal looks like a good idea.  However, I can't but
> > help notice that its necessity is driven almost entirely by the fact
> > that we cannot use our existing bugzilla tool to do this job for us.
> > All of the extra app stuff could be avoided if we disallowed reporters
> > (or random people) to change the Severity and Priority fields.
> We could request this from bugzilla folks (restrict those fields to
> people in fedorabugs? Or should it be more restricted ?)

To be useful for this purpose, it's gotta be super-restricted. I'm not
sure if that will interfere with existing workflows.

Also, I think this only solves 10% of the problem (the "how do we
indicate") part. It doesn't solve the workflow and acceptance part.


-- 
Matthew Miller

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

Schedule for Thursday's FPC Meeting (2016-10-13 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-10-13 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2016-10-13 09:00 Thu US/Pacific PDT
2016-10-13 12:00 Thu
US/Eastern EDT
2016-10-13 16:00 Thu UTC <-
2016-10-13 17:00
Thu Europe/London  BST
2016-10-13 18:00 Thu
Europe/Paris  CEST
2016-10-13 18:00 Thu
Europe/Berlin CEST
2016-10-13 21:30 Thu
Asia/Calcutta  IST
--new day--

2016-10-14 00:00 Fri Asia/Singapore SGT
2016-10-14 00:00 Fri
Asia/Hong_Kong HKT
2016-10-14 01:00 Fri
Asia/Tokyo JST
2016-10-14 02:00 Fri
Australia/BrisbaneAEST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/13

= Followups =

#topic #398 Tilde in version
.fpc 398
https://fedorahosted.org/fpc/ticket/398

#topic #558 Application/Library distinction and package splitting
.fpc 558
https://fedorahosted.org/fpc/ticket/558

#topic #610 Packaging guidelines: Check upstream tarball signatures
.fpc 610
https://fedorahosted.org/fpc/ticket/610

#topic #650 Alternate Python Interpreters
.fpc 650
https://fedorahosted.org/fpc/ticket/650

#topic #654 glibc file triggers
.fpc 654
https://fedorahosted.org/fpc/ticket/654

= New business =

#topic #655 meson buildsystem guidelines
.fpc 655
https://fedorahosted.org/fpc/ticket/655

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/13

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
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: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Josh Boyer]

On Oct 12, 2016 4:15 PM, "Matthew Miller"  wrote:
>
> On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote:
> > > I agree Jan's proposal looks like a good idea.  However, I can't but
> > > help notice that its necessity is driven almost entirely by the fact
> > > that we cannot use our existing bugzilla tool to do this job for us.
> > > All of the extra app stuff could be avoided if we disallowed reporters
> > > (or random people) to change the Severity and Priority fields.
> > We could request this from bugzilla folks (restrict those fields to
> > people in fedorabugs? Or should it be more restricted ?)
>
> To be useful for this purpose, it's gotta be super-restricted. I'm not
> sure if that will interfere with existing workflows.
>
> Also, I think this only solves 10% of the problem (the "how do we
> indicate") part. It doesn't solve the workflow and acceptance part.

True, but acceptance can be done in bugzilla too via tracker bugs.
Workflow is similar either way; people review the issues in a tool.

To be clear, I'm not adamant we use bugzilla.  I simply think it's odd to
invest in yet another custom tool and service that Fedora infrastructure
will now have to maintain and run.  How many one off solutions do we need?

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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Matthew Miller]

On Wed, Oct 12, 2016 at 04:41:31PM -0400, Josh Boyer wrote:
> To be clear, I'm not adamant we use bugzilla.  I simply think it's odd to
> invest in yet another custom tool and service that Fedora infrastructure
> will now have to maintain and run.  How many one off solutions do we need?

I was hoping we could just configure a corner of the blockerbugs app QA
already uses rather than actually having a whole new one.


-- 
Matthew Miller

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

Re: Interactive builds

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 12 October 2016 at 16:56, Richard W.M. Jones wrote:
> We've noticed that some builds are interactive.  This combined
> with a bug in our autobuilder so these builds were hanging.
> 
> However I can reproduce the same behaviour using 'fedpkg local'
> (see below).
> 
> Obviously mock or Koji must be closing stdin.
> 
> Anyway is this a bug in the packaging?

It is. Builds must be non-interactive.

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: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Wed, Oct 12, 2016 at 6:29 AM, Gerald B. Cox  wrote:
> On Tue, Oct 11, 2016 at 8:52 PM, Chris Murphy 
> wrote:
>>
>>
>> About the rewrite comment: that did not come from a developer, and is
>> definitely overstated. In any case, rewrites are not inherently bad
>> news, there's a bunch of OpenZFS videos from last yearss summit in
>> which the developers talk about various things being completely
>> rewritten from scratch, some things more than twice. So kinda par for
>> the course, and given enough time things get rewritten anyway. XFS has
>> had substantial changes over its history including numerous on disk
>> format changes even before it found its way onto Linux.
>
>
> Could be, should be, may be... that's fine - but it all says the same
> thing... they
> don't know how much time it is going to take to fix - and who knows what
> their
> priority is to get around to it.  The advantages over what already is
> available
> don't appear to be that compelling, especially when weighed with the risks.

So you are saying that you started using raid56 when it was brand new,
before it had *any* kind of persistent repairing or device replacement
and only now, due to a bug that manifests remarkably less bad than the
normal behavior of everything else (minus ZFS), are you now
complaining? So basically this is, "I want it now!" complaint. Because
all the available information has been saying don't use raid56 for
production, but you did so anyway. This is a subjective change in your
evaluation. It has nothing to do with the state of Btrfs so you really
shouldn't blame it when your requirements have clearly changed.


>
> When all this started I did some searches and found Kent Overstreet's page
> on
> bcachefs:  https://goo.gl/U0UFfN
>
> He had some words about the different filesystems - and had this to say
> about btrfs:
>
> btrfs, which was supposed to be Linux's next generation COW filesystem -
> Linux's answer to zfs. Unfortunately, too much code was written too quickly
> without focusing on getting the core design correct first, and now it has
> too many design mistakes baked into the on disk format and an enormous,
> messy codebase - bigger that xfs. It's taken far too long to stabilize as
> well - poisoning the well for future filesystems because too many people
> were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs
> multiple times and had to switch at the last minute, and server vendors who
> years ago hoped to one day roll out btrfs are now quietly migrating to xfs
> instead).

I have heard from a couple developers that it was a victim of its own
hype/success and too many feature additions without equivalent effort
on error reporting, debugging, and fault injection tools. I have yet
to hear a Btrfs developer say the core design or on disk format has
anything to do with the problems, but to the contrary. The comment
it's bigger than XFS is kinda funny, seeing as it does more than XFS,
md, and LVM combined, so a proper comparison would be comparing all of
them to Btrfs minus their user space tools (for sure Btrfs tools do
not come anywhere near the metric ass tonne of switches or
documentation in LVM or mdadm).

The Fedora report is simply nonsense. Fedora made no meaningful
attempt to switch to Btrfs once, let alone multiple times. FESCo
considered and approved it, with conditions attached. Josef kept
pushing it off because he thought it wasn't ready. And then Josef
moved on from Red Hat, and wasn't replaced. Characterizing this as
"tried to switch" and "had to switch at the last minute" is at best
hyperbole. It was a change proposal, and it never met the requirements
of either the proposer or FESCo for it to proceed further. No changes
in default happened in the installer that had to be reverted.

Perhaps the secret of fast and stable fs development is a single
developer authored file system.

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

Where is /null coming from [was Re: where is /1 coming from?]

[Matthew Miller]

On Wed, Oct 12, 2016 at 04:39:18PM +0200, Björn Esser wrote:
> >Additionally I see a file called /null with zero length!
> Same finding (/null) for me, too.

Yup. Okay, let's try this again. :)

-- 
Matthew Miller

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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Adam Williamson]

On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
> All of the extra app stuff could be avoided if we disallowed reporters
> (or random people) to change the Severity and Priority fields.

Mmm, I don't really think so. Presumably it would be maintainers who
got to set those fields, right? But they are doing so in relation to
*the package*. What's 'critical' for a given package is not necessarily
'critical' for the distribution. If there's a bug in 'some-obscure-
package-two-people-use' that prevents it running, that bug should have
maximum 'severity' (and probably 'priority'), but that still doesn't
mean Matt or Jan would give a damn about it from a 'is the release on
fire?' perspective.
-- 
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: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Wed, Oct 12, 2016 at 3:29 PM, Chris Murphy 
wrote:

> On Wed, Oct 12, 2016 at 6:29 AM, Gerald B. Cox  wrote:
> > On Tue, Oct 11, 2016 at 8:52 PM, Chris Murphy 
> > wrote:
> >>
> >>
> >> About the rewrite comment: that did not come from a developer, and is
> >> definitely overstated. In any case, rewrites are not inherently bad
> >> news, there's a bunch of OpenZFS videos from last yearss summit in
> >> which the developers talk about various things being completely
> >> rewritten from scratch, some things more than twice. So kinda par for
> >> the course, and given enough time things get rewritten anyway. XFS has
> >> had substantial changes over its history including numerous on disk
> >> format changes even before it found its way onto Linux.
> >
> >
> > Could be, should be, may be... that's fine - but it all says the same
> > thing... they
> > don't know how much time it is going to take to fix - and who knows what
> > their
> > priority is to get around to it.  The advantages over what already is
> > available
> > don't appear to be that compelling, especially when weighed with the
> risks.
>
> So you are saying that you started using raid56 when it was brand new,
> before it had *any* kind of persistent repairing or device replacement
> and only now, due to a bug that manifests remarkably less bad than the
> normal behavior of everything else (minus ZFS), are you now
> complaining? So basically this is, "I want it now!" complaint. Because
> all the available information has been saying don't use raid56 for
> production, but you did so anyway. This is a subjective change in your
> evaluation. It has nothing to do with the state of Btrfs so you really
> shouldn't blame it when your requirements have clearly changed.
>

Well no, what I said was that I thought that they might have a somewhat
stable product
after three years... instead I get that a rewrite may be required with no
idea of when it would ever
be production ready.  If you think that is acceptable, more power to you.
I do not and I would
venture to guess that many reasonable people would think three years would
be ample time.
My requirements haven't changed... I just think the time to fish or cut
bait has come.  I've cut
bait.


>
> >
> > When all this started I did some searches and found Kent Overstreet's
> page
> > on
>


> > bcachefs:  https://goo.gl/U0UFfN
>
>
> >
> > He had some words about the different filesystems - and had this to say
> > about btrfs:
> >
> > btrfs, which was supposed to be Linux's next generation COW filesystem -
> > Linux's answer to zfs. Unfortunately, too much code was written too
> quickly
> > without focusing on getting the core design correct first, and now it has
> > too many design mistakes baked into the on disk format and an enormous,
> > messy codebase - bigger that xfs. It's taken far too long to stabilize as
> > well - poisoning the well for future filesystems because too many people
> > were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs
> > multiple times and had to switch at the last minute, and server vendors
> who
> > years ago hoped to one day roll out btrfs are now quietly migrating to
> xfs
> > instead).
>
> I have heard from a couple developers that it was a victim of its own
> hype/success and too many feature additions without equivalent effort
> on error reporting, debugging, and fault injection tools. I have yet
> to hear a Btrfs developer say the core design or on disk format has
> anything to do with the problems, but to the contrary. The comment
> it's bigger than XFS is kinda funny, seeing as it does more than XFS,
> md, and LVM combined, so a proper comparison would be comparing all of
> them to Btrfs minus their user space tools (for sure Btrfs tools do
> not come anywhere near the metric ass tonne of switches or
> documentation in LVM or mdadm).
>

I can't speak for him, but don't believe that was his point.  I read it as
that the
code was bloated.

>
> The Fedora report is simply nonsense. Fedora made no meaningful
> attempt to switch to Btrfs once, let alone multiple times. FESCo
> considered and approved it, with conditions attached.


Well, we're getting into semantics here.  I would call that a serious
attempt - and there
are many articles that are available that talk about Fedora discussing
making BTRFS
a default.  If you don't consider any of those attempts "meaningful" I
suppose that's
a good thing.


> Josef kept
> pushing it off because he thought it wasn't ready.


Smart man, he was right.


> And then Josef
> moved on from Red Hat, and wasn't replaced. Characterizing this as
> "tried to switch" and "had to switch at the last minute" is at best
> hyperbole.


Ok, if you say so.  Again, that wasn't the way the media reported it.


> It was a change proposal, and it never met the requirements
> of either the proposer or FESCo for it to proceed further. No changes
> in default happened in the installer that had to be reverted.
>

So change proposals aren

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Adam Williamson]

On Wed, 2016-10-12 at 16:41 -0400, Josh Boyer wrote:
> On Oct 12, 2016 4:15 PM, "Matthew Miller"  wrote:
> > 
> > On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote:
> > > > I agree Jan's proposal looks like a good idea.  However, I can't but
> > > > help notice that its necessity is driven almost entirely by the fact
> > > > that we cannot use our existing bugzilla tool to do this job for us.
> > > > All of the extra app stuff could be avoided if we disallowed reporters
> > > > (or random people) to change the Severity and Priority fields.
> > > 
> > > We could request this from bugzilla folks (restrict those fields to
> > > people in fedorabugs? Or should it be more restricted ?)
> > 
> > To be useful for this purpose, it's gotta be super-restricted. I'm not
> > sure if that will interfere with existing workflows.
> > 
> > Also, I think this only solves 10% of the problem (the "how do we
> > indicate") part. It doesn't solve the workflow and acceptance part.
> 
> True, but acceptance can be done in bugzilla too via tracker bugs.
> Workflow is similar either way; people review the issues in a tool.
> 
> To be clear, I'm not adamant we use bugzilla.  I simply think it's odd to
> invest in yet another custom tool and service that Fedora infrastructure
> will now have to maintain and run.  How many one off solutions do we need?

For reference, we handled the blocker stuff entirely through Bugzilla
for a while. We wrote blockerbugs for a few reasons. Ones I remember:

1. Since just looking at all bugs that block the 'blocker' tracker
gives you both proposed and accepted blockers, you had to use a saved
search or something to find just proposed blockers or just accepted
blockers; blockerbugs handily groups them for you

2. None of Bugzilla's queries or anything gives you a handy view of
what updates fix what blockers, while blockerbugs does

3. Bugzilla queries are (still) slow as hell (though not quite as bad
as when we wrote blockerbugs). blockerbugs is fast (it has to run slow
Bugzilla queries to sync its data, but it just syncs every half hour,
so the user experience is fast)
-- 
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: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Jeff Fearn]

On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) slow 
as hell (though not
quite as bad
> as when we wrote blockerbugs).

I haven't seen many bugs about this since the hardware upgrade. If something is 
slow please open a bug
and we will look in to it.

It's hard to get time allocated for this kind of stuff without a list of bugs 
to put in front of
management. Every performance bug we have open will give us more leverage to 
spend some time optimizing
the query engine.

Cheers, Jeff.

-- 
Jeff Fearn
Senior Software Engineer
PnT - DevOps - Development
Red Hat Asia Pacific Pty Ltd
http://dilbert.com/fast/2004-08-17/
PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Josh Boyer]

On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
 wrote:
> On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
>> All of the extra app stuff could be avoided if we disallowed reporters
>> (or random people) to change the Severity and Priority fields.
>
> Mmm, I don't really think so. Presumably it would be maintainers who
> got to set those fields, right? But they are doing so in relation to

No, why would you presume that?

> *the package*. What's 'critical' for a given package is not necessarily
> 'critical' for the distribution. If there's a bug in 'some-obscure-
> package-two-people-use' that prevents it running, that bug should have
> maximum 'severity' (and probably 'priority'), but that still doesn't
> mean Matt or Jan would give a damn about it from a 'is the release on
> fire?' perspective.

Right.  Which speaks to Matt's "very restricted" list of people.
Which would essentially be the same group that is going to do the
categorizing anyway.  Which means that since the fields are useless
today (as in, completely) restricting them to useful to avoid another
process or tool could be a possibility.

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

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Josef Bacik]

On Wed, Oct 12, 2016 at 8:35 PM, Gerald B. Cox  wrote:
>
> On Wed, Oct 12, 2016 at 3:29 PM, Chris Murphy 
> wrote:
>>
>> On Wed, Oct 12, 2016 at 6:29 AM, Gerald B. Cox  wrote:
>> > On Tue, Oct 11, 2016 at 8:52 PM, Chris Murphy 
>> > wrote:
>> >>
>> >>
>> >> About the rewrite comment: that did not come from a developer, and is
>> >> definitely overstated. In any case, rewrites are not inherently bad
>> >> news, there's a bunch of OpenZFS videos from last yearss summit in
>> >> which the developers talk about various things being completely
>> >> rewritten from scratch, some things more than twice. So kinda par for
>> >> the course, and given enough time things get rewritten anyway. XFS has
>> >> had substantial changes over its history including numerous on disk
>> >> format changes even before it found its way onto Linux.
>> >
>> >
>> > Could be, should be, may be... that's fine - but it all says the same
>> > thing... they
>> > don't know how much time it is going to take to fix - and who knows what
>> > their
>> > priority is to get around to it.  The advantages over what already is
>> > available
>> > don't appear to be that compelling, especially when weighed with the
>> > risks.
>>
>> So you are saying that you started using raid56 when it was brand new,
>> before it had *any* kind of persistent repairing or device replacement
>> and only now, due to a bug that manifests remarkably less bad than the
>> normal behavior of everything else (minus ZFS), are you now
>> complaining? So basically this is, "I want it now!" complaint. Because
>> all the available information has been saying don't use raid56 for
>> production, but you did so anyway. This is a subjective change in your
>> evaluation. It has nothing to do with the state of Btrfs so you really
>> shouldn't blame it when your requirements have clearly changed.
>
>
> Well no, what I said was that I thought that they might have a somewhat
> stable product
> after three years... instead I get that a rewrite may be required with no
> idea of when it would ever
> be production ready.  If you think that is acceptable, more power to you.  I
> do not and I would
> venture to guess that many reasonable people would think three years would
> be ample time.
> My requirements haven't changed... I just think the time to fish or cut bait
> has come.  I've cut
> bait.
>
>>
>>
>> >
>> > When all this started I did some searches and found Kent Overstreet's
>> > page
>> > on
>
>
>>
>> > bcachefs:  https://goo.gl/U0UFfN
>>
>>
>> >
>> > He had some words about the different filesystems - and had this to say
>> > about btrfs:
>> >
>> > btrfs, which was supposed to be Linux's next generation COW filesystem -
>> > Linux's answer to zfs. Unfortunately, too much code was written too
>> > quickly
>> > without focusing on getting the core design correct first, and now it
>> > has
>> > too many design mistakes baked into the on disk format and an enormous,
>> > messy codebase - bigger that xfs. It's taken far too long to stabilize
>> > as
>> > well - poisoning the well for future filesystems because too many people
>> > were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs
>> > multiple times and had to switch at the last minute, and server vendors
>> > who
>> > years ago hoped to one day roll out btrfs are now quietly migrating to
>> > xfs
>> > instead).
>>
>> I have heard from a couple developers that it was a victim of its own
>> hype/success and too many feature additions without equivalent effort
>> on error reporting, debugging, and fault injection tools. I have yet
>> to hear a Btrfs developer say the core design or on disk format has
>> anything to do with the problems, but to the contrary. The comment
>> it's bigger than XFS is kinda funny, seeing as it does more than XFS,
>> md, and LVM combined, so a proper comparison would be comparing all of
>> them to Btrfs minus their user space tools (for sure Btrfs tools do
>> not come anywhere near the metric ass tonne of switches or
>> documentation in LVM or mdadm).
>
>
> I can't speak for him, but don't believe that was his point.  I read it as
> that the
> code was bloated.
>>
>>
>> The Fedora report is simply nonsense. Fedora made no meaningful
>> attempt to switch to Btrfs once, let alone multiple times. FESCo
>> considered and approved it, with conditions attached.
>
>
> Well, we're getting into semantics here.  I would call that a serious
> attempt - and there
> are many articles that are available that talk about Fedora discussing
> making BTRFS
> a default.  If you don't consider any of those attempts "meaningful" I
> suppose that's
> a good thing.
>
>>
>> Josef kept
>> pushing it off because he thought it wasn't ready.
>
>
> Smart man, he was right.
>
>>
>> And then Josef
>> moved on from Red Hat, and wasn't replaced. Characterizing this as
>> "tried to switch" and "had to switch at the last minute" is at best
>> hyperbole.
>
>
> Ok, if you say so.  Again, that wasn't the way the media reported 

Fedora Rawhide-20161012.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/102 (x86_64), 1/17 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20161011.n.0):

ID: 40773   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/40773

Old failures (same test failed in Rawhide-20161011.n.0):

ID: 40691   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/40691
ID: 40712   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/40712
ID: 40759   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/40759
ID: 40800   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/40800

Passed openQA tests: 99/102 (x86_64), 16/17 (i386)

New passes (same test did not pass in Rawhide-20161011.n.0):

ID: 40683   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/40683
ID: 40700   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/40700
ID: 40701   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/40701
ID: 40702   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/40702
ID: 40703   Test: x86_64 KDE-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/40703
ID: 40704   Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/40704
ID: 40705   Test: x86_64 KDE-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/40705
ID: 40706   Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/40706
ID: 40707   Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/40707
ID: 40708   Test: x86_64 KDE-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/40708
ID: 40709   Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/40709
ID: 40710   Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/40710
ID: 40711   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/40711
ID: 40742   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/40742

Skipped openQA tests: 1 of 121
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Adam Williamson]

On Thu, 2016-10-13 at 10:45 +1000, Jeff Fearn wrote:
> On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) 
> slow as hell (though not
> quite as bad
> > as when we wrote blockerbugs).
> 
> I haven't seen many bugs about this since the hardware upgrade. If something 
> is slow please open a bug
> and we will look in to it.
> 
> It's hard to get time allocated for this kind of stuff without a list of bugs 
> to put in front of
> management. Every performance bug we have open will give us more leverage to 
> spend some time optimizing
> the query engine.

It's nothing out of the ordinary, it's just...I mean, it's doing a
complex query of a gigantic database. Of course it won't be
instantaneous. It's just nice with blockerbugs that you can just go to
the URL and see the list right away.
-- 
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: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Adam Williamson]

On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
> On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
>  wrote:
> > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
> > > All of the extra app stuff could be avoided if we disallowed reporters
> > > (or random people) to change the Severity and Priority fields.
> > 
> > Mmm, I don't really think so. Presumably it would be maintainers who
> > got to set those fields, right? But they are doing so in relation to
> 
> No, why would you presume that?

I dunno, just seemed logical. That's how they're intended to be used at
present. Bug reporters aren't supposed to set them and don't have the
privilege purely by rights of having an account...but because we grant
'editbugs' to all packagers and all QA team members, in practice a lot
of the people who actually report bugs do have the power to set it.

If you're suggesting we restrict access to those fields such that even
the packagers can't use them...well, it's a possibility, but I think at
least *some* teams do actually use those fields at present, and would
be inconvenienced by not being able to any more because we'd decided to
take them over for distribution purposes.

> Right.  Which speaks to Matt's "very restricted" list of people.
> Which would essentially be the same group that is going to do the
> categorizing anyway.  Which means that since the fields are useless
> today (as in, completely) restricting them to useful to avoid another
> process or tool could be a possibility.

Well sure, but on the other hand, if all you want to propose is 'do it
all in Bugzilla', you don't really need to use those fields; just a
tracking bug works fine. Or a whiteboard field. Or a flag. Anything
searchable, really. blockerbugs is a convenience tool on top of the
blocker process, it's not *necessary*. You *can* run the entire blocker
process without it, and we used to do that.
-- 
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: F26 Self Contained Change: PHP 7.1 - mcrypt extension

[Remi Collet]

Le 11/10/2016 à 14:43, Jan Kurik a écrit :
> = Proposed Self Contained Change: PHP 7.1 =
> https://fedoraproject.org/wiki/Changes/php71


Among some minor changes, starting with 7.1, the "mcrypt" extension is
deprecated.

So latest version to fix packages which still use/require this dead cow.
Will be removed in 7.2 (probably in F28)


Remi.



P.S.1: more information about mcrypt / libmcrypt
https://blog.remirepo.net/post/2015/07/07/About-libmcrypt-and-php-mcrypt

P.S.2: mcrypt will be moved to pecl, so it will be possible to create a
php-pecl-mcrypt package, BTW, still far better to kill it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Jeff Fearn]

On 13/10/16 14:02, Adam Williamson wrote:
> On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
>> On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
>>  wrote:
>>> On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
 All of the extra app stuff could be avoided if we disallowed reporters
 (or random people) to change the Severity and Priority fields.
>>>
>>> Mmm, I don't really think so. Presumably it would be maintainers who
>>> got to set those fields, right? But they are doing so in relation to
>>
>> No, why would you presume that?
> 
> I dunno, just seemed logical. That's how they're intended to be used at
> present. Bug reporters aren't supposed to set them and don't have the
> privilege purely by rights of having an account

This is true for priority but not true for severity. Severity is the external, 
i.e. reporters, weighting
of the bug and you do not need to be in editbugs to set it.

Cheers, Jeff.

-- 
Jeff Fearn
Senior Software Engineer
PnT - DevOps - Development
Red Hat Asia Pacific Pty Ltd
http://dilbert.com/fast/2004-08-17/
PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Jeff Fearn]

On 13/10/16 13:59, Adam Williamson wrote:
> On Thu, 2016-10-13 at 10:45 +1000, Jeff Fearn wrote:
>> On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) 
>> slow as hell (though not
>> quite as bad
>>> as when we wrote blockerbugs).
>>
>> I haven't seen many bugs about this since the hardware upgrade. If something 
>> is slow please open a bug
>> and we will look in to it.
>>
>> It's hard to get time allocated for this kind of stuff without a list of 
>> bugs to put in front of
>> management. Every performance bug we have open will give us more leverage to 
>> spend some time optimizing
>> the query engine.
> 
> It's nothing out of the ordinary, it's just...I mean, it's doing a
> complex query of a gigantic database. Of course it won't be
> instantaneous. It's just nice with blockerbugs that you can just go to
> the URL and see the list right away.

:( But optimizing the query engine is more fun than fixing UI stuff...

Cheers, Jeff.

-- 
Jeff Fearn
Senior Software Engineer
PnT - DevOps - Development
Red Hat Asia Pacific Pty Ltd
http://dilbert.com/fast/2004-08-17/
PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Where is /null coming from [was Re: where is /1 coming from?]

[Ralf Corsepius]

On 10/13/2016 01:03 AM, Matthew Miller wrote:

On Wed, Oct 12, 2016 at 04:39:18PM +0200, Björn Esser wrote:

Additionally I see a file called /null with zero length!

Same finding (/null) for me, too.


Yup. Okay, let's try this again. :)



FWIW: It seems to be created at each boot.

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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Adam Williamson]

On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote:
> On 13/10/16 14:02, Adam Williamson wrote:
> > On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
> > > On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
> > >  wrote:
> > > > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
> > > > > All of the extra app stuff could be avoided if we disallowed reporters
> > > > > (or random people) to change the Severity and Priority fields.
> > > > 
> > > > Mmm, I don't really think so. Presumably it would be maintainers who
> > > > got to set those fields, right? But they are doing so in relation to
> > > 
> > > No, why would you presume that?
> > 
> > I dunno, just seemed logical. That's how they're intended to be used at
> > present. Bug reporters aren't supposed to set them and don't have the
> > privilege purely by rights of having an account
> 
> This is true for priority but not true for severity. Severity is the
> external, i.e. reporters, weighting
> of the bug and you do not need to be in editbugs to set it.

That's not the intent of the fields as I understand them. 'severity' is
supposed to represent how bad the bug is, whereas 'priority' is
supposed to represent how important it is to get it fixed compared to
other bugs in the same component. They're obviously related, but not
the same, and it's not "severity is the reporter's opinion, priority is
the maintainers' opinion", no.

I think you might be right that we allow the bug reporter to set
'severity', though.
-- 
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