Re: how to set passwrod for Fedora LiveCD (Fedora 30)?

[Globe Trotter via devel]

 Thanks again! I do have these lines in my fedora-live-base.ks also (that is 
being called by fedora-live-shunya-30.ks).


# add fedora user with no passwd
action "Adding live user" useradd \$USERADDARGS -c "Live System User" liveuser
passwd -d liveuser > /dev/null
usermod -aG wheel liveuser > /dev/null




On Thursday, May 30, 2019, 12:37:32 AM CDT, Samuel Sieb  
wrote:  
 
 On 5/29/19 10:17 PM, Globe Trotter via devel wrote:
> %include fedora-live-base.ks

That file is where the user creation should be.

I am still on F29 and this is what is in 
/usr/share/spin-kickstarts/fedora-live-base.ks:

# add liveuser user with no passwd
action "Adding live user" useradd \$USERADDARGS -c "Live System User" 
liveuser
passwd -d liveuser > /dev/null
usermod -aG wheel liveuser > /dev/null


That's part of the bootup scripts near the bottom of the file.  See what 
is in yours.
___
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: how to set passwrod for Fedora LiveCD (Fedora 30)?

[Samuel Sieb]

On 5/29/19 10:17 PM, Globe Trotter via devel wrote:

%include fedora-live-base.ks


That file is where the user creation should be.

I am still on F29 and this is what is in 
/usr/share/spin-kickstarts/fedora-live-base.ks:


# add liveuser user with no passwd
action "Adding live user" useradd \$USERADDARGS -c "Live System User" 
liveuser

passwd -d liveuser > /dev/null
usermod -aG wheel liveuser > /dev/null


That's part of the bootup scripts near the bottom of the file.  See what 
is in yours.

___
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: Google Chrome Flash doesn't seem to work in F30

[Tomas Popela]

On Wed, May 29, 2019 at 2:59 PM Tomas Popela  wrote:

> I will mail some Chromium devs to consider backporting it.
>

