Re: Can we maybe reduce the set of packages we install by default a bit?

[Lennart Poettering]

On Di, 09.04.19 10:11, Adam Williamson (adamw...@fedoraproject.org) wrote:

> Basically, anything that's part of the install environment is going to
> be present after a live install. That accounts for both of the above:
> the installer supports multipath and dmraid storage devices, so the
> relevant packages are part of the install environment, so they're part
> of the lives, so they're installed by a live install.

Hmm, but the installed OS is not 100% the same as the livesys, or is
it? If not, it should be possible to add a "systemctl disable
dmraid.service --root=/path/to/os" somewhere, no?

> To be specific here, 'at' is part of the @standard group. 'chrony'
> is

Yupp, it's very confusing that we have chrony and cronie in our OS
and both are installed by default... ;-)

> > I don't know on this. I remember something about containers and flatpaks
> > but .. I don't know.
>
> Boxes is a key component of Workstation, and it relies on libvirt. It's
> in the 'Core Applications' definition of the Workstation tech spec:

Hmm, but boxes supposedly uses the user session version of libvirt,
no? it doesn't actually use the system service?

I mean, I am even fine if that gets instaleld by default and is
listening on a local IPC socket, but why does it have to run all the
time? activation by socket and exit-on-idle should be fine too.

Very similar is actually "fwupd", why does that need to run all the
time? Seems like something that should be bus activatable, and
exit-on-idle, but why run it all the time?

Lennart

--
Lennart Poettering, Berlin
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Japheth Cleaver]

On 4/9/2019 11:14 AM, Lennart Poettering wrote:

On Di, 09.04.19 12:54, Stephen John Smoogen (smo...@gmail.com) wrote:


This is more about socializing and teaching the systemd replacements...
because most of the systemd advocates and heavy users I have asked aren't
sure about how systemd replaces them and go back to cron/atd. I actually
think that the replacements seem much better thought out than cruft-ware
but.. but I also have little confidence I could get it to work consistently
while I can find 10k tutorials on cron.

Well, we addresses similar cases by placing README files or so in
those directories, so that people might notice if they are looking for
something there... i.e. /var/log/README is a similar case and
/etc/inittab too. I think we can do the same here too and make clear
that people need to install cronie first before these things work.

Alternatively. just drop the cron dropin dirs from the base image: if
i want to drop in a script in the dirs I should notice if I can't
because the dir doesn't actually exist.

Is this really worth the effort? cronie in F30 is a 103K package, and a 
decent chunk of that might be the ChangeLog. crontabs is all of 18K, 
which is 95% the GPL and the RPM header. It seems like a very small 
price to pay for something everyone is going to assume will be on any 
*nix-compatible system of note.


The last thing I'd want to have to deal with is solving for a missing 
/etc/cron.* because someone forgot to click a checkbox somewhere or 
didn't call it out in kickstart.


-jc
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Richard Hughes]

On Tue, 9 Apr 2019 at 19:27, Lennart Poettering  wrote:
> Hmm? Can you elaborate? Why does fwupd's runtime have something to do
> with display flickers? Not grokking the connection?

More information in
https://github.com/hughsie/fwupd/commit/75b965d01d80d70ae51816acd4d4cafdaf792e99
-- in the case of MST it's where a fake monitor gets created on the
hardware so the chip can wake up enough to tell us the current
firmware version, but the fake monitor causes a flicker for a couple
of reasons. I guess we could always just cache the last known version
in some database somewhere and just assume it's not changed, but if
we're not "alive" to see the device removal/insertion event we don't
know the true state of the hardware. If you're worried about the
startup speed or memory usage, we've been pretty keenly fixing both,
but if you have any specific concerns let me know.

Richard.
___
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: Sphinx and xindy

[Brian C. Lane]

On Mon, Apr 08, 2019 at 08:57:22AM -0600, Jerry James wrote:
> On Mon, Apr 1, 2019 at 9:36 PM Jerry James  wrote:
> > That was, in fact, an s390x-specific gcc bug, now fixed in Rawhide.
> > Sadly, the clisp build is still failing in Rawhide, with failures in
> > the socket tests:
> 
> The failing test attempts to bind to localhost:9090.  Apparently

FYI port 9090 is used by cockpit.

-- 
Brian C. Lane (PST8PDT)
___
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 Rawhide-20190409.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost raw-xz x86_64
Atomichost qcow2 x86_64

Compose FAILS proposed Rawhide gating check!
17 of 47 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 35/144 (x86_64), 7/24 (i386), 1/2 (arm)

ID: 380088  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/380088
ID: 380089  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/380089
ID: 380093  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/380093
ID: 380094  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/380094
ID: 380096  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/380096
ID: 380104  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/380104
ID: 380110  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/380110
ID: 380111  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/380111
ID: 380112  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/380112
ID: 380116  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380116
ID: 380117  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/380117
ID: 380119  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/380119
ID: 380120  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/380120
ID: 380121  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/380121
ID: 380123  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380123
ID: 380125  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380125
ID: 380135  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/380135
ID: 380136  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380136
ID: 380138  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/380138
ID: 380139  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/380139
ID: 380141  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/380141
ID: 380157  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/380157
ID: 380159  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/380159
ID: 380160  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/380160
ID: 380161  Test: x86_64 Silverblue-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/380161
ID: 380171  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/380171
ID: 380178  Test: x86_64 universal install_kickstart_firewall_configured 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380178
ID: 380180  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/380180
ID: 380192  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/380192
ID: 380197  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/380197
ID: 380199  Test: x86_64 universal install_kickstart_user_creation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380199
ID: 380214  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/380214
ID: 380215  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/380215
ID: 380223  Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/380223
ID: 380227  Test: x86_64 universal install_sata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/380227
ID: 380232  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/380232
ID: 380237  Test: x86_64 universal install_kickstart_firewall_disabled 
**GATING**
URL: 

Re: Can we maybe reduce the set of packages we install by default a bit?

[Lennart Poettering]

On Di, 09.04.19 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
> > multipathd [...] And beyond that, this daemon is really ugly too: it logs
> >at high log levels during boot that it found no configuration and
> >hence nothing to do. Yes, obviously, but that's a reason to shut up
> >and proceed quickly, not to complain loudly about that so that it
> >even appears on the scren (I mean srsly, this is the first thing I
> >saw when i booted from the fedora live media: a log message printed
> >all over the screen that multipathd has no working
> >configuration...).
>
> This was supposed to be fixed 
> https://bugzilla.redhat.com/show_bug.cgi?id=1631772.
> If not, please reopen that bug.

Appears to be a problem still. Commented there...

> > 5. libvirtd. Why is this running? Can't we make this socket
> >activatable + exit-on-idel?
>
> This was supposed to happen. See
> https://bugzilla.redhat.com/show_bug.cgi?id=1290357.

But it's what I see here. :-(

Lennart

--
Lennart Poettering, Berlin
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Adam Williamson]

On Tue, 2019-04-09 at 20:20 +0200, Lennart Poettering wrote:
> On Di, 09.04.19 10:11, Adam Williamson (adamw...@fedoraproject.org) wrote:
> 
> > Basically, anything that's part of the install environment is going to
> > be present after a live install. That accounts for both of the above:
> > the installer supports multipath and dmraid storage devices, so the
> > relevant packages are part of the install environment, so they're part
> > of the lives, so they're installed by a live install.
> 
> Hmm, but the installed OS is not 100% the same as the livesys, or is
> it? If not, it should be possible to add a "systemctl disable
> dmraid.service --root=/path/to/os" somewhere, no?

It's possible, sure. Every bit of post-install tinkering added to
anaconda is another thing anaconda has to maintain and that could go
wrong or become stale, is the argument against it, I think. But anyone
can send a pull request. :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 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: Can we maybe reduce the set of packages we install by default a bit?

[Cole Robinson]

On 4/9/19 2:20 PM, Lennart Poettering wrote:
> On Di, 09.04.19 10:11, Adam Williamson (adamw...@fedoraproject.org) wrote:
> 
>> Basically, anything that's part of the install environment is going to
>> be present after a live install. That accounts for both of the above:
>> the installer supports multipath and dmraid storage devices, so the
>> relevant packages are part of the install environment, so they're part
>> of the lives, so they're installed by a live install.
> 
> Hmm, but the installed OS is not 100% the same as the livesys, or is
> it? If not, it should be possible to add a "systemctl disable
> dmraid.service --root=/path/to/os" somewhere, no?
> 
>> To be specific here, 'at' is part of the @standard group. 'chrony'
>> is
> 
> Yupp, it's very confusing that we have chrony and cronie in our OS
> and both are installed by default... ;-)
> 
>>> I don't know on this. I remember something about containers and flatpaks
>>> but .. I don't know.
>>
>> Boxes is a key component of Workstation, and it relies on libvirt. It's
>> in the 'Core Applications' definition of the Workstation tech spec:
> 
> Hmm, but boxes supposedly uses the user session version of libvirt,
> no? it doesn't actually use the system service?
> 

You're right it does not explicitly talk to the system libvirtd
instance. But boxes implicitly depends on system libvirtd to autostart
the 'default' virtual network, which is the preferred networking method.
boxes VMs then essentially use a small setuid helper shipped with qemu
to use the default virbr0 for unprivileged VMs.

Thanks,
Cole
___
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: Could not execute import_srpm

[Todd Zullinger]

Antonio Trande wrote:
> On 09/04/19 22:29, Kevin Fenzi wrote:
>> Can any of you folks seeing this:
>> 
>> Run this script:
>> https://paste.fedoraproject.org/paste/tWt5LBT13-~d22wBpo38uQ/raw
>> 
>> and send me the output?
> 
> Sorry,
> 
> how this script works?

You can download the script (using Patrick's fedorapeople
URL is probably simplest):

$ curl -O https://puiterwijk.fedorapeople.org/fedpkg_new-sources.sh

Then make it executable and run it:

$ chmod +x fedpkg_new-sources.sh
$ ./fedpkg_new-sources.sh
Usage: ./fedpkg_new-sources.sh rpms/project filename

As the usage says, there are two arguments.  One is the
package name (with rpms/ prefixed in most cases).  The
second is the file you want to upload, just as you would
pass to the 'fedpkg new-sources' command.

In your case, the error occurred when trying to upload
smoldyn-2.58.tgz, so based on the path in your error
message, you'd want to run the following:

$ ./fedpkg_new-sources.sh rpms/smoldyn 
/home/sagitter/rpmbuild/SRPMS/fedora-scm/smoldyn/smoldyn-2.58.tgz

-- 
Todd


signature.asc
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: Can we maybe reduce the set of packages we install by default a bit?

[Neal Gompa]

On Tue, Apr 9, 2019 at 1:11 PM Adam Williamson
 wrote:
