Re: [heads-up] soname version bump for evolution-data-server in rawhide

[Milan Crha]

On Sat, 2020-07-04 at 15:27 -0700, Kevin Fenzi wrote:
> On Sat, Jul 04, 2020 at 09:48:04AM -0700, Kevin Fenzi wrote:
> > On Sat, Jul 04, 2020 at 06:37:09PM +0200, Fabio Valentini wrote:
> > > I don't understand the rush.

Hi,
there had been some major issues with the previous release, which I
didn't want to delay for another week.

> > 
> I looked a bit and it didn't seem easy to fix the test failure in
> folks...

Right, I saw that too and didn't understand why that single test fails.
When I built folks locally it passed with no problem, using the same
evolution-data-server. I'd surely rebuild the three I have commits
right for if the folks could work.

> so in the interest of not having rawhide broken all
> weekend/until we can sort that out I went and untagged that set of
> packages: 

Okay, thanks. I didn't expect causing such a problem. I'm sorry about
that.

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

Re: Packagers with no corresponding valid bugzilla accounts

[Mattia Verga via devel]

Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
>
> Good Morning Everyone,
>
> The list is slowly going down, we have now 38 accounts that are still
> problematic, they have all received several personal emails over the last few
> weeks and none but one reacted.
> I will likely start to ping FESCo about them starting next week.
> ...

 From a quick look to that list, there are some users that have no 
package assigned... I wonder if the unresponsive maintainer process 
implies the user to be removed from the packager group when their 
packages get orphaned and the user has no more any package associated to 
their account.

Here it is the list of packagers without any associated packages:
alen
gnikandrov
itsbill
jefferson2z
kir
pgibson
squallbayu
sturivnyi
yuwata


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

Re: Packagers with no corresponding valid bugzilla accounts

[Pierre-Yves Chibon]

On Tue, Jul 07, 2020 at 08:17:00AM +, Mattia Verga wrote:
> Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
> >
> > Good Morning Everyone,
> >
> > The list is slowly going down, we have now 38 accounts that are still
> > problematic, they have all received several personal emails over the last 
> > few
> > weeks and none but one reacted.
> > I will likely start to ping FESCo about them starting next week.
> > ...
> 
>  From a quick look to that list, there are some users that have no 
> package assigned... I wonder if the unresponsive maintainer process 
> implies the user to be removed from the packager group when their 
> packages get orphaned and the user has no more any package associated to 
> their account.

The source of info is: https://src.fedoraproject.org/extras/pagure_bz.json
which includes people that are packagers as well as people who are watching the
packages (ie who asked to be included in the CC list on bugzilla).

> Here it is the list of packagers without any associated packages:
> alen

Watching firefox:
http://src.fedoraproject.org/api/0/rpms/firefox/watchers

> gnikandrov

Watching setup:
https://src.fedoraproject.org/api/0/rpms/setup/watchers

> itsbill

Watching ratpoison:
https://src.fedoraproject.org/api/0/rpms/ratpoison/watchers

> jefferson2z

Watching godot:
https://src.fedoraproject.org/api/0/rpms/godot/watchers

> kir

Watching criu:
https://src.fedoraproject.org/api/0/rpms/criu/watchers

> pgibson

Watching pam:
https://src.fedoraproject.org/api/0/rpms/pam/watchers

> squallbayu

Watching gnome-control-center:
https://src.fedoraproject.org/api/0/rpms/gnome-control-center/watchers
and gnome-desktop3
https://src.fedoraproject.org/api/0/rpms/gnome-desktop3/watchers

> sturivnyi

Watching cpio:
https://src.fedoraproject.org/api/0/rpms/cpio/watchers

> yuwata

Watching dracut, eigen3 and systemd
https://src.fedoraproject.org/api/0/rpms/dracut/watchers
https://src.fedoraproject.org/api/0/rpms/eigen3/watchers
https://src.fedoraproject.org/api/0/rpms/systemd/watchers
 
 
Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [heads-up] soname version bump for evolution-data-server in rawhide

[Milan Crha]

On Tue, 2020-07-07 at 09:05 +0200, Milan Crha wrote:
> Right, I saw that too and didn't understand why that single test
> fails. When I built folks locally it passed with no problem, using
> the same evolution-data-server. I'd surely rebuild the three I have
> commits right for if the folks could work.

Hi,
I currently use the f33-build-side-25060 sidetag.

I managed to find the cause of the test failure in folks [1], I'll
backport the change into the sidetag for the time being and I'll build
what I can there as well.

Fabio, could you move/build your packages into that sidetag too,
please? The updated folks might be in the sidetag within an hour or so,
depending on koji speed.
Thanks and bye,
Milan

[1] https://gitlab.gnome.org/GNOME/folks/-/merge_requests/40
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[David Sterba]

> Yes, BtrFs was very unstable, but before. Every software has this process.  I
> have talked to one of the maintainer of BtrFs, she thinks that BtrFs is ready
> to production usage. (few years before, she is strongly against using BtrFs
> for production purpose).

May I ask who was the person you talked to? I'm asking as the active maintainer
of btrfs. I'm familiar who does what in the community and overall status so it
would be of my community interest to know who is speaking on behalf of the
project, without me having even a slightest idea who that could be.

If you don't want to disclose the name in public, feel free to respond in
private.

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

Re: The future of legacy BIOS support in Fedora.

[Gerd Hoffmann]

On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
> On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and
> > LVM.  If you ask for full disk encryption LVM is encrypted, ESP + boot
> > are not.  Which makes sense to me.  Why would you encrypt /boot?  The
> > files you can find there are public anyway, you can download them from
> > the fedora servers.  Encrypting /boot would make the boot process more
> > fragile for no benefit.
> 
> I guess that shows how unfamiliar I am with UEFI boot Fedora. You would 
> encrypt /boot to ensure that your boot images have not been tampered with,

Well, if that is your concern the answer is secure boot.  That will not
only prevent tampering with /boot files, but also prevent tampering with
the bootloader itself.

> or  config files haven't been read by somebody other than the end
> user.

Hmm, typically that is pretty standard stuff and very simliar on all
fedora installs.  Only the root filesystem uuid differs, and possibly
local tweaks like configuring a serial console.  I can't see how reading
that is of much concern.

> > We could that by using vfat for /boot.  Or by shipping & using xfs.efi,
> > simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> > filesystems.
> 
> Is there a notable benefit to using that over GRUB2, which already has
> support on both UEFI and BIOS?

Well, for my day-to-day work it doesn't make much of a difference.  Both
get the job done.

I generally dislike the grub2 config file format.  I'm not going to
repeat all the arguments here which have been mentioned numerous times
already.  With BLS support things became a bit better because for the
most part I can just ignore grub.cfg after install.

I suspect the grub2 maintainers have a different view on this.  They
have to deal with the mess to make sure I don't have to.  And on top
of that getting changes merged upstream to grub2 seems to be a PITA,
leading to a huge stack of patches in the fedora grub2 rpm ...

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Qiyu Yan]

David Sterba  于2020年7月7日周二 下午6:09写道：
>
> > Yes, BtrFs was very unstable, but before. Every software has this process.  
> > I
> > have talked to one of the maintainer of BtrFs, she thinks that BtrFs is 
> > ready
> > to production usage. (few years before, she is strongly against using BtrFs
> > for production purpose).
>
> May I ask who was the person you talked to? I'm asking as the active 
> maintainer
> of btrfs. I'm familiar who does what in the community and overall status so it
> would be of my community interest to know who is speaking on behalf of the
> project, without me having even a slightest idea who that could be.
I may have take it wrongly, she is an developer at SUSE but not a maintainer.
Sorry for my mistake and that is only a personal opinion.

And that is a private talk.
>
> If you don't want to disclose the name in public, feel free to respond in
> private.
>
> Thanks.
[1] https://twitter.com/mawei_spoiler/status/1275692573999407108
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [heads-up] soname version bump for evolution-data-server in rawhide

[Fabio Valentini]

On Tue, Jul 7, 2020 at 11:52 AM Milan Crha  wrote:
>
> On Tue, 2020-07-07 at 09:05 +0200, Milan Crha wrote:
> > Right, I saw that too and didn't understand why that single test
> > fails. When I built folks locally it passed with no problem, using
> > the same evolution-data-server. I'd surely rebuild the three I have
> > commits right for if the folks could work.
>
> Hi,
> I currently use the f33-build-side-25060 sidetag.
>
> I managed to find the cause of the test failure in folks [1], I'll
> backport the change into the sidetag for the time being and I'll build
> what I can there as well.
>
> Fabio, could you move/build your packages into that sidetag too,
> please? The updated folks might be in the sidetag within an hour or so,
> depending on koji speed.
> Thanks and bye,
> Milan
>
> [1] https://gitlab.gnome.org/GNOME/folks/-/merge_requests/40

- wingpanel-indicator-datetime: has already been rebuilt for eds
3.37.3 and was already pushed to rawhide repos + mirrors (the current
broken dependencies should be resolved once eds 3.37.3 hits stable
again)
- elementary-calendar: submitted rebuild against eds 3.37.3 and the
fixed folks to f33-build-side-25060

If you need help with building other packages, feel free to ping me.

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

Re: [heads-up] soname version bump for evolution-data-server in rawhide

[Milan Crha]

On Tue, 2020-07-07 at 13:12 +0200, Fabio Valentini wrote:
> If you need help with building other packages, feel free to ping me.

Hi,
thanks. I'm currently working on a patch for syncevolution and I
started a build of ekiga few minutes ago.

According to:
  $ repoquery --whatrequires libedataserver-1.2.so* --alldeps
there lefts elementary-planner, evolution-chime and gnome-panel, to
which I do not have commit rights. I can wait until Friday and tag the
things to rawhide later, thus the maintainers have more time to even
notice the change.

I'm sorry I caused this mess.

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Wednesday's FESCo Meeting (2020-07-08)

[Miro Hrončok]

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

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

or run:
  date -d '2020-07-08 14:00 UTC'


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

= Discussed and Voted in the Ticket =

F33 System-Wide Change: LLVM 11
https://pagure.io/fesco/issue/2419
APPROVED (+8, 0, -0)

F33 System-Wide Change: Zanata removal
https://pagure.io/fesco/issue/2421
APPROVED (+7, 0, -0)

Fedora 34 System-Wide Change: Binutils 2.35
https://pagure.io/fesco/issue/2423
APPROVED (+8, 0, -0)

Fedora 33 System-Wide Change: The GNU C Library version 2.32
https://pagure.io/fesco/issue/2424
APPROVED (+8, 0, -0)

F33 Self-Contained Change: Automatic RPM dependencies on Python Extras
https://pagure.io/fesco/issue/2425
APPROVED (+8, 0, -0)

F33 System-Wide Change: Make nano the default editor
https://pagure.io/fesco/issue/2426
APPROVED (+8, 0, -0)

F33 Self-Contained Change: Deprecate python-pytoml
https://pagure.io/fesco/issue/2427
APPROVED (+7, 0, -0)

F33 Self-Contained Change: GHC 8.8 and Haskell Stackage LTS 16
https://pagure.io/fesco/issue/2428
APPROVED (+7, 0, -0)

= New business =

#topic #2420 F33 System-Wide Change: Use %make_build and %make_install macros
.fesco 2420
https://pagure.io/fesco/issue/2420

= Open Floor =

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Problem with auto CMake out-of-source builds?