It has been merged to Chromium 75 (
https://bugs.chromium.org/p/chromium/issues/detail?id=956644#c16 ) and will
be released next week when the Chrome 75 will be promoted to stable -
https://www.chromestatus.com/features/schedule.

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

Re: how to set passwrod for Fedora LiveCD (Fedora 30)?

[Globe Trotter via devel]

 Thanks! Because Yahoo Mail mangles responses, I will write things here clearly 
(including your questions).
> How are you creating it?

sudo livecd-creator --config=fedora-live-shunya-30.ks --tmpdir=tmp 
--fslabel=Fedora-Shunya-30-x86_64
> Is there more to the kickstart?  Where is the user creation?  That's where 
> the password would be set.
Here is the entire kickstart file:
# fedora-live-shunya.ks
#
# Description:
# - Fedora Live Spin with the light-weight Shunya Environment
#

repo --name=MyBaseRepo --baseurl=file:///home/maitra/rpmbuild/RPMS/$basearch
%include fedora-live-base.ks
%include fedora-live-minimization.ks
%include fedora-shunya-common.ks

#enable slim%postsystemctl enable slim

# This is a huge file and things work ok without it #taken from 
fedora-livecd-xfce
rm -f /usr/share/icons/HighContrast/icon-theme.cache


# create /etc/sysconfig/desktop (needed for installation)
cat > /etc/sysconfig/desktop <> /etc/rc.d/init.d/livesys << EOF
# disable screensaver locking and make sure gamin gets started
cat >> /etc/xdg/openbox/autostart << FOE
/usr/libexec/gam_server
/usr/bin/thaali &
/usr/bin/pnmixer &
/usr/libexec/notification-daemon &
@nm-applet 
#(sleep 5; /usr/bin/wbar -c /etc/wbar.d/wbar.cfg &)&
wbar&
conky&
FOE


# set up preferred apps 
cat > /etc/xdg/libfm/pref-apps.conf << FOE 
[Preferred Applications]
WebBrowser=firefox.desktop
MailClient=sylpheed.desktop
FOE

sed '
/#default_user/a\
default_user  liveuser
' /etc/slim.conf
sed '
/#auto_login/a\
autologin  yes
' /etc/slim.conf


sed '
/sessions/ c\
sessions  openbox
' /etc/slim.conf


sed '
/exec/ c\
exec   openbox-session
' /etc/X11/xinit/xinitrc


# Show harddisk install on the desktop
sed -i -e 's/NoDisplay=true/NoDisplay=false/' 
/usr/share/applications/liveinst.desktop
mkdir /home/liveuser/Desktop
cp /usr/share/applications/liveinst.desktop /home/liveuser/Desktop


# this goes at the end after all other changes.
chown -R liveuser:liveuser /home/liveuser
restorecon -R /home/liveuser

EOF

%end



-
And here is the fedora-shunya-common.ks file (probably not needed for your 
question):


# fedora-shunya-common.ks
#
# Description:
# - Fedora Live Spin with the Shunya Zero Desktop Environment 
#
%packages
slim
openbox
obconf
obmenu
udisks2
spacefm
thaali
wbar
aNu
leafpad
#dillo
gpicview

fetchmail
procmail
xorg-x11-fonts-misc
@networkmanager-submodules
NetworkManager-openconnect
gnome-keyring

#emacspeak
#xdvi
#R-devel
#lapack-devel
#fftw-devel
#octave-devel
#libRmath-devel
#valgrind
#texlive-pdfjam
#okular

### internet
firefox
pidgin
sylpheed
sylfilter
### office
#libreoffice
abiword
gnumeric
osmo
conky
network-manager-applet
###xplanet
### graphics
#zathura
#zathura-ps
#zathura-pdf-poppler
#zathura-djvu
#mtpaint
#fstransform
#luksipc
pdf-stapler

### audio & video
alsa-plugins-pulseaudio
#asunder
#gxine
#gxine-mozplugin
pavucontrol
#pnmixer
bitmap-fixed-fonts
ucs-miscfixed-fonts
blueman
#clipit
sylfilter
redshift

## font packages for blueman
-gtk2-engines
-gtk-nodoka-engine
-gtk-solidity-engine
-libwvstreams
-nano
lockdev
-wvdial


# pam-fprint causes a segfault in LXDM when enabled
-fprintd-pam


# LXDE has lxpolkit. Make sure no other authentication agents end up in the 
spin.
-polkit-gnome
-polkit-kde

# make sure xfce4-notifyd is not pulled in
dunst
#notification-daemon
-xfce4-notifyd
-audit
-abrt-cli
-abrt
libreport

# make sure xfwm4 is not pulled in for firstboot
# https://bugzilla.redhat.com/show_bug.cgi?id=643416
# metacity


# dictionaries are big
-man-pages-*
-words

# use ssmtp instead of sendmail
-sendmail
# ssmtp

# save some space
autofs
-acpid
-gimp-help
-f30-backgrounds-base
-f30-backgrounds-gnome
desktop-backgrounds-basic  # slim brings this in, so this will not be removed
realmd # only seems to be used in GNOME
-PackageKit*    # we switched to yumex, so we don't need this
-foomatic-db-ppds
-foomatic
-stix-fonts
-ibus-typing-booster
-xscreensaver
-wqy-zenhei-fonts
#-tigervnc*
#tigervnc-server-minimal

# drop some system-config things
# -system-config-boot
#-system-config-language
-system-config-network
-system-config-rootpassword
#-system-config-services
-policycoreutils-gui
-gnome-disk-utility

# Dial-up and Networking:
-@dial-up

# Guest Desktop Agents
-@guest-desktop-agents

# Printing
#-@printing

# we need UPower for suspend and hibernate
upower

%end


-

Thank you very miuch for your help!!



On Wednesday, May 29, 2019, 11:03:54 PM CDT, Samuel Sieb  
wrote:  
 
 On 5/29/19 6:46 PM, Globe Trotter via devel wrote:
> I created a LiveCD for my own personal use (with openbox) in Fedora 30. 
> I have created such a live cd for the past several cycles (I think

How are you creating it?How are you creating it?

> In the past, I have the SLiM (slim) screen show up with username (that I 
> say is liveuser) and does not prompt me for a 

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[John Reiser]

If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to build for Fedora 3x?  Or does RHEL 7 RPM
support zstd?



We're pretty much screwed here. Also, since RHEL 8's rpm package does
not have zstd support compiled in, it too cannot handle the RPMs.



Hence it needs to be configurable. Fedora EPEL RPMs need to be built
with xz. Everything else  that's expected to be consumed by Fedora 29
and higher, can use either zstd or xz. I'd expect RHEL built packages
intended for Fedora would use xz, and Fedora's RPM would support that
just fine.


Fedora should provide a means to convert from .rpm-with-compression-A
to .rpm-with-compression-B.  Already there is 'alien' which converts
between .rpm, .deb, and .tgz.
___
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: how to set passwrod for Fedora LiveCD (Fedora 30)?

[Samuel Sieb]

On 5/29/19 6:46 PM, Globe Trotter via devel wrote:
I created a LiveCD for my own personal use (with openbox) in Fedora 30. 
I have created such a live cd for the past several cycles (I think


How are you creating it?

In the past, I have the SLiM (slim) screen show up with username (that I 
say is liveuser) and does not prompt me for a password. However, in 
Fedora 30, I am prompted for password from the created LiveCD. So I can 
not get in.


Here are the lines in my kickstart file:


Is there more to the kickstart?  Where is the user creation?  That's 
where the password would be set.

___
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

[389-devel] 389 DS nightly 2019-05-30 - 93% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/05/30/report-389-ds-base-1.4.1.2-2.fc30.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

Fedora Rawhide-20190529.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!
1 of 47 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 8/137 (x86_64), 1/2 (arm)

ID: 407317  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/407317
ID: 407346  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/407346
ID: 407352  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/407352
ID: 407356  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/407356
ID: 407357  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/407357
ID: 407358  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/407358
ID: 407387  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/407387
ID: 407409  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/407409
ID: 407424  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/407424

Soft failed openQA tests: 63/137 (x86_64), 17/22 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 407291  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/407291
ID: 407292  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/407292
ID: 407299  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/407299
ID: 407300  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/407300
ID: 407301  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/407301
ID: 407302  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/407302
ID: 407304  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/407304
ID: 407316  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/407316
ID: 407320  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/407320
ID: 407321  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/407321
ID: 407332  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/407332
ID: 407339  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/407339
ID: 407340  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/407340
ID: 407343  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/407343
ID: 407360  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/407360
ID: 407361  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/407361
ID: 407363  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/407363
ID: 407364  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/407364
ID: 407366  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/407366
ID: 407367  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/407367
ID: 407368  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/407368
ID: 407369  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/407369
ID: 407371  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/407371
ID: 407372  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/407372
ID: 407373  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/407373
ID: 407374  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/407374
ID: 407375  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/407375
ID: 407376  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/407376
ID: 407377  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/407377
ID: 407378  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/407378
ID: 407379  Test: x86_64 universal 

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Chris Murphy]

On Wed, May 29, 2019 at 4:07 PM Neal Gompa  wrote:
>
> This is news to me, as I've never heard of any "side mass rebuilds".
> They're prohibitively expensive to do, which is why we do only one per
> release anyway.

Is it sane to test this in Rawhide now with just new builds? As things
get rebuilt in rawhide, we should start seeing reduced times in
various installation tests, including the ones openqa does, I think
dozens of times every day.

> I'm pretty sure this would break DeltaRPMs, since none of the drpm
> software has been updated to handle zstd compression. Neither drpm nor
> deltarpm handle it today.

'dnf info deltarpm' says
URL  : http://gitorious.org/deltarpm/deltarpm
which has an expired certificate, but pushing passed that it says
current version 3.6 is 5 years old. Is this really maintained or
updatabled?

I see compression options in makedeltarpm, and zstd isn't in it. I'm
guessing we'd end up at line 580:

  fprintf(stderr, "unknown compression type: %s\n", comp);

https://github.com/rpm-software-management/deltarpm/blob/3.6.1/makedeltarpm.c

Anyway, I think optimizing for this is something rpm-ostree is better
suited for anyway. Due to the significantly faster decompress time of
zstd, whatever advantage there is of deltarpm is rapidly diminished.
Possibly the only way to know this is for someone to update deltarpm
to handle zstd and then test if the savings is still significant
compared to local reprocessing time.


> > If we did this, wouldn't it make it very difficult to use tools like
> > mock on RHEL / CentOS 7 to build for Fedora 3x?  Or does RHEL 7 RPM
> > support zstd?
> >
>
> We're pretty much screwed here. Also, since RHEL 8's rpm package does
> not have zstd support compiled in, it too cannot handle the RPMs.

Hence it needs to be configurable. Fedora EPEL RPMs need to be built
with xz. Everything else  that's expected to be consumed by Fedora 29
and higher, can use either zstd or xz. I'd expect RHEL built packages
intended for Fedora would use xz, and Fedora's RPM would support that
just fine.


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

Fedora rawhide compose report: 20190529.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190527.n.0
NEW: Fedora-Rawhide-20190529.n.0

= SUMMARY =
Added images:10
Dropped images:  12
Added packages:  10
Dropped packages:20
Upgraded packages:   180
Downgraded packages: 0

Size of added packages:  101.38 MiB
Size of dropped packages:49.37 MiB
Size of upgraded packages:   7.80 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: LXDE live i386
Path: Spins/i386/iso/Fedora-LXDE-Live-i386-Rawhide-20190529.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190529.n.0.s390x.qcow2
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20190529.n.0-sda.raw.xz
Image: Astronomy_KDE live i386
Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20190529.n.0.iso
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190529.n.0.s390x.vmdk
Image: Security live i386
Path: Labs/i386/iso/Fedora-Security-Live-i386-Rawhide-20190529.n.0.iso
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20190529.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190529.n.0.s390x.raw.xz
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20190529.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20190529.n.0.iso

= DROPPED IMAGES =
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20190527.n.0-sda.raw.xz
Image: KDE live i386
Path: Spins/i386/iso/Fedora-KDE-Live-i386-Rawhide-20190527.n.0.iso
Image: Xfce live i386
Path: Spins/i386/iso/Fedora-Xfce-Live-i386-Rawhide-20190527.n.0.iso
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190527.n.0-sda.raw.xz
Image: Container_Minimal_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20190527.n.0.x86_64.tar.xz
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20190527.n.0-sda.raw.xz
Image: Workstation live i386
Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-Rawhide-20190527.n.0.iso
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20190527.n.0.ppc64le.tar.xz
Image: Design_suite live i386
Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20190527.n.0.iso
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20190527.n.0.iso
Image: Games live i386
Path: Labs/i386/iso/Fedora-Games-Live-i386-Rawhide-20190527.n.0.iso
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20190527.n.0.aarch64.raw.xz

= ADDED PACKAGES =
Package: R-miniUI-0.1.1.1-1.fc31
Summary: Shiny UI Widgets for Small Screens
RPMs:R-miniUI
Size:44.94 KiB

Package: R-styler-1.1.1-1.fc31
Summary: Non-Invasive Pretty Printing of R Code
RPMs:R-styler
Size:476.01 KiB

Package: belle-sip-1.4.2-9.fc31
Summary: Linphone SIP stack
RPMs:belle-sip belle-sip-devel
Size:2.94 MiB

Package: cri-o-2:1.14.1-2.gitb7644f6.module_f31+4388+7bbe13e2
Summary: Kubernetes Container Runtime Interface for OCI-based containers
RPMs:conmon cri-o
Size:71.99 MiB

Package: libdnf-plugin-swidtags-0.8.5-1.fc31
Summary: Keeping SWID tags in sync with rpms installed via libdnf-based tools
RPMs:libdnf-plugin-swidtags
Size:157.71 KiB

Package: libecap-1.0.1-4.module_f31+4407+71ecefea
Summary: Squid interface for embedded adaptation modules
RPMs:libecap libecap-devel
Size:269.81 KiB

Package: libslirp-4.0.0-1.fc31
Summary: A general purpose TCP-IP emulator
RPMs:libslirp libslirp-devel
Size:429.36 KiB

Package: python-betamax-serializers-0.2.0-2.fc31
Summary: A set of third-party serializers for Betamax
RPMs:python3-betamax-serializers
Size:13.61 KiB

Package: python-urwid-2.0.1-6.fc31
Summary: Console user interface library
RPMs:python3-urwid
Size:4.56 MiB

Package: squid-7:4.7-4.module_f31+4407+71ecefea
Summary: The Squid proxy caching server
RPMs:squid
Size:20.52 MiB


= DROPPED PACKAGES =
Package: ikarus-0.0.3-17.fc27
Summary: An incremental optimizing compiler for R6RS Scheme
RPMs:ikarus
Size:1.19 MiB

Package: perl-Qt-4.14.3-17.fc30
Summary: Perl bindings for Qt
RPMs:perl-Qt perl-Qt-devel
Size:16.54 MiB

Package: python-castellan-0.5.0-7.fc30
Summary: Generic Key Manager interface for OpenStack
RPMs:python-castellan-doc python3-castellan
Size:273.80 KiB

Package: python-cursive-0.1.2-8.fc30
Summary: OpenStack-specific validation of digital signatures
RPMs:python-cursive-doc python3-cursive
Size:196.85 KiB

Package: python-keystonemiddleware-4.21.0-2.fc30
Summary: Middleware for OpenStack Identity
RPMs:python

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Chris Murphy]

On Wed, May 29, 2019 at 2:20 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
> == Summary ==
> Binary RPMs are currently compressed with xz level 2.
> Switching to zstd would increase decompression speed significantly.

Arch has been discussing this change also, with more elaborate test
results. This is the most recent table including --ultra flag to
unlock level 20+
https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029542.html

The first post
https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029520.html

> * The recommended compression level is 19. The builds will take
> longer, but the additional compression time is negligible in the total
> build time and it pays off in better compression ratio than xz lvl2
> has.

Even without dictionary, -T0 will outperform xz. By how much depends
on the resources available at the time.

Phase 2 (it's out of scope for this feature): If you can figure out a
way to leverage the zstd (training) dictionary feature, that would
increase compression ratios, reduce compression time, as well as
decompression speed. The gotcha is the dictionary must be specified
for both compression and decompression. So you'd need a way for the
RPM metadata to reference a dictionary version, and package the
dictionary with RPM to make sure it's available. You only need one
version, but if future training demonstrates a significant
improvement, you'd want a way to deploy multiple dictionaries, and
differentiate which was used to compress an RPM since packages could
be made with either or none.
https://github.com/facebook/zstd  See "the case for small data compression"



> == Benefit to Fedora ==
> * Faster installations/upgrades of user systems
> * Faster koji builds (installations in build roots)
> * Faster container builds
> * Lower bandwidth on mirrors if we choose the highest compression level

Likely also faster openqa installations and testing.



> == How To Test ==
> * dnf install 
> * rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n" 
> * expected output: zstd 19

Someone building an RPM locally for local use (or within their
organization) shouldn't get hit with level 19 compression time and
memory requirements. They're probably alright with just the default,
level 3. That's way faster than xz, and compresses better than any of
the zips.

Is there a way to configure different defaults, either on the command
line or with a configuration file? If you don't want to expose all of
the zstd options, even coming up with your own mapping/grouping is
useful: faster=3, better=20  And at some future date, both of them can
use the latest version dictionary automatically.


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

how to set passwrod for Fedora LiveCD (Fedora 30)?

[Globe Trotter via devel]

Hi, 

I created a LiveCD for my own personal use (with openbox) in Fedora 30. I have 
created such a live cd for the past several cycles (I think 

In the past, I have the SLiM (slim) screen show up with username (that I say is 
liveuser) and does not prompt me for a password. However, in Fedora 30, I am 
prompted for password from the created LiveCD. So I can not get in. 

Here are the lines in my kickstart file:

sed '
/#default_user/a\
default_user  liveuser
' /etc/slim.conf
sed '
/#auto_login/a\
autologin  yes
' /etc/slim.conf


sed '
/sessions/ c\
sessions  openbox
' /etc/slim.conf


# Show harddisk install on the desktop
sed -i -e 's/NoDisplay=true/NoDisplay=false/' 
/usr/share/applications/liveinst.desktop
mkdir /home/liveuser/Desktop
cp /usr/share/applications/liveinst.desktop /home/liveuser/Desktop

# this goes at the end after all other changes.
chown -R liveuser:liveuser /home/liveuser
restorecon -R /home/liveuser

EOF


So, I was wondering what to do in this case, or at the very least, try and 
provide a password for the livecd which can be used to login.
Thanks for any suggestions!



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

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Josh Boyer]

On Wed, May 29, 2019 at 6:07 PM Neal Gompa  wrote:
>
> On Wed, May 29, 2019 at 5:53 PM Josh Boyer  wrote:
> >
> > On Wed, May 29, 2019 at 4:20 PM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
> > >
> > > = Switch RPMs to zstd compression =
> > >
> > > == Summary ==
> > > Binary RPMs are currently compressed with xz level 2.
> > > Switching to zstd would increase decompression speed significantly.
> > >
> > > == Owner ==
> > > * Name: [[User:dmach| Daniel Mach]]
> > > * Email: dm...@redhat.com
> > >
> > > == Detailed Description ==
> > > * The change requires setting a new compression algorithm in rpm
> > > macros. Then a mass rebuild of all packages is required.
> >
> > The gcc team often does mass rebuilds on the side prior to updating
> > gcc in Fedora.  Would it be possible to do the same or leverage their
> > rebuild work with the default changed in RPM to see what the true
> > overall savings is?  That would get us a lot more data to see if it's
> > truly going to benefit the distro in terms of size and installation
> > speed.
> >
>
> This is news to me, as I've never heard of any "side mass rebuilds".
> They're prohibitively expensive to do, which is why we do only one per
> release anyway.

They do them quite frequently outside of the Fedora infrastructure.

> > > * The macro for setting the compression is: %define _binary_payload 
> > > w19.zstdio
> > > * The recommended compression level is 19. The builds will take
> > > longer, but the additional compression time is negligible in the total
> > > build time and it pays off in better compression ratio than xz lvl2
> > > has.
> > > * SRPM payload compression should stay at gzip (there's almost no
> > > benefit in changing the compression, because SRPM's contents is
> > > compressed already)
> > >
> > > === Use case: Firefox installation ===
> > > I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
> > > Then I compared installation times with the original (xz compressed) 
> > > package:
> > >
> > > {| class="wikitable"
> > > |-
> > > ! Compression !! Target File System !! Time
> > > |-
> > > | xz level 2  || tmpfs || 8s
> > > |-
> > > | xz level 2 || ext4 on nvme || 11s
> > > |-
> > > | zstd level 19  || tmpfs || 2s
> > > |-
> > > | zstd level 19  ||  ext4 on nvme || 4s
> > > |-
> > > |}
> > >
> > >
> > > === Comparison of compression algorithms and levels ===
> > > Following table shows '''cpio''' and '''compressed cpio''' extraction
> > > times into a tmpfs. Actual times in decompressing RPMs will differ due
> > > to extracting on an actual disk and also some overhead in the RPM tool
> > > (checks, scriptlets).
> > >
> > > {| class="wikitable"
> > > |-
> > > ! Compression   !! Level!! Size B   !! Size GiB
> > >  !! Compression time !! Compression time, 4 threads  !!
> > > Decompression time   !! Comment
> > > |-
> > > | CPIO  || -|| 5016785692   || 4,7
> > >  || -|| -|| -
> > >   ||
> > > |-
> > > | xz|| 2|| 1615017616   || 1,6
> > >  || 9m55s|| -|| 1m36s
> > >   || slow decompression
> > > |-
> > > | pxz   || 2|| 1631869880   || 1,6
> > >  || -|| 6m11s|| 1m38s
> > >   || slow decompression
> > > |-
> > > | gzip  || 9|| 2086354992   || 2,0
> > >  || 10m23s   || -|| 31s
> > >   || insufficient compression ratio
> > > |-
> > > | bzip2 || 9|| 1889161565   || 1,8
> > >  || 8m   || -|| 2m50s
> > >   || very slow decompression; compression ratio could be
> > > better
> > > |-
> > > | zstd  || 3|| 1913536587   || 1,8
> > >  || 31s  || 29s  || 6,5s
> > >   ||
> > > |-
> > > | zstd  || 10   || 1737928978   || 1,7
> > >  || 3m27s|| 2m34s|| 6,3s
> > >   ||
> > > |-
> > > | zstd  || 15   || 1717303256   || 1,7
> > >  || 9m37s|| 6m34s|| 6,3s
> > >   || identical compression speed to xz; fast decompression;
> > > slightly worse compression ratio than xz
> > > |-
> > > | zstd  || 17   || 1635525492   || 1,6
> > >  || 16m16s   || 11m20s   || 6,7s
> > >   ||
> > > |-
> > > | zstd  || 19   || 1575843696   || 1,5
> > >  || 24m2s|| 18m55s   || 7,7s
> > >   ||
> > > |-
> > > |}
> > >
> > > == Benefit to Fedora ==
> > > * Faster installations/upgrades of user systems
> > > * Faster koji builds (installations in build roots)
> > > * Faster container 

[Test-Announce] Fedora 31 Rawhide 20190529.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 31 Rawhide 20190529.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20190524.n.1: anaconda-31.12-1.fc31.src, 20190529.n.0: 
anaconda-31.13-1.fc31.src
pungi - 20190524.n.1: pungi-4.1.36-5.fc31.src, 20190529.n.0: 
pungi-4.1.37-1.fc31.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/31

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190529.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190529.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190529.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190529.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190529.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190529.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190529.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@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: Wiki page correction: GRUB2

[Chris Murphy]

On Wed, May 29, 2019 at 5:52 AM Michal Schorm  wrote:
>
> Hello,
>
> I'd like to propose tiny correction for the Fedora wiki page about GRUB2 [1].
>
> However I'm not confident enought to edit it prior to any discussions,
> so that's why I'm writing here.
>
> In the chapter "Updating GRUB 2 configuration on UEFI systems"
> In the section "Install the bootloader files"
> I believe, there should be an information added, that the 'grub2-efi'
> package *must* match your architecture. So e.g. for x86_64, you want
> the 'grub2-efi-x64' package.

No. You can have x86_64 CPU but the firmware is 32-bit, hence ia32
which is why there is:

grub2-efi-ia32-1:2.02-81.fc30.x86_64.rpm

The user space will still be 64-bit but the EFI binaries will be
32-bit for the rare firmware floating out there that require it. There
isn't a problem with 32-bit and 64-bit EFI binaries being located on
the same EFI system volume in EFI/fedora, the firmware figures it out
(I think by filenaming convention which is mentioned in the UEFI
spec).

My suggested change for this section:

 Install the bootloader files
If you don't already have the relevant packages installed, do for
Fedora 22 and later versions with DNF or with YUM for older Fedora
releases:

- dnf install grub2-efi shim
+ dnf install grub2-efi-ia32 grub2-efi-x64
- yum install grub2-efi shim

If you do, then try:

dnf reinstall grub2-efi shim
- yum reinstall grub2-efi shim

---

I think it's a negative for user to have to read a wall of text
explaining any aspect of architecture to them. It's bad enough we have
to explain BIOS vs UEFI. Just tell them to install the bootloader for
both, which is what a default Workstation installation does anyway.
And then remove deprecated yum command.

For reinstall, the existing command will replace both packages and
their respective EFI binaries.

> but I believe I only need the 'grub2-efi-x64.x86_64'.
> Given that, maybe the anaconda installation should be checked to not
> pull uneeded packages?

I'm pretty sure UEFI bitness is exposed by
/sys/firmware/efi/fw_platform_size but I don't know if anaconda uses
it.


-- 
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: Writing C/C++ code to detect running desktop environment

[Germano Massullo]

Il giorno mer 29 mag 2019 alle ore 22:12 Stephen Gallagher
 ha scritto:
>
> On Wed, May 29, 2019 at 1:16 PM Kalev Lember  wrote:
> I realize you said that the reasons are off-topic, but in general I'd
> recommend not making desktop-specific decisions at a high-level

I need to retrieve user idle time. To achieve this I was using GDbus
API of GLib/GIO to retrieve the systemd-logind IdleSinceHint DBus
property, but I have been told that logind relies on desktop
environment to pass the information to update this property. None of
main desktop environments does it, so I am writing code that will
interact with specific d.e. to retrieve user idle time. More infos at
"[systemd-devel] interacting with logind to detect user idle time"[1]

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

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[James Cassell]

On Wed, May 29, 2019, at 4:20 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
> 
> = Switch RPMs to zstd compression =
> 
[...]
> == Benefit to Fedora ==
> * Faster installations/upgrades of user systems
> * Faster koji builds (installations in build roots)
> * Faster container builds
> * Lower bandwidth on mirrors if we choose the highest compression level
> 

Would this help with drpms similar to how it helps with faster yum repo 
metadata downloads? My biggest problem with drpms is the slow rebuild speed 
which is usually slower than my download bandwidth.  It would be a big win if 
zstd helps here.


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

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Neal Gompa]

On Wed, May 29, 2019 at 5:53 PM Josh Boyer  wrote:
>
> On Wed, May 29, 2019 at 4:20 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
> >
> > = Switch RPMs to zstd compression =
> >
> > == Summary ==
> > Binary RPMs are currently compressed with xz level 2.
> > Switching to zstd would increase decompression speed significantly.
> >
> > == Owner ==
> > * Name: [[User:dmach| Daniel Mach]]
> > * Email: dm...@redhat.com
> >
> > == Detailed Description ==
> > * The change requires setting a new compression algorithm in rpm
> > macros. Then a mass rebuild of all packages is required.
>
> The gcc team often does mass rebuilds on the side prior to updating
> gcc in Fedora.  Would it be possible to do the same or leverage their
> rebuild work with the default changed in RPM to see what the true
> overall savings is?  That would get us a lot more data to see if it's
> truly going to benefit the distro in terms of size and installation
> speed.
>

This is news to me, as I've never heard of any "side mass rebuilds".
They're prohibitively expensive to do, which is why we do only one per
release anyway.

> > * The macro for setting the compression is: %define _binary_payload 
> > w19.zstdio
> > * The recommended compression level is 19. The builds will take
> > longer, but the additional compression time is negligible in the total
> > build time and it pays off in better compression ratio than xz lvl2
> > has.
> > * SRPM payload compression should stay at gzip (there's almost no
> > benefit in changing the compression, because SRPM's contents is
> > compressed already)
> >
> > === Use case: Firefox installation ===
> > I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
> > Then I compared installation times with the original (xz compressed) 
> > package:
> >
> > {| class="wikitable"
> > |-
> > ! Compression !! Target File System !! Time
> > |-
> > | xz level 2  || tmpfs || 8s
> > |-
> > | xz level 2 || ext4 on nvme || 11s
> > |-
> > | zstd level 19  || tmpfs || 2s
> > |-
> > | zstd level 19  ||  ext4 on nvme || 4s
> > |-
> > |}
> >
> >
> > === Comparison of compression algorithms and levels ===
> > Following table shows '''cpio''' and '''compressed cpio''' extraction
> > times into a tmpfs. Actual times in decompressing RPMs will differ due
> > to extracting on an actual disk and also some overhead in the RPM tool
> > (checks, scriptlets).
> >
> > {| class="wikitable"
> > |-
> > ! Compression   !! Level!! Size B   !! Size GiB
> >  !! Compression time !! Compression time, 4 threads  !!
> > Decompression time   !! Comment
> > |-
> > | CPIO  || -|| 5016785692   || 4,7
> >  || -|| -|| -
> >   ||
> > |-
> > | xz|| 2|| 1615017616   || 1,6
> >  || 9m55s|| -|| 1m36s
> >   || slow decompression
> > |-
> > | pxz   || 2|| 1631869880   || 1,6
> >  || -|| 6m11s|| 1m38s
> >   || slow decompression
> > |-
> > | gzip  || 9|| 2086354992   || 2,0
> >  || 10m23s   || -|| 31s
> >   || insufficient compression ratio
> > |-
> > | bzip2 || 9|| 1889161565   || 1,8
> >  || 8m   || -|| 2m50s
> >   || very slow decompression; compression ratio could be
> > better
> > |-
> > | zstd  || 3|| 1913536587   || 1,8
> >  || 31s  || 29s  || 6,5s
> >   ||
> > |-
> > | zstd  || 10   || 1737928978   || 1,7
> >  || 3m27s|| 2m34s|| 6,3s
> >   ||
> > |-
> > | zstd  || 15   || 1717303256   || 1,7
> >  || 9m37s|| 6m34s|| 6,3s
> >   || identical compression speed to xz; fast decompression;
> > slightly worse compression ratio than xz
> > |-
> > | zstd  || 17   || 1635525492   || 1,6
> >  || 16m16s   || 11m20s   || 6,7s
> >   ||
> > |-
> > | zstd  || 19   || 1575843696   || 1,5
> >  || 24m2s|| 18m55s   || 7,7s
> >   ||
> > |-
> > |}
> >
> > == Benefit to Fedora ==
> > * Faster installations/upgrades of user systems
> > * Faster koji builds (installations in build roots)
> > * Faster container builds
> > * Lower bandwidth on mirrors if we choose the highest compression level
> >

I'm pretty sure this would break DeltaRPMs, since none of the drpm
software has been updated to handle zstd compression. Neither drpm nor
deltarpm handle it today.

> > == Scope ==
> > * Proposal owners: submit a patch to redhat-rpm-config
> > * Other developers: 

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Josh Boyer]