>
> On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote:
> > On Tue, 9 Apr 2019 at 12:07, Lennart Poettering 
> > wrote:
> >
> > > Heya,
> > >
> > > today I installed the current Fedora 30 Workstation beta on my new
> > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> > > crashed five times or so on me, always kicking me out of anaconda
> > > again, just because I wanted to undo something). But I don't really
> > > want to discuss that. What I do want to discuss is this:
> > >
> > > Can we maybe reduce the default set of packages a bit? In particular
> > > the following ones I really don't think should be in our default
> > > install:
> > >
> > >
> > This is not the first time this has come up and I expect it won't be the
> > last time.
> >
> > I think the main reason they stick around is that the people who want them
> > gone just show up right after a release, drop a bunch of requests, and then
> > go off to their own busy work. Then they come back a release later, don't
> > see any change and either drop another email detailing things to be dropped
> > OR discouraged that no-one ever listens. The things that do get changed and
> > pulled out (or kept in) do so because people come in and work on scrubbing
> > out the reasons and making sure the replacements are socialized in.
> >
> > One of the things is that I am not sure any of these items
> >
> >
> > 1. multipathd. On a workstation, uh?? I obviously have no multipath
> >
> > 2. dmraid. Not quite as bad as multipathd as it is more likely to
> > >
> >
> > I think these two are here because of the blivet you mentioned earlier.
> > Advanced partitioning requires them to be there... and there do seem to be
> > people who actually do expect both of those to work on their workstations
> > when it was looked at to be removed in the past.
> >
> > I do not know if the SIlverBlue does not have them on the other hand.
>
> Basically, anything that's part of the install environment is going to
> be present after a live install. That accounts for both of the above:
> the installer supports multipath and dmraid storage devices, so the
> relevant packages are part of the install environment, so they're part
> of the lives, so they're installed by a live install.
>
> This is kind of a limitation of the live deployment mechanism. In
> theory a post-install stage could be added to strip things that were
> only needed at install time, or that we can tell aren't actually needed
> by the installed system, but this has never been done, though I recall
> it being discussed at times.
>

I'd personally like to see some kind of post-install mechanism that
could remove unneeded things or apply updates before rebooting into
the new environment. That's something that Ubiquity, DrakX, Calamares,
and YaST all do, and it's quite nice to have...

> >
> > > 3. atd? Do we still need that? Do we have postinst scripts that need
> >
> > 4. Similar crond. On my fresh install it's only used by "zfs-fuse",
> > >
>
> > This is more about socializing and teaching the systemd replacements...
> > because most of the systemd advocates and heavy users I have asked aren't
> > sure about how systemd replaces them and go back to cron/atd. I actually
> > think that the replacements seem much better thought out than cruft-ware
> > but.. but I also have little confidence I could get it to work consistently
> > while I can find 10k tutorials on cron.
>
> To be specific here, 'at' is part of the @standard group. 'chrony' is
> pulled in several ways. It's part of @standard *if gnome-control-center
> is being installed*, so effectively it'll be installed with Workstation
> but not other editions/spins. That sort of implies that there's some
> functionality in GNOME that depends on chrony; I am not sure what that
> is, off hand. It's also part of 'anaconda-tools' (so it will be in all
> live images and all live installs), part of 'server-product' (so it is
> in Server installs), and part of 'system-tools' (so it'll be in
> anything that includes that). It's also part of 'workstation-product',
> so it's really super *definitely* included in Workstation. :P
>
> I think it is reasonable to suggest that there is a general expectation
> that, on an out of the box *nix system, you can put stuff in crontab
> and it will work. I like systemd timers, but the system doesn't attempt
> cron compatibility so far as I'm aware; if we don't install a cron
> daemon, this won't be the case. (I'm actually slightly interested in
> whether you wind up with chrony if you do a non-live install of a non-
> GNOME desktop; it looks to me like you don't, which is I guess
> notable).
>

'chrony' isn't a cron job thing. That's 'cron' and 'anacron'. 'chrony'
is a time server thing, and we should keep that. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- 

Re: Can we maybe reduce the set of packages we install by default a bit?

[Lennart Poettering]

On Di, 09.04.19 19:24, Richard Hughes (hughsi...@gmail.com) wrote:

> On Tue, 9 Apr 2019 at 19:21, Lennart Poettering  wrote:
> > Very similar is actually "fwupd", why does that need to run all the
> > time? Seems like something that should be bus activatable, and
> > exit-on-idle, but why run it all the time?
>
> It does exit on idle, if you don't have hardware that is tricky to get
> version numbers from. If we're polling for the list of firmware
> updates once per day we don't want to cause display flicker or that
> kind of thing. ThunderBolt and MST are the main offenders here. We're
> working on it, but it's not super simple.

Hmm? Can you elaborate? Why does fwupd's runtime have something to do
with display flickers? Not grokking the connection?

Lennart

--
Lennart Poettering, Berlin
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Lennart Poettering]

On Di, 09.04.19 20:12, Richard Hughes (hughsi...@gmail.com) wrote:

> On Tue, 9 Apr 2019 at 19:27, Lennart Poettering  wrote:
> > Hmm? Can you elaborate? Why does fwupd's runtime have something to do
> > with display flickers? Not grokking the connection?
>
> More information in
> https://github.com/hughsie/fwupd/commit/75b965d01d80d70ae51816acd4d4cafdaf792e99
> -- in the case of MST it's where a fake monitor gets created on the
> hardware so the chip can wake up enough to tell us the current
> firmware version, but the fake monitor causes a flicker for a couple
> of reasons. I guess we could always just cache the last known version
> in some database somewhere and just assume it's not changed, but if
> we're not "alive" to see the device removal/insertion event we don't
> know the true state of the hardware. If you're worried about the
> startup speed or memory usage, we've been pretty keenly fixing both,
> but if you have any specific concerns let me know.

Hmm, but why would you scan for firmware versions during hotplug? why
not just when the user triggers a query if there's something to
update?

I presume fwupd subscribes to udev events for this, what precisely is
it susbcribing to?

Lennart

--
Lennart Poettering, Berlin
___
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: Can we maybe reduce the set of packages we install by default a bit?

[David Cantrell]

On 4/9/19 2:14 PM, Lennart Poettering wrote:
> On Di, 09.04.19 12:54, Stephen John Smoogen (smo...@gmail.com) wrote:
> 
>> I think these two are here because of the blivet you mentioned earlier.
>> Advanced partitioning requires them to be there... and there do seem to be
>> people who actually do expect both of those to work on their workstations
>> when it was looked at to be removed in the past.
> 
> Well, but anaconda makes some changes to the image after copying in
> the OS, no? it could also do an "systemctl disable mdraid.service
> --root=/installed/tree" or so if it knows that mdraid is not actually
> needed...

The general argument against doing things like that in anaconda is that
it will change later and this email thread becomes "Why is anaconda
running systemctl disable mdraid.service after installing the OS"

>> This is more about socializing and teaching the systemd replacements...
>> because most of the systemd advocates and heavy users I have asked aren't
>> sure about how systemd replaces them and go back to cron/atd. I actually
>> think that the replacements seem much better thought out than cruft-ware
>> but.. but I also have little confidence I could get it to work consistently
>> while I can find 10k tutorials on cron.
> 
> Well, we addresses similar cases by placing README files or so in
> those directories, so that people might notice if they are looking for
> something there... i.e. /var/log/README is a similar case and
> /etc/inittab too. I think we can do the same here too and make clear
> that people need to install cronie first before these things work.
> 
> Alternatively. just drop the cron dropin dirs from the base image: if
> i want to drop in a script in the dirs I should notice if I can't
> because the dir doesn't actually exist.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> 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
> 


-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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 30-20190408.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Failed openQA tests: 12/144 (x86_64), 1/2 (arm), 2/24 (i386)

ID: 379607  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/379607
ID: 379619  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/379619
ID: 379621  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/379621
ID: 379622  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/379622
ID: 379623  Test: x86_64 Silverblue-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/379623
ID: 379642  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/379642
ID: 379644  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/379644
ID: 379659  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/379659
ID: 379665  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/379665
ID: 379676  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/379676
ID: 379681  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/379681
ID: 379682  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/379682
ID: 379700  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/379700
ID: 379710  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/379710
ID: 379711  Test: i386 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/379711

Soft failed openQA tests: 13/144 (x86_64), 4/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 379550  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/379550
ID: 379551  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/379551
ID: 379552  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/379552
ID: 379554  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/379554
ID: 379578  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/379578
ID: 379579  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/379579
ID: 379580  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/379580
ID: 379596  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/379596
ID: 379599  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/379599
ID: 379600  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/379600
ID: 379602  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/379602
ID: 379649  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/379649
ID: 379655  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/379655
ID: 379679  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/379679
ID: 379680  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/379680
ID: 379684  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/379684
ID: 379717  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/379717

Passed openQA tests: 112/144 (x86_64), 18/24 (i386)

Skipped non-gating openQA tests: 8 of 170
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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: Can we maybe reduce the set of packages we install by default a bit?

[Lennart Poettering]

On Di, 09.04.19 12:54, Stephen John Smoogen (smo...@gmail.com) wrote:

> I think these two are here because of the blivet you mentioned earlier.
> Advanced partitioning requires them to be there... and there do seem to be
> people who actually do expect both of those to work on their workstations
> when it was looked at to be removed in the past.

Well, but anaconda makes some changes to the image after copying in
the OS, no? it could also do an "systemctl disable mdraid.service
--root=/installed/tree" or so if it knows that mdraid is not actually
needed...

> This is more about socializing and teaching the systemd replacements...
> because most of the systemd advocates and heavy users I have asked aren't
> sure about how systemd replaces them and go back to cron/atd. I actually
> think that the replacements seem much better thought out than cruft-ware
> but.. but I also have little confidence I could get it to work consistently
> while I can find 10k tutorials on cron.

Well, we addresses similar cases by placing README files or so in
those directories, so that people might notice if they are looking for
something there... i.e. /var/log/README is a similar case and
/etc/inittab too. I think we can do the same here too and make clear
that people need to install cronie first before these things work.

Alternatively. just drop the cron dropin dirs from the base image: if
i want to drop in a script in the dirs I should notice if I can't
because the dir doesn't actually exist.

Lennart

--
Lennart Poettering, Berlin
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Lennart Poettering]

On Di, 09.04.19 14:16, Cole Robinson (crobi...@redhat.com) wrote:

> On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
> >> multipathd [...] And beyond that, this daemon is really ugly too: it logs
> >>at high log levels during boot that it found no configuration and
> >>hence nothing to do. Yes, obviously, but that's a reason to shut up
> >>and proceed quickly, not to complain loudly about that so that it
> >>even appears on the scren (I mean srsly, this is the first thing I
> >>saw when i booted from the fedora live media: a log message printed
> >>all over the screen that multipathd has no working
> >>configuration...).
> >
> > This was supposed to be fixed 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1631772.
> > If not, please reopen that bug.
> >
> >> 5. libvirtd. Why is this running? Can't we make this socket
> >>activatable + exit-on-idel?
> >
> > This was supposed to happen. See
> > https://bugzilla.redhat.com/show_bug.cgi?id=1290357.
> >
>
> This bug (briefly) describes why at present libvirt can't use socket
> activation: https://bugzilla.redhat.com/show_bug.cgi?id=1326136

Hmm, so that is a valid request I guess. But why can't libvirt do
exit-on-idle? i.e. after it started up, after it noticed that it has no VMs to
run, checks that there are no IPC requests pending, can't it just exit
then and then rely on socket activation to be started again when it is
needed the next time? That way libvirt would start at boot, but not
stick around during normal runtime.

Lennart

--
Lennart Poettering, Berlin
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Richard Hughes]

On Tue, 9 Apr 2019 at 19:21, Lennart Poettering  wrote:
> Very similar is actually "fwupd", why does that need to run all the
> time? Seems like something that should be bus activatable, and
> exit-on-idle, but why run it all the time?