[Richard Shaw]

On Sun, Jul 5, 2020 at 8:20 AM Neal Gompa  wrote:

> On Sun, Jul 5, 2020 at 9:16 AM Richard Shaw  wrote:
> >
> > I saw the change notification but didn't know it went in to
> "production". I was trying to build OpenImageIO in rawhide and it failed,
> because I was already doing an out of source build which it appended
> "%{_arch}-redhat-linux-gnu" or something like that to.
> >
> > So I looked up the guidelines for CMake which state:
> >
> > %build
> > %cmake .
> > %make_build
> >
> >
> > Oookay... Now OIIO CMake config is giving me:
> >
> > CMake Error at CMakeLists.txt:50 (message):
> >   Not allowed to run in-source build!
> >
> > And low and behold I see new options being passed to CMake...
> >
> > + /usr/bin/cmake -S . -B .
> >
> > Which point the source and binary locations to the same directory.
> >
> > So I was all for the change other than the fact I was already doing
> out-of-source builds for all of the CMake packages I maintain, which this
> breaks, and right now the "automagic" seems to be broken as well.
> >
>
> Temporarily, we have %__cmake_in_source_build set, which forces back
> the legacy behavior. You can switch to the upcoming out of source
> default by adding the following to the top of your spec:
>
> # Force out of source build
> %undefine __cmake_in_source_build
>
> With that, you can use %cmake with no arguments and everything should work
> fine.


Well, both ways seem to be broken now. If I use the out-of-source build,
cmake works fine but apparently %make_build doesn't auto-change to the
generated directory. Am I expected to know the direcotory pattern and
handle it myself? If so this seems like a major step backwards.

If I allow in source builds it adds the "-S . -B ." and even though I make
my own directory and point back to it "%cmake ... ../" it still fails the
projects in source build check:

 + /usr/bin/cmake -S . -B . -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
-DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
-DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
-DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_SKIP_RPATH:BOOL=TRUE
-DPYTHON_VERSION=3.9 -DBUILD_DOCS:BOOL=TRUE -DINSTALL_DOCS:BOOL=FALSE
-DINSTALL_FONTS:BOOL=FALSE -DUSE_EXTERNAL_PUGIXML:BOOL=TRUE
-DSTOP_ON_WARNING:BOOL=FALSE -DJPEG_INCLUDE_DIR=/usr/include
-DOPENJPEG_INCLUDE_DIR=/usr/include/openjpeg-2.3
-DOpenGL_GL_PREFERENCE=GLVND -DVERBOSE=TRUE ../
-- The CXX compiler identification is GNU 10.1.1
-- The C compiler identification is GNU 10.1.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Building OpenImageIO 2.1.17.0
-- CMake version is 3.18.0-rc3
-- Configuring OpenImageIO 2.1.17.0
-- CMake 3.18.0-rc3
-- CMake system   = Linux-5.6.19-300.fc32.x86_64
-- CMake system name  = Linux
-- Project source dir = /builddir/build/BUILD/oiio-Release-2.1.17.0
-- Project build dir  = /builddir/build/BUILD/oiio-Release-2.1.17.0
-- Project install prefix = /usr
-- Configuration types=
-- Build type = RelWithDebInfo
CMake Error at CMakeLists.txt:50 (message):
  Not allowed to run in-source build!

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

Re: Problem with auto CMake out-of-source builds?

[Neal Gompa]

On Tue, Jul 7, 2020 at 8:14 AM Richard Shaw  wrote:
>
> On Sun, Jul 5, 2020 at 8:20 AM Neal Gompa  wrote:
>>
>> On Sun, Jul 5, 2020 at 9:16 AM Richard Shaw  wrote:
>> >
>> > I saw the change notification but didn't know it went in to "production". 
>> > I was trying to build OpenImageIO in rawhide and it failed, because I was 
>> > already doing an out of source build which it appended 
>> > "%{_arch}-redhat-linux-gnu" or something like that to.
>> >
>> > So I looked up the guidelines for CMake which state:
>> >
>> > %build
>> > %cmake .
>> > %make_build
>> >
>> >
>> > Oookay... Now OIIO CMake config is giving me:
>> >
>> > CMake Error at CMakeLists.txt:50 (message):
>> >   Not allowed to run in-source build!
>> >
>> > And low and behold I see new options being passed to CMake...
>> >
>> > + /usr/bin/cmake -S . -B .
>> >
>> > Which point the source and binary locations to the same directory.
>> >
>> > So I was all for the change other than the fact I was already doing 
>> > out-of-source builds for all of the CMake packages I maintain, which this 
>> > breaks, and right now the "automagic" seems to be broken as well.
>> >
>>
>> Temporarily, we have %__cmake_in_source_build set, which forces back
>> the legacy behavior. You can switch to the upcoming out of source
>> default by adding the following to the top of your spec:
>>
>> # Force out of source build
>> %undefine __cmake_in_source_build
>>
>> With that, you can use %cmake with no arguments and everything should work 
>> fine.
>
>
> Well, both ways seem to be broken now. If I use the out-of-source build, 
> cmake works fine but apparently %make_build doesn't auto-change to the 
> generated directory. Am I expected to know the direcotory pattern and handle 
> it myself? If so this seems like a major step backwards.
>

%cmake_build and %cmake_install are recommended here, as those will do
the right thing.

If you want to use %make_build and %make_install, you'll need to add
"-C %{_vpath_builddir}"



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Kevin Kofler]

Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/UseNanoByDefault
> 
> == Summary ==
> 
> Let's make Fedora more approachable, by having a default editor that
> doesn't require specialist knowledge to use.
> 
> == Owner ==
> * Name: [[User:chrismurphy| Chris Murphy]]
> * Email:  chrismur...@fedoraproject.org

+1, it makes a lot of sense to default to a usable editor.

The only vi command I know is :q! that gets me the heck out of there.

Does this mean we can stop having things depend on vim-minimal?

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Peter Robinson]

On Tue, Jul 7, 2020 at 11:17 AM Gerd Hoffmann  wrote:
>
> On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
> > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and
> > > LVM.  If you ask for full disk encryption LVM is encrypted, ESP + boot
> > > are not.  Which makes sense to me.  Why would you encrypt /boot?  The
> > > files you can find there are public anyway, you can download them from
> > > the fedora servers.  Encrypting /boot would make the boot process more
> > > fragile for no benefit.
> >
> > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would
> > encrypt /boot to ensure that your boot images have not been tampered with,
>
> Well, if that is your concern the answer is secure boot.  That will not
> only prevent tampering with /boot files, but also prevent tampering with
> the bootloader itself.

It's part of the solution, how exactly does secure-boot it deal with
the initrd when isn't signed because it's generate on install, or
changes to config files such as grub.cfg? It doesn't, you need
technologies such as a TPM2 to measure and attest, and things like IMA
to enforce policies.

> > or  config files haven't been read by somebody other than the end
> > user.
>
> Hmm, typically that is pretty standard stuff and very simliar on all
> fedora installs.  Only the root filesystem uuid differs, and possibly
> local tweaks like configuring a serial console.  I can't see how reading
> that is of much concern.

There's lots of cases where that is a concern, if you can't trust one
part of your boot chain can you trust any of it?

> > > We could that by using vfat for /boot.  Or by shipping & using xfs.efi,
> > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> > > filesystems.
> >
> > Is there a notable benefit to using that over GRUB2, which already has
> > support on both UEFI and BIOS?
>
> Well, for my day-to-day work it doesn't make much of a difference.  Both
> get the job done.
>
> I generally dislike the grub2 config file format.  I'm not going to
> repeat all the arguments here which have been mentioned numerous times
> already.  With BLS support things became a bit better because for the
> most part I can just ignore grub.cfg after install.
>
> I suspect the grub2 maintainers have a different view on this.  They
> have to deal with the mess to make sure I don't have to.  And on top
> of that getting changes merged upstream to grub2 seems to be a PITA,
> leading to a huge stack of patches in the fedora grub2 rpm ...

Well the whole upstream situation has started improving recently and
the number of patches is coming down and being unified. The whole
stack of patches was fairly standard across distros.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: yuv2png and vpxenc (webm) in fedora ?

[Kevin Kofler]

J. Scheurich wrote:
> Would it be ok, to create a png2vuy and vpxenc package in fedora ?

They are both already packaged:
* png2yuv is part of the mjpegtools package in RPM Fusion,
* vpxenc is part of the libvpx-utils package in Fedora.

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 07/07/20 14:24 +0200, Kevin Kofler wrote:

Ben Cotton wrote:

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

== Summary ==

Let's make Fedora more approachable, by having a default editor that
doesn't require specialist knowledge to use.

== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email:  chrismur...@fedoraproject.org


+1, it makes a lot of sense to default to a usable editor.

The only vi command I know is :q! that gets me the heck out of there.

Does this mean we can stop having things depend on vim-minimal?


I don't think so. POSIX requires some commands to use vi when EDITOR
is not set, so unless you modify bash (and other shells) to prevent
EDITOR being unset, you need vi for a functioning POSIX system.

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

List of long term FTBFS packages to be retired in August

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 33 approximately one week before branching (August 
2020).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


Note that some listed packages are orphaned and hence may be retired even 
sooner.

The packages in rawhide were not successfully built at least since Fedora 31.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.


  Package (co)maintainers  Latest build

OpenCoarrays   jussilehtolaFedora 30
js-jquery-jqplot   xavierb Fedora 30
js-jquery1 nodejs-sig, patches, vondruch   Fedora 30
js-jquery2 vondruchFedora 30
js-sizzle  nodejs-sig, patches, vondruch   Fedora 30
nodejs-path-type   nodejs-sig, orphan  Fedora 30
nodejs-temp-write  orphan  Fedora 30
nodejs-unique-stream   jsmith, nodejs-sig  Fedora 30
orpie  bowlofeggs, orphan  Fedora 30
rubygem-ruby-hmac  humaton, mmorsi Fedora 30
xvarstar   orphan  Fedora 30

The following packages require above mentioned packages:
Depending on: js-jquery-jqplot (1)
sympa (maintained by: xavierb)
sympa-6.2.56-1.fc33.src requires js-jquery-jqplot = 1.0.9-3.fc30
sympa-6.2.56-1.fc33.x86_64 requires js-jquery-jqplot = 
1.0.9-3.fc30

Depending on: js-jquery1 (70)
R-profvis (maintained by: qulogic)
R-profvis-0.3.6-3.fc33.src requires js-jquery1 = 1.12.4-7.fc30
R-profvis-0.3.6-3.fc33.x86_64 requires js-jquery1 = 
1.12.4-7.fc30

R-rmarkdown (maintained by: qulogic)
R-rmarkdown-2.2-1.fc33.noarch requires js-jquery1 = 
1.12.4-7.fc30
R-rmarkdown-2.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30

copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, 
msuchy, praiskup)
copr-frontend-1.166-1.fc33.noarch requires js-jquery1 = 
1.12.4-7.fc30

ghc-pretty-show (maintained by: mathstuf)
ghc-pretty-show-1.9.5-3.fc32.x86_64 requires js-jquery1 = 
1.12.4-7.fc30

mkdocs (maintained by: cheeselee)
mkdocs-1.1.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
mkdocs-1.1.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30

python-XStatic-jQuery (maintained by: mrunge, openstack-sig, rdopiera)
python3-XStatic-jQuery-3.4.1.0-2.fc33.noarch requires 
js-jquery1 = 1.12.4-7.fc30