On Wed, May 29, 2019 at 4:20 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
> == Summary ==
> Binary RPMs are currently compressed with xz level 2.
> Switching to zstd would increase decompression speed significantly.
>
> == Owner ==
> * Name: [[User:dmach| Daniel Mach]]
> * Email: dm...@redhat.com
>
> == Detailed Description ==
> * The change requires setting a new compression algorithm in rpm
> macros. Then a mass rebuild of all packages is required.

The gcc team often does mass rebuilds on the side prior to updating
gcc in Fedora.  Would it be possible to do the same or leverage their
rebuild work with the default changed in RPM to see what the true
overall savings is?  That would get us a lot more data to see if it's
truly going to benefit the distro in terms of size and installation
speed.

> * The macro for setting the compression is: %define _binary_payload w19.zstdio
> * The recommended compression level is 19. The builds will take
> longer, but the additional compression time is negligible in the total
> build time and it pays off in better compression ratio than xz lvl2
> has.
> * SRPM payload compression should stay at gzip (there's almost no
> benefit in changing the compression, because SRPM's contents is
> compressed already)
>
> === Use case: Firefox installation ===
> I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
> Then I compared installation times with the original (xz compressed) package:
>
> {| class="wikitable"
> |-
> ! Compression !! Target File System !! Time
> |-
> | xz level 2  || tmpfs || 8s
> |-
> | xz level 2 || ext4 on nvme || 11s
> |-
> | zstd level 19  || tmpfs || 2s
> |-
> | zstd level 19  ||  ext4 on nvme || 4s
> |-
> |}
>
>
> === Comparison of compression algorithms and levels ===
> Following table shows '''cpio''' and '''compressed cpio''' extraction
> times into a tmpfs. Actual times in decompressing RPMs will differ due
> to extracting on an actual disk and also some overhead in the RPM tool
> (checks, scriptlets).
>
> {| class="wikitable"
> |-
> ! Compression   !! Level!! Size B   !! Size GiB
>  !! Compression time !! Compression time, 4 threads  !!
> Decompression time   !! Comment
> |-
> | CPIO  || -|| 5016785692   || 4,7
>  || -|| -|| -
>   ||
> |-
> | xz|| 2|| 1615017616   || 1,6
>  || 9m55s|| -|| 1m36s
>   || slow decompression
> |-
> | pxz   || 2|| 1631869880   || 1,6
>  || -|| 6m11s|| 1m38s
>   || slow decompression
> |-
> | gzip  || 9|| 2086354992   || 2,0
>  || 10m23s   || -|| 31s
>   || insufficient compression ratio
> |-
> | bzip2 || 9|| 1889161565   || 1,8
>  || 8m   || -|| 2m50s
>   || very slow decompression; compression ratio could be
> better
> |-
> | zstd  || 3|| 1913536587   || 1,8
>  || 31s  || 29s  || 6,5s
>   ||
> |-
> | zstd  || 10   || 1737928978   || 1,7
>  || 3m27s|| 2m34s|| 6,3s
>   ||
> |-
> | zstd  || 15   || 1717303256   || 1,7
>  || 9m37s|| 6m34s|| 6,3s
>   || identical compression speed to xz; fast decompression;
> slightly worse compression ratio than xz
> |-
> | zstd  || 17   || 1635525492   || 1,6
>  || 16m16s   || 11m20s   || 6,7s
>   ||
> |-
> | zstd  || 19   || 1575843696   || 1,5
>  || 24m2s|| 18m55s   || 7,7s
>   ||
> |-
> |}
>
> == Benefit to Fedora ==
> * Faster installations/upgrades of user systems
> * Faster koji builds (installations in build roots)
> * Faster container builds
> * Lower bandwidth on mirrors if we choose the highest compression level
>
> == Scope ==
> * Proposal owners: submit a patch to redhat-rpm-config
> * Other developers: redhat-rpm-config maintainer: include the patch
> and make a new build
> * Release engineering: [https://pagure.io/releng/issue/8345 #8345]
> mass rebuild is needed
>
> == Upgrade/compatibility impact ==
> * RPM in Fedora supports zstd compression already (from Fedora 28,
> rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
> * Fedora <= 27 and some other distros will not be able to decompress
> zstd-compressed RPMs.

If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to build for Fedora 3x?  Or does RHEL 7 RPM
support zstd?

Does MBS's concept of platform modules help 

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Jason L Tibbitts III]

> "BC" == Ben Cotton  writes:

BC> * The change requires setting a new compression algorithm in rpm
BC> macros. Then a mass rebuild of all packages is required.

Technically there is no harm if a mass rebuild is not done; there will
simply be no benefit for packages which aren't rebuilt.  Certainly the
change should be made in advance of the mass rebuild, assuming we're
going to do one.

BC> * The recommended compression level is 19. The builds will take
BC> longer, but the additional compression time is negligible in the
BC> total build time and it pays off in better compression ratio than xz
BC> lvl2 has.

That seems different than other results I've seen.  According to the
wikipedia page (https://en.wikipedia.org/wiki/Zstandard) and the
references therein, Ubuntu found that zstd level 19 was faster but with
poorer compression when compared with xz level 2 (which is the same
level that we use now).

I'm not super familiar with zstd but the data presented also implies
that multithreaded compression is available and at no loss to package
size (unlike parallel xz).  But looking at the RPM source, I don't see
that the thread count can be specified for zstdio as it can be with xzio
(as in setting %_binary_payload to "w2T16.xzdio").  If I'm understanding
this correctly, it would be really nice of threaded zstd compression
(and decompression) were possible and supported.

Finally, note that as far as I can tell, this will render RHEL7 and
older unable to decompress Fedora RPMs.  RPM 4.14 seems to be required.

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

[Bug 1715236] New: perl-SQL-Translator-1.60 is available

[bugzilla]

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

Bug ID: 1715236
   Summary: perl-SQL-Translator-1.60 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-SQL-Translator
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.60
Current version/release in rawhide: 0.11024-5.fc30
URL: http://search.cpan.org/dist/SQL-Translator/

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

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

Re: Writing C/C++ code to detect running desktop environment

[Kevin Kofler]

Stephen Gallagher wrote:
> I realize you said that the reasons are off-topic, but in general I'd
> recommend not making desktop-specific decisions at a high-level and
> instead base your decisions off of availability of particular
> functionality. For example, if your application needs to manage
> software updates, have it check for whether PackageKit or dnf-daemon
> are available. If it needs to store something in a password wallet,
> check for GNOME Keyring or KWallet, etc.

Another solution is to use abstraction layers. E.g., for the password 
wallet, you can use QtKeychain: https://github.com/frankosterfeld/qtkeychain
To open a document or web page, instead of hardcoding the application (e.g., 
the web browser), you can run xdg-open. Etc.

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

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Stuart D. Gathman]

On Wed, 29 May 2019, Ben Cotton wrote:


https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression

= Switch RPMs to zstd compression =

== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.


...


mass rebuild is needed


Why?  Newly built RPMs will use the new compression, and will rapidly 
replace the old compression - with 100% replacement by fedora 32.


--
  Stuart D. Gathman 
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
___
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 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression

= Switch RPMs to zstd compression =

== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.

== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dm...@redhat.com

== Detailed Description ==
* The change requires setting a new compression algorithm in rpm
macros. Then a mass rebuild of all packages is required.
* The macro for setting the compression is: %define _binary_payload w19.zstdio
* The recommended compression level is 19. The builds will take
longer, but the additional compression time is negligible in the total
build time and it pays off in better compression ratio than xz lvl2
has.
* SRPM payload compression should stay at gzip (there's almost no
benefit in changing the compression, because SRPM's contents is
compressed already)

=== Use case: Firefox installation ===
I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
Then I compared installation times with the original (xz compressed) package:

{| class="wikitable"
|-
! Compression !! Target File System !! Time
|-
| xz level 2  || tmpfs || 8s
|-
| xz level 2 || ext4 on nvme || 11s
|-
| zstd level 19  || tmpfs || 2s
|-
| zstd level 19  ||  ext4 on nvme || 4s
|-
|}


=== Comparison of compression algorithms and levels ===
Following table shows '''cpio''' and '''compressed cpio''' extraction
times into a tmpfs. Actual times in decompressing RPMs will differ due
to extracting on an actual disk and also some overhead in the RPM tool
(checks, scriptlets).

{| class="wikitable"
|-
! Compression   !! Level!! Size B   !! Size GiB
 !! Compression time !! Compression time, 4 threads  !!
Decompression time   !! Comment
|-
| CPIO  || -|| 5016785692   || 4,7
 || -|| -|| -
  ||
|-
| xz|| 2|| 1615017616   || 1,6
 || 9m55s|| -|| 1m36s
  || slow decompression
|-
| pxz   || 2|| 1631869880   || 1,6
 || -|| 6m11s|| 1m38s
  || slow decompression
|-
| gzip  || 9|| 2086354992   || 2,0
 || 10m23s   || -|| 31s
  || insufficient compression ratio
|-
| bzip2 || 9|| 1889161565   || 1,8
 || 8m   || -|| 2m50s
  || very slow decompression; compression ratio could be
better
|-
| zstd  || 3|| 1913536587   || 1,8
 || 31s  || 29s  || 6,5s
  ||
|-
| zstd  || 10   || 1737928978   || 1,7
 || 3m27s|| 2m34s|| 6,3s
  ||
|-
| zstd  || 15   || 1717303256   || 1,7
 || 9m37s|| 6m34s|| 6,3s
  || identical compression speed to xz; fast decompression;
slightly worse compression ratio than xz
|-
| zstd  || 17   || 1635525492   || 1,6
 || 16m16s   || 11m20s   || 6,7s
  ||
|-
| zstd  || 19   || 1575843696   || 1,5
 || 24m2s|| 18m55s   || 7,7s
  ||
|-
|}

== Benefit to Fedora ==
* Faster installations/upgrades of user systems
* Faster koji builds (installations in build roots)
* Faster container builds
* Lower bandwidth on mirrors if we choose the highest compression level

== Scope ==
* Proposal owners: submit a patch to redhat-rpm-config
* Other developers: redhat-rpm-config maintainer: include the patch
and make a new build
* Release engineering: [https://pagure.io/releng/issue/8345 #8345]
mass rebuild is needed

== Upgrade/compatibility impact ==
* RPM in Fedora supports zstd compression already (from Fedora 28,
rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
* Fedora <= 27 and some other distros will not be able to decompress
zstd-compressed RPMs.

== How To Test ==
* dnf install 
* rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n" 
* expected output: zstd 19

Also the overall system installation time should decrease significantly.

== User Experience ==
See '''Benefit to Fedora'''

== Dependencies ==
N/A

== Contingency Plan ==
* Contingency mechanism: Not needed, Fedora will stay at current compression.
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? N/A

== Documentation ==
N/A

== Release Notes ==
RPMs have switched to zstd compression level 19.
Users will benefit from faster package decompression.
Users that build their packages will experience slightly longer build times.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce 

Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression

= Switch RPMs to zstd compression =

== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.

== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dm...@redhat.com

== Detailed Description ==
* The change requires setting a new compression algorithm in rpm
macros. Then a mass rebuild of all packages is required.
* The macro for setting the compression is: %define _binary_payload w19.zstdio
* The recommended compression level is 19. The builds will take
longer, but the additional compression time is negligible in the total
build time and it pays off in better compression ratio than xz lvl2
has.
* SRPM payload compression should stay at gzip (there's almost no
benefit in changing the compression, because SRPM's contents is
compressed already)

=== Use case: Firefox installation ===
I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
Then I compared installation times with the original (xz compressed) package:

{| class="wikitable"
|-
! Compression !! Target File System !! Time
|-
| xz level 2  || tmpfs || 8s
|-
| xz level 2 || ext4 on nvme || 11s
|-
| zstd level 19  || tmpfs || 2s
|-
| zstd level 19  ||  ext4 on nvme || 4s
|-
|}


=== Comparison of compression algorithms and levels ===
Following table shows '''cpio''' and '''compressed cpio''' extraction
times into a tmpfs. Actual times in decompressing RPMs will differ due
to extracting on an actual disk and also some overhead in the RPM tool
(checks, scriptlets).

{| class="wikitable"
|-
! Compression   !! Level!! Size B   !! Size GiB
 !! Compression time !! Compression time, 4 threads  !!
Decompression time   !! Comment
|-
| CPIO  || -|| 5016785692   || 4,7
 || -|| -|| -
  ||
|-
| xz|| 2|| 1615017616   || 1,6
 || 9m55s|| -|| 1m36s
  || slow decompression
|-
| pxz   || 2|| 1631869880   || 1,6
 || -|| 6m11s|| 1m38s
  || slow decompression
|-
| gzip  || 9|| 2086354992   || 2,0
 || 10m23s   || -|| 31s
  || insufficient compression ratio
|-
| bzip2 || 9|| 1889161565   || 1,8
 || 8m   || -|| 2m50s
  || very slow decompression; compression ratio could be
better
|-
| zstd  || 3|| 1913536587   || 1,8
 || 31s  || 29s  || 6,5s
  ||
|-
| zstd  || 10   || 1737928978   || 1,7
 || 3m27s|| 2m34s|| 6,3s
  ||
|-
| zstd  || 15   || 1717303256   || 1,7
 || 9m37s|| 6m34s|| 6,3s
  || identical compression speed to xz; fast decompression;
slightly worse compression ratio than xz
|-
| zstd  || 17   || 1635525492   || 1,6
 || 16m16s   || 11m20s   || 6,7s
  ||
|-
| zstd  || 19   || 1575843696   || 1,5
 || 24m2s|| 18m55s   || 7,7s
  ||
|-
|}

== Benefit to Fedora ==
* Faster installations/upgrades of user systems
* Faster koji builds (installations in build roots)
* Faster container builds
* Lower bandwidth on mirrors if we choose the highest compression level

== Scope ==
* Proposal owners: submit a patch to redhat-rpm-config
* Other developers: redhat-rpm-config maintainer: include the patch
and make a new build
* Release engineering: [https://pagure.io/releng/issue/8345 #8345]
mass rebuild is needed

== Upgrade/compatibility impact ==
* RPM in Fedora supports zstd compression already (from Fedora 28,
rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
* Fedora <= 27 and some other distros will not be able to decompress
zstd-compressed RPMs.

== How To Test ==
* dnf install 
* rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n" 
* expected output: zstd 19

Also the overall system installation time should decrease significantly.

== User Experience ==
See '''Benefit to Fedora'''

== Dependencies ==
N/A

== Contingency Plan ==
* Contingency mechanism: Not needed, Fedora will stay at current compression.
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? N/A

== Documentation ==
N/A

== Release Notes ==
RPMs have switched to zstd compression level 19.
Users will benefit from faster package decompression.
Users that build their packages will experience slightly longer build times.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing 

Re: Writing C/C++ code to detect running desktop environment

[Stephen Gallagher]

On Wed, May 29, 2019 at 1:16 PM Kalev Lember  wrote:
>
> On Wed, May 29, 2019 at 7:11 PM Germano Massullo  
> wrote:
>>
>> I am working on implementing a piece of code that allows BOINC client
>> [1] to detect the desktop environment used by the user (mainly GNOME,
>> KDE Plasma, XFCE, LXDE/LXQT).
>> This feature will be needed for various reason that are off topic.
>>
>> One idea is to use GDBus to scan DBus to detect the running d.e.
>> What do you think about?
>> Thank you
>
>
> I would suggest reading the XDG_CURRENT_DESKTOP env variable. AFAIK all major 
> desktops support it and set it correctly for their sessions.
>

I realize you said that the reasons are off-topic, but in general I'd
recommend not making desktop-specific decisions at a high-level and
instead base your decisions off of availability of particular
functionality. For example, if your application needs to manage
software updates, have it check for whether PackageKit or dnf-daemon
are available. If it needs to store something in a password wallet,
check for GNOME Keyring or KWallet, etc.

Among other things, it means that alternative desktops that share some
tools with the popular ones don't have to get special code to work
with your project.
___
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: Wiki page correction: GRUB2

[Adam Williamson]

On Wed, 2019-05-29 at 13:50 +0200, Michal Schorm wrote:
> Hello,
> 
> I'd like to propose tiny correction for the Fedora wiki page about GRUB2 [1].
> 
> However I'm not confident enought to edit it prior to any discussions,
> so that's why I'm writing here.
> 
> In the chapter "Updating GRUB 2 configuration on UEFI systems"
> In the section "Install the bootloader files"
> I believe, there should be an information added, that the 'grub2-efi'
> package *must* match your architecture. So e.g. for x86_64, you want
> the 'grub2-efi-x64' package.
> 
> By default the 'dnf install grub2-efi' will find 'grub2-efi-ia32'
> package which doesn't contain the files you need for boot on x86_64
> system, nor pulls the correct package as a dependency.

That sounds correct, yes. For background, IIRC this split was done to
allow the special case of Baytrail-like systems (which have 64-bit CPUs
and on which you can install an x86_64 OS, but whose firmwares are 32-
bit and so require a 32-bit EFI bootloader) to work. I *think* on such
systems both grub2-efi-x64 and grub2-efi-ia32 is needed, but IMBW.

> Also, on once of my old F28 Cinnamon system, I can see, that there are 
> packages:
>   $ dnf list installed | grep grub2-efi | awk '{ print $1 }'
>   grub2-efi-ia32.x86_64
>   grub2-efi-ia32-cdboot.x86_64
>   grub2-efi-x64.x86_64
>   grub2-efi-x64-cdboot.x86_64
> 
> but I believe I only need the 'grub2-efi-x64.x86_64'.
> Given that, maybe the anaconda installation should be checked to not
> pull uneeded packages?

Current anaconda is designed to do this - it has a check to only
install grub2-efi-ia32 on systems with a 32-bit firmware. I'm not sure
if this wasn't in place when you installed, or if it went wrong
somehow...
-- 
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: Wiki page correction: GRUB2

[Michal Schorm]

> Be bold and just update the page... it's a wiki, so it keeps a change 
> history, and if someone else has a problem with what you wrote, they can 
> either update it or roll back the changes.  You shouldn't ever feel like you 
> have to ask permission or have the details 100% correct before updating 
> something on the wiki.

I'm not looking for a permission.
I'm looking for a sanity check.

I personaly take care of several wiki pages. If that would be a
subject I understand well and I'm confident in, I'd edit right away.
I also take it as a chance, that someone may spot it's not right and
uncover some packaging issue by it.

The fact It's a wiki IMHO doesn't imply anyone *should* edit it
without being confident about it.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, May 29, 2019 at 8:51 PM Jared K. Smith  wrote:
>
> On Wed, May 29, 2019 at 8:01 AM Michal Schorm  wrote:
>>
>> However I'm not confident enought to edit it prior to any discussions,
>> so that's why I'm writing here.
>
>
> Be bold and just update the page... it's a wiki, so it keeps a change 
> history, and if someone else has a problem with what you wrote, they can 
> either update it or roll back the changes.  You shouldn't ever feel like you 
> have to ask permission or have the details 100% correct before updating 
> something on the wiki.
>
> --
> Jared Smith
> ___
> 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: Destop environment and gl performance...

[Adam Jackson]

On Wed, 2019-05-29 at 19:45 +0200, Theodore Papadopoulo wrote:
>   Can someone explain why the destop environment (here Cinnamon) can have
> such an impact on the graphic card performance ?

Because (I suspect) you're not measuring glmark2 --off-screen, which
means the output that glmark generates has to also be presented to the
screen, which - for cinnamon, and gnome-shell, and kwin's gl mode -
means that display _also_ uses GL and so will be contending with glmark
for the GPU.

The offscreen glmark numbers ought to be nearly identical.

> Even better is there a way to investigate the GPU usage (a la ps or top)
> to understand such issues ?

GL profiling is something of a dark art with the open source tools. If
you have an intel gpu you could start with intel_gpu_top from the igt-
gpu-tools package.

- ajax
___
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: Wiki page correction: GRUB2

[Jared K. Smith]

On Wed, May 29, 2019 at 8:01 AM Michal Schorm  wrote:

> However I'm not confident enought to edit it prior to any discussions,
> so that's why I'm writing here.
>

Be bold and just update the page... it's a wiki, so it keeps a change
history, and if someone else has a problem with what you wrote, they can
either update it or roll back the changes.  You shouldn't ever feel like
you have to ask permission or have the details 100% correct before updating
something on the wiki.

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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Randy Barlow]

On Wed, 2019-05-29 at 20:29 +0200, Fabio Valentini wrote:
> I just noticed one other thing: fedora-easy-karma is now broken,
> because the REST API doesn't return the "anonymous" field on comments
> anymore, which the tool checks for.

See https://pagure.io/fesco/issue/2137


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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Fabio Valentini]

On Wed, May 29, 2019 at 7:27 PM Fabio Valentini  wrote:
>
> On Wed, May 29, 2019, 18:52 Randy Barlow  wrote:
>>
>> On Wed, 2019-05-29 at 17:51 +0200, Fabio Valentini wrote:
>> > If you're already working on fixing bugs - searching in the web
>> > interface also seems to be broken.
>> > Entries on an autocompleted result in the "package" section link to a
>> > (usually non-existent) user page.
>>
>> That's surprising, and sounds like this issue:
>>
>> https://github.com/fedora-infra/bodhi/issues/3040
>
>
> Yep, that's exactly what happened.
>
> However, after deleting the browser cache for the bodhi site and trying 
> again, it now works as expected. Thanks!
>
> I guess there was some stale JavaScript in the cache that didn't get reloaded.
>
> Fabio

I just noticed one other thing: fedora-easy-karma is now broken,
because the REST API doesn't return the "anonymous" field on comments
anymore, which the tool checks for.

Fabio

>>
>>
>> However, when I try this myself in Firefox on production it does seem
>> to work as I expect. For example, if I search "kernel" and then click
>> or use the keyboard to navigate and hit enter on "kernel", I am taken
>> to this URL:
>>
>> https://bodhi.fedoraproject.org/updates/?packages=kernel
>>
>> Can you describe in more detail what you are doing and seeing?
>> ___
>> 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

Destop environment and gl performance...

[Theodore Papadopoulo]

Can someone explain why the destop environment (here Cinnamon) can have
such an impact on the graphic card performance ?

Using glmark, we see a 2x to 20x factor in glmark performance between
various destops (mate,xlfce,cinnamon). What can justify such a huge gap
in perfs ?

Even better is there a way to investigate the GPU usage (a la ps or top)
to understand such issues ?

Thank's in advance..

Theo.


0x12BF16AD4F273D5D.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

[EPEL-devel] Proposed for Meeting 2019-05-29

[Stephen John Smoogen]

Sorry fro the dayle

REMINDER: There will be a EPEL Steering COmittee meeting today (2019-05-29)
at 18:00 UTC in #fedora-meeting. Please update the gobby-0.5 document at
infinote.fedoraproject.org with any agenda items
https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next


#startmeeting EPEL (2019-05-29)
#meetingname epel
#topic Chair and Introductions
#chair bstinson Evolution nirik smooge pgreco tdawson

#topic Agenda
#info EPEL Proposal: Removal of PPC64 (Not PPC64le) in 2019-06-01
#info EPEL Proposal: EPEL Master branch AKA Rawhide
#info CentOS-8

#topic EPEL PPC64
#info
https://www.scrye.com/wordpress/nirik/2019/05/23/attention-epel6-and-epel7-ppc64-users/

#topic EPEL Rawhide
#info
https://smoogespace.blogspot.com/2019/05/epel-proposal-epel-master-branch-aka.html

#topic CentOS 8
#info

#topic EPEL-8
#info met with people on plans
#info wrote rawhide proposal last night
#info sgallagh pushed libmodulemd-2.5.0 and I need to update grobisplitter
we can roll then
#info make branches in things tomorrow.
#info make koji work next week
#info make fedpkg work next week?
#info ???

#topic Open Floor

#endmeeting
-- 
Stephen J Smoogen.
___
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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Fabio Valentini]

On Wed, May 29, 2019, 18:52 Randy Barlow 
wrote:

> On Wed, 2019-05-29 at 17:51 +0200, Fabio Valentini wrote:
> > If you're already working on fixing bugs - searching in the web
> > interface also seems to be broken.
> > Entries on an autocompleted result in the "package" section link to a
> > (usually non-existent) user page.
>
> That's surprising, and sounds like this issue:
>
> https://github.com/fedora-infra/bodhi/issues/3040


Yep, that's exactly what happened.

However, after deleting the browser cache for the bodhi site and trying
again, it now works as expected. Thanks!

I guess there was some stale JavaScript in the cache that didn't get
reloaded.

Fabio


>
> However, when I try this myself in Firefox on production it does seem
> to work as I expect. For example, if I search "kernel" and then click
> or use the keyboard to navigate and hit enter on "kernel", I am taken
> to this URL:
>
> https://bodhi.fedoraproject.org/updates/?packages=kernel
>
> Can you describe in more detail what you are doing and seeing?
> ___
> 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: Writing C/C++ code to detect running desktop environment

[Kalev Lember]

On Wed, May 29, 2019 at 7:11 PM Germano Massullo 
wrote:

> I am working on implementing a piece of code that allows BOINC client
> [1] to detect the desktop environment used by the user (mainly GNOME,
> KDE Plasma, XFCE, LXDE/LXQT).
> This feature will be needed for various reason that are off topic.
>
> One idea is to use GDBus to scan DBus to detect the running d.e.
> What do you think about?
> Thank you
>

I would suggest reading the XDG_CURRENT_DESKTOP env variable. AFAIK all
major desktops support it and set it correctly for their sessions.

Kalev

>
> [1]: https://github.com/BOINC/boinc/tree/master/client
> ___
> 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

Writing C/C++ code to detect running desktop environment

[Germano Massullo]

I am working on implementing a piece of code that allows BOINC client
[1] to detect the desktop environment used by the user (mainly GNOME,
KDE Plasma, XFCE, LXDE/LXQT).
This feature will be needed for various reason that are off topic.

One idea is to use GDBus to scan DBus to detect the running d.e.
What do you think about?
Thank you

[1]: https://github.com/BOINC/boinc/tree/master/client
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi 4.0.0 deployed, one known issue so far

[Randy Barlow]

On Wed, 2019-05-29 at 17:51 +0200, Fabio Valentini wrote:
> If you're already working on fixing bugs - searching in the web
> interface also seems to be broken.
> Entries on an autocompleted result in the "package" section link to a
> (usually non-existent) user page.

That's surprising, and sounds like this issue:

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

However, when I try this myself in Firefox on production it does seem
to work as I expect. For example, if I search "kernel" and then click
or use the keyboard to navigate and hit enter on "kernel", I am taken
to this URL:

https://bodhi.fedoraproject.org/updates/?packages=kernel

Can you describe in more detail what you are doing and seeing?


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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Randy Barlow]

On Wed, 2019-05-29 at 11:58 -0400, Josh Boyer wrote:
> Could you make a container image based on F30 that can be run on
> F29/EPEL 7/8?  That offers users a way to use the new tool on the OS
> of their choice and avoids you having to write new code or bring back
> a bunch of dependencies to the Fedora release itself.

Yeah anyone could easily do this (just a FROM line [note: it's in
Rawhide, not F30] and a RUN dnf install line), but there are also
dependencies on bodhi-client in EPEL 7 and F29/30 so it wouldn't fully
address the issue. Any end user who wants to work around it could do
this though, and I have also provided a Copr[0] that has the new Bodhi
client that you can use too.

I also considered modularity, but there's currently a stay on adding
new packages to the default stream since RPMs can't currently depend on
modules (and things do depend on Bodhi).

Miro and I have proposed on the FESCo ticket to create a bodhi3-client
package and upgrade F29/30 to Bodhi 4.


[0] https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi


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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Josh Boyer]

