Re: Ursa Major (modules in buildroot) enablement

[Raphael Groner]

Kevin,
>* that no package may ever be module-only, but 
> modules can only be used for non-default 
> versions.

That statement doesn't make any sense for me. Can you explain, please? How 
should modules live without packages in background? We'd already discussed this 
in another thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ursa Major (modules in buildroot) enablement

[Raphael Groner]

> Neal Gompa wrote:
…

> But obviously, I think this is a very poor tradeoff. Helping packagers must 
> not happen at the end users' expense!
> 
> Kevin Kofler

+1
Can you think about a time when modules can or will (hopefully) bring benefits 
to our users? Well, it's just seen as an additional feature of many Features 
like we expect from Fedora. Where's Friends, First, Freedom?!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libmodulemd is missing from EPEL7 branch

[Qixiang Wan]

Hi,

This is for an issue we encountered while building Ursa-Major on EPEL7
branch [1], the build task failed due to missing libmodulemd, seems
libmodulemd was retired on EPEL7 because it's available in RHEL7.6,
but our buildroot is still RHEL7.5, see log from task 30747718 which
shows the os release [2]:

+ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.5 (Maipo)
+ rpm -qf /etc/redhat-release
redhat-release-server-7.5-1.ppc64le

Could someone help to fix this?

[1]  https://bugzilla.redhat.com/show_bug.cgi?id=1644194
[2] https://kojipkgs.fedoraproject.org//work/tasks/7718/30747718/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ursa Major (modules in buildroot) enablement

[Kevin Kofler]

Neal Gompa wrote:
> Moreover, as it stands, I don't think modularity provides any quality
> of life improvements for packagers within Fedora (it adds extra steps
> and makes it confusing to figure out what is maintained),

There is one I can see in that it allows packagers to make their packages 
depend on incompatible library versions, which makes their job easier (by 
not having to care about compatibility, patching for different library 
versions, etc.) at the expense of the users that are left with an unsolvable 
Module Hell and the total impossibility to install the software they need.

But obviously, I think this is a very poor tradeoff. Helping packagers must 
not happen at the end users' expense!

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ursa Major (modules in buildroot) enablement

[Kevin Kofler]

Stephen Gallagher wrote:
> The feedback that we (Red Hat) got about SCLs that was filtered down
> to Engineering was this:

But is that feedback relevant for Fedora, as opposed to RHEL?

> 1) Customers really like having the option to install the version of
> software that their applications needs from a trusted source (the OS
> vendor/distributor)

Fedora is normally about having the latest version of everything available. 
(That's what the "First" in the 4 'F's stands for.) So it rarely happens 
that the default version is too old. And if the default version is too new 
for the user, that is generally filed in the PEBKAC category. ;-)

> 2) Customers really *dislike* needing to modify their software to
> understand the SCL enablement process.

That is a non-issue if everything uses the latest version, as it is supposed 
to. And we never allowed SCLs in Fedora to begin with.

> 3) Customers very rarely need to install different versions of the
> same software on the same system. They use containers or VMs for
> separate applications.

I don't see this being the case for Fedora users at all. A container for 
every single application is something some large-scale deployments of RHEL 
may be doing. But the average Fedora user is a home user with one or two 
(desktop and notebook) computers running a single Fedora installation each. 
They do not want to have to deal with the added complexity of containers, 
and container technologies such as Flatpak or Snap that try to hide the 
container from the user do not allow the user to upgrade the libraries in 
the container and so often suffer from delayed or absent security updates 
(because the whole container or the whole runtime has to be respun by the 
maintainer to provide them, and then the user has to upgrade to the respun 
image).

So I think that having things in Fedora that are not parallel-installable is 
not a good idea, at all. There is a reason that the guideline on Conflicts 
says to avoid it at all costs, and that compatibility libraries, in 
particular, are NOT allowed to conflict at runtime (Conflicts are only 
tolerated in the -devel packages, and discouraged even there).

It really worries me that we are allowing Fedora-provided packages to depend 
on arbitrary branches of modular packages (modular Fedora packages can 
already do that, Ursa Major would apparently extend that possibility even to 
normal packages), because that can easily lead to Module Hell (RPM Hell 
2.0), where application A requires module Foo version n whereas application 
B requires module Foo version m (and obviously versions n and m of Foo are 
not compatible). So the user is stuck being unable to install applications A 
and B from our repository. That is something that should NEVER happen in a 
consistent distribution. (Avoiding that is the main job of a distribution!)