python-sphinx-bootstrap-theme (maintained by: besser82, sic)
		python3-sphinx-bootstrap-theme-0.8.0-3.fc33.noarch requires js-jquery1 = 
1.12.4-7.fc30


rubygem-apipie-rails (maintained by: jaruga, ruby-packagers-sig, 
vondruch)
rubygem-apipie-rails-0.5.5-6.fc32.noarch requires js-jquery1 = 
1.12.4-7.fc30

R-BiocFileCache (maintained by: spot)
R-BiocFileCache-1.12.0-2.fc33.src requires R-rmarkdown = 
2.2-1.fc33

R-DBItest (maintained by: qulogic)
R-DBItest-1.7.0-1.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-V8 (maintained by: qulogic)
R-V8-3.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-broom (maintained by: qulogic)
R-broom-0.5.6-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-cellranger (maintained by: qulogic)
R-cellranger-1.1.0-6.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-clipr (maintained by: qulogic)
R-clipr-0.7.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-dbplyr (maintained by: qulogic)
R-dbplyr-1.4.3-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-devtools (maintained by: qulogic)
R-devtools-2.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-diffobj (maintained by: qulogic)
R-diffobj-0.3.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-dplyr (maintained by: qulogic)
R-dplyr-0.8.5-2.fc33~bootstrap.src requires R-rmarkdown = 
2.2-1.fc33

R-dtplyr (maintained by: qulogic)
R-dtplyr-1.0.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-foghorn (maintained by: qulogic)
R-foghorn-1.1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33

R-forcats (maintained by: qulogic)

Re: Problem with auto CMake out-of-source builds?

[Vitaly Zaitsev via devel]

On 05.07.2020 15:19, Neal Gompa wrote:
> Temporarily, we have %__cmake_in_source_build set, which forces back
> the legacy behavior.

Proven-packages are changing SPEC files already using out of tree builds
(with push..popd) and then disabling it globally.

This is so weird.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular and personal koji

[Didier FABERT]

Thank you Stephen, I will try asap.

Le 06/07/2020 à 17:16, Stephen John Smoogen a écrit :
> On Mon, 6 Jul 2020 at 10:33, Didier Fabert  wrote:
>> Hi all,
>>
>> With my personal koji (on el8), I cannot build some packages for my el8
>> tag. All failures are about modular metadata packages which cannot be
>> installed.
>>
> Koji doesn't really understand modules and the depsolver has problems.
> For setting up EPEL we needed to do 2 things to make this work.
>
> 1. At first we needed to use grobisplitter to flatten the repos a bit
> so that koji could understand them:
> https://github.com/fedora-modularity/GrobiSplitter
> 2. We then followed
> https://smoogespace.blogspot.com/2019/07/epel-8-production-layout.html
> 3. In koji itself we needed to tell the depsolver to use dnf versus
> its own solver.
> 4. We also had to have koji to turn on the hotpatch flag so dnf would
> pull in items.
>
>
>> DEBUG util.py:621:  No available modular metadata for modular package
>> 'httpd-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be
>> installed on the system
>> DEBUG util.py:621:  No available modular metadata for modular package
>> 'httpd-devel-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be
>> installed on the system
>> DEBUG util.py:621:  No available modular metadata for modular package
>> 'httpd-filesystem-2.4.37-21.module_el8.2.0+382+15b0afa8.noarch', it
>> cannot be installed on the system
>> DEBUG util.py:621:  No available modular metadata for modular package
>> 'httpd-tools-2.4.37-21.module_el8.2.0+382+15b0afa8.x86_64', it cannot be
>> installed on the system
>> DEBUG util.py:621:  No available modular metadata for modular package
>> 'mod_http2-1.11.3-3.module_el8.2.0+307+4d18d695.x86_64', it cannot be
>> installed on the system
>> DEBUG util.py:621:  No available modular metadata for modular package
>> 'mysql-common-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be
>> installed on the system
>> DEBUG util.py:621:  No available modular metadata for modular package
>> 'mysql-devel-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be
>> installed on the system
>> DEBUG util.py:621:  No available modular metadata for modular package
>> 'mysql-libs-8.0.17-3.module_el8.0.0+181+899d6349.x86_64', it cannot be
>> installed on the system
>>
>> Any idea to solve this problem ? I miss somthing ?
>>
>> I setup my el8 tag like this
>>
>> koji add-tag centos-8
>> koji add-tag --parent "centos-8" --arches 'x86_64' centos-8-build
>> koji add-group centos-8-build build
>> koji add-group centos-8-build srpm-build
>>
>> koji add-external-repo -t centos-8-build -p 10 centos-8-external-baseos
>> http://mirrors.ircam.fr/pub/CentOS/8/BaseOS/\$arch/os
>> koji add-external-repo -t centos-8-build -p 15 centos-8-external-epel
>> http://mirrors.ircam.fr/pub/fedora/epel/8/Everything/\$arch
>> koji add-external-repo -t centos-8-build -p 11
>> centos-8-external-appstream
>> http://mirrors.ircam.fr/pub/CentOS/8/AppStream/\$arch/os
>> koji add-external-repo -t centos-8-build -p 12
>> centos-8-external-powertools
>> http://mirrors.ircam.fr/pub/CentOS/8/PowerTools/\$arch/os
>> koji add-external-repo -t centos-8-build -p 13 centos-8-external-extras
>> http://mirrors.ircam.fr/pub/CentOS/8/extras/\$arch/os
>>
>> koji add-target centos-8 centos-8-build
>>
>> koji add-group-pkg centos-8-build build bash bash bzip2 coreutils cpio
>> diffutils findutils gawk gcc grep sed gcc-c++ gzip info patch
>> redhat-rpm-config rpm-build shadow-utils tar unzip util-linux which make
>> centos-release xz
>> koji add-group-pkg centos-8-build srpm-build bash redhat-release
>> centos-release make redhat-rpm-config rpm-build shadow-utils wget
>> rpmdevtools
>>
>> Thanks,
>>
>> Didier (tartare)
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
-- 
Didier FABERT
didier.fab...@gmail.com
TZ Europe/Paris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

LWN for Fedora contributors [was Re: LWN: btrfs @ Facebook ...]

[Matthew Miller]

On Fri, Jul 03, 2020 at 09:05:25AM +0200, Tomasz Torcz wrote:
>   During 2020 Open Source Summit North America, Josef shared some
> details about how btrfs excels in production at Facebook.  And where
> the problems were.
>   I cannot find the recording, but the write up is at Linux Weekly News:
>   https://lwn.net/SubscriberLink/824855/e601d11e157e1b4a/
>   I highly recomend it.  Also, consider subscribing to LWN – it's an
> invaluable source of high quality writing.

If you have funds to do so, absolutely. But if you are a Fedora contributor
and do not, Red Hat sponsors a group membership which I manage and can add
you to. Message me off-list if you're interested. (Currently, there are 15
unused subscription slots.)

-- 
Matthew Miller

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

Re: The future of legacy BIOS support in Fedora.

[Lennart Poettering]

On Mo, 06.07.20 16:34, Neal Gompa (ngomp...@gmail.com) wrote:

> Encryption != integrity/authentication. The only thing encryption
> guarantees is that the data is not visible, not that it hasn't been
> tampered with. Usually, dm-verity or dm-integrity is used for what
> you're asking for. Android uses dm-verity, if I remember correctly.

EFI SecureBoot uses PE signed executables.

> Less complexity in the boot chain, mainly. But the EFI drivers would
> need to be signed by MS, I think? That would massively complicate
> things.

Could use SHIM like everything else.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Matthew Miller]

On Wed, Jul 01, 2020 at 03:50:37PM -0400, Josef Bacik wrote:
> I've stated this many times before, btrfs is more vulnerable to
> things going wrong.  It's also more likely to notice things going
> wrong.  There's things we can do to make it easier in the face of
> these issues, they're patches I've written and submitted in the last
> few days.  There's bigger, more complex things that I can do to make
> us more resilient in the face of these corruptions.  But even with
> all of the things I have in my head, I could still go do one or two
> things and render the file system unusable.  Would these things
> happen in practice?  Unlikely.  Is it impossible?  Unfortunately no.

Thanks Josef. I definitely appreciate your responsiveness here, and your
explanation helps me understand things better.


-- 
Matthew Miller

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

Re: Problem with auto CMake out-of-source builds?

[Kevin Kofler]

Vitaly Zaitsev via devel wrote:
> Proven-packages are changing SPEC files already using out of tree builds
> (with push..popd) and then disabling it globally.
> 
> This is so weird.

Yes, I think that this is a completely pointless backwards-incompatible 
change that just hides more error-prone automagic in macros instead of 
sticking to the Fedora traditions of keeping the macros as simple as 
possible. And the fact that it breaks the very packages that have been 
already doing for years exactly what the feature is about makes it 
particularly counterproductive.

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning og my nodejs packages

[Tom Hughes via devel]

I have orphaned all my nodejs packages - feel free to grab though
be aware that in many cases they have hopeless dependency issues.

Full list of affected packages:

carto
jake
kosmtik
lodash
node-gyp
nodejs-agentkeepalive
nodejs-ap
nodejs-array-differ
nodejs-array-union
nodejs-arrify
nodejs-assertion-error
nodejs-async-queue
nodejs-aws-sign2
nodejs-bl
nodejs-bluebird
nodejs-buffer-writer
nodejs-chai
nodejs-chai-connect-middleware
nodejs-chai-passport-strategy
nodejs-chroma-js
nodejs-chrono
nodejs-clean-css
nodejs-clone
nodejs-closure-compiler
nodejs-co
nodejs-concat-stream
nodejs-constantinople
nodejs-deep-eql
nodejs-deep-equal
nodejs-define-properties
nodejs-dep-graph
nodejs-difflet
nodejs-es-abstract
nodejs-es-to-primitive
nodejs-express
nodejs-extend
nodejs-eyes
nodejs-filelist
nodejs-fill-keys
nodejs-foreach
nodejs-fs-extra
nodejs-function-bind
nodejs-gdal
nodejs-generate-function
nodejs-generate-object-property
nodejs-get
nodejs-globule
nodejs-graceful-fs
nodejs-grunt-cli
nodejs-grunt-known-options
nodejs-grunt-legacy-log
nodejs-grunt-legacy-log-utils
nodejs-har-validator
nodejs-has
nodejs-hash_file
nodejs-has-symbols
nodejs-has-unicode
nodejs-hsluv
nodejs-humanize-ms
nodejs-i2c
nodejs-iconv
nodejs-iconv-lite
nodejs-image-size
nodejs-inherits
nodejs-is
nodejs-is-callable
nodejs-is-date-object
nodejs-is-my-json-valid
nodejs-is-object
nodejs-is-property
nodejs-is-regex
nodejs-isstream
nodejs-is-symbol
nodejs-is-typedarray
nodejs-json-localizer
nodejs-jsonpointer
nodejs-js-string-escape
nodejs-JSV
nodejs-klaw
nodejs-leaflet
nodejs-leaflet-formbuilder
nodejs-leaflet-hash
nodejs-less
nodejs-less-plugin-clean-css
nodejs-libpq
nodejs-libxmljs
nodejs-lodash
nodejs-make-arrow-function
nodejs-make-generator-function
nodejs-mapnik
nodejs-mapnik-pool
nodejs-mapnik-reference
nodejs-mapnik-vector-tile
nodejs-mbtiles
nodejs-merge-descriptors
nodejs-millstone
nodejs-mock-fs
nodejs-module-not-found-error
nodejs-monocle
nodejs-multimatch
nodejs-nan
nodejs-nan1
nodejs-node-expat
nodejs-node-markdown
nodejs-node-stringprep
nodejs-numeral
nodejs-oauth
nodejs-object-dot-assign
nodejs-object-inspect
nodejs-object-is
nodejs-object-keys
nodejs-okay
nodejs-packet-reader
nodejs-passport
nodejs-passport-oauth
nodejs-passport-oauth1
nodejs-passport-oauth2
nodejs-passport-strategy
nodejs-path-exists
nodejs-pedding
nodejs-pff
nodejs-pg
nodejs-pg-connection-string
nodejs-pg-cursor
nodejs-pg-escape
nodejs-pg-int8
nodejs-pg-native
nodejs-pg-numeric
nodejs-pg-packet-stream
nodejs-pgpass
nodejs-pg-pool
nodejs-pg-protocol
nodejs-pg-types
nodejs-postgres-array
nodejs-postgres-bytea
nodejs-postgres-date
nodejs-postgres-interval
nodejs-progress-stream
nodejs-prompt
nodejs-proxyquire
nodejs-queue-async
nodejs-readdir-scoped-modules
nodejs-request
nodejs-require-directory
nodejs-resumer
nodejs-rewire
nodejs-safe-buffer
nodejs-secure-random
nodejs-set-immediate
nodejs-set-immediate-shim
nodejs-should
nodejs-should-equal
nodejs-should-format
nodejs-should-http
nodejs-should-type
nodejs-simple-assert
nodejs-single-line-log
nodejs-sinon
nodejs-sliced
nodejs-speedometer
nodejs-sphericalmercator
nodejs-sqlite3
nodejs-srs
nodejs-step
nodejs-string-dot-prototype-dot-trim
nodejs-stringstream
nodejs-supports-color
nodejs-tap
nodejs-tape
nodejs-tilelive-mapnik
nodejs-tiletype
nodejs-tmp
nodejs-tough-cookie
nodejs-type-detect
nodejs-uid2
nodejs-uri-js
nodejs-uri-path
nodejs-utilities
nodejs-utils-merge
nodejs-vows
nodejs-with
nodejs-xml2js
nodejs-xmlbuilder
nodejs-zap
nodejs-zipfile

Tom

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

Rebase of fmt to 7.0.0

[Vitaly Zaitsev via devel]

Hello all.

Fmt package will be rebased in Rawhide from version 6.2.1 to 7.0.0 next
week.

This will include soversion bump from 6 to 7. All dependent packages
must be rebuilt.

Please check your packages, because there are some breaking API changes:
https://github.com/fmtlib/fmt/releases/tag/7.0.0

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Michal Schorm]

+1 for nano.

What I miss is the presence of nano in the default installations and images.
I strongly believe it was there just a few Fedora releases back, but
now, it's gone.

I would really simplify - or atleast make more friendly - fast file
editing / configuration on fresh systems.

This might not be what this discussions is about, but I feel that it
would be nice to have nano part of the default images / installations
before we would start talking about making it default editor.
(Assuming vi won't disappear)

--

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Chris Adams]

Once upon a time, Lennart Poettering  said:
> EFI SecureBoot uses PE signed executables.

Secure Boot also triggers the Linux kernel to disable functionality, so
should be avoided as a requirement (except when necessary to boot some
other OSes).
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Lennart Poettering]

On Mo, 06.07.20 21:58, Peter Robinson (pbrobin...@gmail.com) wrote:

> >
> > Less complexity in the boot chain, mainly. But the EFI drivers would
> > need to be signed by MS, I think? That would massively complicate
> > things.
>
> I believe that to be correct, of could Apply has control over that for
> their platform, you'd also need to load them some how, I'm guessing
> sd-boot could try loading/locking if it can't read a file system...
> suddenly things start to head towards complexity again.

Quite frankly, I don't see the point of using a different file system
than VFAT here. You cannot avoid VFAT anyway, since that's the only
thing EFI firmware can generally read, and hence your boot loader
itself is always read from VFAT anyway. Throwing in another file system
just increases the maintenance burden: previously you had one problem
and now you have two problems.

Given that the update cycles for boot loaders in a world where boot
loaders do certificate management, TLS, HTTP, networking, IP, yadda
yadda isn't much different from update cycles for kernels/initrds
adding in a second, separate file system such as XFS or ext4 won't
give you much additional data safety, it just gives you more code that
can break. In particular as features such as boot counting/assessment
require writable fs access from the boot loader, but that is very hard
to tackle on journalling file systems (grub doesn't do it afaik), and
basically means you need to maintain your own fully blown file system
implementation. VFAT on the other hand is simple, its there anyway,
you need to rely on it anyway and allows writing from firmware too.

That all said, one feature I'd like to add to sd-boot is that we
define a drop-in dir where you can put drivers in, and we'll load them
all, one by one. The idea would be that distros can drop in XFS or
ext4 drivers there, properly signed, and we'd load them, so that it
doesn't matter to sd-boot which file system you actually pick: if you
want XFS or ext4 then you can easily make it happen, just by dropping
in their driver files, and things will just work.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Lennart Poettering]

On Mo, 06.07.20 20:06, Chris Murphy (li...@colorremedies.com) wrote:

> On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen  wrote:
> >
> > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote:
> >
> > >On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek 
> > >wrote:
> > >> Making btrfs opt-in for F33 and (assuming the result go well) opt-out 
> > >> for F34
> > >> could be good option. I know technically it is already opt-in, but it's 
> > >> not
> > >> very visible or popular. We could make the btrfs option more prominent 
> > >> and
> > >> ask people to pick it if they are ready to handle potential fallout.
> > >
> > >I'm leaning towards recommending this as well. I feel like we don't have
> > >good data to make a decision on -- the work that Red Hat did previously 
> > >when
> > >making a decision was 1) years ago and 2) server-focused, and the Facebook
> > >production usage is encouraging but also not the same use case. I'm
> > >particularly concerned about metadata corruption fragility as noted in the
> > >Usenix paper. (It'd be nice if we could do something about that!)
> >
> > So if one has a spare partition to play with btrfs, is there an easy
> > way to install a second copy of Fedora without having the /boot/efi/
> > entries overwrite the existing Fedora installation?  Or fix it to have
> > 2 separate entries after the fact?
>
>
> It's possible but has challenges. Separate ESP's you'll need to
> either

Thou shallt not have multiple ESPs per disk. See:

https://news.ycombinator.com/item?id=16261695

The EFI spec is kinda vague about it, but it breaks everywhere, in
particular with Windows.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning og my nodejs packages

[Jamie Nguyen]

Hi Tom,

Thank you for your tireless nodejs packaging over the years!

I vaguely recall trading tens and tens of nodejs package reviews with 
you back when Fedora's nodejs ecosystem was rapidly growing.



Kind regards,

--
Jamie Nguyen
jamielinux.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Przemek Klosowski via devel]

On 7/6/20 6:49 PM, John M. Harris Jr wrote:

Unless you're actively using all of those tabs (I don't know how you would be,
but it's certainly possible), swap sounds like the perfect solution. Unless
Firefox keeps JS running in there, and it's updating the DOM, these would
likely be able to get swapped out.

Firefox will actually unload tabs that you haven't done anything with in a
while under specific circumstances, but I don't know what those are. You may
notice, for example, that the page "reloads" without network traffic, when
going to a tab you haven't had open in a while. I've seen this on my system
recently.
Take a look at the Task Manager. You will see tabs running even though 
you're not touching that: the pages have elements (ads, animations, etc) 
that run even though the tabs are not visible. True, the browser tries 
to pacify them (turns off sound/video, and whatnot) but they still 
run---and if the JS engine has memory leaks their memory footprint 
increases. You can see the culprits---sort them by "Energy Impact" or 
"Memory" by clicking on the column headers.



More swap doesn't necessarily solve this problem: remember that 1GB/min
is a ballpark HD speed so if you have 10GB swap  that your system is
actually trying to use, you will just sit there for 10 minutes.

I don't really understand how that'd be the case. For that to happen, you'd
have to load all of those into memory, have them swap out, then try to swap
them all back in at the same time.


That's my point---you don't have control over it. Swap algorithm decides 
which pages are evicted from RAM or brought back---if the browser starts 
allocating memory, my FreeCAD might get pushed out, and if I click on 
GIMP window after not using it for an hour it tries to bring it back in.


One way to think about it is that disk is tens of thousands times slower 
than RAM. If you need to use it, your system is commensurably slower. 
That's why zram is such a good idea. Swap was always a tradeoff: you 
saved $'s not spent on RAM, and paid with your time sitting idle waiting 
for the computer.


With the modern way of computing, where your data is mostly NOT on your 
system---so you don't lose it if your application shuts down---I am 
beginning to think that application crashes aren't such a big deal as 
they used to be. I'd rather crash and restart where I left off than have 
the computer drag me along trying to save my application.


Having said that, of course lots of applications ARE local and will lose 
data if crashed, so maybe the cgroup-based approach is the definitive 
solution: hard-limit the memory for cloud apps, to protect the local 
apps from resource exhaustion.


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

Re: Packagers with no corresponding valid bugzilla accounts

[Pierre-Yves Chibon]

On Tue, Jul 07, 2020 at 10:30:02AM +0200, Pierre-Yves Chibon wrote:
> On Tue, Jul 07, 2020 at 08:17:00AM +, Mattia Verga wrote:
> > Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
> > >
> > > Good Morning Everyone,
> > >
> > > The list is slowly going down, we have now 38 accounts that are still
> > > problematic, they have all received several personal emails over the last 
> > > few
> > > weeks and none but one reacted.
> > > I will likely start to ping FESCo about them starting next week.
> > > ...
> > 
> >  From a quick look to that list, there are some users that have no 
> > package assigned... I wonder if the unresponsive maintainer process 
> > implies the user to be removed from the packager group when their 
> > packages get orphaned and the user has no more any package associated to 
> > their account.
> 
> The source of info is: https://src.fedoraproject.org/extras/pagure_bz.json
> which includes people that are packagers as well as people who are watching 
> the
> packages (ie who asked to be included in the CC list on bugzilla).

So after this, I took a little time to write a script that reports who
maintains/watches what on dist-git (that will be synced to bugzilla).

The script is available at:
https://pagure.io/releng/blob/master/f/scripts/who_maintains_what.py

Here is the list for the users and groups affected:
@graphics-sig is watching rpms/xorg-x11-drv-ati
@graphics-sig is watching rpms/xorg-x11-drv-intel