It does exit on idle, if you don't have hardware that is tricky to get
version numbers from. If we're polling for the list of firmware
updates once per day we don't want to cause display flicker or that
kind of thing. ThunderBolt and MST are the main offenders here. We're
working on it, but it's not super simple.

Richard.
___
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: Could not execute import_srpm

[Kevin Fenzi]

On 4/9/19 9:27 AM, Antonio Trande wrote:
> On 08/04/19 19:45, Paulo César Pereira de Andrade wrote:
>> Em seg, 8 de abr de 2019 às 10:09, Antonio Trande
>>  escreveu:
>>>
>>> Hi all.
>>
>>   Hi,
>>
>>   Just a guess that it was the same issue as for me a few days ago. But it 
>> might
>> be something else, like an offline server for some reason.
>>
>>   I did not do much work on Fedora for some time, then, when uploading
>> a new source I was getting all kinds of errors.
>>Eventually fixing some .rpmsav andor .rpmorig files,
> 
> ??
> 
>> plus using rdns = false
>> in /etc/krb5.conf fixed the issue.
>>   For other possible issues check
>> https://fedoraproject.org/wiki/Infrastructure/Kerberos
>>
> 
> The line 'rdns = false' is already in '/etc/krb5.conf'.
> 
>>> I can't upload source archive of new package 'smoldyn'
>>>
> 
> I tried to download the source archive again but i'm not able to import
> the 'smoldyn' srpm by fedpkg.

We have had at least 3 reports of this today...
(upload causing 408 error).

Can any of you folks seeing this:

Run this script:
https://paste.fedoraproject.org/paste/tWt5LBT13-~d22wBpo38uQ/raw

and send me the output?

Also, if you could check and see if anything updated on your systems
since the last time it worked and what os/version you are running that
could be of help.

if the above script works, that points to a fedpkg/rpkg problem.
If it doesn't hopefully it will give us enough info to track it down.

Finally, I'll remind folks that for issues like these if you file a
ticket we will likely notice sooner and get the right people looking at
it than if you post to the list.


thanks!

kevin



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: Can we maybe reduce the set of packages we install by default a bit?

[Cole Robinson]

On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
>> multipathd [...] And beyond that, this daemon is really ugly too: it logs
>>at high log levels during boot that it found no configuration and
>>hence nothing to do. Yes, obviously, but that's a reason to shut up
>>and proceed quickly, not to complain loudly about that so that it
>>even appears on the scren (I mean srsly, this is the first thing I
>>saw when i booted from the fedora live media: a log message printed
>>all over the screen that multipathd has no working
>>configuration...).
> 
> This was supposed to be fixed 
> https://bugzilla.redhat.com/show_bug.cgi?id=1631772.
> If not, please reopen that bug.
> 
>> 5. libvirtd. Why is this running? Can't we make this socket
>>activatable + exit-on-idel? 
> 
> This was supposed to happen. See
> https://bugzilla.redhat.com/show_bug.cgi?id=1290357.
>

This bug (briefly) describes why at present libvirt can't use socket
activation: https://bugzilla.redhat.com/show_bug.cgi?id=1326136

Libvirtd has a feature to autostart VMs and other resources at host boot
up, which is useful and used often that people get mad when it breaks.
We need some new work to make this play with socket activation, maybe
move the autostart checking to some separate service that runs once at
startup. But with a simple implementation Workstation wouldn't benefit
because the installed 'default' network is still set to autostart.

Thanks,
Cole
___
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: Can we maybe reduce the set of packages we install by default a bit?

[mcatanzaro]

On Tue, Apr 9, 2019 at 12:11 PM, Adam Williamson 
 wrote:

To be specific here, 'at' is part of the @standard group. 'chrony' is
pulled in several ways. It's part of @standard *if 
gnome-control-center
is being installed*, so effectively it'll be installed with 
Workstation

but not other editions/spins.


Note that Workstation doesn't include @standard at all.

___
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: Can we maybe reduce the set of packages we install by default a bit?

[Cole Robinson]

On 4/9/19 2:24 PM, Lennart Poettering wrote:
> On Di, 09.04.19 14:16, Cole Robinson (crobi...@redhat.com) wrote:
> 
>> On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
 multipathd [...] And beyond that, this daemon is really ugly too: it logs
at high log levels during boot that it found no configuration and
hence nothing to do. Yes, obviously, but that's a reason to shut up
and proceed quickly, not to complain loudly about that so that it
even appears on the scren (I mean srsly, this is the first thing I
saw when i booted from the fedora live media: a log message printed
all over the screen that multipathd has no working
configuration...).
>>>
>>> This was supposed to be fixed 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1631772.
>>> If not, please reopen that bug.
>>>
 5. libvirtd. Why is this running? Can't we make this socket
activatable + exit-on-idel?
>>>
>>> This was supposed to happen. See
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1290357.
>>>
>>
>> This bug (briefly) describes why at present libvirt can't use socket
>> activation: https://bugzilla.redhat.com/show_bug.cgi?id=1326136
> 
> Hmm, so that is a valid request I guess. But why can't libvirt do
> exit-on-idle? i.e. after it started up, after it noticed that it has no VMs to
> run, checks that there are no IPC requests pending, can't it just exit
> then and then rely on socket activation to be started again when it is
> needed the next time? That way libvirt would start at boot, but not
> stick around during normal runtime.
> 

I don't know off hand of anything that would prevent it. Libvirt does
process events from running qemu VMs, but if there's no API users
connected to the daemon then I don't think libvirtd needs to be running;
it can handle restart and reconnecting to running VMs. That's
essentially the same behavior the session libvirtd instance uses which
auto shuts down after 30 seconds if there's no clients IIRC. danpb would
know best though, CCd

Thanks,
Cole
___
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: Could not execute import_srpm

[Antonio Trande]

On 09/04/19 22:29, Kevin Fenzi wrote:
> On 4/9/19 9:27 AM, Antonio Trande wrote:
>> On 08/04/19 19:45, Paulo César Pereira de Andrade wrote:
>>> Em seg, 8 de abr de 2019 às 10:09, Antonio Trande
>>>  escreveu:

 Hi all.
>>>
>>>   Hi,
>>>
>>>   Just a guess that it was the same issue as for me a few days ago. But it 
>>> might
>>> be something else, like an offline server for some reason.
>>>
>>>   I did not do much work on Fedora for some time, then, when uploading
>>> a new source I was getting all kinds of errors.
>>>Eventually fixing some .rpmsav andor .rpmorig files,
>>
>> ??
>>
>>> plus using rdns = false
>>> in /etc/krb5.conf fixed the issue.
>>>   For other possible issues check
>>> https://fedoraproject.org/wiki/Infrastructure/Kerberos
>>>
>>
>> The line 'rdns = false' is already in '/etc/krb5.conf'.
>>
 I can't upload source archive of new package 'smoldyn'

>>
>> I tried to download the source archive again but i'm not able to import
>> the 'smoldyn' srpm by fedpkg.
> 
> We have had at least 3 reports of this today...
> (upload causing 408 error).
> 
> Can any of you folks seeing this:
> 
> Run this script:
> https://paste.fedoraproject.org/paste/tWt5LBT13-~d22wBpo38uQ/raw
> 
> and send me the output?

Sorry,

how this script works?


> 
> Also, if you could check and see if anything updated on your systems
> since the last time it worked and what os/version you are running that
> could be of help.
> 
> if the above script works, that points to a fedpkg/rpkg problem.
> If it doesn't hopefully it will give us enough info to track it down.
> 
> Finally, I'll remind folks that for issues like these if you file a
> ticket we will likely notice sooner and get the right people looking at
> it than if you post to the list.
> 
> 
> thanks!
> 
> 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
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.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: Can we maybe reduce the set of packages we install by default a bit?

[Chris Murphy]

On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering  wrote:
>
> Heya,
>
> today I installed the current Fedora 30 Workstation beta on my new
> laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> crashed five times or so on me, always kicking me out of anaconda
> again, just because I wanted to undo something).

I haven't seen a single one come across in QA

> 1. multipathd.

I'm pretty sure it gets dragged in by the installer, i.e. the
installation environment needs it because installing to multipath is
supported. And since it's on the Workstation LiveOS, it just gets
copied over along with the installer itself (LiveOS installs use
rsync). I wonder if it's reasonable to apply more exclude filtering
during rsync to avoid copying some things needed for Live OS
environment, but not on the final installed system. But that's sorta
up to Workstation WG I think.


> 2. dmraid.

Same as above. I'm not sure whether, or when, dmraid stuff is going to
be dropped by anaconda. For a long time now dmraid is deprecated. The
two supported ways of doing software raid are managed by mdadm and
lvm, both of which actually use the md driver in the kernel.

So I think this is a question for the anaconda team.


> 4. Similar crond. On my fresh install it's only used by "zfs-fuse",
>which I really wonder why it even is in the default install? And
>"mdadm" wants this too. (which would be great if it would just use
>timer units)

I think zfs-fuse and glusterfs are dragged in by libvirt, which is
present because of GNOME Boxes. I don't know why any of those want
crond.

mdadm scrub and monitoring depends on crond, and then email
notifications if mismatch count != 0; it's archaic these days I guess,
but that's how it works.


> 5. libvirtd. Why is this running? Can't we make this socket
>activatable + exit-on-idel? While I am sure it's useful on
>workstations why run it all the time, given that only very few
>users probably actually need that, and if they do starting it on
>demand would be much more appropriate? On my freshly installed
>system it is running all the time even though there are no VMs or
>anything around.

Agreed.


>
> Ideally, the top 4 wouldn't be installed at all anymore (in case of
> the first two at least on the systems which do not need them). But if
> that's not in the cards, it would be great to at least not enable
> these services anymore in the default boot so that they are only a
> "systemctl enable" away for people who need them?

At the least it seems reasonable they can be disabled on the installed
system, and enabled for Live OS boot if the installer needs them.

-- 
Chris Murphy
___
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: auto-starting libvirtd on Workstation

[Orion Poplawski]

On 4/9/19 1:00 PM, Cole Robinson wrote:

On 4/9/19 2:20 PM, Lennart Poettering wrote:

On Di, 09.04.19 10:11, Adam Williamson (adamw...@fedoraproject.org) wrote:


Basically, anything that's part of the install environment is going to
be present after a live install. That accounts for both of the above:
the installer supports multipath and dmraid storage devices, so the
relevant packages are part of the install environment, so they're part
of the lives, so they're installed by a live install.


Hmm, but the installed OS is not 100% the same as the livesys, or is
it? If not, it should be possible to add a "systemctl disable
dmraid.service --root=/path/to/os" somewhere, no?


To be specific here, 'at' is part of the @standard group. 'chrony'
is


Yupp, it's very confusing that we have chrony and cronie in our OS
and both are installed by default... ;-)


I don't know on this. I remember something about containers and flatpaks
but .. I don't know.


Boxes is a key component of Workstation, and it relies on libvirt. It's
in the 'Core Applications' definition of the Workstation tech spec:


Hmm, but boxes supposedly uses the user session version of libvirt,
no? it doesn't actually use the system service?



You're right it does not explicitly talk to the system libvirtd
instance. But boxes implicitly depends on system libvirtd to autostart
the 'default' virtual network, which is the preferred networking method.
boxes VMs then essentially use a small setuid helper shipped with qemu
to use the default virbr0 for unprivileged VMs.

Thanks,
Cole