> So with Modularity, we opted to drop the parallel-installability
> requirement in favor of parallel-*availability* and the ability to
> keep the packages installing in the standard locations (/usr/bin,
> /usr/lib64, etc.)
> 
> This *is* a net improvement for the vast majority of deployments.

Sure, the SCL hack with its non-FHS-compliance is a bad idea, too, but that 
was never allowed in Fedora for a reason.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi update pushes are now automated

[Matthew Miller]

On Wed, Nov 07, 2018 at 11:44:29AM -0500, Mohan Boddu wrote:
> Now, the pushes are automated and are pushed everyday at 00:00 UTC. If
> anything fails there will be an oncall person (same person who used to do
> the pushes) who will take care of the failure.

Amazing! Congratulations!


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unretire recordmydesktop

[Alex Thomas]

On Thu, Nov 8, 2018 at 10:40 AM Richard W.M. Jones 
wrote:

> On Thu, Nov 08, 2018 at 12:59:40PM +0100, Felipe Borges wrote:
> > On Tue, Nov 6, 2018 at 8:19 PM Samuel Sieb  wrote:
> > >
> > > On 11/6/18 6:21 AM, Jiri Eischmann wrote:
> > > > Samuel Sieb píše v Po 05. 11. 2018 v 17:07 -0800:
> > > >> On 11/5/18 12:47 PM, Adam Williamson wrote:
> > > >>> On Sun, 2018-11-04 at 16:42 -0800, Samuel Sieb wrote:
> > >  I don't know about the other bugs, but not working on Wayland
> > >  can't be
> > >  held against it.  Nothing works to record the desktop on Wayland
> > >  since
> > >  that isn't supported yet.
> > > >>>
> > > >>> GNOME's inbuilt screen recorder does it fine.
> > > >>
> > > >> Does that use a Gnome shell-specific API or does Wayland have
> > > >> support
> > > >> for that now?
> > > >
> > > > You can either use Mutter API (several utilities can do that, not
> only
> > > > the built-in tool) or newly PipeWire. Works both on Wayland and Xorg.
> > > > Screen recording (or more precisely providing apps with screen
> frames)
> > > > is not something Wayland as a protocol covers and plans to cover.
> > >
> > > Then it's time to port vino to PipeWire, so I don't have to disable
> > > Wayland on all the systems I install.
> >
> > See https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
>
> >When is Wayland going to get X11-style >remote applications support?
>
> >Rich.
>

When someone big tells RH that RHEL 8 w/ wayland is a non starter until
that is fixed. Same way that you finally got local plain text logs under
systemd.

>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-packager purpose and future

[Mohan Boddu]

Hi,

There was some communication gap and I didn't pay much attention to that
package.

I am very much interested in maintaining the package going forward.

Sorry for the confusion that I have caused. Please create the PR's if
anything is needed,
and I will take care of it.

I will also go ahead and clear up some clutter asap.

Thanks.

On Thu, Nov 8, 2018 at 5:30 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Thursday, 08 November 2018 at 10:32, Vít Ondruch wrote:
> [...]
> > Just browsing the upstream, these should be removed or updated:
> >
> >
> > https://pagure.io/fedora-packager/blob/master/f/src/rpmbuild-md5
> >
> > (What was is good for anyway??)
>
> Building RPMs for RHEL5.
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unretire recordmydesktop

[Richard W.M. Jones]

On Thu, Nov 08, 2018 at 12:59:40PM +0100, Felipe Borges wrote:
> On Tue, Nov 6, 2018 at 8:19 PM Samuel Sieb  wrote:
> >
> > On 11/6/18 6:21 AM, Jiri Eischmann wrote:
> > > Samuel Sieb píše v Po 05. 11. 2018 v 17:07 -0800:
> > >> On 11/5/18 12:47 PM, Adam Williamson wrote:
> > >>> On Sun, 2018-11-04 at 16:42 -0800, Samuel Sieb wrote:
> >  I don't know about the other bugs, but not working on Wayland
> >  can't be
> >  held against it.  Nothing works to record the desktop on Wayland
> >  since
> >  that isn't supported yet.
> > >>>
> > >>> GNOME's inbuilt screen recorder does it fine.
> > >>
> > >> Does that use a Gnome shell-specific API or does Wayland have
> > >> support
> > >> for that now?
> > >
> > > You can either use Mutter API (several utilities can do that, not only
> > > the built-in tool) or newly PipeWire. Works both on Wayland and Xorg.
> > > Screen recording (or more precisely providing apps with screen frames)
> > > is not something Wayland as a protocol covers and plans to cover.
> >
> > Then it's time to port vino to PipeWire, so I don't have to disable
> > Wayland on all the systems I install.
> 
> See https://wiki.gnome.org/Projects/Mutter/RemoteDesktop