On Wed, May 29, 2019 at 11:39 AM Randy Barlow
 wrote:
>
> On Tue, 2019-05-28 at 17:41 -0400, Dan Čermák wrote:
> > I just tried to submit an update via `fedpkg update` but got a
> > failure
> > via the cli:
> > $ fedpkg update
> > Could not execute update: Could not generate update request:
> > 'anonymous'
> > A copy of the filled in template is saved as bodhi.template.last
> >
> > Nevertheless the update got submitted and is available on Bodhi (it's
> > this one:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-16433c312e).
>
> Hi Dan!
>
> I presume you are using a Bodhi 2 or 3 client there? This is a known
> compatibility issue between the Bodhi 3 client and the Bodhi 4 server:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1714950
>
> There's a FESCo ticket where we are discussing what to do about it. I'm
> kind of undecided between putting Bodhi 4 into Fedora 29+ (and maybe
> even EPEL 7, which may be tricky due to dependencies) and making a
> Bodhi 3.15 that can talk to Bodhi 4 server (downside is that this will
> require more effort on my part, and I have a lot on my plate ☹). Feel
> free to voice your opinions on the FESCo ticket!

Could you make a container image based on F30 that can be run on
F29/EPEL 7/8?  That offers users a way to use the new tool on the OS
of their choice and avoids you having to write new code or bring back
a bunch of dependencies to the Fedora release itself.

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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Fabio Valentini]