I've long thought that the virtual network should be its own service:
https://bugzilla.redhat.com/show_bug.cgi?id=1597326#c5

but of course I don't have the time to do the work so that doesn't count 
for much.  But this possibly points to another reason to do so.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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: [PSA] %meson contains -Db_ndebug=true

[Peter Hutterer]

On Mon, Apr 08, 2019 at 01:26:47PM +0200, Igor Gnatenko wrote:
> Ok, I have reverted change:
> 
> * https://bodhi.fedoraproject.org/updates/FEDORA-2019-42ea21c6e4
> * https://bodhi.fedoraproject.org/updates/FEDORA-2019-660ccd306c
> * https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-eb940f069c
> * https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-d229ead72a
> * https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-9f6eea54fe

thanks!

Cheers,
   Peter
___
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

dlib update

[Luya Tshimbalanga]

Hello team,

dlib needs an update but the maintainer has not responded for month to
verify and merge the change.
Can a proven test push the merge and update that package matching
upstream release.

See https://release-monitoring.org/project/18600/

Reference:

---

https://src.fedoraproject.org/rpms/dlib/pull-request/4


Thanks,

Luya



0x5E528174D8A2609A.asc
Description: application/pgp-keys
___
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: Could not execute import_srpm

[Jerry James]

On Tue, Apr 9, 2019 at 2:30 PM Kevin Fenzi  wrote:
> We have had at least 3 reports of this today...
> (upload causing 408 error).
>
> Can any of you folks seeing this:
>
> Run this script:
> https://paste.fedoraproject.org/paste/tWt5LBT13-~d22wBpo38uQ/raw
>
> and send me the output?

I just had a failure to upload new sources for eclib, and ran this
script.  The output is attached.

> Also, if you could check and see if anything updated on your systems
> since the last time it worked and what os/version you are running that
> could be of help.

uname -a says:
Linux localhost.localdomain 5.0.5-200.fc29.x86_64 #1 SMP Wed Mar 27
20:58:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

My last successful upload was on Apr 6.  Since that time, the
following updates have been installed on my system:

appstream-data-29-10.fc29.noarch
audit-3.0-0.7.20190326git03e7489.fc29.x86_64
audit-libs-3.0-0.7.20190326git03e7489.fc29.x86_64
cmake-3.14.1-1.fc29.x86_64
cmake-data-3.14.1-1.fc29.noarch
cmake-filesystem-3.14.1-1.fc29.x86_64
cmake-rpm-macros-3.14.1-1.fc29.noarch
dnf-4.2.2-2.fc29.noarch
dnf-data-4.2.2-2.fc29.noarch
dnf-yum-4.2.2-2.fc29.noarch
edk2-ovmf-20190308stable-1.fc29.noarch
egl-wayland-1.1.2-2.fc29.x86_64
environment-modules-4.2.3-1.fc29.x86_64
evolution-data-server-3.30.5-2.fc29.x86_64
evolution-data-server-langpacks-3.30.5-2.fc29.noarch
evolution-ews-3.30.5-2.fc29.x86_64
evolution-ews-langpacks-3.30.5-2.fc29.noarch
ffmpeg-libs-4.0.4-2.fc29.x86_64
firefox-66.0.2-1.fc29.x86_64
glibc-2.28-27.fc29.i686
glibc-2.28-27.fc29.x86_64
glibc-all-langpacks-2.28-27.fc29.x86_64
glibc-common-2.28-27.fc29.x86_64
glibc-devel-2.28-27.fc29.x86_64
glibc-headers-2.28-27.fc29.x86_64
glibc-langpack-en-2.28-27.fc29.x86_64
gnucash-3.5-1.fc29.x86_64
gnucash-docs-3.5-1.fc29.noarch
google-chrome-stable-73.0.3683.103-1.x86_64
gtk-update-icon-cache-3.24.1-3.fc29.x86_64
gtk3-3.24.1-3.fc29.x86_64
highlight-3.50-1.fc29.x86_64
hostname-3.20-7.fc29.x86_64
hplip-3.18.12-9.fc29.x86_64
hplip-common-3.18.12-9.fc29.x86_64
hplip-libs-3.18.12-9.fc29.x86_64
httpd-2.4.39-2.fc29.x86_64
httpd-filesystem-2.4.39-2.fc29.noarch
httpd-tools-2.4.39-2.fc29.x86_64
hwdata-0.322-1.fc29.noarch
kernel-5.0.6-200.fc29.x86_64
kernel-core-5.0.6-200.fc29.x86_64
kernel-devel-5.0.6-200.fc29.x86_64
kernel-headers-5.0.6-200.fc29.x86_64
kernel-modules-5.0.6-200.fc29.x86_64
kernel-modules-extra-5.0.6-200.fc29.x86_64
libmodulemd1-1.8.6-2.fc29.x86_64
libnsl-2.28-27.fc29.x86_64
librepo-1.9.6-2.fc29.x86_64
libsane-hpaio-3.18.12-9.fc29.x86_64
libsolv-0.7.4-2.fc29.x86_64
libxmlb-0.1.8-1.fc29.x86_64
metamath-0.176-1.fc29.x86_64
metamath-doc-0.176-1.fc29.noarch
metamath-theories-0.176-1.fc29.noarch
ntfs-3g-2:2017.3.23-11.fc29.x86_64
ntfsprogs-2:2017.3.23-11.fc29.x86_64
openjpeg2-2.3.1-1.fc29.x86_64
osinfo-db-20190319-1.fc29.noarch
perl-DateTime-TimeZone-2.34-1.fc29.noarch
poppler-0.67.0-16.fc29.x86_64
poppler-glib-0.67.0-16.fc29.x86_64
poppler-utils-0.67.0-16.fc29.x86_64
python2-dnf-4.2.2-2.fc29.noarch
python3-audit-3.0-0.7.20190326git03e7489.fc29.x86_64
python3-dnf-4.2.2-2.fc29.noarch
python3-librepo-1.9.6-2.fc29.x86_64
rpm-ostree-libs-2019.3-1.fc29.x86_64
selinux-policy-3.14.2-53.fc29.noarch
selinux-policy-targeted-3.14.2-53.fc29.noarch
sos-3.7-1.fc29.noarch
tzdata-2019a-1.fc29.noarch
tzdata-java-2019a-1.fc29.noarch
vim-common-2:8.1.1099-1.fc29.x86_64
vim-enhanced-2:8.1.1099-1.fc29.x86_64
vim-filesystem-2:8.1.1099-1.fc29.noarch
vim-minimal-2:8.1.1099-1.fc29.x86_64
wget-1.20.3-1.fc29.x86_64
wine-4.5-1.fc29.x86_64
wine-alsa-4.5-1.fc29.i686
wine-alsa-4.5-1.fc29.x86_64
wine-arial-fonts-4.5-1.fc29.noarch
wine-capi-4.5-1.fc29.i686
wine-capi-4.5-1.fc29.x86_64
wine-cms-4.5-1.fc29.i686
wine-cms-4.5-1.fc29.x86_64
wine-common-4.5-1.fc29.noarch
wine-core-4.5-1.fc29.i686
wine-core-4.5-1.fc29.x86_64
wine-courier-fonts-4.5-1.fc29.noarch
wine-desktop-4.5-1.fc29.noarch
wine-filesystem-4.5-1.fc29.noarch
wine-fixedsys-fonts-4.5-1.fc29.noarch
wine-fonts-4.5-1.fc29.noarch
wine-ldap-4.5-1.fc29.i686
wine-ldap-4.5-1.fc29.x86_64
wine-marlett-fonts-4.5-1.fc29.noarch
wine-ms-sans-serif-fonts-4.5-1.fc29.noarch
wine-openal-4.5-1.fc29.i686
wine-openal-4.5-1.fc29.x86_64
wine-opencl-4.5-1.fc29.i686
wine-opencl-4.5-1.fc29.x86_64
wine-pulseaudio-4.5-1.fc29.i686
wine-pulseaudio-4.5-1.fc29.x86_64
wine-small-fonts-4.5-1.fc29.noarch
wine-symbol-fonts-4.5-1.fc29.noarch
wine-system-fonts-4.5-1.fc29.noarch
wine-systemd-4.5-1.fc29.noarch
wine-tahoma-fonts-4.5-1.fc29.noarch
wine-times-new-roman-fonts-4.5-1.fc29.noarch
wine-twain-4.5-1.fc29.i686
wine-twain-4.5-1.fc29.x86_64
wine-wingdings-fonts-4.5-1.fc29.noarch
zchunk-libs-1.1.0-1.fc29.x86_64

Regards,
--
Jerry James
http://www.jamezone.org/
Checking if eclib-20190226.tar.gz exists...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 209.132.181.16...
* TCP_NODELAY set
* Connected to 

Re: Updating/rebuilding of coin-or packages

[Jerry James]

On Tue, Apr 9, 2019 at 4:21 AM Antonio Trande  wrote:
> We can complete the coin-or-Bonmin, coin-or-Couenne, coin-or-Dip,
> coin-or-OS reviews before, of course.
>
> Let me check them.

I had hoped to get a COPR set up tonight, but alas!  I ran out of
time.  So I just uploaded a tarball here:

http://www.jamezone.org/coin-or.tar

I'll leave it there for a few days.  I haven't had time to review what
you have done, either.  Sorry.  I'm going to be busy tomorrow, too, so
I probably won't get to anything else until Thursday.

Regards,
-- 
Jerry James
http://www.jamezone.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: Can we maybe reduce the set of packages we install by default a bit?

[Neal Gompa]

On Tue, Apr 9, 2019 at 8:35 PM Chris Murphy  wrote:
>
> On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering  
> wrote:
> >
> > Heya,
> >
> > today I installed the current Fedora 30 Workstation beta on my new
> > laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> > crashed five times or so on me, always kicking me out of anaconda
> > again, just because I wanted to undo something).
>
> I haven't seen a single one come across in QA
>
> > 1. multipathd.
>
> I'm pretty sure it gets dragged in by the installer, i.e. the
> installation environment needs it because installing to multipath is
> supported. And since it's on the Workstation LiveOS, it just gets
> copied over along with the installer itself (LiveOS installs use
> rsync). I wonder if it's reasonable to apply more exclude filtering
> during rsync to avoid copying some things needed for Live OS
> environment, but not on the final installed system. But that's sorta
> up to Workstation WG I think.
>

Not having the rpmdb in sync with what content is on the system is
probably not a good idea. I'd advocate for anaconda being able to run
dnf to clean up stuff instead.

>
> > 2. dmraid.
>
> Same as above. I'm not sure whether, or when, dmraid stuff is going to
> be dropped by anaconda. For a long time now dmraid is deprecated. The
> two supported ways of doing software raid are managed by mdadm and
> lvm, both of which actually use the md driver in the kernel.
>
> So I think this is a question for the anaconda team.
>
>
> > 4. Similar crond. On my fresh install it's only used by "zfs-fuse",
> >which I really wonder why it even is in the default install? And
> >"mdadm" wants this too. (which would be great if it would just use
> >timer units)
>
> I think zfs-fuse and glusterfs are dragged in by libvirt, which is
> present because of GNOME Boxes. I don't know why any of those want
> crond.
>

These could be converted to systemd units. There's no reason not to, really...