When is Wayland going to get X11-style remote applications support?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora's OpenH264 repo issue

[Mohan Boddu]

I am working with Cisco on fixing this. We got an email from Cisco that the
rpms are available on their CDN.

So, we pushed the repodata on our end. But it seems they are still not
available on their CDN.

On Thu, Nov 8, 2018 at 6:03 AM Peter Robinson  wrote:

> https://pagure.io/releng/issue/7590
>
> On Thu, Nov 8, 2018 at 10:51 AM Jan Pokorný  wrote:
> >
> > Not sure where to report this for the Fedora side, but there seems to
> > be some synchronization issue regarding the built artifacts hosted at
> > http://ciscobinary.openh264.org, since older packages can be obtained
> > just fine:
> > https://github.com/cisco/openh264/issues/3037#issuecomment-436932562
> >
> > --
> > Jan (Poki)
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi update pushes are now automated

[Randy Barlow]

On Thu, 2018-11-08 at 08:07 +, Zbigniew Jędrzejewski-Szmek wrote:
> The 'Autopush' happens when the update reaches the karma threshold.
> It 
> > is not applied based on days in testing.
> 
> That's what I thought. This seems bad to me, because it is yet
> another
> thing that I need to poke by hand. What I want is that after the
> update
> is filed, I never have to think about it again unless somebody
> provides
> negative feedback.

FWIW, I am beginning to work on a proposal for a new updates policy and
I plan for this to be part of it - the update will by default go stable
unless a human stops it.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Vagrant dependencies updated in Rawhide

[Vít Ondruch]

Hi Vagrant users,

If you are using Vagrant together with libvirt backend (default on
Fedora), please be warned that today, I have updated fog-libvirt
(dependency of vagrant-libvrit) and its dependencies in Rawhide. Because
fog upstream is currently a bit of a mess, where some major
sub-components are not compatible between each other, it might be that I
missed something and Vagrant might not work for you anymore. In that
case I apologize and please fill the bug via regular channels.

Thx for your attention.


Vít

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NSS package consolidation

[Tom Hughes]

On 08/11/2018 14:00, Vít Ondruch wrote:


Dne 08. 11. 18 v 13:04 Tom Hughes napsal(a):

On 08/11/2018 11:44, Daiki Ueno wrote:


The question is, is there any documented procedure to do this kind of
package merge safely?  I guess at least the unnecessary packages
(nss-util and nss-softokn) would need to be retired.


Just follow the normal procedures for replacing packages:

https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages


So have the new merged nss obsolete the old versions of
nss-util and nss-softokn and then retire them.



I don't see any reason why the old versions should be explicitly
obsoleted, if the nss package is going to provide precisely the same
packages set. Just retiring should be fine IMO.


Oh sorry I misread the message and thought the goal was to produce
one binary rpm.

If it's going to one source rpm producing the same three binary
rpms then you are indeed correct.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NSS package consolidation

[Vít Ondruch]

Dne 08. 11. 18 v 13:04 Tom Hughes napsal(a):
> On 08/11/2018 11:44, Daiki Ueno wrote:
>
>> The question is, is there any documented procedure to do this kind of
>> package merge safely?  I guess at least the unnecessary packages
>> (nss-util and nss-softokn) would need to be retired.
>
> Just follow the normal procedures for replacing packages:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
>
>
> So have the new merged nss obsolete the old versions of
> nss-util and nss-softokn and then retire them.


I don't see any reason why the old versions should be explicitly
obsoleted, if the nss package is going to provide precisely the same
packages set. Just retiring should be fine IMO.


V.


>
> Tom
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NSS package consolidation

[Tom Hughes]

On 08/11/2018 11:44, Daiki Ueno wrote:


The question is, is there any documented procedure to do this kind of
package merge safely?  I guess at least the unnecessary packages
(nss-util and nss-softokn) would need to be retired.


Just follow the normal procedures for replacing packages:

https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

So have the new merged nss obsolete the old versions of
nss-util and nss-softokn and then retire them.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unretire recordmydesktop

[Felipe Borges]

On Tue, Nov 6, 2018 at 8:19 PM Samuel Sieb  wrote:
>
> On 11/6/18 6:21 AM, Jiri Eischmann wrote:
> > Samuel Sieb píše v Po 05. 11. 2018 v 17:07 -0800:
> >> On 11/5/18 12:47 PM, Adam Williamson wrote:
> >>> On Sun, 2018-11-04 at 16:42 -0800, Samuel Sieb wrote:
>  I don't know about the other bugs, but not working on Wayland
>  can't be
>  held against it.  Nothing works to record the desktop on Wayland
>  since
>  that isn't supported yet.
> >>>
> >>> GNOME's inbuilt screen recorder does it fine.
> >>
> >> Does that use a Gnome shell-specific API or does Wayland have
> >> support
> >> for that now?
> >
> > You can either use Mutter API (several utilities can do that, not only
> > the built-in tool) or newly PipeWire. Works both on Wayland and Xorg.
> > Screen recording (or more precisely providing apps with screen frames)
> > is not something Wayland as a protocol covers and plans to cover.
>
> Then it's time to port vino to PipeWire, so I don't have to disable
> Wayland on all the systems I install.

See https://wiki.gnome.org/Projects/Mutter/RemoteDesktop

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

NSS package consolidation

[Daiki Ueno]

Hello,

We currently have 3 source packages for NSS (nss-util, nss-softokn, and
nss), split from upstream release tarball.  This splitting was
introduced for FIPS certification purposes in RHEL, where only
nss-softokn part is certified.

In Fedora, however, this doesn't apply (as we don't certify), and had
rather caused troubles, such as upgrade path issues, incomplete
buildroot overrides, etc.

Therefore we are considering merging those source packages back into a
single package[1].  The same set of binary packages will still be
produced and they should be compatible with the current ones.

The question is, is there any documented procedure to do this kind of
package merge safely?  I guess at least the unnecessary packages
(nss-util and nss-softokn) would need to be retired.

Suggestions appreciated.


Footnotes:
[1]  https://src.fedoraproject.org/rpms/nss/pull-request/3

Regards,
-- 
Daiki Ueno
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora's OpenH264 repo issue

[Peter Robinson]

https://pagure.io/releng/issue/7590

On Thu, Nov 8, 2018 at 10:51 AM Jan Pokorný  wrote:
>
> Not sure where to report this for the Fedora side, but there seems to
> be some synchronization issue regarding the built artifacts hosted at
> http://ciscobinary.openh264.org, since older packages can be obtained
> just fine:
> https://github.com/cisco/openh264/issues/3037#issuecomment-436932562
>
> --
> Jan (Poki)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Commit notifications for Fedora dist-git

[Florian Weimer]

* Kevin Fenzi:

> On 11/1/18 6:51 AM, Florian Weimer wrote:
>> On src.fedoraproject.org, I selected “Watch Issues, PRs, and Commits”
>> for various packages and assumed that I would receive notifications for
>> new commits.  But nothing arrives anymore, as far as I can tell.
>> 
>> Obviously, this is problematic if proven packages do uncoordinated
>> package changes.
>> 
>> What can we do here?  I can filter down scm-commits, but I don't know
>> how complete those notifications are.
>
> Something is clearly broken here, can you file a infrastructure or
> pagure ticket on it and we can try and figure out whats going on?
>
> This should work.



Maybe it's just a UI issue and the message bus filter still gets
applied, but that's not clear from the Pagure web interface at all.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-packager purpose and future

[Dominik 'Rathann' Mierzejewski]

On Thursday, 08 November 2018 at 10:32, Vít Ondruch wrote:
[...]
> Just browsing the upstream, these should be removed or updated:
> 
> 
> https://pagure.io/fedora-packager/blob/master/f/src/rpmbuild-md5
> 
> (What was is good for anyway??)

Building RPMs for RHEL5.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora's OpenH264 repo issue

[Kamil Paral]

On Thu, Nov 8, 2018 at 11:00 AM Jan Pokorný  wrote:

> Not sure where to report this for the Fedora side, but there seems to
> be some synchronization issue regarding the built artifacts hosted at
> http://ciscobinary.openh264.org, since older packages can be obtained
> just fine:
> https://github.com/cisco/openh264/issues/3037#issuecomment-436932562
>

I suppose either infra or releng team is managing this. If nobody qualified
responds here, please try to file a ticket in their trackers, thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora's OpenH264 repo issue

[Jan Pokorný]

Not sure where to report this for the Fedora side, but there seems to
be some synchronization issue regarding the built artifacts hosted at
http://ciscobinary.openh264.org, since older packages can be obtained
just fine:
https://github.com/cisco/openh264/issues/3037#issuecomment-436932562

-- 
Jan (Poki)


pgp1jxaanH_Ek.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Empty debugsources.list file when building a package

[Martin Gansser]

ok, rpmlint give me a hint:

vdr-osd2web.x86_64: E: executable-marked-as-config-file 
/etc/vdr/plugins/osd2web/startBrowser.sh
Executables must not be marked as config files because that may prevent
upgrades from working correctly. If you need to be able to customize an
executable, make it for example read a config file in /etc/sysconfig.

solved with:
# fix the perm due E: executable-marked-as-config-file
chmod 0755 %{buildroot}/%{vdr_plugindir}/libvdr-*.so.%{vdr_apiversion}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-packager purpose and future

[Vít Ondruch]

Dne 08. 11. 18 v 10:03 Vít Ondruch napsal(a):
>
>
> Dne 08. 11. 18 v 1:57 Kevin Fenzi napsal(a):
>> On 11/7/18 9:22 AM, Miro Hrončok wrote:
>>> On 05. 09. 18 9:38, Vít Ondruch wrote:
 Dne 4.9.2018 v 21:46 Rex Dieter napsal(a):
> Ben Rosser wrote:
>
>> On Tue, Sep 4, 2018 at 2:59 PM, Rex Dieter 
>> wrote:
>>> Vít Ondruch wrote:
>>>
 This is a bit unfortunate considering this is package
 every Fedora packager has to have installed
>>> I don't think that's true, can you explain?
>> Well, the "join the package collection maintainers" document
>> explicitly tells new packagers to install fedora-packager, because it
>> will "bring in everything necessary for general packaging work".
> Sorry, I was going off the $SUBJECT that referened "fedora-package",
> which
> didn't exist as far as I could tell.  *fedora-packager*, yes indeed.
 Sorry for the typo and confusion. I was speaking about fedora-packager
 indeed.

 And people need it not just because the "join ..." page suggests that,
 but there appears to be circular dependency between fedpkg and
 fedora-packager, presumably because fedora-pacakger ships some
 configuration files for koji, etc.

 I think that the idea behind this package was to have everything
 possibly needed by Fedora packager installed by single package. But when
 it is not maintained, then it somehow looses its point.
>>> I'd like to revisit this discussion.
>>>
>>> Can we get rid of that package or make it maintained again?
>> As far as I can tell it is maintained. After that last thread I talked
>> with the maintainers and they merged / answered all ourstanding PR's as
>> far as I know.
>>
>> If there's more to do, PR's welcome I am sure.
>
>
> So what about opened tickets in upstream? If it was maintained, there
> would be non or at least there would not be opened tickets such as
> [1]. Click on "merge" button once somebody loudly complains is not
> maintenance IMO.
>

Just browsing the upstream, these should be removed or updated:


https://pagure.io/fedora-packager/blob/master/f/src/rpmbuild-md5

(What was is good for anyway??)

https://pagure.io/fedora-packager/blob/master/f/src/fedoradev-pkgowners

https://pagure.io/fedora-packager/blob/master/f/src/getPackages.sh

https://pagure.io/fedora-packager/blob/master/f/src/fedora-qa

https://pagure.io/fedora-packager/blob/master/f/src/fedora-hosted.py

https://pagure.io/fedora-packager/blob/master/f/src/fedora-cert.py

(Not sure, but since kerberos, this is probably useless)


This is two thirds of the repository content. Again, I can't see how
this is maintained.


V.


>
> V.
>
>
>
> [1] https://pagure.io/fedora-packager/issue/138
>
>
>> kevin
>>
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I'm dropping libreoffice-gtk2

[Caolán McNamara]