@weldr-sig is watching rpms/ghc-RSA
@weldr-sig is watching rpms/ghc-attoparsec-binary
@weldr-sig is watching rpms/ghc-authenticate-oauth
@weldr-sig is watching rpms/ghc-bindings-DSL
@weldr-sig is watching rpms/ghc-chunked-data
@weldr-sig is watching rpms/ghc-codec-rpm
@weldr-sig is watching rpms/ghc-concurrent-extra
@weldr-sig is watching rpms/ghc-cond
@weldr-sig is watching rpms/ghc-conduit-combinators
@weldr-sig is watching rpms/ghc-content-store
@weldr-sig is watching rpms/ghc-cpio-conduit
@weldr-sig is watching rpms/ghc-crypto-pubkey-types
@weldr-sig is watching rpms/ghc-generics-sop
@weldr-sig is watching rpms/ghc-gi-ggit
@weldr-sig is watching rpms/ghc-gi-gio
@weldr-sig is watching rpms/ghc-gi-glib
@weldr-sig is watching rpms/ghc-gi-gobject
@weldr-sig is watching rpms/ghc-gi-ostree
@weldr-sig is watching rpms/ghc-haskell-gi
@weldr-sig is watching rpms/ghc-haskell-gi-base
@weldr-sig is watching rpms/ghc-haskell-gi-overloading
@weldr-sig is watching rpms/ghc-hspec
@weldr-sig is watching rpms/ghc-hspec-core
@weldr-sig is watching rpms/ghc-hspec-discover
@weldr-sig is watching rpms/ghc-hspec-expectations
@weldr-sig is watching rpms/ghc-htoml
@weldr-sig is watching rpms/ghc-http-media
@weldr-sig is watching rpms/ghc-lens-aeson
@weldr-sig is watching rpms/ghc-listsafe
@weldr-sig is watching rpms/ghc-lzma-conduit
@weldr-sig is watching rpms/ghc-mono-traversable
@weldr-sig is watching rpms/ghc-natural-transformation
@weldr-sig is watching rpms/ghc-parsec-numbers
@weldr-sig is watching rpms/ghc-quickcheck-io
@weldr-sig is watching rpms/ghc-semver
@weldr-sig is watching rpms/ghc-servant
@weldr-sig is watching rpms/ghc-servant-client
@weldr-sig is watching rpms/ghc-servant-client-core
@weldr-sig is watching rpms/ghc-servant-foreign
@weldr-sig is watching rpms/ghc-servant-options
@weldr-sig is watching rpms/ghc-servant-server
@weldr-sig is watching rpms/ghc-string-conversions
@weldr-sig is watching rpms/ghc-string-qq
@weldr-sig is watching rpms/ghc-tar-conduit
@weldr-sig is watching rpms/ghc-unbounded-delays
@weldr-sig is watching rpms/ghc-vector-algorithms
@weldr-sig is watching rpms/ghc-wai-cors
@weldr-sig is watching rpms/ghc-wreq

affix is maintaining rpms/libmygpo-qt
affix is watching rpms/nagios
affix is watching rpms/nginx
affix is watching rpms/znc-infobot

alen is watching rpms/firefox

amitshah is maintaining rpms/pius
amitshah is maintaining rpms/qemu

andreyma is maintaining rpms/ucx

avesh is maintaining rpms/ima-evm-utils
avesh is maintaining rpms/libtnc
avesh is watching rpms/openpts
avesh is watching rpms/openswan
avesh is watching rpms/pam_ccreds
avesh is watching rpms/pam_passwdqc
avesh is watching rpms/passwdqc
avesh is maintaining rpms/strongswan
avesh is maintaining rpms/stunnel
avesh is maintaining rpms/tpm-quote-tools
avesh is maintaining rpms/tpm-tools
avesh is watching rpms/trousers

etingof is maintaining rpms/python-pyghmi

gnikandrov is watching rpms/setup

ignotusp is watching rpms/leechcraft
ignotusp is watching rpms/qxmpp-dev

itsbill is watching rpms/ratpoison

jefferson2z is watching rpms/godot

kir is watching rpms/criu

luismartingil is maintaining rpms/sipp

marcdeop is maintaining rpms/amarok
marcdeop is maintaining rpms/latte-dock
marcdeop is maintaining rpms/vim-omnicppcomplete

mbartos is watching rpms/ceelog
mbartos is maintaining rpms/libee
mbartos is maintaining rpms/libestr
mbartos is maintaining rpms/liblognorm
mbartos is watching rpms/libmongo-client
mbartos is watching rpms/libumberlog
mbartos is watching rpms/npth

mhabrnal is watching 

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chris Murphy]

On Tue, Jul 7, 2020 at 9:25 AM Lennart Poettering  wrote:

> Thou shallt not have multiple ESPs per disk. See:
>
> https://news.ycombinator.com/item?id=16261695
>
> The EFI spec is kinda vague about it, but it breaks everywhere, in
> particular with Windows.

The Windows *installer* doesn't like it. I'm not aware of Windows
itself having difficulty with it. I have tested this layout. But, it
could be there are UEFI bugs abound.

In any case, this is not general advocacy of two ESPs, so thanks for
the criticism. To be clear, I offer it only for advanced users who are
somewhat prepared for confusion of unknown manifestation. :)



-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Adam Williamson]

On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote:
> On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen  wrote:
> > 
> > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote:
> > 
> > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek 
> > > wrote:
> > > > Making btrfs opt-in for F33 and (assuming the result go well) opt-out 
> > > > for F34
> > > > could be good option. I know technically it is already opt-in, but it's 
> > > > not
> > > > very visible or popular. We could make the btrfs option more prominent 
> > > > and
> > > > ask people to pick it if they are ready to handle potential fallout.
> > > 
> > > I'm leaning towards recommending this as well. I feel like we don't have
> > > good data to make a decision on -- the work that Red Hat did previously 
> > > when
> > > making a decision was 1) years ago and 2) server-focused, and the Facebook
> > > production usage is encouraging but also not the same use case. I'm
> > > particularly concerned about metadata corruption fragility as noted in the
> > > Usenix paper. (It'd be nice if we could do something about that!)
> > 
> > So if one has a spare partition to play with btrfs, is there an easy
> > way to install a second copy of Fedora without having the /boot/efi/
> > entries overwrite the existing Fedora installation?  Or fix it to have
> > 2 separate entries after the fact?
> 
> 
> It's possible but has challenges. Separate ESP's you'll need to either
> (a) use the firmware's built-in boot manager to choose what will
> probably appear to be identically named Fedora's

No, you have to rename the first one before doing the second install.
anaconda explicitly deletes any existing efibootmgr entry named
"Fedora" before creating a new one.
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Adam Williamson]

On Tue, 2020-07-07 at 06:02 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jul 06, 2020 at 08:06:05PM -0600, Chris Murphy wrote:
> > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen  wrote:
> > > So if one has a spare partition to play with btrfs, is there an easy
> > > way to install a second copy of Fedora without having the /boot/efi/
> > > entries overwrite the existing Fedora installation?  Or fix it to have
> > > 2 separate entries after the fact?
> > 
> > It's possible but has challenges. Separate ESP's you'll need to either
> > (a) use the firmware's built-in boot manager to choose what will
> > probably appear to be identically named Fedora's (b) add new NVRAM
> > entries, and names, and switch between them before reboot by using
> > efibootmgr --bootorder or --bootnext.
> > 
> > Another option is shared ESP and /boot but my vague recollection is
> > some things go away. For sure /boot/efi/EFI/fedora is replaced, and
> > then possibly /boot/loader/entries are replaced. But that might be
> > easier to deal with than the above, and more efficient.
> 
> This is so sad. Boot Loader Specification was explicitly designed to
> support parallel installations on a single ESP. (The case of different
> systems was the goal, but the general logic works for different
> installations of the same system as well.) BLS entries are stored
> underneath $ESP/, so different Fedora installations which
> have different machine-id numbers simply don't conflict. sd-boot just
> displays the combined list. If two entries happen to be *exactly* the
> same — same os name, same os version, same kernel version — it'll use
> the machine-id in the entry title to disambiguate them to the user (*).
> 
> There is really no reason for this not to work. If are considering
> separate ESPs and efibootmgr to switch between them then something
> went rather wrong somewhere.

I can't speak for Chris, but I was honestly just gaming it out in my
head, trying to think how I'd try it if I was going to do it. I've
never actually tried it myself.
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Markus Larsson]

On 7 July 2020 18:31:32 CEST, Adam Williamson  
wrote:
>On Tue, 2020-07-07 at 06:02 +, Zbigniew Jędrzejewski-Szmek wrote:
>> On Mon, Jul 06, 2020 at 08:06:05PM -0600, Chris Murphy wrote:
>> > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen  wrote:
>> > > So if one has a spare partition to play with btrfs, is there an easy
>> > > way to install a second copy of Fedora without having the /boot/efi/
>> > > entries overwrite the existing Fedora installation?  Or fix it to have
>> > > 2 separate entries after the fact?
>> > 
>> > It's possible but has challenges. Separate ESP's you'll need to either
>> > (a) use the firmware's built-in boot manager to choose what will
>> > probably appear to be identically named Fedora's (b) add new NVRAM
>> > entries, and names, and switch between them before reboot by using
>> > efibootmgr --bootorder or --bootnext.
>> > 
>> > Another option is shared ESP and /boot but my vague recollection is
>> > some things go away. For sure /boot/efi/EFI/fedora is replaced, and
>> > then possibly /boot/loader/entries are replaced. But that might be
>> > easier to deal with than the above, and more efficient.
>> 
>> This is so sad. Boot Loader Specification was explicitly designed to
>> support parallel installations on a single ESP. (The case of different
>> systems was the goal, but the general logic works for different
>> installations of the same system as well.) BLS entries are stored
>> underneath $ESP/, so different Fedora installations which
>> have different machine-id numbers simply don't conflict. sd-boot just
>> displays the combined list. If two entries happen to be *exactly* the
>> same — same os name, same os version, same kernel version — it'll use
>> the machine-id in the entry title to disambiguate them to the user (*).
>> 
>> There is really no reason for this not to work. If are considering
>> separate ESPs and efibootmgr to switch between them then something
>> went rather wrong somewhere.
>
>I can't speak for Chris, but I was honestly just gaming it out in my
>head, trying to think how I'd try it if I was going to do it. I've
>never actually tried it myself.

The easy way to do it is to keep the same ESP and solve it with a nice little 
GRUB config.
It works well even between distributions.
You can of course break it by having one of the distributions overwrite it 
wrongly but that's easily fixed and prevented.

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

Orphaning my golang packages

[Fabio Valentini]

Hi everybody,

I have to finally admit that I'll never again be able to play catch-up
with the ever-changing sprawling go library dependency tree of
syncthing.

I have switched to using bundled dependencies for syncthing ~years ago
already, and I do not have the time nor the energy to do the amount of
work that would be necessary to un-bundle everything again. The
following packages are now orphaned:

- golang-github-calmh-du
- golang-github-calmh-xdr
- golang-github-chmduquesne-rollinghash
- golang-github-d4l3k-messagediff
- golang-github-gobwas-glob
- golang-github-jackpal-gateway
- golang-github-minio-sha256-simd
- golang-github-petermattis-goid
- golang-github-syncthing-notify
- golang-github-thejerf-suture
- golang-github-vitrun-qart
- golang-gopkg-asn1-ber-1
- golang-gopkg-ldap-2

I think most of them have never been used for anything but building
syncthing, so they have been useless baggage for me for years. Some
are also used by other packages, and I hope that those few can find a
new home.

The packages should comply with the latest Packaging Guidelines for
Go, should be up-to-date, and are all building successfully, with
passing test suites.

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

Re: Packagers with no corresponding valid bugzilla accounts

[Michel Alexandre Salim]