> mdadm scrub and monitoring depends on crond, and then email
> notifications if mismatch count != 0; it's archaic these days I guess,
> but that's how it works.
>
>
> > 5. libvirtd. Why is this running? Can't we make this socket
> >activatable + exit-on-idel? While I am sure it's useful on
> >workstations why run it all the time, given that only very few
> >users probably actually need that, and if they do starting it on
> >demand would be much more appropriate? On my freshly installed
> >system it is running all the time even though there are no VMs or
> >anything around.
>
> Agreed.
>
>
> >
> > Ideally, the top 4 wouldn't be installed at all anymore (in case of
> > the first two at least on the systems which do not need them). But if
> > that's not in the cards, it would be great to at least not enable
> > these services anymore in the default boot so that they are only a
> > "systemctl enable" away for people who need them?
>
> At the least it seems reasonable they can be disabled on the installed
> system, and enabled for Live OS boot if the installer needs them.
>
> --
> Chris Murphy
> ___
> 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



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Sphinx and xindy

[Dridi Boukelmoune]

On Mon, Apr 8, 2019 at 4:58 PM Jerry James  wrote:
>
> On Mon, Apr 1, 2019 at 9:36 PM Jerry James  wrote:
> > That was, in fact, an s390x-specific gcc bug, now fixed in Rawhide.
> > Sadly, the clisp build is still failing in Rawhide, with failures in
> > the socket tests:
>
> The failing test attempts to bind to localhost:9090.  Apparently
> something on the s390x koji builders binds that port.  The test is
> arguably broken; it should iterate over successive port numbers until
> if finds one that is available, rather than picking a single port
> number and failing if that port is unavailable.

No, for that you should bind port zero instead to get a random one in
a race-free manner (e.g. parallel execution of multiple tests for
example).