In favour of the libreoffice-gtk3 which has already been the default
for the last few fedora releases
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Empty debugsources.list file when building a package

[Martin Gansser]

Hi,

i get this message, when building the package with spec file:

Processing files: vdr-osd2web-debugsource-0.2.48-1.fc29.x86_64
error: Empty %files file 
/home/martin/rpmbuild/BUILD/vdr-plugin-osd2web-0.2.48/debugsourcefiles.list

RPM build errors:
Macro expanded in comment on line 3: %{nil}

Empty %files file 
/home/martin/rpmbuild/BUILD/vdr-plugin-osd2web-0.2.48/debugsourcefiles.list

What should I do? you can see my specfile [2]

[1] 
https://martinkg.fedorapeople.org/Packages/vdr-osd2web/vdr-osd2web-0.2.48-1.fc29.src.rpm
[2] https://martinkg.fedorapeople.org/Packages/vdr-osd2web/vdr-osd2web.spec

Thanks
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-packager purpose and future

[Vít Ondruch]

Dne 08. 11. 18 v 1:57 Kevin Fenzi napsal(a):
> On 11/7/18 9:22 AM, Miro Hrončok wrote:
>> On 05. 09. 18 9:38, Vít Ondruch wrote:
>>>
>>> Dne 4.9.2018 v 21:46 Rex Dieter napsal(a):
 Ben Rosser wrote:

> On Tue, Sep 4, 2018 at 2:59 PM, Rex Dieter 
> wrote:
>> Vít Ondruch wrote:
>>
>>> This is a bit unfortunate considering this is package
>>> every Fedora packager has to have installed
>> I don't think that's true, can you explain?
> Well, the "join the package collection maintainers" document
> explicitly tells new packagers to install fedora-packager, because it
> will "bring in everything necessary for general packaging work".
 Sorry, I was going off the $SUBJECT that referened "fedora-package",
 which
 didn't exist as far as I could tell.  *fedora-packager*, yes indeed.
>>> Sorry for the typo and confusion. I was speaking about fedora-packager
>>> indeed.
>>>
>>> And people need it not just because the "join ..." page suggests that,
>>> but there appears to be circular dependency between fedpkg and
>>> fedora-packager, presumably because fedora-pacakger ships some
>>> configuration files for koji, etc.
>>>
>>> I think that the idea behind this package was to have everything
>>> possibly needed by Fedora packager installed by single package. But when
>>> it is not maintained, then it somehow looses its point.
>> I'd like to revisit this discussion.
>>
>> Can we get rid of that package or make it maintained again?
> As far as I can tell it is maintained. After that last thread I talked
> with the maintainers and they merged / answered all ourstanding PR's as
> far as I know.
>
> If there's more to do, PR's welcome I am sure.


So what about opened tickets in upstream? If it was maintained, there
would be non or at least there would not be opened tickets such as [1].
Click on "merge" button once somebody loudly complains is not
maintenance IMO.


V.



[1] https://pagure.io/fedora-packager/issue/138


>
> kevin
>
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi update pushes are now automated

[Mattia Verga]

Il 11/8/18 9:07 AM, Zbigniew Jędrzejewski-Szmek ha scritto:
> On Thu, Nov 08, 2018 at 07:25:10AM +, Mattia Verga wrote:
>
> That's what I thought. This seems bad to me, because it is yet another
> thing that I need to poke by hand. What I want is that after the update
> is filed, I never have to think about it again unless somebody provides
> negative feedback.
>
> Zbyszek

It seems there's already a request for enhancement filled in:

https://github.com/fedora-infra/bodhi/issues/1803

I'll try to work it out.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi update pushes are now automated

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 08, 2018 at 07:25:10AM +, Mattia Verga wrote:
> Il 11/8/18 8:00 AM, Zbigniew Jędrzejewski-Szmek ha scritto:
> >
> > What about this part? There's an "Autopush — enabled" item in bodhi, but
> > afaict, it doesn't do anything and I always click "push to batched" manually
> > on all updates. I'd like to have the update got to batched automatically
> > once the 7 days of waiting are up.
> >
> > Zbyszek
> >
> >
> The 'Autopush' happens when the update reaches the karma threshold. It 
> is not applied based on days in testing.

That's what I thought. This seems bad to me, because it is yet another
thing that I need to poke by hand. What I want is that after the update
is filed, I never have to think about it again unless somebody provides
negative feedback.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org