On Tue, 2020-07-07 at 10:30 +0200, Pierre-Yves Chibon wrote:
> On Tue, Jul 07, 2020 at 08:17:00AM +, Mattia Verga wrote:
> > Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto:
> > > Good Morning Everyone,
> > > 
> > > The list is slowly going down, we have now 38 accounts that are
> > > still
> > > problematic, they have all received several personal emails over
> > > the last few
> > > weeks and none but one reacted.
> > > I will likely start to ping FESCo about them starting next week.
> > > ...
> > 
> >  From a quick look to that list, there are some users that have no 
> > package assigned... I wonder if the unresponsive maintainer
> > process 
> > implies the user to be removed from the packager group when their 
> > packages get orphaned and the user has no more any package
> > associated to 
> > their account.
> 
> The source of info is: 
> https://src.fedoraproject.org/extras/pagure_bz.json
> which includes people that are packagers as well as people who are
> watching the
> packages (ie who asked to be included in the CC list on bugzilla).
> 

Should we make the script more robust and ignore invalid watcher
emails? Seems worrying if someone who's not even a packager can block
packager changes from being reflected in Bugzilla.

Regards,

-- 
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Orion Poplawski]

On 6/15/20 1:47 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds

== Summary ==
%cmake macro will be adjusted (-B parameter)
to use separate build folder (already standardized
%{_vpath_builddir} macro). Additionally,
%cmake_build, %cmake_install and
%ctest macro will be created (and backported to the older
supported Fedora releases) to perform various operations that are
commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
etc.) way.

Packages that will stop building are trivial to fix and will be
adjusted either by maintainers or change owners.

== Owner ==
* Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
Esser]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobr...@fedoraproject.org, besse...@fedoraproject.org,
ngomp...@gmail.com

== Detailed Description ==
Historically, software builds had a singular build configuration and
required running the build within the project root. Nowadays, there
are many build modes and options that can be configured in projects,
different build settings (e.g. compiler flags) / types (release,
debug) that can be applied and different tools that can be used to
actually execute builds (compilers like gcc/clang, build job
schedulers like make/ninja, and so on). Thus, CMake upstream strongly
discourages users of doing in-source builds and recommends doing
out-of-source builds.

 From cmake.1:


To maintain a pristine source tree, perform an out-of-source build by
using a separate dedicated build tree. An in-source build in which the
build tree is placed in the same directory as the source tree is also
supported, but discouraged.


The other part of the change is introduction of additional macros is
creation of set of macro that can build, install and run tests in a
backend-agnostic, vpath-aware (out-of-source, in-source) way.

=== Migration ===

 %cmake + %(make|ninja)_(build|install) 

There are multiple paths to complete the migration:

* Add -C "%{_vpath_builddir}" to the %(make|ninja)_*
* Replace %(make|ninja)_build and
%(make|ninja)_install with %cmake_build and
%cmake_install respectively
* Redefine vpath builddir %global _vpath_builddir . to
continue performing in-source builds (and optionally converting to the
%cmake_*)

Depending on the package, one of these options may be used to adapt to
this change.

 %cmake -B builddir +
%(make|ninja)_(build|install) -C builddir 

No changes are needed.

== Benefit to Fedora ==
* Follow CMake upstream recommendations when building packages
* Brings Fedora package builds more in-line with how upstream projects
expect them to be built
* Improve compatibility with other RPM distributions that already do this
* Support backend-agnostic way of building CMake projects

== Scope ==
* Proposal owners: Implement necessary macros, try to build packages
that BuildRequires: cmake in a side tag, analyze failures
and fix the relevant ones (introduced by this change).
* Other developers: While proposal owners will try to fix all affected
packages, there might be some cases where package is already FTBFS so
the fix can't be performed. Other package maintainers will have to fix
the issue themselves after they fix FTBFS.
* Release engineering: [https://pagure.io/releng/issue/9524 #9524]
* Policies and guidelines: CMake page will be adjusted to mention
newly created macros and the documentation about relevant VPATH macros
needs to be restructured a bit (they are already documented on the
Meson page, they need to be moved to the separate page and referenced
both from CMake and Meson page).
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Existing packages can (and most likely will) become FTBFS, but
proposal owners will fix as many Fedora packages as possible. However
fixing third-party packages is not possible and out of scope.
Third-party packagers will need to adapt based on the recommendations
noted in this Change.


What's the plan for EPEL8/7 compatibility?



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



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Orion Poplawski]

On 6/15/20 1:47 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds

== Summary ==
%cmake macro will be adjusted (-B parameter)
to use separate build folder (already standardized
%{_vpath_builddir} macro). Additionally,
%cmake_build, %cmake_install and
%ctest macro will be created (and backported to the older
supported Fedora releases) to perform various operations that are
commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
etc.) way.

Packages that will stop building are trivial to fix and will be
adjusted either by maintainers or change owners.

== Owner ==
* Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
Esser]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobr...@fedoraproject.org, besse...@fedoraproject.org,
ngomp...@gmail.com

== Detailed Description ==
Historically, software builds had a singular build configuration and
required running the build within the project root. Nowadays, there
are many build modes and options that can be configured in projects,
different build settings (e.g. compiler flags) / types (release,
debug) that can be applied and different tools that can be used to
actually execute builds (compilers like gcc/clang, build job
schedulers like make/ninja, and so on). Thus, CMake upstream strongly
discourages users of doing in-source builds and recommends doing
out-of-source builds.

 From cmake.1:


To maintain a pristine source tree, perform an out-of-source build by
using a separate dedicated build tree. An in-source build in which the
build tree is placed in the same directory as the source tree is also
supported, but discouraged.


The other part of the change is introduction of additional macros is
creation of set of macro that can build, install and run tests in a
backend-agnostic, vpath-aware (out-of-source, in-source) way.

=== Migration ===

 %cmake + %(make|ninja)_(build|install) 

There are multiple paths to complete the migration:

* Add -C "%{_vpath_builddir}" to the %(make|ninja)_*
* Replace %(make|ninja)_build and
%(make|ninja)_install with %cmake_build and
%cmake_install respectively
* Redefine vpath builddir %global _vpath_builddir . to
continue performing in-source builds (and optionally converting to the
%cmake_*)

Depending on the package, one of these options may be used to adapt to
this change.

 %cmake -B builddir +
%(make|ninja)_(build|install) -C builddir 

No changes are needed.

== Benefit to Fedora ==
* Follow CMake upstream recommendations when building packages
* Brings Fedora package builds more in-line with how upstream projects
expect them to be built
* Improve compatibility with other RPM distributions that already do this
* Support backend-agnostic way of building CMake projects

== Scope ==
* Proposal owners: Implement necessary macros, try to build packages
that BuildRequires: cmake in a side tag, analyze failures
and fix the relevant ones (introduced by this change).
* Other developers: While proposal owners will try to fix all affected
packages, there might be some cases where package is already FTBFS so
the fix can't be performed. Other package maintainers will have to fix
the issue themselves after they fix FTBFS.
* Release engineering: [https://pagure.io/releng/issue/9524 #9524]
* Policies and guidelines: CMake page will be adjusted to mention
newly created macros and the documentation about relevant VPATH macros
needs to be restructured a bit (they are already documented on the
Meson page, they need to be moved to the separate page and referenced
both from CMake and Meson page).
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Existing packages can (and most likely will) become FTBFS, but
proposal owners will fix as many Fedora packages as possible. However
fixing third-party packages is not possible and out of scope.
Third-party packagers will need to adapt based on the recommendations
noted in this Change.


What's with %{nil}?  If we're writing macros that require the use of 
%{nil} I think we have a problem.


 %cmake3 \
%{?_with_cppunit: -DENABLE_CPPUNIT=ON} \
   %{nil}


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



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski  wrote:
>
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org, besse...@fedoraproject.org,
> > ngomp...@gmail.com
> >
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> >
> >  From cmake.1:
> >
> > 
> > To maintain a pristine source tree, perform an out-of-source build by
> > using a separate dedicated build tree. An in-source build in which the
> > build tree is placed in the same directory as the source tree is also
> > supported, but discouraged.
> > 
> >
> > The other part of the change is introduction of additional macros is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> >
> > === Migration ===
> >
> >  %cmake + %(make|ninja)_(build|install) 
> >
> > There are multiple paths to complete the migration:
> >
> > * Add -C "%{_vpath_builddir}" to the 
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to the
> > %cmake_*)
> >
> > Depending on the package, one of these options may be used to adapt to
> > this change.
> >
> >  %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir 
> >
> > No changes are needed.
> >
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already do this
> > * Support backend-agnostic way of building CMake projects
> >
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build packages
> > that BuildRequires: cmake in a side tag, analyze failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all affected
> > packages, there might be some cases where package is already FTBFS so
> > the fix can't be performed. Other package maintainers will have to fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Existing packages can (and most likely will) become FTBFS, but
> > proposal owners will fix as many Fedora packages as possible. However
> > fixing third-party packages is not possible and out of scope.
> > Third-party packagers will need to adapt based on the recommendations
> > noted in this Change.
>
> What's the plan for EPEL8/7 compatibility?
>

I need to talk to EPEL folks about how to handle this. I'm not sure
exactly what strategy we should take here. I could override the macros
entirely with epel-rpm-macros, which is probably the easiest way to do
it.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https:/

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 7/7/20 7:56 AM, Michal Schorm wrote:

What I miss is the presence of nano in the default installations and images.
I strongly believe it was there just a few Fedora releases back, but
now, it's gone.


Why do you think it's gone?  It's in the "standard" group, so I think it 
should be installed on anything other than base minimal.  I find that 
it's installed on everything.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: 20200707.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200706.n.0
NEW: Fedora-Rawhide-20200707.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  8
Dropped packages:2
Upgraded packages:   86
Downgraded packages: 0

Size of added packages:  53.03 MiB
Size of dropped packages:7.19 MiB
Size of upgraded packages:   2.44 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20200707.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20200706.n.0.iso

= ADDED PACKAGES =
Package: barrier-2.3.2-2.fc33
Summary: Use a single keyboard and mouse to control multiple computers
RPMs:barrier
Size:3.74 MiB

Package: ghc-HsOpenSSL-0.11.4.18-1.fc33
Summary: Partial OpenSSL binding for Haskell
RPMs:ghc-HsOpenSSL ghc-HsOpenSSL-devel ghc-HsOpenSSL-doc ghc-HsOpenSSL-prof
Size:5.95 MiB

Package: golang-github-francoispqt-gojay-1.2.13-1.fc33
Summary: Fastest JSON encoder/decoder with powerful stream API for Golang
RPMs:golang-github-francoispqt-gojay golang-github-francoispqt-gojay-devel
Size:16.63 MiB

Package: new-session-manager-1.3.2-1.fc33
Summary: Music production session manager
RPMs:new-session-manager
Size:548.10 KiB

Package: python-markdown-math-0.7-1.fc33
Summary: Math extension for Python-Markdown
RPMs:python3-markdown-math
Size:16.01 KiB

Package: rtklib-2.4.3.b33-2.fc33
Summary: Program Package for GNSS Positioning
RPMs:rtklib rtklib-devel rtklib-doc rtklib-libs rtklib-qt
Size:26.12 MiB

Package: rust-invalidstring-0.1.2-1.fc33
Summary: Just for testing invalid string data
RPMs:rust-invalidstring+default-devel rust-invalidstring-devel
Size:17.21 KiB