Dridi
___
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: vanishing abrt logs

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 08, 2019 at 02:21:47PM +0200, jfi...@fedoraproject.org wrote:
> I agree, but the file /proc/meminfo is not present, right?
> And yes, the abrt thing just reads the data from journal and
> 
> stores them on filesystem to be able to upload them to Bugzilla.
> 
> 
> 
> 
> 
> Regarding the missing logs, the journal log lines should
> 
> be extracted by this thing:
> 
> https://github.com/abrt/abrt/blob/master/src/plugins/ccpp_event.conf#L25
> (https://github.com/abrt/abrt/blob/master/src/plugins/ccpp_event.conf#L25)
> 
> which is a little bit complex, so no wonder if it is broken

Thanks for the link. That code boils down to
"journalctl -q -b --since=-3m --system -n 99 _COMM="$base_executable"
and for systemd services this is very underwhelming, because it doesn't
use the information that the process is part of service, and all logs
from that service are relevant, e.g. when it launches a second
executable or switches uid.

I think abrt should figure out if the crashing binary is part of a
system service, and switch to a log collection mode that is more like
'journalctl -u' in this case. Also, don't limit the messages to just 3
minutes or 99 messages.

> (I am just not sure why the abrt test suite is not failing though).
> 
> Regarding the core files, I was under the impression that
> the core files can be attached only if the reporter wants to attach it.
> IOW the core files were never attached automatically (due to security
> issues).

Could we have a per-service switch that says "this service never has
private information, make the coredump file collection opt-out"?
For example, we get a number of reports for systemd-logind, and by
design it never has any private user data or keys. The user interface
could be simplified. Similarly for hwrngd, and probably many others.

> If you need some information that is relevant only to your packages,
> we can work together to create a new abrt configuration which will
> gather that information for your packages
> (for example, dnf ships its own abrt configuration).

Can you point me to it? rpm -ql $(rpm -qa|grep dnf)|grep abrt doesn't
yield anything.

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

Re: vanishing abrt logs

[Martin Kutlak]

On Tue, 9 Apr 2019 at 08:58, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> > If you need some information that is relevant only to your packages,
> > we can work together to create a new abrt configuration which will
> > gather that information for your packages
> > (for example, dnf ships its own abrt configuration).
>
> Can you point me to it? rpm -ql $(rpm -qa|grep dnf)|grep abrt doesn't
> yield anything.
>

You can find the DNF configuration for ABRT in
/etc/libreport/events.d/collect_dnf.conf

And more about event configurations here:
https://abrt.readthedocs.io/en/latest/conf.html#event-configuration


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: vanishing abrt logs

[Miroslav Suchý]

Dne 09. 04. 19 v 8:56 Zbigniew Jędrzejewski-Szmek napsal(a):
> Can you point me to it? rpm -ql $(rpm -qa|grep dnf)|grep abrt doesn't
> yield anything.

What and how it is collected is determined by libreport with configs in 
/etc/libreport
Some of those configs even have man page. You can start with `man 
report_event.conf`.

Miroslav
___
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: Introduction for gaming packaging/maintaining

[Dan Čermák]

Hi Andi,

welcome to the pack!

You can try to review some packages or submit your own package, whatever
you feel like doing (if you submit a package, you'll need to get
sponsored though and reviewing packages is a good way how to get
sponsored).

In case you want to package some games, there's a pretty long list of
open source game clones: https://osgameclones.com/
Most of these are afaik not in Fedora (yet) and some smaller ones could
be a nice start (although you should watch out for licensing issues).

In case you are looking for other ways to contribute, there's always
this site: https://whatcanidoforfedora.org/


Cheers,

Dan

Karsten Andreas Artz  writes:

> Hi Benson,
> thx for welcoming me on Fedora and thx for providing the links. 
> I’ve read through them and skimmed them. 
> Should I start reviewing packages or do you have another idea?
> Regards
> Andi 
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, April 8, 2019, 9:35 PM, Benson Muite  
> wrote:
>
>  
> Hi Andi,
>  Welcome to Fedora. Some general information is at:
>  https://docs.fedoraproject.org/en-US/project/
>  The get involved page still needs an update:
>  https://docs.fedoraproject.org/en-US/project/join/
>  but packaging guidelines are here:
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/
>  
> most people start by reviewing packages - though there are other ways to 
> contribute other than packaging.
>  
>
>  
>  Regards,
>  Benson 
>
>  
>  On 4/8/19 7:32 PM, Karsten Andreas Artz wrote:
>   
>  
>Hi guys, 
>   my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
> (Fedora 26). My programming skills are on Python, Java/Java Script, and  
> C/C++. But acutally I prefer mostly Python hacking. I studied B.A. of Arts 
> History, Archaeology and Cath.Theology. Besides this, I can speak a lot of 
> languages: German, English, French, a  bit Italian and Spanish. 
>   
>   It would be glad starting contributing on Fedora as a maintainer. Therefore 
> I hope to work on a small  project soon.
>   I'm interested in games packaging, but I don't know where to start.
>   
>   
>   Regards 
>   Andi
>   
>   
>
>   ___
> 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


signature.asc
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: [PSA] %meson contains -Db_ndebug=true

[Kalev Lember]

Awesome, thanks Igor! All of this sounds good to me.

Kalev

On 4/9/19 14:47, Igor Gnatenko wrote:

At this moment,

* %meson doesn't pass -Db_ndebug at all, we use project-specific options
* If project doesn't specify it, b_ndebug=false is default in meson
* In case of mesa, it specifies b_ndebug=if-release which works 
correctly now with backported patch


On Mon, Apr 8, 2019 at 4:29 PM Kalev Lember > wrote:



On 4/8/19 15:16, mcatanz...@gnome.org 
wrote:
 > - Plain builds should match the behavior of release builds, and
Fedora
 > plain builds should match the behavior of upstream plain builds.
This is
 > what we briefly had but just reverted. (Option one)

I believe this is the case already in upstream meson git master. Igor,
correct me if I'm wrong.

-- 
Kalev

___
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: [PSA] %meson contains -Db_ndebug=true

[Igor Gnatenko]

At this moment,

* %meson doesn't pass -Db_ndebug at all, we use project-specific options
* If project doesn't specify it, b_ndebug=false is default in meson
* In case of mesa, it specifies b_ndebug=if-release which works correctly
now with backported patch

On Mon, Apr 8, 2019 at 4:29 PM Kalev Lember  wrote:

>
> On 4/8/19 15:16, mcatanz...@gnome.org wrote:
> > - Plain builds should match the behavior of release builds, and Fedora
> > plain builds should match the behavior of upstream plain builds. This is
> > what we briefly had but just reverted. (Option one)
>
> I believe this is the case already in upstream meson git master. Igor,
> correct me if I'm wrong.
>
> --
> Kalev
> ___
> 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: Orphaned packages to be retired

[Raphael Groner]

>  Sorry, but I'm afraid I don't quite get this. Could you please rephrase?
> The script uses source repos to fetch build-dependencies.

Thanks. That answers my question.
___
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: [PSA] %meson contains -Db_ndebug=true

[Tomasz Kłoczko]

On Tue, 9 Apr 2019 at 13:54, Igor Gnatenko 
wrote:

> At this moment,
>
> * %meson doesn't pass -Db_ndebug at all, we use project-specific options
> * If project doesn't specify it, b_ndebug=false is default in meson
> * In case of mesa, it specifies b_ndebug=if-release which works correctly
> now with backported patch
>

IMO discussed here issue is more related to Fedora macros.

As current definition of the %meson uses --buildtype=plain
instead --buildtype=release and that build type is fixed and does not
provide any other way to redefine build type than just just pass
another --buildtype= fiddling anything around plain build
profile straight in meson source code may introduce more harm than good
thing.

IMO whole rpm macro suite should proved something like %build_type macro
which should be used transparently by %configure, %cmake and %meson.
Effectively for now Fedora IMO needs only as %build_type something like
"release" and "debug".
Any other type of the build should have some strict definition of the
propose.

IMO it would be even good to have in whole rawhide development cycle
something like build all packages with build type "debug" and use "release"
type only after branching all packages and rebuild everything with build
type "release".
This would as well guarantee that whatever will be offered in new stable
release will be building with all other packages (which up to now still is
not the case).

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: [PSA] %meson contains -Db_ndebug=true

[mcatanzaro]

On Tue, Apr 9, 2019 at 7:54 AM, Kalev Lember  
wrote:

Awesome, thanks Igor! All of this sounds good to me.


Yeah, sounds like everything is fine now after the if-release fix. 
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

Re: Introduction for gaming packaging/maintaining

[Karsten Andreas Artz]

Hi Dan, 
thx for welcoming me to the pack! 
I’ve skimmed through the games. I have different games in favor: Raildroad 
Tycoon, Pizza Tycoon and escape from Monkey Island. 
What are the first steps to start? 
Thx in forward
Cheers 
Andi 


Sent from Yahoo Mail for iPhone


On Tuesday, April 9, 2019, 10:48 AM, Dan Čermák 
 wrote:

Hi Andi,

welcome to the pack!

You can try to review some packages or submit your own package, whatever
you feel like doing (if you submit a package, you'll need to get
sponsored though and reviewing packages is a good way how to get
sponsored).

In case you want to package some games, there's a pretty long list of
open source game clones: https://osgameclones.com/
Most of these are afaik not in Fedora (yet) and some smaller ones could
be a nice start (although you should watch out for licensing issues).

In case you are looking for other ways to contribute, there's always
this site: https://whatcanidoforfedora.org/


Cheers,

Dan

Karsten Andreas Artz  writes:

> Hi Benson,
> thx for welcoming me on Fedora and thx for providing the links. 
> I’ve read through them and skimmed them. 
> Should I start reviewing packages or do you have another idea?
> Regards
> Andi 
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, April 8, 2019, 9:35 PM, Benson Muite  
> wrote:
>
>  
> Hi Andi,
>  Welcome to Fedora. Some general information is at:
>  https://docs.fedoraproject.org/en-US/project/
>  The get involved page still needs an update:
>  https://docs.fedoraproject.org/en-US/project/join/
>  but packaging guidelines are here:
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/
>  
> most people start by reviewing packages - though there are other ways to 
> contribute other than packaging.
>  
>
>  
>  Regards,
>  Benson 
>
>  
>  On 4/8/19 7:32 PM, Karsten Andreas Artz wrote:
>  
>  
>            Hi guys, 
>  my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
>(Fedora 26). My programming skills are on Python, Java/Java Script, and  
>C/C++. But acutally I prefer mostly Python hacking. I studied B.A. of Arts 
>History, Archaeology and Cath.Theology. Besides this, I can speak a lot of 
>languages: German, English, French, a  bit Italian and Spanish. 
>  
>  It would be glad starting contributing on Fedora as a maintainer. Therefore 
>I hope to work on a small  project soon.
>  I'm interested in games packaging, but I don't know where to start.
>  
>  
>  Regards 
>  Andi
>          
>  
>    
>  ___
> 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


___
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 rawhide compose report: 20190409.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190408.n.0
NEW: Fedora-Rawhide-20190409.n.0

= SUMMARY =
Added images:6
Dropped images:  6
Added packages:  30
Dropped packages:12
Upgraded packages:   94
Downgraded packages: 0

Size of added packages:  58.74 MiB
Size of dropped packages:98.01 MiB
Size of upgraded packages:   3.20 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   124.05 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Mate live i386
Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-Rawhide-20190409.n.0.iso
Image: Astronomy_KDE live i386
Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20190409.n.0.iso
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20190409.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20190409.n.0.iso
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20190409.n.0.s390x.tar.xz
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20190409.n.0.iso

= DROPPED IMAGES =
Image: Games live i386
Path: Labs/i386/iso/Fedora-Games-Live-i386-Rawhide-20190408.n.0.iso
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20190408.n.0-sda.raw.xz
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20190408.n.0.iso
Image: LXDE live i386
Path: Spins/i386/iso/Fedora-LXDE-Live-i386-Rawhide-20190408.n.0.iso
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20190408.n.0.iso
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20190408.n.0.iso

= ADDED PACKAGES =
Package: apache-commons-el-1.0-42.fc31
Summary: The Apache Commons Extension Language
RPMs:apache-commons-el apache-commons-el-javadoc
Size:206.61 KiB

Package: ghc-wai-handler-launch-3.0.2.4-1.fc31
Summary: Launch a web app in the default browser
RPMs:ghc-wai-handler-launch ghc-wai-handler-launch-devel
Size:859.31 KiB

Package: glassfish-jsp-2.3.3-0.14.b02.fc31
Summary: Glassfish J2EE JSP API implementation
RPMs:glassfish-jsp glassfish-jsp-javadoc
Size:774.65 KiB

Package: gnatcoll-bindings-2018-2.fc31
Summary: The GNAT Components Collection ??? bindings
RPMs:gnatcoll-bindings-devel gnatcoll-gmp gnatcoll-iconv gnatcoll-readline 
gnatcoll-syslog
Size:991.40 KiB

Package: golang-github-armon-consul-api-0-0.1.20190408giteb2c6b5.fc31
Summary: Golang API client for Consul
RPMs:golang-github-armon-consul-api-devel
Size:27.60 KiB

Package: golang-github-eapache-xerial-snappy-0-0.1.20190408git776d571.fc31
Summary: Xerial-compatible Snappy framing support for golang
RPMs:golang-github-eapache-xerial-snappy-devel
Size:14.38 KiB

Package: golang-github-grpc-ecosystem-middleware-1.0.0-1.fc31
Summary: Golang gRPC Middlewares: interceptor chaining, auth, logging, retries 
and more
RPMs:golang-github-grpc-ecosystem-middleware-devel
Size:86.59 KiB

Package: golang-github-mattn-pointer-0-0.1.20190408git49522c3.fc31
Summary: Utility for cgo
RPMs:golang-github-mattn-pointer-devel
Size:9.34 KiB

Package: golang-github-tmc-grpc-websocket-proxy-0-0.1.20190408git0ad062e.fc31
Summary: A proxy to transparently upgrade grpc-gateway streaming endpoints to 
use websockets
RPMs:golang-github-tmc-grpc-websocket-proxy-devel
Size:13.29 KiB

Package: golang-uber-zap-1.9.1-1.fc31
Summary: Blazing fast, structured, leveled logging in Go
RPMs:golang-uber-zap-devel
Size:114.38 KiB

Package: python-aiohttp-socks-0.2.2-1.fc31
Summary: SOCKS proxy connector for aiohttp
RPMs:python3-aiohttp-socks
Size:26.08 KiB

Package: python-cheroot-6.5.4-1.fc31
Summary: Highly-optimized, pure-python HTTP server
RPMs:python3-cheroot
Size:134.40 KiB

Package: python-impacket-0.9.18-4.fc31
Summary: Collection of Python classes providing access to network packets
RPMs:python2-impacket
Size:1.76 MiB

Package: python-inema-0.6-1.fc31
Summary: A Python interface to the Deutsche Post Internetmarke Online Franking
RPMs:python3-inema
Size:30.93 KiB

Package: python-jaraco-classes-2.0-2.fc31
Summary: Utility functions for Python class constructs
RPMs:python3-jaraco-classes
Size:15.48 KiB

Package: python-pyrpm-0.8-1.fc31
Summary: Python module for parsing RPM spec files
RPMs:python3-pyrpm
Size:23.20 KiB

Package: python-requests-unixsocket-0.1.5-2.fc31
Summary: Use requests to talk HTTP via a UNIX domain socket
RPMs:python3-requests-unixsocket
Size:23.64 KiB

Package: ruby-2.6.2-119.module_f31+3837+684e965a
Summary: An interpreter of object-oriented scripting language
RPMs:ruby ruby-devel ruby-doc ruby-libs rubygem-bigdecimal rubygem-bundler 
rubygem-did_you_mean rubygem-io-console rubygem-irb rubygem-json 
rubygem-minitest rubygem-net-telnet rubygem-openssl rubygem

Re: Updating/rebuilding of coin-or packages

[Antonio Trande]

On 09/04/19 06:31, Jerry James wrote:
> Hi Antonio,

Hi Jerry.

> 
> On Mon, Apr 8, 2019 at 12:26 PM Antonio Trande  > wrote:
>> Hi all.
>>
>> Updates of coin-or-Sample/CoinUtils/Ipopt packages are coming on
>> Rawhide; involved packages:
> 
> I didn't know you were working on this.

I've admin permissions just for some of them: Bonmin, CoinUtils, Ipopt,
OS, Sample, Couenne.

> I noticed a week or so ago that
> several of the coin-or packages have FTBFS bugs filed against them, so I
> started working on fixing and updating all of them.  I had to stop due
> to a trip out of town, but I got through about 4/5 of the coin-or
> packages, with various improvements.  Are you interested in seeing what
> I've got, or would you rather just go ahead with what you've already
> done?  Here is a summary of what I've done so far, in the approximate
> order in which the packages would have to be built.
> 
>   * coin-or-Data-miplib3: new package
> (https://bugzilla.redhat.com/show_bug.cgi?id=1693913)
>   * coin-or-Data-Netlib: new package
> (https://bugzilla.redhat.com/show_bug.cgi?id=1693514)
>   * coin-or-Ipopt: update to 3.12.12, correct license to "EPL-1.0", drop
> unnecessary BRs and Rs
>   * coin-or-Sample: update to 1.2.11, drop unnecessary pkgconfig R
>   * coin-or-CoinUtils: update to 2.11.1, correct license to "EPL-1.0",
> change URL to github, add a patch to prevent a segfault when a
> problem's status has not been set (need to send that upstream), kill
> rpath
>   * coin-or-Osi: update to 0.108.3, correct license to "EPL-1.0", change
> URL to github, add patch to build with glpk >= 4.48
> (see https://github.com/coin-or/Osi/pull/121), kill rpath, drop
> unnecessary BRs and Rs
>   * coin-or-Clp: update to 1.17.1, correct license to "EPL-1.0", change
> URL to github, add bootstrap conditional due to circular build
> dependencies with Cbc, build with MUMPS and suitesparse support,
> build with Cbc and nauty support on the non-bootstrap build, add
> patch to fix a bad static cast, add patch to fix a crash in
> coin-or-lemon, add patch to fix a bad parameter when building with
> Cbc support
>   * coin-or-DyLP: update to 1.10.4, correct license to "EPL-1.0",
> install and set the path to the error text message file, kill rpath,
> drop unnecessary BRs and Rs
>   * coin-or-Vol: update to 1.5.4, correct license to "EPL-1.0", kill
> rpath, drop unnecessary BRs and Rs
>   * coin-or-Cgl: update to 0.60.1, correct license to "EPL-1.0", change
> URL to github, kill rpath, drop unnecessary BRs and Rs
>   * coin-or-Cbc: update to 2.10.1, correct license to "EPL-1.0", change
> URL to github, add patch to fix failure to link with glpk, build
> with nauty support, drop unnecessary BRs and Rs
>   * coin-or-SYMPHONY: update to 5.6.17, correct license to "EPL-1.0",
> change URL to github, provide the PDF manual, drop unnecessary BRs
> and Rs
>   * coin-or-Alps: update to 1.5.7, correct license to "EPL-1.0", change
> URL to github, kill rpath, drop unnecessary BRs and Rs
>   * coin-or-Bcp: update to 1.4.4, kill rpath, drop unnecessary BRs and Rs
>   * coin-or-CoinMP: update to 1.8.4, kill rpath, drop unnecessary BRs and Rs
>   * coin-or-FlopC++: update to 1.2.5, correct license to "EPL-1.0",
> update URL, add -doc subpackage with doxygen output, kill rpath,
> drop unnecessary BRs and Rs
>   * coin-or-lemon: add patch to fix template problem (causes FTBFS), add
> patch to fix test failures due to references to temporary objects
> that go out of scope, fix the cmake file to refer to a shared
> library, kill rpath
>   * coin-or-Bcps: correct license to "EPL-1.0", change URL to github,
> kill rpath, drop unnecessary BRs and Rs
>   * coin-or-Blis: update to 0.94.8, correct license to "EPL-1.0", change
> URL to github, drop unnecessary BRs and Rs
> 
> That's as far as I've gotten.  I haven't looked at coin-or-Bonmin,
> coin-or-Couenne, coin-or-Dip, or coin-or-OS yet.  Let me know if you
> would like to see all these changes first, or proceed with what you have
> planned first.
> 

We can complete the coin-or-Bonmin, coin-or-Couenne, coin-or-Dip,
coin-or-OS reviews before, of course.

Let me check them.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.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

Can we maybe reduce the set of packages we install by default a bit?

[Lennart Poettering]

Heya,

today I installed the current Fedora 30 Workstation beta on my new
laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
crashed five times or so on me, always kicking me out of anaconda
again, just because I wanted to undo something). But I don't really
want to discuss that. What I do want to discuss is this:

Can we maybe reduce the default set of packages a bit? In particular
the following ones I really don't think should be in our default
install:

1. multipathd. On a workstation, uh?? I obviously have no multipath
   devices configured on my laptop, how would I even? Has anyone? This
   is a really nasty one: to this day it pulls in udev settle, which
   is really backwards, and slows down our boot considerably. No
   current daemon should require udev settle, any daemon that still
   does is just backwards because it assumes that hardware would
   guarantee to have shown up at some specific time at boot, though in
   today's world that's really not how this works: hardware can take
   any time it wants, and thus instead of "waiting for everything" you
   can reasonably just wait for the stuff you know you actually need,
   based on your configuration. systemd-udev-settle.service however is
   a compat kludge that is supposed to provide "wait for everything",
   though this is racy and flaky. To say this clearly: anything that
   still relied on systemd-udev-settle.service 5y ago was bad, but
   still pulling that in today in 2019, and doing that in a default
   fedora install is just bad bad bad. This alone costs half the boot
   time on my system because it just waits for stuff for nothing, and
   for what? And beyond that, this daemon is really ugly too: it logs
   at high log levels during boot that it found no configuration and
   hence nothing to do. Yes, obviously, but that's a reason to shut up
   and proceed quickly, not to complain loudly about that so that it
   even appears on the scren (I mean srsly, this is the first thing I
   saw when i booted from the fedora live media: a log message printed
   all over the screen that multipathd has no working
   configuration...).

2. dmraid. Not quite as bad as multipathd as it is more likely to
   exist on a workstation (still quite exotic though), but also pulls
   in udev settle and hence should not be in our default boot. Much
   like multipathd this should be fixed to not require udev settle
   anymore, and in the absence of that at least not end up in the
   default fedora boot process, except for those people who actually
   have dmraid.

3. atd? Do we still need that? Do we have postinst scripts that need
   this? If so, wouldn't systemd-run be a better approach for those?
   Isn't it time to make this an RPM people install if they want it?

4. Similar crond. On my fresh install it's only used by "zfs-fuse",
   which I really wonder why it even is in the default install? And
   "mdadm" wants this too. (which would be great if it would just use
   timer units)

5. libvirtd. Why is this running? Can't we make this socket
   activatable + exit-on-idel? While I am sure it's useful on
   workstations why run it all the time, given that only very few
   users probably actually need that, and if they do starting it on
   demand would be much more appropriate? On my freshly installed
   system it is running all the time even though there are no VMs or
   anything around.

Ideally, the top 4 wouldn't be installed at all anymore (in case of
the first two at least on the systems which do not need them). But if
that's not in the cards, it would be great to at least not enable
these services anymore in the default boot so that they are only a
"systemctl enable" away for people who need them?

I wonder the first one is rooted in a misconception about systemd's
unit condition concept: conditions are extremely lightwight: they just
bypass service start-up, that's all. They have no effect on whether
dependencies are pulled in before hand or not, and they are only
tested the instant the service is ready to be fork()ed off. This means
multipathd.service (which has
ConditionPathExists=/etc/multipathd.conf) pulls in
systemd-udev-settle.service regardless if the condition holds or
fails...

I guess I should file bz issues about all of the above, but I am not
sure against which packages? anaconda? comps (does that still exist)?
the individual packages?

It's also my hope that maybe some champion volunteers for tracking
down issues like this and fixing them? i.e. keeping udev settle out of
the default install alone would be a worthy goal for every release,
given that it doubles boot time on typical systems... Anyone up for
that?

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

Fedora Rawhide-20190409.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost raw-xz x86_64
Atomichost qcow2 x86_64

Compose FAILS proposed Rawhide gating check!
17 of 47 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 35/144 (x86_64), 7/24 (i386), 1/2 (arm)

ID: 380088  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/380088
ID: 380089  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/380089
ID: 380093  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/380093
ID: 380094  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/380094
ID: 380096  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/380096
ID: 380104  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/380104
ID: 380110  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/380110
ID: 380111  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/380111
ID: 380112  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/380112
ID: 380116  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380116
ID: 380117  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/380117
ID: 380119  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/380119
ID: 380120  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/380120
ID: 380121  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/380121
ID: 380123  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380123
ID: 380125  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380125
ID: 380135  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/380135
ID: 380136  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380136
ID: 380138  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/380138
ID: 380139  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/380139
ID: 380141  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/380141
ID: 380153  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/380153
ID: 380157  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/380157
ID: 380159  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/380159
ID: 380160  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/380160
ID: 380161  Test: x86_64 Silverblue-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/380161
ID: 380171  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/380171
ID: 380178  Test: x86_64 universal install_kickstart_firewall_configured 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380178
ID: 380180  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/380180
ID: 380192  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/380192
ID: 380197  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/380197
ID: 380199  Test: x86_64 universal install_kickstart_user_creation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/380199
ID: 380214  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/380214
ID: 380215  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/380215
ID: 380223  Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/380223
ID: 380227  Test: x86_64 universal install_sata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/380227
ID: 380232  Test: x86_64 universal install_blivet_btrfs@uefi
URL: 

Re: Could not execute import_srpm

[Antonio Trande]

On 08/04/19 19:45, Paulo César Pereira de Andrade wrote:
> Em seg, 8 de abr de 2019 às 10:09, Antonio Trande
>  escreveu:
>>
>> Hi all.
> 
>   Hi,
> 
>   Just a guess that it was the same issue as for me a few days ago. But it 
> might
> be something else, like an offline server for some reason.
> 
>   I did not do much work on Fedora for some time, then, when uploading
> a new source I was getting all kinds of errors.
>Eventually fixing some .rpmsav andor .rpmorig files,

??

> plus using rdns = false
> in /etc/krb5.conf fixed the issue.
>   For other possible issues check
> https://fedoraproject.org/wiki/Infrastructure/Kerberos
> 

The line 'rdns = false' is already in '/etc/krb5.conf'.

>> I can't upload source archive of new package 'smoldyn'
>>

I tried to download the source archive again but i'm not able to import
the 'smoldyn' srpm by fedpkg.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.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: Can we maybe reduce the set of packages we install by default a bit?

[Stephen John Smoogen]

On Tue, 9 Apr 2019 at 12:07, Lennart Poettering 
wrote:

> Heya,
>
> today I installed the current Fedora 30 Workstation beta on my new
> laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> crashed five times or so on me, always kicking me out of anaconda
> again, just because I wanted to undo something). But I don't really
> want to discuss that. What I do want to discuss is this:
>
> Can we maybe reduce the default set of packages a bit? In particular
> the following ones I really don't think should be in our default
> install:
>
>
This is not the first time this has come up and I expect it won't be the
last time.

I think the main reason they stick around is that the people who want them
gone just show up right after a release, drop a bunch of requests, and then
go off to their own busy work. Then they come back a release later, don't
see any change and either drop another email detailing things to be dropped
OR discouraged that no-one ever listens. The things that do get changed and
pulled out (or kept in) do so because people come in and work on scrubbing
out the reasons and making sure the replacements are socialized in.

One of the things is that I am not sure any of these items


1. multipathd. On a workstation, uh?? I obviously have no multipath

2. dmraid. Not quite as bad as multipathd as it is more likely to
>
>

I think these two are here because of the blivet you mentioned earlier.
Advanced partitioning requires them to be there... and there do seem to be
people who actually do expect both of those to work on their workstations
when it was looked at to be removed in the past.

I do not know if the SIlverBlue does not have them on the other hand.


>
> 3. atd? Do we still need that? Do we have postinst scripts that need

4. Similar crond. On my fresh install it's only used by "zfs-fuse",
>
>

This is more about socializing and teaching the systemd replacements...
because most of the systemd advocates and heavy users I have asked aren't
sure about how systemd replaces them and go back to cron/atd. I actually
think that the replacements seem much better thought out than cruft-ware
but.. but I also have little confidence I could get it to work consistently
while I can find 10k tutorials on cron.



>
> 5. libvirtd. Why is this running? Can't we make this socket
>

I don't know on this. I remember something about containers and flatpaks
but .. I don't know.


>
> I wonder the first one is rooted in a misconception about systemd's
> unit condition concept: conditions are extremely lightwight: they just
>

I think it is actually more about what comes up more in the Arch and
serverfault pages on how to set up timed jobs. It has to do with tools to
make it 'one-liners' and 'convert your cruft cron' or 'this will read your
cron and make it cron-d'

As you say below it is about finding champions but those champions have got
to feel comfortable that they can answer things. Those people would then be
the ones to help shepherd this through.


> I guess I should file bz issues about all of the above, but I am not
> sure against which packages? anaconda? comps (does that still exist)?
> the individual packages?
>
>
It may actually require a larger change that goes through the release
process. It would work better to work with the Workstation and/or
Silverblue team to get them to champion it themselves as it does meet what
they have said they want..



> It's also my hope that maybe some champion volunteers for tracking
> down issues like this and fixing them? i.e. keeping udev settle out of
> the default install alone would be a worthy goal for every release,
> given that it doubles boot time on typical systems... Anyone up for
> that?
>
> Lennart
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
> multipathd [...] And beyond that, this daemon is really ugly too: it logs
>at high log levels during boot that it found no configuration and
>hence nothing to do. Yes, obviously, but that's a reason to shut up
>and proceed quickly, not to complain loudly about that so that it
>even appears on the scren (I mean srsly, this is the first thing I
>saw when i booted from the fedora live media: a log message printed
>all over the screen that multipathd has no working
>configuration...).

This was supposed to be fixed 
https://bugzilla.redhat.com/show_bug.cgi?id=1631772.
If not, please reopen that bug.

> 5. libvirtd. Why is this running? Can't we make this socket
>activatable + exit-on-idel? 

This was supposed to happen. See
https://bugzilla.redhat.com/show_bug.cgi?id=1290357.

> I guess I should file bz issues about all of the above, but I am not
> sure against which packages? anaconda? comps (does that still exist)?
> the individual packages?

Individual packages. Logging issue obviously belong in the packages.
In principle fedora-release gets to decide what is started by default,
but it's probably better to start with a bug on the package because
its the maintainers know best if not starting the service by default
is possible and can file a fedora-release PR.

> It's also my hope that maybe some champion volunteers for tracking
> down issues like this and fixing them? i.e. keeping udev settle out of
> the default install alone would be a worthy goal for every release,
> given that it doubles boot time on typical systems... Anyone up for
> that?

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

Re: Can we maybe reduce the set of packages we install by default a bit?

[Adam Williamson]

On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote:
> On Tue, 9 Apr 2019 at 12:07, Lennart Poettering 
> wrote:
> 
> > Heya,
> > 
> > today I installed the current Fedora 30 Workstation beta on my new
> > laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> > crashed five times or so on me, always kicking me out of anaconda
> > again, just because I wanted to undo something). But I don't really
> > want to discuss that. What I do want to discuss is this:
> > 
> > Can we maybe reduce the default set of packages a bit? In particular
> > the following ones I really don't think should be in our default
> > install:
> > 
> > 
> This is not the first time this has come up and I expect it won't be the
> last time.
> 
> I think the main reason they stick around is that the people who want them
> gone just show up right after a release, drop a bunch of requests, and then
> go off to their own busy work. Then they come back a release later, don't
> see any change and either drop another email detailing things to be dropped
> OR discouraged that no-one ever listens. The things that do get changed and
> pulled out (or kept in) do so because people come in and work on scrubbing
> out the reasons and making sure the replacements are socialized in.
> 
> One of the things is that I am not sure any of these items
> 
> 
> 1. multipathd. On a workstation, uh?? I obviously have no multipath
> 
> 2. dmraid. Not quite as bad as multipathd as it is more likely to
> > 
> 
> I think these two are here because of the blivet you mentioned earlier.
> Advanced partitioning requires them to be there... and there do seem to be
> people who actually do expect both of those to work on their workstations
> when it was looked at to be removed in the past.
> 
> I do not know if the SIlverBlue does not have them on the other hand.