On Wed, May 29, 2019 at 5:40 PM Randy Barlow
 wrote:
>
> On Tue, 2019-05-28 at 20:22 -0600, Orion Poplawski wrote:
> > Perhaps this is the source of:
> >
> > # /etc/cron.hourly/0yum-hourly.cron
> > Updateinfo file is not valid XML:  > '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d1
> > 53d7a3e27ff41946f476af5b4-updateinfo.xml.zck',
> > mode 'rt' at 0x7fa11cc331e0>
> >
> > https://pagure.io/releng/issue/8392
>
> I am working on a bodhi-4.0.1 release today to address this particular
> issue.

If you're already working on fixing bugs - searching in the web
interface also seems to be broken.
Entries on an autocompleted result in the "package" section link to a
(usually non-existent) user page.

Fabio

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

[EPEL-devel] Re: Updateinfo file is not valid XML - Zchunk support?

[Randy Barlow]

On Wed, 2019-05-29 at 14:36 +, Anderson, Charles R wrote:
> I'm getting this error as of last night on all of my CentOS 7 boxes:
> 
> /etc/cron.hourly/0yum-hourly.cron:
> 
> Updateinfo file is not valid XML:  '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d1
> 53d7a3e27ff41946f476af5b4-updateinfo.xml.zck', mode 'rt' at
> 0x7f2f134d6270>