Package: rust-libcryptsetup-rs-sys-0.1.4-1.fc33
Summary: Low level bindings for libcryptsetup
RPMs:rust-libcryptsetup-rs-sys+default-devel rust-libcryptsetup-rs-sys-devel
Size:23.26 KiB


= DROPPED PACKAGES =
Package: glassfish-hk2-2.5.0-6.fc32
Summary: Glassfish Hundred Kilobytes Kernel
RPMs:glassfish-hk2 glassfish-hk2-api glassfish-hk2-class-model 
glassfish-hk2-configuration glassfish-hk2-core glassfish-hk2-extras 
glassfish-hk2-hk2 glassfish-hk2-javadoc glassfish-hk2-jmx glassfish-hk2-locator 
glassfish-hk2-maven-plugins glassfish-hk2-metadata-generator 
glassfish-hk2-osgi-resource-locator glassfish-hk2-runlevel 
glassfish-hk2-testing glassfish-hk2-utils
Size:1.94 MiB

Package: kchildlock-0.91.1-12.fc32
Summary: KDE Parental Control Application
RPMs:kchildlock
Size:5.25 MiB


= UPGRADED PACKAGES =
Package:  R-dplyr-0.8.5-2.fc33
Old package:  R-dplyr-0.8.5-2.fc33~bootstrap
Summary:  A Grammar of Data Manipulation
RPMs: R-dplyr R-dplyr-devel
Size: 11.00 MiB
Size change:  68.05 KiB

Package:  R-purrr-0.3.4-2.fc33
Old package:  R-purrr-0.3.4-2.fc33~bootstrap
Summary:  Functional Programming Tools
RPMs: R-purrr
Size: 2.09 MiB
Size change:  36.11 KiB

Package:  R-rlang-0.4.6-4.fc33
Old package:  R-rlang-0.4.6-3.fc33
Summary:  Functions for Base Types and Core R and 'Tidyverse' Features
RPMs: R-rlang
Size: 5.45 MiB
Size change:  81.40 KiB
Changelog:
  * Fri Jul 03 2020 Jos?? Matos  - 0.4.6-4
  - skip check on bootstrap (testthat is required for tests)


Package:  batctl-2020.2-1.fc33
Old package:  batctl-2020.0-1.fc33
Summary:  B.A.T.M.A.N. advanced control and management tool
RPMs: batctl
Size: 404.56 KiB
Size change:  1.54 KiB
Changelog:
  * Fri Apr 24 2020 Felix Kaechele  - 2020.1-1
  - update to 2020.1

  * Tue Jul 07 2020 Felix Kaechele  - 2020.2-1
  - update to 2020.2


Package:  console-login-helper-messages-0.18.2-1.fc33
Old package:  console-login-helper-messages-0.18.1-1.fc33
Summary:  Combines motd, issue, profile features to show system information 
to the user before/on login
RPMs: console-login-helper-messages 
console-login-helper-messages-issuegen console-login-helper-messages-motdgen 
console-login-helper-messages-profile
Size: 54.34 KiB
Size change:  3.13 KiB
Changelog:
  * Mon Jul 06 2020 Robert Fairley  - 0.18.2-1
  - Update to 0.18.2


Package:  dummy-test-package-crested-0-756.fc33
Old package:  dummy-test-package-crested-0-749.fc33
Summary:  Dummy Test Package called Crested
RPMs: dummy-test-package-crested
Size: 54.20 KiB
Size change:  420 B
Changelog:
  * Mon Jul 06 2020 packagerbot  - 0-750
  - rebuilt

  * Mon Jul 06 2020 packagerbot  - 0-751
  - rebuilt

  * Mon Jul 06 2020 packagerbot  - 0-752
  - rebuilt

  * Mon Jul 06 2020 packagerbot  - 0-753
  - rebuilt

  * Mon Jul 06 2020 packagerbot  - 0-754
  - rebuilt

  * Mon Jul 06 2020 packagerbot  - 0-755
  - rebuilt

  * Tue Jul 07 2020 p

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Markus Larsson]

On 7 July 2020 20:26:52 CEST, Samuel Sieb  wrote:
>On 7/7/20 7:56 AM, Michal Schorm wrote:
>> What I miss is the presence of nano in the default installations and images.
>> I strongly believe it was there just a few Fedora releases back, but
>> now, it's gone.
>
>Why do you think it's gone?  It's in the "standard" group, so I think it 
>should be installed on anything other than base minimal.  I find that 
>it's installed on everything.

Yeah I make sure via configuration management that nano and Emacs aren't 
installed on any of my systems. I have 3 kids and don't want them to be led 
astray.

M

>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: 
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

btrfs, ssd & metadata single profile

[Dominique Martinet]

Chris Murphy wrote on Wed, Jul 01, 2020:
> This is called 'dup' profile in Btrfs. Two copies of a block group. It
> can be set on metadata only, or both metadata and data block groups.
> It is the default mkfs option for HDDs. It is not enabled by default
> on SSDs because concurrent writes of metadata i.e. they happen
> essentially at the exact same time, means the data is likely to end up
> on the same erase block, and typical corruptions affect the whole
> block so it's widely considered to be pointless to use dup on flash
> media. You can use it anyway, either with mkfs, or by converting the
> block group from the single profile to dup. This is a safe procedure.

Does anyone know if anything in the nvme spec says that creating two
namespaces should or could prevent coalescing IO like this?
perhaps is the blocksize is different?

(this doesn't really help with default setup case, but it could make
sense to split the disk in two with data single + metadata raid1 over
a nvme namespace for people who can bother creating one. Unfortunately
nvme namespaces are rather messy and I don't think autopartitionning
tools should mess with that, but having a raid just for metadata is one
of btrfs' strength so it's a shame to pass on it... Alternatively it
would require something like async copyback of the second metadata copy
but that in itself has a lot of other problems and don't really look
like an option)

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

Using "rawhide" for the dist-git branch for Fedora Rawhide

[Till Maas]

Hi,

in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
branch for Fedora Rawhide "rawhide" to clarify the purpose of that
branch. There was also some feedback that Rawhide might not be the best
name and it could be renamed. In that case, the branch could be named as
this. This is just the first step to check if there is enough support
for this to move forward. The next step would be to start a change
process.

In case you would like to help handling the effort that this needs, want
to highlight any tools that need to be adjusted (if they hard code the
branch name instead of querying it from some place) or have other
remarks, please add them here or in the ticket for FESCo to learn about
them.

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

Re: out of Koji disk space

[Kevin Fenzi]

On Tue, Jul 07, 2020 at 07:55:09AM +0200, Jan Kratochvil wrote:
> On Fri, 03 Jul 2020 14:52:00 +0200, Jan Kratochvil wrote:
> > On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote:
> > > On Wed, Jul 01, 2020 at 11:22:26PM +0200, Jan Kratochvil wrote:
> > > > I will file a ticket after Spot says his opinion (or not).
> > > 
> > > Sure. 
> > 
> > https://src.fedoraproject.org/rpms/chromium/pull-request/27
> 
> So Spot says:
>   I'm not sure that the additional build time and storage demands of
>   this are worthwhile in practice.
> 
> Not sure what to do when after all the compiler tools effort the debuginfo is
> not worth even the time building it.

I am not sure what to tell you here. Perhaps you could describe the
reason you are working on the chromium debuginfo? Is it broken? Missing?
Less useful that normal? 

All I see in this thread is that you were working on it and it increased
disk space usage, I must have missed the background/goal here?

kevin


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

PostgreSQL 13 - Fedora 33 Self-Contained Change proposal

[Ben Cotton]

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

== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.

== Owner ==
* Name: [[User:panovotn| Patrik Novotny]]
* Email: panov...@redhat.com

== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.

This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.

== Benefit to Fedora ==

Latest stable software is used by Fedora users.

== Scope ==
* Proposal owners:

**Prepare PostgreSQL 13 as a module for Rawhide and at least one
stable Fedora release (done)
**Prepare PostgreSQL 12 as a module for Rawhide, so there would be a
failover in case of problems
**Build PostgreSQL 13 to Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Gather user input on the changes between PostgreSQL 12 and PostgreSQL 13

* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible, so
there shouldn't be any issues, but rebuild of the depended components
is better to be sure. There is a
[https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/
COPR build] available for testing.
Server plugins might require a newer version update, because they
sometimes have explicit server requirements. PostgreSQL maintainer
will help fixing/rebuilding any issues in the plugins.

== How To Test ==

Usual testing as when upgrading between major PostgreSQL versions,
running `postgresql-setup --upgrade` is necessary between major
versions.

Test that all other software runs well with PostgreSQL 13.

== User Experience ==