Basically, anything that's part of the install environment is going to
be present after a live install. That accounts for both of the above:
the installer supports multipath and dmraid storage devices, so the
relevant packages are part of the install environment, so they're part
of the lives, so they're installed by a live install.

This is kind of a limitation of the live deployment mechanism. In
theory a post-install stage could be added to strip things that were
only needed at install time, or that we can tell aren't actually needed
by the installed system, but this has never been done, though I recall
it being discussed at times.

> 
> > 3. atd? Do we still need that? Do we have postinst scripts that need
> 
> 4. Similar crond. On my fresh install it's only used by "zfs-fuse",
> > 

> This is more about socializing and teaching the systemd replacements...
> because most of the systemd advocates and heavy users I have asked aren't
> sure about how systemd replaces them and go back to cron/atd. I actually
> think that the replacements seem much better thought out than cruft-ware
> but.. but I also have little confidence I could get it to work consistently
> while I can find 10k tutorials on cron.

To be specific here, 'at' is part of the @standard group. 'chrony' is
pulled in several ways. It's part of @standard *if gnome-control-center 
is being installed*, so effectively it'll be installed with Workstation
but not other editions/spins. That sort of implies that there's some
functionality in GNOME that depends on chrony; I am not sure what that
is, off hand. It's also part of 'anaconda-tools' (so it will be in all
live images and all live installs), part of 'server-product' (so it is
in Server installs), and part of 'system-tools' (so it'll be in
anything that includes that). It's also part of 'workstation-product',
so it's really super *definitely* included in Workstation. :P