Apologies for the trouble - we are working on fixing this and you can
follow along at https://pagure.io/releng/issue/8392.


signature.asc
Description: This is a digitally signed message part
___
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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Randy Barlow]

On Tue, 2019-05-28 at 20:22 -0600, Orion Poplawski wrote:
> Perhaps this is the source of:
> 
> # /etc/cron.hourly/0yum-hourly.cron
> Updateinfo file is not valid XML:  '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d1
> 53d7a3e27ff41946f476af5b4-updateinfo.xml.zck', 
> mode 'rt' at 0x7fa11cc331e0>
> 
> https://pagure.io/releng/issue/8392

I am working on a bodhi-4.0.1 release today to address this particular
issue.


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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Randy Barlow]

On Tue, 2019-05-28 at 17:41 -0400, Dan Čermák wrote:
> I just tried to submit an update via `fedpkg update` but got a
> failure
> via the cli:
> $ fedpkg update
> Could not execute update: Could not generate update request:
> 'anonymous'
> A copy of the filled in template is saved as bodhi.template.last
> 
> Nevertheless the update got submitted and is available on Bodhi (it's
> this one:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-16433c312e).

Hi Dan!

I presume you are using a Bodhi 2 or 3 client there? This is a known
compatibility issue between the Bodhi 3 client and the Bodhi 4 server:

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