The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade`.

If users want to stick with PostgreSQL 12 for a little longer, there
should be PostgreSQL 12 module.
If users want to test it before it reaches Fedora 33, there is a
[https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/
COPR build] available.

== Dependencies ==

There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires, others should use libpq. In both
the cases, rebuild should be done to make sure all potential binary
incompatibilities are handled.

== Contingency Plan ==

Modules will provide the functional version of PostgreSQL 12,
available to all users.

== Documentation ==

Upgrade startegy: https://www.postgresql.org/docs/13/upgrading.html

== Release Notes ==

Release notes for PostgreSQL 13 release:
https://www.postgresql.org/docs/13/index.html

Overall overview of the changes and improvements:
https://www.postgresql.org/docs/13/release-13.html


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Support PARSEC - Fedora 33 Self-Contained Change proposal

[Ben Cotton]

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

== Summary ==
PARSEC is the Platform AbstRaction for SECurity, an open-source
initiative to provide a common API to hardware security and
cryptographic services in a platform-agnostic way. This abstraction
layer keeps workloads decoupled from physical platform details,
enabling cloud-native delivery flows within the data center and at the
edge.
From a hardware perspective the PARSEC daemon can currerntly use a
TPM2, HSM or an Arm TrustZone secure world application.

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]], [[User:puiterwijk |
Patrick Uiterwijk]]
* Email: [mailto:pbrobin...@gmail.com| pbrobin...@gmail.com],
[mailto:patr...@puiterwijk.org | patr...@puiterwijk.org]


== Detailed Description ==

PARSEC (Platform AbstRaction for SECurity) is an initiative started
out of Arm to provide a straight forward API for accessing secure
credentials stored in hardware. It's a sandbox project in the CNCF.

== Benefit to Fedora ==

PARSEC is a useful technology for Fedora because making HW security
technologies appear seemless to applications and users helps make
security more straight forward and secure overall. It's a relative new
initiative and having it available in Fedora for people to start to
integrate into their applications helps make Fedora a leader in
security in particular for Internet of Things and Device Edge. The IoT
Edition will be using PARSEC.

== Scope ==
* Proposal owners:
** Package the PARSEC daemon, libraries and language bindings.

* Other developers:
** No impact but developers may wish to add support for PARSEC to
their application.

* Release engineering: [https://pagure.io/releng/issue/9583 #9583]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
This is net new to Fedora so there is no upgrade issues.

== How To Test ==

There's a number of hardware options for testing. Any device with a
TPM2 including most modern laptops.

There will be selection of Arm devices available (final models still
TBD) with the appropriate firmware running the TrustZone secure world
application.

A VM with a swTPM, while not secure, will enable testing.

A number of HW security modules, exact devices still TBD.

== User Experience ==
There will be a new daemon start in the early boot process for those
that install the PARSEC stack. Fedora IoT Edition will install and
start this by default.

The Red Hat Device Edge team and Arm are working on a demo application
for IoT to provide a demonstration application on the technology.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: Most of the work here is packaging so if it
doesn't make the release it would be available as an installable
update.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No.
* Blocks product? No.

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Matthew Miller]

On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote:
> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
> branch for Fedora Rawhide "rawhide" to clarify the purpose of that
> branch. There was also some feedback that Rawhide might not be the best
> name and it could be renamed. In that case, the branch could be named as
> this. This is just the first step to check if there is enough support
> for this to move forward. The next step would be to start a change
> process.

I'm in favor of this. "Master" is not a good, functional description of the
Rawhide branch. It was just taking the default. Plus, as we're investigating
a new git system _and_ looking at packaging workflow improvements all around
anyway, that seems like the time.

I don't have any strong opinion on the "Rawhide" name, although it has
always seemed strange to me, because of course fedoras are made of felt, not
rawhide. And I guess the same "hey, while we're changing things" sentiment
applies here.

-- 
Matthew Miller

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

[Test-Announce] [Test Day] F33 Btrfs by default is 2020-07-08 *TODAY*

[Sumantro Mukherjee]

Hey All,

A new change proposal has been submitted for the Fedora 33 release
cycle which entails usage of btrfs by default [0] for Workstations and
Spins across x86_64 and ARM architectures As a result, we  have
organized a test day on Wed, July 08, 2020. As a part of this test
day, we will aim at folks running a VM or bare metal install with
Btrfs as storage and sharing their experience. Results can be
submitted for the test cases[2]

Refer to the wiki page[1] for links to the test cases and materials
you’ll need to participate!

As usual, we will hang out on the #fedora-test-day over Freenode to
address questions

[0] https://fedoraproject.org/wiki/Changes/BtrfsByDefault
[1] http://fedoraproject.org/wiki/Test_Day:F33_btrfs_by_default_2020-07-08
[2]https://testdays.fedorainfracloud.org/events/87

Thanks
-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Michael Catanzaro]

On Tue, Jul 7, 2020 at 11:26 am, Samuel Sieb  wrote:
Why do you think it's gone?  It's in the "standard" group, so I think 
it

should be installed on anything other than base minimal.  I find that
it's installed on everything.


Warning: @standard is not included at all in Workstation

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

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Markus Larsson]

On 7 July 2020 21:20:22 CEST, Matthew Miller  wrote:
>On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote:
>> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
>> branch for Fedora Rawhide "rawhide" to clarify the purpose of that
>> branch. There was also some feedback that Rawhide might not be the best
>> name and it could be renamed. In that case, the branch could be named as
>> this. This is just the first step to check if there is enough support
>> for this to move forward. The next step would be to start a change
>> process.
>
>I'm in favor of this. "Master" is not a good, functional description of the
>Rawhide branch. It was just taking the default. Plus, as we're investigating
>a new git system _and_ looking at packaging workflow improvements all around
>anyway, that seems like the time.
>
>I don't have any strong opinion on the "Rawhide" name, although it has
>always seemed strange to me, because of course fedoras are made of felt, not
>rawhide. And I guess the same "hey, while we're changing things" sentiment
>applies here.
>

I thought Rawhide was a reference to the wild west via the tv-show by that 
name, isn't that the case?
As for naming, I have no emotional connection to the name rawhide and doesn't 
see any problems with changing it. I would suggest that if it changes maybe not 
Felt or Wool but something more descriptive like Edge, Next or Volatile.

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 7/7/20 12:39 PM, Michael Catanzaro wrote:

On Tue, Jul 7, 2020 at 11:26 am, Samuel Sieb  wrote:

Why do you think it's gone?  It's in the "standard" group, so I think it
should be installed on anything other than base minimal.  I find that
it's installed on everything.


Warning: @standard is not included at all in Workstation


That's good to know for the change proposal then.  I never use the 
Workstation install.  I net install either with a kickstart or selecting 
the options I want, so that would explain why I always end up with nano 
installed.

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

[Test-Announce] Re: [Test Day] F33 Btrfs by default is 2020-07-08 *TODAY*

[Sumantro Mukherjee]

On Wed, Jul 8, 2020 at 12:55 AM Sumantro Mukherjee 
wrote:

> Hey All,
>
> A new change proposal has been submitted for the Fedora 33 release
> cycle which entails usage of btrfs by default [0] for Workstations and
> Spins across x86_64 and ARM architectures As a result, we  have
> organized a test day on Wed, July 08, 2020. As a part of this test
> day, we will aim at folks running a VM or bare metal install with
> Btrfs as storage and sharing their experience. Results can be
> submitted for the test cases[2]
>
> Refer to the wiki page[1] for links to the test cases and materials
> you’ll need to participate!
>
> As usual, we will hang out on the #fedora-test-day over Freenode to
> address questions
>
> [0] https://fedoraproject.org/wiki/Changes/BtrfsByDefault
> [1] http://fedoraproject.org/wiki/Test_Day:F33_btrfs_by_default_2020-07-08
> [2]https://testdays.fedorainfracloud.org/events/87


The event results  link is https://testdays.fedorainfracloud.org/events/88


>
>
> Thanks
> --
> //sumantro
> Fedora QE
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED
>


-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED 
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Michael Catanzaro]

On Tue, Jul 7, 2020 at 12:49 pm, Samuel Sieb  wrote:

That's good to know for the change proposal then.  I never use the
Workstation install.  I net install either with a kickstart or 
selecting
the options I want, so that would explain why I always end up with 
nano

installed.


I don't think so... nano is already installed by default regardless of 
what exactly you are installing (it's in both @standard and 
@workstation-product). It's just not *used* by default.


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

Re: Orphaning my golang packages

[Elliott Sales de Andrade]

On Tue, 7 Jul 2020 at 13:05, Fabio Valentini  wrote:
>
> Hi everybody,
>
> I have to finally admit that I'll never again be able to play catch-up
> with the ever-changing sprawling go library dependency tree of
> syncthing.
>
> I have switched to using bundled dependencies for syncthing ~years ago
> already, and I do not have the time nor the energy to do the amount of
> work that would be necessary to un-bundle everything again. The
> following packages are now orphaned:
>
> - golang-github-calmh-du
> - golang-github-calmh-xdr
> - golang-github-chmduquesne-rollinghash
> - golang-github-d4l3k-messagediff

> - golang-github-gobwas-glob

This one is used by hugo, and you're already admin, so you probably
want to become primary maintainer, Athos.

> - golang-github-jackpal-gateway
> - golang-github-minio-sha256-simd
> - golang-github-petermattis-goid
> - golang-github-syncthing-notify
> - golang-github-thejerf-suture
> - golang-github-vitrun-qart

> - golang-gopkg-asn1-ber-1
> - golang-gopkg-ldap-2

These two are used by golang-vitess, Robert-André.


>
> I think most of them have never been used for anything but building
> syncthing, so they have been useless baggage for me for years. Some
> are also used by other packages, and I hope that those few can find a
> new home.
>
> The packages should comply with the latest Packaging Guidelines for
> Go, should be up-to-date, and are all building successfully, with
> passing test suites.
>
> Thanks.
> Fabio

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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Richard Shaw]

Ok, so it appears this change was for F32+ only, so I can't merge master
into f32 or earlier...

This whole change is still broken AF.

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

Re: Using "rawhide" for the dist-git branch for Fedora Rawhide

[Gary Buhrmaster]

On Tue, Jul 7, 2020 at 7:04 PM Till Maas  wrote:
>
> Hi,
>
> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
> branch for Fedora Rawhide "rawhide" to clarify the purpose of that
> branch. There was also some feedback that Rawhide might not be the best
> name and it could be renamed. In that case, the branch could be named as
> this. This is just the first step to check if there is enough support
> for this to move forward. The next step would be to start a change
> process.

I (strongly) support the renaming of the branch, but I really
really would prefer there to be a rough consensus on the
replacement name across the entire git community, so
that I don't need to remember to git-checkout devel in one
project, git-checkout trunk in another, git-checkout main in
a third, git-checkout release in a fourth, git-checkout default
in a fifth, etc.(*).  In this case, I would prefer Fedora follow
the rough consensus presuming that one can be achieved
rather than pick yet another (different) name.

Gary



(*) Yes, I understand I have already mostly lost that battle
for the moment, although hope springs eternal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Qiyu Yan]

Richard Shaw  于 2020年7月8日周三 上午6:11写道：

> Ok, so it appears this change was for F32+ only, so I can't merge master
> into f32 or earlier...
>
 Maybe wait it to be backported into f31. The documents said this will be
backported into older supported version.

But now, merging master into older version is impossible, can cause FTBTS.

>
> This whole change is still broken AF.
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1854141] perl-Socket-2.030 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-ae00b3db48 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-ae00b3db48`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ae00b3db48

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Btrfs by default, the compression option

[Chris Murphy]

Hi,

The change proposal has a 'compression option' and we kinda need to
get organized.
https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression

 - Compression saves space, significantly reduces write amplification
and therefore increases flash lifespan, and in some cases increases
performance.
 - Desired but not a requirement of the change proposal.

1. Goal: probably the goal performance wise is to perform as good or
better than now. Is it OK if there's a write time performance hit for
a small percent of folks, for a high value target like usr that isn't
updated that often, and is also updated out of band (offline updates
typically, but also isn't something directly related to the daily
workload)? How to decide this?

2. Benchmarking: this is hard. A simple tool for doing comparisons
among algorithms on a specific bit of hardware is lzbench.
https://github.com/inikep/lzbench
How to compile on F32.
https://github.com/inikep/lzbench/issues/69
But is that adequate? How do we confirm/deny on a wide variety of
hardware that this meets the goal? And how is this test going to
account for parallelization, and read ahead? Do we need a lot of data
or is it adequate to get a sample "around the edges" (e.g. slow cpu
fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow
drive). What algorithm?

3. Improvements and upgrades. We'll do plan A, but learn new things
later, and come up with plan B. How do we get the plan A folks
upgraded to plan B? Or just don't worry?

4. The whole file system (using a mount option) or curated (using an
XATTR set on specific "high value" directories)? This part is
elaborated below.

A.  do this with a mount option '-o compress=zstd:1'
   - dilemma: it doesn't always lead to equal or better performance.
On some systems and workloads, write performance is slightly reduced.
What about LZO?

B. do this with per directory XATTR
   - dilemma: the target directories don't exist at install time,
depending on whether the installation is rsync, rpm, or unsquashfs
based.

C. do the install with '-o compres=zstd', then set XATTR post-install
   - dilemma: the installed files won't have XATTR set, only new files
inherit;  does a 'dnf update' overwrite files and therefore the XATTR
is not inherited, or are they new files and do inherit the XATTR?

D. Which directories? Some may be outside of the installer's scope.

/usr
/var/lib/flatpak
~/.local/share/flatpak
/var/lib/containers/
~/.local/share/containers/
~/.var
~/.cache

(Plausible this list should be reversed. While compressing ~/.cache
may not save much space, it's likely hammered with more changes than
other locations, hence more benefit in terms of reducing write
amplification.)

For reference, the above is mostly from the description in the RFE bug
attached to the feature's tracker bug. But I think it's best to have
most discussion here and leave the bug for implementing+testing the
implementation details.
https://bugzilla.redhat.com/show_bug.cgi?id=1851276

Thanks,

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org