I think it is reasonable to suggest that there is a general expectation
that, on an out of the box *nix system, you can put stuff in crontab
and it will work. I like systemd timers, but the system doesn't attempt
cron compatibility so far as I'm aware; if we don't install a cron
daemon, this won't be the case. (I'm actually slightly interested in
whether you wind up with chrony if you do a non-live install of a non-
GNOME desktop; it looks to me like you don't, which is I guess
notable).

> > 5. libvirtd. Why is this running? Can't we make this socket
> > 
> 
> I don't know on this. I remember something about containers and flatpaks
> but .. I don't know.

Boxes is a key component of Workstation, and it relies on libvirt. It's
in the 'Core Applications' definition of the Workstation tech spec:

https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: Can we maybe reduce the set of packages we install by default a bit?

[Adam Williamson]

On Tue, 2019-04-09 at 10:11 -0700, Adam Williamson wrote:
> 
> To be specific here, 'at' is part of the @standard group. 'chrony' is
> pulled in several ways. It's part of @standard *if gnome-control-center 
> is being installed*, so effectively it'll be installed with Workstation
> but not other editions/spins. That sort of implies that there's some
> functionality in GNOME that depends on chrony; I am not sure what that
> is, off hand. It's also part of 'anaconda-tools' (so it will be in all
> live images and all live installs), part of 'server-product' (so it is
> in Server installs), and part of 'system-tools' (so it'll be in
> anything that includes that). It's also part of 'workstation-product',
> so it's really super *definitely* included in Workstation. :P

nirik points out that I have been sunk by homonyms here: chrony is an
NTP daemon, not a cron daemon. :P

Our 'default' cron daemon is cronie, but that hasn't appeared in comps
at all since it was specifically removed by a PR:

https://pagure.io/fedora-comps/pull-request/179

However, I think I know why it's still showing up: 'crontabs' is in
@workstation-product and @standard in comps, and crontabs Recommends
cronie.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2019-04-10 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. Agenda is in the 
https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next 


Source: https://apps.fedoraproject.org/calendar/meeting/9364/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[Bug 1698174] New: perl-Sereal-Encoder-4.007 is available

[bugzilla]

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

Bug ID: 1698174
   Summary: perl-Sereal-Encoder-4.007 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Encoder
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.007
Current version/release in rawhide: 4.006-1.fc31
URL: http://search.cpan.org/dist/Sereal-Encoder/

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

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

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1698173] New: perl-Sereal-Decoder-4.007 is available

[bugzilla]

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

Bug ID: 1698173
   Summary: perl-Sereal-Decoder-4.007 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal-Decoder
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.007
Current version/release in rawhide: 4.006-1.fc31
URL: http://search.cpan.org/dist/Sereal-Decoder/

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

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

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1698172] New: perl-Sereal-4.007 is available

[bugzilla]

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

Bug ID: 1698172
   Summary: perl-Sereal-4.007 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sereal
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.007
Current version/release in rawhide: 4.006-1.fc31
URL: http://search.cpan.org/dist/Sereal/

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

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

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697635] perl-Sereal-Encoder-4.006 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Sereal-Encoder-4.006-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf812a3fd3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697634] perl-Sereal-Decoder-4.006 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Sereal-Decoder-4.006-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-2363e01b3b

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1698315] New: perl-Verilog-Perl-3.462 is available

[bugzilla]

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

Bug ID: 1698315
   Summary: perl-Verilog-Perl-3.462 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Verilog-Perl
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: chitl...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.462
Current version/release in rawhide: 3.460-2.fc30
URL: http://search.cpan.org/dist/Verilog-Perl/

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

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

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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[389-devel] please review: PR 50323 - Add monitor tab functionality to UI/CLI

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50323
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2019-04-10 - 88% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/04/10/report-389-ds-base-1.4.1.2-20190409git51eb5b2.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 238  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  46  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2   
tor-0.3.5.8-1.el7
  40  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9c2c40e3df   
guacamole-server-1.0.0-1.el7
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-317c9a2f81   
drupal7-7.65-1.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-114610bd18   
golang-googlecode-go-crypto-0-0.15.20190324gitb7391e9.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294   
cinnamon-3.6.7-5.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f1efad2982   
aria2-1.34.0-4.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7bae341677   
chromium-73.0.3683.86-2.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c9cd2d9a6c   
ntfs-3g-2017.3.23-11.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd   
afflib-3.7.18-2.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c739f0a89d   
openjpeg2-2.3.1-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-77190f3ef7   
python34-3.4.10-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8395a0247   
transmission-2.94-6.el7


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

bdii-5.2.25-2.el7
dnsperf-2.2.1-3.el7
kronosnet-1.8-1.el7
pagure-5.5-1.el7
pspg-1.6.5-1.el7
python-catkin_pkg-0.4.11-1.el7
python-impacket-0.9.19-1.el7
python-pymssql-2.1.4-1.el7
python3-pyparsing-2.4.0-1.el7
znc-1.7.3-1.el7

Details about builds:



 bdii-5.2.25-2.el7 (FEDORA-EPEL-2019-83a42ffdb7)
 The Berkeley Database Information Index (BDII)

Update Information:

bdii 5.2.25

ChangeLog:

* Tue Apr  9 2019 Mattias Ellert  - 5.2.25-2
- Define __python2 if undefined
* Tue Apr  9 2019 Mattias Ellert  - 5.2.25-1
- Version 5.2.25
- Upstream project moved to github
* Thu Jan 31 2019 Fedora Release Engineering  - 
5.2.23-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Tue Nov 13 2018 Mattias Ellert  - 5.2.23-11
- Don't use /usr/bin/python shebang
- Remove EPEL 5 conditionals
* Thu Jul 12 2018 Fedora Release Engineering  - 
5.2.23-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Wed Feb  7 2018 Iryna Shcherbina  - 5.2.23-9
- Update Python 2 dependency declarations to new packaging standards
  (See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3)
* Wed Feb  7 2018 Fedora Release Engineering  - 
5.2.23-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Jul 26 2017 Fedora Release Engineering  - 
5.2.23-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Fri Feb 10 2017 Fedora Release Engineering  - 
5.2.23-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Mon Aug 15 2016 Mattias Ellert  - 5.2.23-5
- Convert to systemd unit files (Fedora 25+)
* Wed Feb  3 2016 Fedora Release Engineering  - 
5.2.23-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
* Sun Jul 26 2015 Mattias Ellert  - 5.2.23-3
- Adapt to new policycoreutils packaging (Fedora 23+)
* Wed Jun 17 2015 Fedora Release Engineering  
- 5.2.23-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild




 dnsperf-2.2.1-3.el7 (FEDORA-EPEL-2019-dbca455024)
 Benchmarking authorative and recursing DNS servers

Update Information:

New dnsperf package with latest upstream version.

References:

  [ 1 ] Bug #1305888 - dnsperf for epel7
https://bugzilla.redhat.com/show_bug.cgi?id=1305888




 kronosnet-1.8-1.el7 (FEDORA-EPEL-2019-4780c5a01a)
 Multipoint-to-Multipoint VPN daemon

Update Information:

Updated to upstream release v1.8.    Updated to upstream release v1.5.  
Updated to upstream release v1.4.    First commit of the new kronosnet
package.

References:

  [ 1 ] Bug #1507103 - Review Request: kronosnet - Multipoint-to-Multipoint 

[Bug 1697630] perl-App-a2p-1.011 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-App-a2p-1.011-1.fc31



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697630] perl-App-a2p-1.011 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-App-a2p-1.011-1.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-d7bb240e1b

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697634] perl-Sereal-Decoder-4.006 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Sereal-Decoder-4.006-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-2363e01b3b

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697634] perl-Sereal-Decoder-4.006 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Sereal-Decoder-4.006-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-d5b3e2cb13

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697633] perl-Sereal-4.006 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||Github
   ||Sereal/Sereal/issues/197



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697635] perl-Sereal-Encoder-4.006 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Sereal-Encoder-4.006-1.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-d5ce92c1b9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697635] perl-Sereal-Encoder-4.006 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Sereal-Encoder-4.006-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf812a3fd3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697634] perl-Sereal-Decoder-4.006 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Sereal-Decoder-4.006-1
   ||.fc31



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697635] perl-Sereal-Encoder-4.006 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Sereal-Encoder-4.006-1
   ||.fc31



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697634] perl-Sereal-Decoder-4.006 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Sereal-Decoder-4.006-1.fc30 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-e03735d10d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697633] perl-Sereal-4.006 is available

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
This release fixes a bug but at the same time Serial module stops exporting
write_sereal and read_sereal symbols. This a breaking change and thus this
release is suitable for Rawhide only.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697635] perl-Sereal-Encoder-4.006 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Sereal-Encoder-4.006-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-4965667f10

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697633] perl-Sereal-4.006 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Sereal-4.006-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-04-09 13:32:17



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697633] perl-Sereal-4.006 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Depends On||1697634, 1697635




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1697634
[Bug 1697634] perl-Sereal-Decoder-4.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1697635
[Bug 1697635] perl-Sereal-Encoder-4.006 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697635] perl-Sereal-Encoder-4.006 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1697633




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1697633
[Bug 1697633] perl-Sereal-4.006 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org

[Bug 1697634] perl-Sereal-Decoder-4.006 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1697633




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1697633
[Bug 1697633] perl-Sereal-4.006 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org