There's a FESCo ticket where we are discussing what to do about it. I'm
kind of undecided between putting Bodhi 4 into Fedora 29+ (and maybe
even EPEL 7, which may be tricky due to dependencies) and making a
Bodhi 3.15 that can talk to Bodhi 4 server (downside is that this will
require more effort on my part, and I have a lot on my plate ☹). Feel
free to voice your opinions on the FESCo ticket!


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

Re: Wiki page correction: GRUB2

[Michal Schorm]

Also, it's IMHO worth mentioning, a package 'grub2-pc-modules' is
needed on BIOS systems in order to 'grub2-install' utility to work


--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, May 29, 2019 at 1:50 PM Michal Schorm  wrote:
>
> Hello,
>
> I'd like to propose tiny correction for the Fedora wiki page about GRUB2 [1].
>
> However I'm not confident enought to edit it prior to any discussions,
> so that's why I'm writing here.
>
> In the chapter "Updating GRUB 2 configuration on UEFI systems"
> In the section "Install the bootloader files"
> I believe, there should be an information added, that the 'grub2-efi'
> package *must* match your architecture. So e.g. for x86_64, you want
> the 'grub2-efi-x64' package.
>
> By default the 'dnf install grub2-efi' will find 'grub2-efi-ia32'
> package which doesn't contain the files you need for boot on x86_64
> system, nor pulls the correct package as a dependency.
>
> Also, on once of my old F28 Cinnamon system, I can see, that there are 
> packages:
>   $ dnf list installed | grep grub2-efi | awk '{ print $1 }'
>   grub2-efi-ia32.x86_64
>   grub2-efi-ia32-cdboot.x86_64
>   grub2-efi-x64.x86_64
>   grub2-efi-x64-cdboot.x86_64
>
> but I believe I only need the 'grub2-efi-x64.x86_64'.
> Given that, maybe the anaconda installation should be checked to not
> pull uneeded packages?
>
> Correct me, if I'm wrong, thanks.
>
>
>
> [1] https://fedoraproject.org/wiki/GRUB_2
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
___
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] Re: Updateinfo file is not valid XML - Zchunk support?

[Kevin Fenzi]

On 5/29/19 7:36 AM, Anderson, Charles R wrote:
> I'm getting this error as of last night on all of my CentOS 7 boxes:
> 
> /etc/cron.hourly/0yum-hourly.cron:
> 
> Updateinfo file is not valid XML:  '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck',
>  mode 'rt' at 0x7f2f134d6270>
> 
> Is this an infrastructure problem that can be addressed on the master mirror, 
> or is there some manual step I'm expected to perform on all my CentOS 7 boxes 
> due to the introduction of Zchunk?

It was a bug in a new version of bodhi that was deployed yesterday.

It's being fixed and the repos should already be fixed up, so no action
to take and sorry for the trouble.

kevin




signature.asc
Description: OpenPGP digital signature
___
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

Re: Bodhi 4.0.0 deployed, one known issue so far

[Petr Pisar]

On 2019-05-28, Dan Čermák  wrote:
> I just tried to submit an update via `fedpkg update` but got a failure
> via the cli:
> $ fedpkg update
> Could not execute update: Could not generate update request: 'anonymous'
> A copy of the filled in template is saved as bodhi.template.last
>
Similar to "bodhi update query" dying with "KeyError: 'anonymous'"
.

-- Petr
___
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] Updateinfo file is not valid XML - Zchunk support?

[Anderson, Charles R]

I'm getting this error as of last night on all of my CentOS 7 boxes:

/etc/cron.hourly/0yum-hourly.cron:

Updateinfo file is not valid XML: 

Is this an infrastructure problem that can be addressed on the master mirror, 
or is there some manual step I'm expected to perform on all my CentOS 7 boxes 
due to the introduction of Zchunk?

Thanks.
___
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

Fedora Atomic Host Two Week Release Announcement: 29.20190528.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 29.20190528.0
Commit(x86_64): cb50ac29d58f4e7e8dcfc3c2dd4156c6acd17038577437e4744edee7b7c02eda
Commit(aarch64): 
a07e18d150100f136bf4170107174cc7f5349a89106c458eaa2283613164b834
Commit(ppc64le): 
261ea0cc3cdb6437295d78b031974d794fff38e12728cc8bb0c94be2f5e1b34c


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190528.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190528.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190528.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190528.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190528.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190528.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190528.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190528.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190528.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190528.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190528.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190528.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190528.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190528.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190528.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190528.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190528.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename

Re: Google Chrome Flash doesn't seem to work in F30

[Brian (bex) Exelbierd]

On Wed, May 29, 2019 at 3:09 PM Alessio  wrote:
>
> On Wed, 2019-05-29 at 14:39 +0200, Brian (bex) Exelbierd wrote:
> > Hi,
> >
> > I've noticed that Flash doesn't seem to work in F30 in the upstream
> > Google Chrome.  It works in F29.  As a test, I installed an F29 and
>
> It seems to me that, even if the default option for Flash is "Always
> ask", when you go to a site where Flash is needed, no answer appears.
> So I need to click on the (i) or the padlock near the address bar,
> select "Site settings" and allow Flash explicitly.
> At this point it works.
>
> Someone can confirm?

This is my experience.  I believe this is actually a new feature as
part of the Flash deprication.

regards,

bex

>
> Ciao,
> A.
> ___
> 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



-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
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: Google Chrome Flash doesn't seem to work in F30

[Alessio]

On Wed, 2019-05-29 at 14:39 +0200, Brian (bex) Exelbierd wrote:
> Hi,
> 
> I've noticed that Flash doesn't seem to work in F30 in the upstream
> Google Chrome.  It works in F29.  As a test, I installed an F29 and

It seems to me that, even if the default option for Flash is "Always
ask", when you go to a site where Flash is needed, no answer appears.
So I need to click on the (i) or the padlock near the address bar,
select "Site settings" and allow Flash explicitly.
At this point it works.

Someone can confirm?

Ciao,
A.
___
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: Google Chrome Flash doesn't seem to work in F30

[Brian (bex) Exelbierd]

On Wed, May 29, 2019 at 2:55 PM Tomas Popela  wrote:
>
> Hi Brian,
>
> it's this bug - https://bugs.chromium.org/p/chromium/issues/detail?id=949312 
> . It will probably be fixed in Chrome 76+ (current stable is Chrome 74), so 
> that means it will take few months (unless someone from Chromium team 
> backports it).

Thank you!  I am glad I am not imagining this and that it is not
specific to my systems.

regards,

bex

>
> Tom
>
> On Wed, May 29, 2019 at 2:41 PM Brian (bex) Exelbierd  
> wrote:
>>
>> Hi,
>>
>> I've noticed that Flash doesn't seem to work in F30 in the upstream
>> Google Chrome.  It works in F29.  As a test, I installed an F29 and an
>> F30 Workstation VM.  I did nothing other than install Google Chrome
>> from the upstream site.  The app I need and a test site work in F29
>> but not in F30.
>>
>> I realize we don't package or distribute Google Chrome, but I was
>> wondering if anyone could provide some advice on where/how to
>> troubleshoot this?
>>
>> I have a flash application that I use as part of my work for the
>> Fedora Project so this is a challenge for me.
>>
>> thank you.
>>
>> regards,
>>
>> bex
>> --
>> Brian "bex" Exelbierd (he/him/his)
>> Fedora Community Action & Impact Coordinator
>> @bexelbie | http://www.winglemeyer.org
>> bexel...@redhat.com | b...@pobox.com
>> ___
>> 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



-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
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: Google Chrome Flash doesn't seem to work in F30

[Tomas Popela]

On Wed, May 29, 2019 at 2:53 PM Tomas Popela  wrote:

> it's this bug -
> https://bugs.chromium.org/p/chromium/issues/detail?id=949312 . It will
> probably be fixed in Chrome 76+ (current stable is Chrome 74), so that
> means it will take few months (unless someone from Chromium team backports
> it).
>

Yes, it's as I said - it's fixed in 76 -
https://storage.googleapis.com/chromium-find-releases-static/114.html#11429f6b3ab962e68bc792e2af51c9858b383a76.
I will mail some Chromium devs to consider backporting it.
___
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: Google Chrome Flash doesn't seem to work in F30

[Tomas Popela]

Hi Brian,

it's this bug - https://bugs.chromium.org/p/chromium/issues/detail?id=949312 .
It will probably be fixed in Chrome 76+ (current stable is Chrome 74), so
that means it will take few months (unless someone from Chromium team
backports it).

Tom

On Wed, May 29, 2019 at 2:41 PM Brian (bex) Exelbierd 
wrote:

> Hi,
>
> I've noticed that Flash doesn't seem to work in F30 in the upstream
> Google Chrome.  It works in F29.  As a test, I installed an F29 and an
> F30 Workstation VM.  I did nothing other than install Google Chrome
> from the upstream site.  The app I need and a test site work in F29
> but not in F30.
>
> I realize we don't package or distribute Google Chrome, but I was
> wondering if anyone could provide some advice on where/how to
> troubleshoot this?
>
> I have a flash application that I use as part of my work for the
> Fedora Project so this is a challenge for me.
>
> thank you.
>
> regards,
>
> bex
> --
> Brian "bex" Exelbierd (he/him/his)
> Fedora Community Action & Impact Coordinator
> @bexelbie | http://www.winglemeyer.org
> bexel...@redhat.com | b...@pobox.com
> ___
> 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

Google Chrome Flash doesn't seem to work in F30

[Brian (bex) Exelbierd]

Hi,

I've noticed that Flash doesn't seem to work in F30 in the upstream
Google Chrome.  It works in F29.  As a test, I installed an F29 and an
F30 Workstation VM.  I did nothing other than install Google Chrome
from the upstream site.  The app I need and a test site work in F29
but not in F30.

I realize we don't package or distribute Google Chrome, but I was
wondering if anyone could provide some advice on where/how to
troubleshoot this?

I have a flash application that I use as part of my work for the
Fedora Project so this is a challenge for me.

thank you.

regards,

bex
-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
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

[Bug 1715009] perl-Test-Strict-0.48 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Test-Strict-0.48-1.fc3
   ||1
 Resolution|--- |RAWHIDE
Last Closed||2019-05-29 12:10:46



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

Re: Python 3.8 failures to triage -- packages failing to build

[Miro Hrončok]

On 29. 05. 19 0:59, Randy Barlow wrote:

On Fri, 2019-05-03 at 15:56 +0200, Miro Hrončok wrote:

python-mongoengine   bowlofeggs echevemaster yograterol


I discovered that this was FTBFS even on 3.7 due to a missing BR[0]. I
fixed that just now, so please try again in Copr.


It works. Thanks.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Wiki page correction: GRUB2

[Michal Schorm]

Hello,

I'd like to propose tiny correction for the Fedora wiki page about GRUB2 [1].

However I'm not confident enought to edit it prior to any discussions,
so that's why I'm writing here.

In the chapter "Updating GRUB 2 configuration on UEFI systems"
In the section "Install the bootloader files"
I believe, there should be an information added, that the 'grub2-efi'
package *must* match your architecture. So e.g. for x86_64, you want
the 'grub2-efi-x64' package.

By default the 'dnf install grub2-efi' will find 'grub2-efi-ia32'
package which doesn't contain the files you need for boot on x86_64
system, nor pulls the correct package as a dependency.

Also, on once of my old F28 Cinnamon system, I can see, that there are packages:
  $ dnf list installed | grep grub2-efi | awk '{ print $1 }'
  grub2-efi-ia32.x86_64
  grub2-efi-ia32-cdboot.x86_64
  grub2-efi-x64.x86_64
  grub2-efi-x64-cdboot.x86_64

but I believe I only need the 'grub2-efi-x64.x86_64'.
Given that, maybe the anaconda installation should be checked to not
pull uneeded packages?

Correct me, if I'm wrong, thanks.



[1] https://fedoraproject.org/wiki/GRUB_2

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

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

[Bug 1715009] New: perl-Test-Strict-0.48 is available

[bugzilla]

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

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



Latest upstream release: 0.48
Current version/release in rawhide: 0.47-3.fc30
URL: http://search.cpan.org/dist/Test-Strict/

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

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

Science/research get together at Flock

[Ankur Sinha]

Hello everyone,

If you work in or are interested in science/research and are planning to
attend Flock, please comment on this ticket to let us know:

https://pagure.io/neuro-sig/NeuroFedora/issue/242

If there are enough of us, we'll try to put together a meetup or a
hackathon to discuss how we can better support science/research as
Fedora community members.

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
https://fedoraproject.org/wiki/User:Ankursinha

Time zone: Europe/London


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: Node.js 12.x Plans for F31+

[Vít Ondruch]

Dne 28. 05. 19 v 15:30 Stephen Gallagher napsal(a):
> On Mon, May 27, 2019 at 6:59 AM Vít Ondruch  wrote:
>>
>> Dne 24. 05. 19 v 21:00 Stephen Gallagher napsal(a):
>>> On Tue, Apr 23, 2019 at 5:40 PM Stephen Gallagher  
>>> wrote:
 Today, the Node.js upstream released 12.0.0, the next in its line of
 long-term support releases. I plan to make this the default version of
 Node.js in Fedora 31+, but not immediately. I'm currently working on
 getting a modular version of 12.x built for F29, F30 and Rawhide. I'll
 get that out to updates-testing this week. I'll send out an update
 once it's pushed to updates-testing.

 Once that's available, I encourage all NPM packagers in Fedora to
 start testing their build and runtime with the 12.x module. I will be
 filing a Change Proposal and plan to switch the system interpreter for
 Rawhide over to 12.x around the end of May or beginning of June.

 The exact timing may depend on the current status of the
 modules-in-the-non-modular-buildroot work in Fedora. If that's
 available by this time, I will retire the non-modular Node.js
 interpreter package and make the 12.x module the default stream for
 F31+. If it's not available, I'll continue to do what I've been doing
 in F29 and F30; building both the modular and non-modular packages.

 If you discover that you own NPM packages that are critical and do not
 work with Node.js 12.x, please inform me immediately. We'll talk with
 upstream and see what we can do about it.
>>> I plan to make this switch on Friday, May 31st, so if you have
>>> packages that may break, now would be a good time to let me know.
>>>
>>> Since the buildroot work isn't yet completely ready, I'm going to take
>>> the stop-gap approach and merge the '12' branch to master and do a
>>> non-modular build of Node.js 12.x in Rawhide on that day.
>>
>> I might be missing something, but you promised "I will be filing a
>> Change Proposal" in your original email above. Was it filled? Was it
>> approved?
> You are correct; I forgot to file the Change I promised. *sigh*
>
> Filing it now and I will move out the cut-over date to June 14th to
> give enough time for it to be approved.


Thx ️


Vít

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

[Bug 1712800] Upgrade perl-Promises to 1.00

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Promises-1.00-1.fc31
 Resolution|--- |RAWHIDE
   Assignee|dd...@cpan.org  |jples...@redhat.com
Last Closed||2019-05-29 06:33:27



-- 
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 1712800] Upgrade perl-Promises to 1.00

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1712800
Bug 1712800 depends on bug 1714511, which changed state.

Bug 1714511 Summary: Review Request: perl-Sub-Attribute - Reliable subroutine 
attribute handlers
https://bugzilla.redhat.com/show_bug.cgi?id=1714511

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE



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