Re: list major languages first in anaconda

2020-10-22 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Oct 22, 2020 at 06:28:38AM -, Sundeep Anand wrote:
> Hi,
> 
> To help users choose their native language anaconda tries to evaluate 
> priority languages based on geolocation and place them first in the list. 
> Proposal[1] is to broad this scope by appending major/common speaking 
> languages as well. This may cater to the use case where a major/common 
> language speaker relocated to a different territory. Determining the list of 
> major/common language is tricky, however, as a starting point we may look at 
> gnome-control-center[2].

I strongly support this. The 10 or so most popular languages cover
maybe 60% of the world population, so this optimizes language selection
a large fraction of our users, without really making anything worse for
other users, who just have to go through the search list as before.

As to the list of languages: I think we should go by the total number
of speakers of a given language, though taking into account popularity of Fedora
and OSS in a given group too. (For example, French is only spoken by 77 mln as
the first language according to Wikipedia, but we have many French contributors
and users, proportionally more than the 1% of world population that that 77 mln 
is.
So I think it is important to include French in this list, even though
it's not that popular in the world.)

Also, I think we should go by the *total* number of speakers, not just the 
speakers
for whom the language is the *first* language. My thinking (and I would love
to hear from people who are in this situation) is that many parts of the world
people know multiple languages and are likely to select the interface in
a second language, if that second language for example is of European origin
and uses the Latin alphabet or is otherwise better supported by the software.

I think we should not put regional dialects (**) of a language on the list,
and always stick to the most popular dialect. A speaker of a given regional
variant might *prefer* it, but they will not have any trouble understanding
the most popular variant. This saves us a spot, which we can fill in with
another language that is significantly different than those already on the list.
This increases the chance that someone who is using Fedora will see at least
one language (and alphabet) which they know enough to operate the installer
interface. (So for example, en_AU, en_GB, en_HK, even though they are somewhat
popular, would not be included since en_US is.)

Finally, a caveat that if our localization in a given language is very
bad, we should not advertise it, even if otherwise we'd want to include it.
We should instead set a medium-term goal to improve 
fonts/translations/localization
in that language first.

Going by 
https://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers
we have:
1  English 1268 mln   <-- on the list already, twice
2  Mandarin1120   <-- on the list already
3  Hindi637.3
4  Spanish  537.9 <-- on the list already
5  French   276.6 <-- on the list already
6  Standard Ar  274.0 <-- on the list already (*)
7  Bengali  265.2
8  Russian  258.0 <-- on the list already
9  Portuguese   252.2
10 Indonesian   199.0
11 Urdu 170.6
12 German   131.6 <-- on the list already
13 Japanese 126.4 <-- on the list already

(*) ar_EG is on the list. Is it close enough to other Arabic languages?

My conclusion would be to drop en_GB, add one Hindi, Bengali,
Portuguese, Indonesian and Urdu variant each (with the caveat about
sufficient supported described above). This covers another 1.5trn people
and gives us significantly better coverage in Asia and South America.

Japanese is important because it's a significantly distinct language
with special fonts and conventions, and I think many speakers would
not be comfortable in anything else. OTOH, German is meh, because in
my experience all Germans understand English well enough to use it in
the UI. If we had to drop one more language, I'd drop German.

Zbyszek

(**) a variety of a language that is a characteristic of a particular
group of the language's speakers (Wikipedia)
___
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: F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)

2020-10-22 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 29, 2020 at 09:46:14PM +0100, Peter Robinson wrote:
> On Tue, Sep 29, 2020 at 9:41 PM Neal Gompa  wrote:
> >
> > On Tue, Sep 29, 2020 at 4:30 PM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/CompressKernelFirmware
> > >
> > > == Summary ==
> > > Compress Kernel Firmwares to reduce on disk size
> > >
> > > == Owner ==
> > > * Name: [[User:pbrobinson| Peter Robinson]]
> > > * Email: [mailto:pbrobin...@fedoraproject.org| 
> > > pbrobin...@fedoraproject.org]
> > >
> > > == Detailed Description ==
> > >
> > > Since the linux 5.3 kernel there has been support for loading firmware
> > > from xz compressed firmware. The upstream linux-firmware respository
> > > is now over 900Mb, not including other kernel firmware that are in
> > > Fedora but come from other sources. By compessing the firmware with
> > > "xz -C crc32", the only option currently supported in the kernel, we
> > > can reduce the ondisk size of the firmware by almost half.
> > >
> >
> > I vaguely recall that there was some effort to add zstd support to
> > compress kernel stuff. Could we consider using that for this instead
> > of xz? Or is that still only for kernel modules?
> 
> ATM the only thing that's upstream is xz hence why that's the only
> thing mentioned.

zstd support has been merged for 5.9:
https://kernelnewbies.org/Linux_5.9#Support_for_ZSTD_compressed_kernel.2C_ramdisk_and_initramfs.
Does this support also extend to firmware?

Zbyszek
___
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: Removing unsupported AUTH_DES interfaces in libtirpc.

2020-10-19 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Oct 19, 2020 at 01:21:35PM -0400, Steve Dickson wrote:
> Hello,
> 
> About a year ago I stub out the interfaces
> and had them return an error if called. 
> No one has complained... 
> 
> This time I would like to remove interfaces
> so there will be no support whatsoever to 
> pass some upcoming audits... 

Hi,

there are three semi-independent ways how to remove an interface:
1. functional stubbing out (which you said is already done)
2. removal of the function from headers
3. removal of the function from ABI and the resulting required SONAME change

(1. affects programs that use the function at runtime. 2. affects programs
which use the function during compilation. 3. affects all programs that
use the library.)

Part 1. is already done, and we are discussing 3.:

IMHO the best option is not to this at all. SONAME changes in
libraries low in the stack are simply quite problematic. It is OK for
leaf libraries with a limited number of users, but even there barely
so. While we can rebuild distro packages, user programs will still
require relinking, making users angry.

What about just doing 2. instead, so that we can make certain that
*new* builds are not trying to use those functions. 

glibc doesn't change SONAME, libsystemd doesn't change SONAME, etc.
We have symbol versioning, which allows precise dependencies on
specific symbols. Use that instead, just never remove any symbols, but
only add new ones. Symbol versioning is nicely integrated with rpm dependency
autogenerators, so packages get granular dependencies on the specific 
symbols they use.

Returning to the original question: if you absolutely must do an
incompatible SONAME, then please provide a compat package with the old
SONAME. Maybe it could even be built from the same sources.

But it seems that the only motivation in this particular case is legal
pretend-work (since the functions were already stubbed out, just
removing the stub has no functional effect except ticking off a box
somewhere). That just doesn't seem like a good enough motivation to go
through the work for both packagers and users.

> This means I will need to change the SONAME for 
> libtirpc which will effect a large other packages.

Zbyszek
___
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: nodejs-svgo dependencies

2020-10-14 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Oct 14, 2020 at 12:13:18AM -0700, Luya Tshimbalanga wrote:
> Hello team,
> 
> I took over the maintenance of nodejs-svgo needed for Inkscape.
> Unfortunately, two dependencies were retired due to lack of
> maintenance: sax and js-ymal. The attempt to rebuild those packages
> failed but the guideline for nodejs packages seems unclear with that
> line [1]:

I seems quite a few more deps have been retired...
npm(mocha)
npm(supports-color)
...

This will be a big task to support all that :(

> %prep
> %setup -q -n package
> %nodejs_fixdep foomodule
...
> + cd package

This directory is called 'js-yaml-3.14.0' in the new version:
 %prep
-%setup -q -n package
-%setup -q -T -D -a 1 -n package
-%setup -q -T -D -a 2 -n package
+%autosetup -n js-yaml-%{version}
+%setup -q -T -D -a 1 -n js-yaml-%{version}
+%setup -q -T -D -a 2 -n js-yaml-%{version}

Unfortunately the build fails later because 'fast-check' is missing...

Zbyszek
___
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: opam2rpm (licensing)

2020-10-13 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Oct 13, 2020 at 06:22:44AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Oct 12, 2020 at 04:43:09PM -0600, Jerry James wrote:
> > I made the possibly controversial decision to write opam2rpm in
> > python.  I did this so that I could borrow code and ideas from other
> > spec file generators, many of which are written in python.  If this
> > proves to be a sticking point with the other OCaml package
> > maintainers, I am not opposed to porting it to OCaml, but will need a
> > fair amount of help to do so.
> I don't think this should be controversial. Both ocaml and python are
> good languages to write this kind of tool, but what's more important is
> dependencies and prior art that can be copied. And python wins in this
> regard because of all the other converters that are already there.
> 
> > The current version owes much to go2rpm.  Thank you, go2rpm developers!
> > 6. Talk to the go2rpm developers about breaking licensing.py and
> > spdx_to_fedora.csv out into a separate project.  Note that I fixed
> > some incorrect LGPL entries in the version in opam2rpm.
> 
> No, please don't do that. go2rpm should not have done that either.

https://pagure.io/GoSIG/go2rpm/pull-request/12

> The original location of licensing.py is in rust2rpm, and it should not
> be copied. It is an importable python module:
> >>> from rust2rpm import licensing
> >>> licensing.translate_license_fedora('GPL-2.0 or GPL-2.0-or-later') 
> >>>  
> Upstream license tag GPL-2.0 translated to GPLv2
> Upstream license tag GPL-2.0-or-later translated to GPLv2+
> ('GPLv2 or GPLv2+', None)
> 
> It gets occasionally updated when people report missing licenses or
> translation bugs, and having _multiple_ copies in the distro is just
> going to lead to frustration.
> 
> If there's anything missing or broken in the canonical version, please
> open a bug against rust2rpm.
> 
> Longer-term, I think the licensing submodule could become more
> prominent and a top-level thing of its own. The data should be
> converted from CSV to something sane. We should try to coalesce all
> the other redundant lists of licenses, including
> https://fedoraproject.org/wiki/Licensing:Main#Software_License_List.
> 
> Zbyszek
___
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: opam2rpm (licensing)

2020-10-13 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Oct 12, 2020 at 04:43:09PM -0600, Jerry James wrote:
> I made the possibly controversial decision to write opam2rpm in
> python.  I did this so that I could borrow code and ideas from other
> spec file generators, many of which are written in python.  If this
> proves to be a sticking point with the other OCaml package
> maintainers, I am not opposed to porting it to OCaml, but will need a
> fair amount of help to do so.
I don't think this should be controversial. Both ocaml and python are
good languages to write this kind of tool, but what's more important is
dependencies and prior art that can be copied. And python wins in this
regard because of all the other converters that are already there.

> The current version owes much to go2rpm.  Thank you, go2rpm developers!
> 6. Talk to the go2rpm developers about breaking licensing.py and
> spdx_to_fedora.csv out into a separate project.  Note that I fixed
> some incorrect LGPL entries in the version in opam2rpm.

No, please don't do that. go2rpm should not have done that either.
The original location of licensing.py is in rust2rpm, and it should not
be copied. It is an importable python module:
>>> from rust2rpm import licensing
>>> licensing.translate_license_fedora('GPL-2.0 or GPL-2.0-or-later')   
>>>
Upstream license tag GPL-2.0 translated to GPLv2
Upstream license tag GPL-2.0-or-later translated to GPLv2+
('GPLv2 or GPLv2+', None)

It gets occasionally updated when people report missing licenses or
translation bugs, and having _multiple_ copies in the distro is just
going to lead to frustration.

If there's anything missing or broken in the canonical version, please
open a bug against rust2rpm.

Longer-term, I think the licensing submodule could become more
prominent and a top-level thing of its own. The data should be
converted from CSV to something sane. We should try to coalesce all
the other redundant lists of licenses, including
https://fedoraproject.org/wiki/Licensing:Main#Software_License_List.

Zbyszek
___
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: Self Introduction: Ben Beasley

2020-10-06 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Oct 06, 2020 at 02:47:36PM -0400, Ben Beasley wrote:
> Hello, everyone—my name is Ben Beasley. I’m an electrical engineer
> in the USA with training and experience in communications systems
> and digital signal processing. I’ve been writing domain-specific and
> general-purpose software in many languages (Python, C, C++,
> JavaScript/ECMAScript, bash/sh, awk, MATLAB/Octave, and others) for
> about fifteen years, and doing RPM packaging on CentOS/RHEL and
> Fedora for about ten years. Very little of this work has been
> published or contributed to the FOSS community.
> 
> Now I want to contribute more to Fedora than I have in the past.
> I’ve made a few PR’s to Fedora and to upstreams recently, and I just
> submitted my first package review request,
> https://bugzilla.redhat.com/show_bug.cgi?id=1885684, “rocm-smi - AMD
> ROCm System Management Interface.” My thanks in advance to anyone
> who is willing to review this submission, and especially to anyone
> who might be willing to subsequently sponsor me into the packager
> group.

Hi,
welcome to Fedora. I replied in the review ticket.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

2020-10-06 Thread Zbigniew Jędrzejewski-Szmek
OK, you convinced me: 
https://src.fedoraproject.org/rpms/systemd/pull-request/37.
Let's see what others say.

Zbyszek


On Fri, Oct 02, 2020 at 12:34:32AM +0200, Marius Schwarz wrote:
> Am 01.10.20 um 16:36 schrieb Alexander Bokovoy:
> >
> > You can also drop a configuration snippet in
> > /etc/systemd/resolved.conf.d/ to contain
> >
> >   FallbackDNS=
> >
> > This will disable global DNS servers for any case.
> >
> if that would be the default, it would be ok.
> 
> Am 01.10.20 um 16:03 schrieb Michael Catanzaro:
> > We are not going to patch out fallback to Cloudflare or Google because
> > it is a non-issue. Fallback only happens when you have zero other DNS
> > servers configured. When was the last time you connected to a network
> > and there's no DHCP, no nothing? The number of users without some
> > other working DNS is probably under 0.1%.
> 
> BTW: thumbs up for the DOT proposal.
> 
> I will make it very clear and easy:  
> 
> O== Situation for Germany
> 
> GDPR is in place as a EU LAW. The protection rules are only active for
> companies or organizations, not for private people.
> 
> 2013 a german court (Kammergericht Berlin) ruled, that IP addresses are
> Personal Data. It has never been overruled.
> 
> Personal Data can only be send to none eu countries and corporations, if
> there is a data protection law in place that has the same or better
> level of protection as the eu law has ( or if it's necessary to buy
> stuff (a house, car, whatever ). The pact the EU did with the US was
> called Privacy Shield. It imploded (for the second time) a few months
> ago. From the moment the eu court rule was public, transfer of personal
> data into the us was illegal.
> 
> If you send a DNS REQUEST to a US DNS server from within a company
> network, and with ipv6 the internal ip is sent out i learned lately, you
> have sent personal data which is protected under the GDRP. It's not
> unlikely to use company pcs for private webvisits while having a meal
> break.
> 
> Therefor, a os that has google and cloudflare as a default, even if it's
> unlikely to happen as you point out, which sends out dns with personal
> data in it to a us dns server, brings the company in great trouble with
> the law. In the end, this means, you as a company/org need to pay a
> (possibly) shitload of money as a fine and therefor they can't use this
> os anymore. (someone else on the list pointed this out too.) The
> consequence is, Fedora is a juristic risk. [The fine is higher, if you
> as corp/org did not document this data transfer in your data protection
> memos] Of course a working dns setup will prevent this problem, but
> thats not the point. Activists in germany and other countries try to get
> more and more gov projects to OSS due to privacy issues with M$. It
> would be a shame if Fedora would also count as a potential problem.
> 
> Do we all really want this, for the benefit on 0.1%(as you say) have a
> dns lookup instead of a hint, that their systems are broken?
> 
> Pls remember: I'm just the messenger, Í didn't write the laws ;)
> 
> Funfact: last time I checked the northern germany police pc in my city,
> they used a fedora based desktop system. I like that fact :D But i'm
> pretty sure, they don't like a cloudflare fallback dns once they reach
> F33 ( if ever ).
> 
> 
> 
> best regards,
> Marius Schwarz
> ___
> 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


Re: new dnf mode of listing upgraded packages

2020-10-05 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Oct 05, 2020 at 09:17:46AM -0400, Neal Gompa wrote:
> On Mon, Oct 5, 2020 at 9:15 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On rawhide:
> > $ sudo dnf upgrade
> > 
> >  PackageArch   Version 
> > Repository  Size
> > 
> > Installing:
> >  kernel-corex86_64 5.9.0-0.rc7.20201002git.24.fc34 
> > fedora-rawhide-kernel-nodebug
> > 
> >32 M
> >  kernel-modules x86_64 5.9.0-0.rc7.20201002git.24.fc34 
> > fedora-rawhide-kernel-nodebug
> > 
> >30 M
> > Upgrading:
> >  NetworkManager x86_64 1:1.26.2-2.fc34 
> > rawhide2.2 M
> >  replacing  NetworkManager.x86_64 1:1.26.2-1.fc34.1
> >  NetworkManager-libnm   x86_64 1:1.26.2-2.fc34 
> > rawhide1.6 M
> >  replacing  NetworkManager-libnm.x86_64 1:1.26.2-1.fc34.1
> >  NetworkManager-teamx86_64 1:1.26.2-2.fc34 
> > rawhide 31 k
> >  replacing  NetworkManager-team.x86_64 1:1.26.2-1.fc34.1
> >  NetworkManager-wifix86_64 1:1.26.2-2.fc34 
> > rawhide 99 k
> >  replacing  NetworkManager-wifi.x86_64 1:1.26.2-1.fc34.1
> >  OpenIPMI-libs  x86_64 2.0.29-1.fc34   
> > rawhide524 k
> >  replacing  OpenIPMI-libs.x86_64 2.0.28-6.fc33
> >  abrt   x86_64 2.14.4-2.fc34   
> > rawhide497 k
> >  replacing  abrt.x86_64 2.14.2-5.fc33
> >  abrt-addon-ccppx86_64 2.14.4-2.fc34   
> > rawhide132 k
> >  replacing  abrt-addon-ccpp.x86_64 2.14.2-5.fc33
> >  abrt-addon-kerneloops  x86_64 2.14.4-2.fc34   
> > rawhide 50 k
> >  replacing  abrt-addon-kerneloops.x86_64 2.14.2-5.fc33
> >  abrt-addon-pstoreoops  x86_64 2.14.4-2.fc34   
> > rawhide 26 k
> >  replacing  abrt-addon-pstoreoops.x86_64 2.14.2-5.fc33
> >  abrt-addon-vmcore  x86_64 2.14.4-2.fc34   
> > rawhide 37 k
> >  replacing  abrt-addon-vmcore.x86_64 2.14.2-5.fc33
> >  abrt-addon-xorgx86_64 2.14.4-2.fc34   
> > rawhide 41 k
> >  replacing  abrt-addon-xorg.x86_64 2.14.2-5.fc33
> >  abrt-cli   x86_64 2.14.4-2.fc34   
> > rawhide 16 k
> >  abrt-dbus  x86_64 2.14.4-2.fc34   
> > rawhide 72 k
> >  replacing  abrt-dbus.x86_64 2.14.2-5.fc33
> >
> > Most packages that are upgraded are shown as "replacing" themselves. This is
> > technically true, but this mode of listing is very verbose. But not all 
> > packages
> > that are upgraded are listed like that, so I think there must be some 
> > additional
> > variable I'm missing?
> >
> > (This output takes a lot of space and is hard to scan quickly, so I can't 
> > say I
> > quite like it.)
> >
> > (dnf-4.2.23-2.fc33.noarch)
> >
> 
> "replacing" stanzas show up if Obsoletes are declared. That's how DNF
> tells you something is Obsoleting something else.

Not in this case. It turns out I had many duplicated packages on this system.
dnf seems to be saying that the upgrade is upgrading the newer
version of the package and removing the dup at the same time.
I think so, the output doesn't make this obvious.

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


new dnf mode of listing upgraded packages

2020-10-05 Thread Zbigniew Jędrzejewski-Szmek
On rawhide:
$ sudo dnf upgrade

 PackageArch   Version 
Repository  Size

Installing:
 kernel-corex86_64 5.9.0-0.rc7.20201002git.24.fc34 
fedora-rawhide-kernel-nodebug

   32 M
 kernel-modules x86_64 5.9.0-0.rc7.20201002git.24.fc34 
fedora-rawhide-kernel-nodebug

   30 M
Upgrading:
 NetworkManager x86_64 1:1.26.2-2.fc34 
rawhide2.2 M
 replacing  NetworkManager.x86_64 1:1.26.2-1.fc34.1
 NetworkManager-libnm   x86_64 1:1.26.2-2.fc34 
rawhide1.6 M
 replacing  NetworkManager-libnm.x86_64 1:1.26.2-1.fc34.1
 NetworkManager-teamx86_64 1:1.26.2-2.fc34 
rawhide 31 k
 replacing  NetworkManager-team.x86_64 1:1.26.2-1.fc34.1
 NetworkManager-wifix86_64 1:1.26.2-2.fc34 
rawhide 99 k
 replacing  NetworkManager-wifi.x86_64 1:1.26.2-1.fc34.1
 OpenIPMI-libs  x86_64 2.0.29-1.fc34   
rawhide524 k
 replacing  OpenIPMI-libs.x86_64 2.0.28-6.fc33
 abrt   x86_64 2.14.4-2.fc34   
rawhide497 k
 replacing  abrt.x86_64 2.14.2-5.fc33
 abrt-addon-ccppx86_64 2.14.4-2.fc34   
rawhide132 k
 replacing  abrt-addon-ccpp.x86_64 2.14.2-5.fc33
 abrt-addon-kerneloops  x86_64 2.14.4-2.fc34   
rawhide 50 k
 replacing  abrt-addon-kerneloops.x86_64 2.14.2-5.fc33
 abrt-addon-pstoreoops  x86_64 2.14.4-2.fc34   
rawhide 26 k
 replacing  abrt-addon-pstoreoops.x86_64 2.14.2-5.fc33
 abrt-addon-vmcore  x86_64 2.14.4-2.fc34   
rawhide 37 k
 replacing  abrt-addon-vmcore.x86_64 2.14.2-5.fc33
 abrt-addon-xorgx86_64 2.14.4-2.fc34   
rawhide 41 k
 replacing  abrt-addon-xorg.x86_64 2.14.2-5.fc33
 abrt-cli   x86_64 2.14.4-2.fc34   
rawhide 16 k
 abrt-dbus  x86_64 2.14.4-2.fc34   
rawhide 72 k
 replacing  abrt-dbus.x86_64 2.14.2-5.fc33

Most packages that are upgraded are shown as "replacing" themselves. This is
technically true, but this mode of listing is very verbose. But not all packages
that are upgraded are listed like that, so I think there must be some additional
variable I'm missing?

(This output takes a lot of space and is hard to scan quickly, so I can't say I
quite like it.)

(dnf-4.2.23-2.fc33.noarch)

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


how to list contents of a side tag?

2020-10-05 Thread Zbigniew Jędrzejewski-Szmek
I'd like to introspect a side tag:
'koji list-pkgs --tag f34-build-side-31299' lists many many packages.
'koji list-pkgs --noinherit --tag f34-build-side-31299' lists nothing.
Is there some command which would list packages that are in the side tag?
Also, is there a nice way to lists builds (failed or not, finished or not)
done against the side tag?

Zbyszek

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

2020-10-04 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Oct 05, 2020 at 01:53:03AM +0200, Alexander Ploumistos wrote:
> Hello everyone,
> 
> I've finally managed to find some time and get the latest Open Babel
> snapshot to build in F32 and rawhide. The spec file is ugly with a
> bunch of comments still in it and I've realized that documentation
> upstream is lacking, especially concerning build options and bindings.
> So far, I've enabled only the python bindings and I'm not sure what
> else is still available. There's also an icon file missing, but that's
> the least of our problems.
> If anyone's interested in taking a look, here's a scratch build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=52775710
> I've also set up a copr, where things are still building, though eln
> builds died almost instantly on all arches and the F32 armhfp builder
> ran out of space:
> https://copr.fedorainfracloud.org/coprs/alexpl/openbabel/
> 
> Going forward, there's a number of things we need to figure out, off
> the top of my head:
> - I suppose I could take over from Dominik (with the hope that not
> many things will break down in the following year) the packages in
> Fedora, but not EPEL and friends. Who wants to do that?
> - Has any of the maintainers of dependent packages that are dead-ish
> upstream looked at porting them to OB 3?
> - Do we create a new package, openbabel3, or do we rename the existing
> one openbabel2? How do we deal with the complications of having both
> of them around, especially since most of the binaries have the same
> name?
> 
> There were many more things in my head when I started writing this
> message, but they've somehow evaporated. I'm off to bed, please feel
> free to chime in.

I think it makes sense to add a new 'openbabel3' package. Like Kevin wrote
in the other mail, it seems likely that some packages will depend on
the old version for the foreseeable future. Python recently switched
to a theme where it the "main" package has a number in the version [1].
This works nicely when there are multiple incompatible versions...

(One alternative would be to rename openbabel→openbabel2, and use
openbabel for the new version. But this requires an extra rename
operation and potentially adjustments in all dependent packages. Seems
like a lot of busywork, with potential for blocking if some dependent
package FTBFS.)

> How do we deal with the complications of having both
> of them around, especially since most of the binaries have the same
> name?

Explicit Conflicts? Unless there's a strong need to install packages
in parallel, that seems like the easiest option.

Zbyszek

[1] https://src.fedoraproject.org/rpms/python3.9
___
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: Self Introduction: Fabrice BAUZAC-STEHLY

2020-10-03 Thread Zbigniew Jędrzejewski-Szmek
On Sat, Oct 03, 2020 at 09:22:52AM +0200, Fabrice BAUZAC-STEHLY wrote:
> Hello,
> 
> I wish to contribute, especially with packaging work.
> 
> I'm a 40-year-old programmer, GNU/Linux user since I'm 15, with
> knowledge about sysadmin, networking, Linux, C, Python, Perl...  And I
> like good technical documentation.  Recently I have started contributing
> some packaging work for Debian (python3-opentracing).  I'd like to
> continue, and not only for Debian but also for Fedora or EPEL8.

Hi Fabrice,

welcome to Fedora. Since you have some experience, you might want to start
by doing informal reviews of anything under
https://fedoraproject.org/PackageReviewStatus/reviewable.html. There's also
a number of SIGs concerned with more specific areas:
https://fedoraproject.org/wiki/Category:SIGs.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

2020-10-01 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Sep 30, 2020 at 11:50:00AM -0500, Michael Catanzaro wrote:
> On Wed, Sep 30, 2020 at 6:43 pm, Dominik 'Rathann' Mierzejewski
>  wrote:
> >What if I'm using NetworkManager and dnssec-trigger? This has been
> >working very well for me for the last couple of releases and I'd hate
> >to be forced to manually reconfigure things so that it starts working
> >again.
> 
> The upgrade process is designed to do the right thing for users who
> stick with our defaults. Manual intervention is required for unusual
> cases like this. You'll need to manually disable systemd-resolved
> after upgrade, restore /etc/resolv.conf from the backup file that
> will be created during upgrade, and restart NetworkManager. That
> would look something like:
> 
> # systemctl disable systemd-resolved.service
> # systmectl stop systemd-resolved.service
> # mv /etc/resolv.conf.orig-with-nm /etc/resolv.conf
> # systemctl restart NetworkManager.service

After the latest updates, this should not necessary (though it will still work).
Instead, specify a preset (before the upgrade):

 sudo bash -c 'mkdir -p /etc/systemd/system-preset && echo "disable 
systemd-resolved.service" 
>/etc/systemd/system-preset/20-systemd-resolved-disable.preset'

This is also described in
https://fedoraproject.org/wiki/Changes/systemd-resolved#Fully_opting_out_of_systemd-resolved_use

Zbyszek
___
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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-10-01 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Oct 01, 2020 at 12:08:19PM -0400, Paul Wouters wrote:
> Clearly, there is a case for making systemd-resolved "default with
> an option to opt-out". It makes no sense that these deployments
> must install and ensure to then disable and keep disabled, the
> systemd-resolved daemon.

I fully agree that an opt-out should be possible. I don't think anyone
suggested differently. On normal upgrades following the transition to F33,
nothing special needs to be done. The only exception is the first upgrade
to F33, where we reset systemd-resolved.service enablement and adjust
resolv.conf symlink. Those changes are conditionalized on
systemd-resolved.service being enabled in presets. To opt out, create
a local preset which disables systemd-resolved.

I now added a section about this to the Change page:
https://fedoraproject.org/w/index.php?title=Changes%2Fsystemd-resolved=revision=589756=588639

(There's also the question of changes to /etc/nsswitch.conf. Those are
currently done unconditionally based on the premise that nss-resolve
has no effect if systemd-resolved.service is not running. We can adjust
that too if needed.)

Zbyszek
___
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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-10-01 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Oct 01, 2020 at 12:55:40PM +0200, Petr Pisar wrote:
> On Wed, Sep 30, 2020 at 04:26:39PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > In addition, two more new subpackages are created: 
> > systemd-standalone-sysusers
> > and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and
> > systemd-tmpfiles binaries.
> 
> root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list systemd 
> |grep systemd-sysusers
> /usr/bin/systemd-sysusers
> /usr/lib/systemd/system/sysinit.target.wants/systemd-sysusers.service
> /usr/lib/systemd/system/systemd-sysusers.service
> /usr/share/man/man8/systemd-sysusers.8.gz
> /usr/share/man/man8/systemd-sysusers.service.8.gz
> root@fedora-34:~ # dnf --quiet repoquery --repo=f34-build --list 
> systemd-standalone-sysusers |grep systemd-sysusers
> /usr/bin/systemd-sysusers
> 
> I think systemd-standalone-sysusers package is missing the manual pages.

I think that's ok. The -standalone- packages are supposed to be minimal. Also, 
people
would use them in minimal images that are also missing man.

Zbyszek
___
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: Proven packager help needed to merge libevent 2.1.12 side tag

2020-10-01 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Oct 01, 2020 at 01:25:13PM +0200, Ondřej Lysoněk wrote:
> Fabio Valentini  writes:
> 
> > On Thu, Oct 1, 2020 at 11:37 AM Ondřej Lysoněk  wrote:
> >>
> >> Fabio Valentini  writes:
> >>
> >> > On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk  
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> So all the required rebuilds for the libevent 2.1.12 rebase should be
> >> >> done now in the side tag. I've tried to merge the side tag by creating
> >> >> an update in Bodhi as described in [1], but Bodhi tells me 'olysonek
> >> >> does not have commit access rights to ...'. So I guess I'll need proven
> >> >> packager help again.
> >> >>
> >> >> Can someone please merge the f34-build-side-30069 side tag?
> >> >>
> >> >> Thanks!
> >> >
> >> > Done!
> >> >
> >> > $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update
> >> > libevent to version 2.1.12. This update includes a rebuild of
> >> > dependent packages due to an soname bump."
> >> >
> >> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2
> >>
> >> Thanks, Fabio.
> >>
> >> I just noticed that it says in the update that it cannot be pushed:
> >> "This update cannot be pushed to stable. These builds
> >> community-mysql-8.0.21-12.fc34 have a more recent build in koji's f34
> >> tag."
> >>
> >> And indeed, community-mysql has been "rebuilt for protobuf 3.13" in F34
> >> after it has been rebuilt in the libevent side tag.
> >>
> >> Not sure what we should do about it. Should we perhaps pull in the new
> >> protobuf into the libevent side tag and rebuild community-mysql again?
> >
> > Ugh. Has the new protobuf been merged into rawhide yet, or is it still
> > in its own side tag?
> 
> It has been merged as far as I can tell.
> 
> > If it's already merged to rawhide, you can just submit another rebuild
> > of community-mysql for your own side tag, and I can hopefully refresh
> > the bodhi update.
> 
> Oh, right. The new protobuf will appear in my side tag by inheritance,
> correct? Great.
> 
> community-mysql owners, please rebuild your package once more in the
> side tag:
> 
> fedpkg build --target=f34-build-side-30069

It's building.

Zbyszek
___
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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-10-01 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Oct 01, 2020 at 11:05:18AM +0200, Petr Menšík wrote:
> 
> 
> On 9/30/20 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote:
> >> On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
> >>
> >>> the systemd package is getting a systemd-networkd subpackage split out
> >>> that will contain systemd-networkd, networkctl, and the associated data 
> >>> files.
> >>> This was requested by coreos maintainers: NetworkManager is used and 
> >>> skipping
> >>> systemd-networkd allows the installation footprint and potential user 
> >>> confusion
> >>> to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.)
> >>
> >>> The main systemd systemd package Obsoletes the -standalone- packages, so 
> >>> it
> >>> should smoothly replace them whenever it is pulled in.
> >>
> >> In which package will systemd-resolved be?
> > 
> > Still in the main rpm. I don't see a good reason to split it out. It
> > can be installed without being enabled (*). And with it being enabled by 
> > default
> > in F33, there's even less reason to do so. networkd is a few times larger 
> > and
> > likely to grow (we're adding support for new tunnel types, new protocols,
> > and new features all the time. systemd-resolved shouldn't grow too much
> > beyond current size.)
> Why is it important to require resolved in main package? 

See the extensive replies from Neal Gompa in the other part of the thread.
Each split brings a maintenance cost and cognitive overhead for users.
So the question is always "why should we split this out", and not "why 
shouldn't we"?
Even for the -networkd it's almost a wash. We split it out to undo a
long-standing problem in coreos. Without that preexisting history [1],
it wouldn't have been split out. Thankfully we don't have a similar situation
with resolved.

> It contains
> both daemon and lookup tool, couple of bash completion scripts and
> manual pages. Reason to split it out was stated already: some people
> won't be using it. It is not so small, 650k deserves own package IMHO.

It's a judgment call. Apart from the problems mentioned above, since
it is a default in F33+ now, after splitting it out we'd need to make
sure that it is almost always pulled in. Sorry, no, that's too much fragility
to save <1MB.

Zbyszek

[1] https://github.com/coreos/fedora-coreos-config/pull/574
___
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: Proven packager help needed to merge libevent 2.1.12 side tag

2020-10-01 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Oct 01, 2020 at 10:32:44AM +0200, Fabio Valentini wrote:
> On Thu, Oct 1, 2020 at 10:27 AM Ondřej Lysoněk  wrote:
> >
> > Hi,
> >
> > So all the required rebuilds for the libevent 2.1.12 rebase should be
> > done now in the side tag. I've tried to merge the side tag by creating
> > an update in Bodhi as described in [1], but Bodhi tells me 'olysonek
> > does not have commit access rights to ...'. So I guess I'll need proven
> > packager help again.
> >
> > Can someone please merge the f34-build-side-30069 side tag?
> >
> > Thanks!
> 
> Done!
> 
> $ bodhi updates new f34-build-side-30069 --from-tag --notes "Update
> libevent to version 2.1.12. This update includes a rebuild of
> dependent packages due to an soname bump."
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-647133cbf2

BTW, the intructions say:
Once you have built all the packages in your side-tag, you can create the bodhi 
update for this side-tag using either:
- the bodhi web UI, in the new update form use the Use Side Tag button
- the bodhi CLI bodhi updates new --from-tag

So the second option works. But I don't see any "Use Side Tag button"
under https://bodhi.fedoraproject.org/updates/new. Am I looking in the
wrong place?

Zbyszek
___
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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Sep 30, 2020 at 01:45:13PM -0700, PGNet Dev wrote:
> anyone else more confused?
> 
> On 9/30/20 1:26 PM, Neal Gompa wrote:
> > And like it or not, all our legacy network configuration mechanisms
> > are deprecated and*will be removed eventually*.
> 
> is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct 
> dependency on systemd-resolved -- considered 'legacy'?

NM does not wrap systemd-networkd. Both remain fully independent ways
to configure networking. The future of systemd-networkd is unclear: it
is being developed upstream, but is largely unused in Fedora. It does
work well in certain scenarios, as you know. I don't think there's any
plan to change this.

> > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
>  variants, as shipped today, *MUST* use NetworkManager.
> 
> how 'bout I turn the question around ...
> 
> what specific steps must be done POST- F32->F32 upgrade to
> 
>   (1) not use NetworkManager
>   (2) not use systemd-resolved
> 
>   (3) return/preserve local configs for systemd-networkd & 'enterprise' 
> (own resolver) DNS configs?

I don't think there's anything special needed for (1) and (3). For (2),
please create a preset to disable systemd-resolved. E.g.:
  echo 'disable systemd-resolved.service' 
>/etc/systemd/system-preset/20-resolved.preset

This will start being enough with the next systemd build though. I just pushed 
a change
to not create the symlink if resolved is disabled:
https://src.fedoraproject.org/rpms/systemd/c/d3d43af8adf70974f5e52d31df0b46935ff2ded2?branch=f33.

Zbyszek
___
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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Sep 30, 2020 at 12:59:20PM -0400, Matthew Miller wrote:
> On Wed, Sep 30, 2020 at 06:50:08PM +0200, Miro Hrončok wrote:
> > >The main systemd systemd package Obsoletes the -standalone- packages, so it
> > >should smoothly replace them whenever it is pulled in.
> > 
> > I am confused by this bit. If systemd package Obsoletes the
> > -standalone- packages, installing them is not possible unless you
> > explicitly exclude systemd from the transaction and keep it excluded
> > for upgrades.
> 
> I expect so, if the use case is containers that will be replaced instead of
> upgraded.

The idea is that if you have an installation which does not need systemd,
but want sysusers or tmpfiles, then you can pull in the -standalone- versions.
They both have files that conflict with the main package, and declare Conflicts
with it.

Zbyszek
___
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: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote:
> On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
> 
> >the systemd package is getting a systemd-networkd subpackage split out
> >that will contain systemd-networkd, networkctl, and the associated data 
> >files.
> >This was requested by coreos maintainers: NetworkManager is used and skipping
> >systemd-networkd allows the installation footprint and potential user 
> >confusion
> >to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.)
> 
> >The main systemd systemd package Obsoletes the -standalone- packages, so it
> >should smoothly replace them whenever it is pulled in.
> 
> In which package will systemd-resolved be?

Still in the main rpm. I don't see a good reason to split it out. It
can be installed without being enabled (*). And with it being enabled by default
in F33, there's even less reason to do so. networkd is a few times larger and
likely to grow (we're adding support for new tunnel types, new protocols,
and new features all the time. systemd-resolved shouldn't grow too much
beyond current size.)

(*) In general, allowing packages to be installed without being active
is much more robust. If we are depending on a package not being
present, it is easy for things go south if something pulls it in as
dependency, and we have huge dependency trees, it's sometimes it's impossible
to uninstall something because of transitive dependencies.

Package need to have a reliable way to preconfigure if they will
become active after installation. In fact we already built a system like this
presets.

But I see you point: it should be possible to opt out of systemd-resolved,
and right now that's not entirely functional, because presets only decide
whether systemd-resolved.service will be enabled, and the resolv.conf symlink
manipulation is not conditionalized on that. I'll make it conditional too.

Zbyszek

> With enterprise server deployments, DNS will be managed by the network
> via resolve.conf to enterprise DNS servers. These servers tend to have
> "bind views" for different category of deployments. These deployments
> will have no VPN, no mDNS requirements etc. They also do not need (and
> most likely do not want) DNS caching.
> 
> I believe it would be useful for kickstart installs to not install
> systemd-resolved for these kind of typical server deployments. I think
> this is an important use case to support.
> 
> For Desktop systems, it could default to installing systemd-resolved. It
> could even default to it for all installs including Server, as long as
> the administrator has the option to not install it via a kickstart file.
> 
> It also allows those Destop users that want to use their own validating
> resolvers on the end node to uninstall systemd-resolved.
> 
> If there are strong reasons not to split systemd-resolved in its own
> package, I would like to better understand these reasons.
> 
> Paul
> ___
> 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


splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+

2020-09-30 Thread Zbigniew Jędrzejewski-Szmek
Hi,

the systemd package is getting a systemd-networkd subpackage split out
that will contain systemd-networkd, networkctl, and the associated data files.
This was requested by coreos maintainers: NetworkManager is used and skipping
systemd-networkd allows the installation footprint and potential user confusion
to be reduced a bit. (By 1.6 MB and an unknown amount, respectively.)

Appropriate Obsoletes are added on both the main package and the new
systemd-networkd subpackage, so the systemd-networkd subpackage should
be installed on upgrades. In addition, the new subpackage has Recommends from
the main package, so it will be installed in normal installations. The split
affects installations with --setopt=install_weak_deps=False. Please make sure
to pull in systemd-networkd.rpm independently if needed. Also note that
systemd-networkd.service was preset as *disabled* in Fedora, which means that
unless it was enabled by the user, the removal of systemd-networkd wouldn't
have an effect.

In addition, two more new subpackages are created: systemd-standalone-sysusers
and systemd-standalone-tmpfiles, with custom-linked systemd-sysusers and
systemd-tmpfiles binaries. They packages are 170kB and 260kB and pull in much
less dependencies compared to the normal systemd package (only glibc, 
libselinux,
and libacl). The goal here is to be able to use those packages in limited
environments where systemd itself is not necessary.

The main systemd systemd package Obsoletes the -standalone- packages, so it
should smoothly replace them whenever it is pulled in.

This change was done in systemd-246.6-2.fc34 in rawhide right now. (There are
some cleanups to move more files to the -networkd subpackage in the works for
246.6-3.fc34). Please give this a spin and report any issues.

The plan is to also do this split for F33 if no issues are noted in rawhide.

Zbyszek
___
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: LTO and F33

2020-09-30 Thread Zbigniew Jędrzejewski-Szmek
I pushed the following to fix build of sems:
https://src.fedoraproject.org/rpms/sems/c/beef747b4641429459065bd39dbea447405f33e9?branch=master
Not my package, and the code is a bit iffy, so it's quite likely that
the problem is in the package... Just letting you know in case you're still
looking for failures.

Zbyszek
___
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: Proven packager help needed to rebuild packages

2020-09-30 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Sep 30, 2020 at 11:00:46AM +0200, Ondřej Lysoněk wrote:
> Zbigniew Jędrzejewski-Szmek  writes:
> 
> > On Wed, Sep 30, 2020 at 10:32:28AM +0200, Ondřej Lysoněk wrote:
> >> Zbigniew Jędrzejewski-Szmek  writes:
> >> 
> >> > On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek 
> >> > wrote:
> >> >> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote:
> >> >> > Hi,
> >> >> > 
> >> >> > I'm coordinating rebuilds of packages due to the libevent rebase [1]
> >> >> > and I'm having trouble reaching owners of some of the packages. Is
> >> >> > there a proven packager willing to help me with the rebuilds?
> >> >> > 
> >> >> > The rebuilds should be done using the following command:
> >> >> > 
> >> >> > fedpkg build --target=f34-build-side-30069
> >> >> 
> >> >> I started the builds now. Unfortunately quite a few have failed.
> >> >> In general fedpkg build --target=f34-build-side-30069 --nowait
> >> >> seems to take a lot of time, sometimes maybe a minute.
> >> >> 
> >> >> > The following packages need to be rebuilt. Note that it is expected
> >> >> > that 'sems' will fail to build, however I think we should try anyway.
> >> >> > 
> >> >> > 389-ds-base
> >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=52468873 failed
> >> >> BuildError: Error running GIT command "git clone -n 
> >> >> https://src.fedoraproject.org/rpms/389-ds-base.git 
> >> >> /var/lib/mock/f34-build-side-30069-23090650-2165901/root/chroot_tmpdir/scmroot/389-ds-base",
> >> >>  see checkout.log for details
> >> >> 
> >> >> I restarted the build, let's see how it does:
> >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=52470545
> >> >> 
> >> >> > ccnet
> >> >> > groonga
> >> >> failed with error:
> >> >> attempt to use unversioned python, define %__python to /usr/bin/python2 
> >> >> or /usr/bin/python3 explicitly
> >> >> error: groonga.spec: line 2: Macro %__provides_exclude_from failed to 
> >> >> expand
> >> >> error: query of specfile groonga.spec failed, can't parse
> >> >> 
> >> >> > links
> >> >> > lldpd
> >> >> > mpris-scrobbler
> >> >> > nbd-runner
> >> >> > netatalk
> >> >> > nsd
> >> >> > perl-Event-Lib
> >> >> > pgbouncer
> >> >> After starting the build I saw that it was already rebuilt:
> >> >> * Tue Sep 29 20:42:50 CEST 2020 Zbigniew Jędrzejewski-Szmek 
> >> >>  - 1.14.0-5
> >> >> - Rebuilt for libevent 2.1.12
> >> >>  
> >> >> * Tue Sep 15 2020 Devrim Gündüz  - 1.14.0-4
> >> >> - Rebuild against new libevent
> >> >> 
> >> >> An additional build probably doesn't hurt.
> >> >> 
> >> >> > remctl
> >> >> > seafile
> >> >> > sems
> >> >> > sslsplit
> >> >> > sstp-client
> >> >> > tmate
> >> >> > trickle
> >> >
> >> > They all built after some pushing and prodding, with the exception of 
> >> > sems:
> >> 
> >> Thank you very much, Zbyszek! Can you please also rebuild scanssh? It
> >> was not on my original list, but it looks like I'll need help with it
> >> too.
> >
> > It's building now.
> >
> > What next: is the side tag ready to merge? Will you do it or should I?
> 
> We're still working on rebuilding libreswan and transmission. I expect
> it to be ready within a couple of days, possibly even today. If I have
> the necessary rights to merge it, I'll do it myself. I'll reach out if I
> need any more help.

I also built sems now, there and for F33.

Zbyszek
___
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: Proven packager help needed to rebuild packages

2020-09-30 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Sep 30, 2020 at 10:32:28AM +0200, Ondřej Lysoněk wrote:
> Zbigniew Jędrzejewski-Szmek  writes:
> 
> > On Tue, Sep 29, 2020 at 06:46:49PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> >> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote:
> >> > Hi,
> >> > 
> >> > I'm coordinating rebuilds of packages due to the libevent rebase [1]
> >> > and I'm having trouble reaching owners of some of the packages. Is
> >> > there a proven packager willing to help me with the rebuilds?
> >> > 
> >> > The rebuilds should be done using the following command:
> >> > 
> >> > fedpkg build --target=f34-build-side-30069
> >> 
> >> I started the builds now. Unfortunately quite a few have failed.
> >> In general fedpkg build --target=f34-build-side-30069 --nowait
> >> seems to take a lot of time, sometimes maybe a minute.
> >> 
> >> > The following packages need to be rebuilt. Note that it is expected
> >> > that 'sems' will fail to build, however I think we should try anyway.
> >> > 
> >> > 389-ds-base
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=52468873 failed
> >> BuildError: Error running GIT command "git clone -n 
> >> https://src.fedoraproject.org/rpms/389-ds-base.git 
> >> /var/lib/mock/f34-build-side-30069-23090650-2165901/root/chroot_tmpdir/scmroot/389-ds-base",
> >>  see checkout.log for details
> >> 
> >> I restarted the build, let's see how it does:
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=52470545
> >> 
> >> > ccnet
> >> > groonga
> >> failed with error:
> >> attempt to use unversioned python, define %__python to /usr/bin/python2 or 
> >> /usr/bin/python3 explicitly
> >> error: groonga.spec: line 2: Macro %__provides_exclude_from failed to 
> >> expand
> >> error: query of specfile groonga.spec failed, can't parse
> >> 
> >> > links
> >> > lldpd
> >> > mpris-scrobbler
> >> > nbd-runner
> >> > netatalk
> >> > nsd
> >> > perl-Event-Lib
> >> > pgbouncer
> >> After starting the build I saw that it was already rebuilt:
> >> * Tue Sep 29 20:42:50 CEST 2020 Zbigniew Jędrzejewski-Szmek 
> >>  - 1.14.0-5
> >> - Rebuilt for libevent 2.1.12
> >>  
> >> * Tue Sep 15 2020 Devrim Gündüz  - 1.14.0-4
> >> - Rebuild against new libevent
> >> 
> >> An additional build probably doesn't hurt.
> >> 
> >> > remctl
> >> > seafile
> >> > sems
> >> > sslsplit
> >> > sstp-client
> >> > tmate
> >> > trickle
> >
> > They all built after some pushing and prodding, with the exception of sems:
> 
> Thank you very much, Zbyszek! Can you please also rebuild scanssh? It
> was not on my original list, but it looks like I'll need help with it
> too.

It's building now.

What next: is the side tag ready to merge? Will you do it or should I?

Zbyszek
___
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: Proven packager help needed to rebuild packages

2020-09-29 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote:
> > Hi,
> > 
> > I'm coordinating rebuilds of packages due to the libevent rebase [1]
> > and I'm having trouble reaching owners of some of the packages. Is
> > there a proven packager willing to help me with the rebuilds?
> > 
> > The rebuilds should be done using the following command:
> > 
> > fedpkg build --target=f34-build-side-30069
> 
> I started the builds now. Unfortunately quite a few have failed.
> In general fedpkg build --target=f34-build-side-30069 --nowait
> seems to take a lot of time, sometimes maybe a minute.
> 
> > The following packages need to be rebuilt. Note that it is expected
> > that 'sems' will fail to build, however I think we should try anyway.
> > 
> > 389-ds-base
> https://koji.fedoraproject.org/koji/taskinfo?taskID=52468873 failed
> BuildError: Error running GIT command "git clone -n 
> https://src.fedoraproject.org/rpms/389-ds-base.git 
> /var/lib/mock/f34-build-side-30069-23090650-2165901/root/chroot_tmpdir/scmroot/389-ds-base",
>  see checkout.log for details
> 
> I restarted the build, let's see how it does:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=52470545
> 
> > ccnet
> > groonga
> failed with error:
> attempt to use unversioned python, define %__python to /usr/bin/python2 or 
> /usr/bin/python3 explicitly
> error: groonga.spec: line 2: Macro %__provides_exclude_from failed to expand
> error: query of specfile groonga.spec failed, can't parse
> 
> > links
> > lldpd
> > mpris-scrobbler
> > nbd-runner
> > netatalk
> > nsd
> > perl-Event-Lib
> > pgbouncer
> After starting the build I saw that it was already rebuilt:
> * Tue Sep 29 20:42:50 CEST 2020 Zbigniew Jędrzejewski-Szmek 
>  - 1.14.0-5
> - Rebuilt for libevent 2.1.12
>  
> * Tue Sep 15 2020 Devrim Gündüz  - 1.14.0-4
> - Rebuild against new libevent
> 
> An additional build probably doesn't hurt.
> 
> > remctl
> > seafile
> > sems
> > sslsplit
> > sstp-client
> > tmate
> > trickle

They all built after some pushing and prodding, with the exception of sems:

In file included from EarlyAnnounce.cpp:27:
EarlyAnnounce.h:37:10: fatal error: cppconn/driver.h: No such file or directory
   37 | #include 
  |  ^~

I looked online and this file seems to be provided by 
mysql-connector-c++-devel.rpm
in some other places, but not in Fedora. We don't seem to have this library at 
all...
Can someone who knows mysql confirm?

Zbyszek
___
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: Proven packager help needed to rebuild packages

2020-09-29 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote:
> Hi,
> 
> I'm coordinating rebuilds of packages due to the libevent rebase [1]
> and I'm having trouble reaching owners of some of the packages. Is
> there a proven packager willing to help me with the rebuilds?
> 
> The rebuilds should be done using the following command:
> 
> fedpkg build --target=f34-build-side-30069

I started the builds now. Unfortunately quite a few have failed.
In general fedpkg build --target=f34-build-side-30069 --nowait
seems to take a lot of time, sometimes maybe a minute.

> The following packages need to be rebuilt. Note that it is expected
> that 'sems' will fail to build, however I think we should try anyway.
> 
> 389-ds-base
https://koji.fedoraproject.org/koji/taskinfo?taskID=52468873 failed
BuildError: Error running GIT command "git clone -n 
https://src.fedoraproject.org/rpms/389-ds-base.git 
/var/lib/mock/f34-build-side-30069-23090650-2165901/root/chroot_tmpdir/scmroot/389-ds-base",
 see checkout.log for details

I restarted the build, let's see how it does:
https://koji.fedoraproject.org/koji/taskinfo?taskID=52470545

> ccnet
> groonga
failed with error:
attempt to use unversioned python, define %__python to /usr/bin/python2 or 
/usr/bin/python3 explicitly
error: groonga.spec: line 2: Macro %__provides_exclude_from failed to expand
error: query of specfile groonga.spec failed, can't parse

> links
> lldpd
> mpris-scrobbler
> nbd-runner
> netatalk
> nsd
> perl-Event-Lib
> pgbouncer
After starting the build I saw that it was already rebuilt:
* Tue Sep 29 20:42:50 CEST 2020 Zbigniew Jędrzejewski-Szmek  
- 1.14.0-5
- Rebuilt for libevent 2.1.12
 
* Tue Sep 15 2020 Devrim Gündüz  - 1.14.0-4
- Rebuild against new libevent

An additional build probably doesn't hurt.

> remctl
> seafile
> sems
> sslsplit
> sstp-client
> tmate
> trickle

Zbyszek
___
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: Proposal: drop extras-qa from all fedora bugs

2020-09-29 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 29, 2020 at 10:17:51AM -0700, Kevin Fenzi wrote:
> On Tue, Sep 29, 2020 at 07:03:29PM +0200, Pierre-Yves Chibon wrote:
> > On Tue, Sep 29, 2020 at 09:30:45AM -0700, Kevin Fenzi wrote:
> > > Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> > > "QA Contact" field set to: extras...@fedoraproject.org.
> > > 
> > > Bugzilla describes "QA Contact" as: 
> > > 
> > > "The person responsible for confirming this bug if it is unconfirmed,
> > > and for verifying the fix once the bug has been resolved."
> > > 
> > > However, also since at least 2007-04-20 emails to that address go to
> > > /dev/null. (Before that they went to a linux.duke.edu address, so I am
> > > not sure where they went). 

Should we be so hasty? If has worked well without causing any problems
for so many years.

> > > I'd like to propose dropping this from all Fedora bugs. 
> > > 
> > > It's a useless extra email that bugzilla has to generate, network has to
> > > send and deliver and we have to drop in the bitbucket. 
> > > 
> > > But, perhaps there's some secret clever use for it I am not aware of?
> > > 
> > > If you can think of some reason to keep it, speak up. ;) 
> > 
> > +1 for me. Just to be sure, bugzilla doesn't require such contact to be set?
> 
> I tested that on partner-bugzilla and it didn't care if it was unset. 
> 
> I guess the quiet way to do this is just modify the sync script so it
> drops it from all packages for new bugs, then if we want later go back
> and remove it from existing bugs if we want to. 
> 
> kevin

(The above was just a joke, +1 of course.)

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 29, 2020 at 07:27:37AM -0700, Kevin Fenzi wrote:
> On Mon, Sep 28, 2020 at 10:38:27AM -0700, Erich Eickmeyer wrote:
> > 
> > 
> > This entire discussion is generating enough emails per hour to be an IRC
> > discussion. Could we please move this discussion to #fedora-devel or
> > someplace more appropriate?
> 
> Well, not everyone is on IRC, and email is sometimes a better medium for
> longer discussions. 
> 
> Sometimes this list just has a really high volume of emails. ;( 

Yeah. This is a complicated subject. IRC is not good for multi paragraph
questions and answers and clarifications.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 02:20:46PM -0400, Simo Sorce wrote:
> On Mon, 2020-09-28 at 13:32 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> > > On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > Instructions were already posted by Vitaly, so I won't repeat that here.
> > > > I'll just note that the scriptlet in systemd.rpm looks for
> > > > 'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> > > > the file is autogenerated.
> > > 
> > > Which is a terrible idea, as has been previously mentioned.  It really
> > > only indicates that the file was once touched my NetworkManager, not
> > > that it is currently managed.
> > > 
> > > If often let Anaconda set up a new system witha  NetworkManager-managed
> > > DHCP and then convert to a legacy network scripts-managed static IP
> > > later.  This doesn't change the DNS server or domain, so I don't bother
> > > editing resolv.conf to remove this comment.  I'm relatively certain that
> > > this is a common pattern.
> > 
> > Yeah, that test is far from ideal, but we need something. If you have
> > a constructive proposal how to improve it, I'm all ears.
> 
> Check if Network Manager is actually enabled as well ?

Makes sense:
https://src.fedoraproject.org/rpms/systemd/c/f3f602da25b51caaa188e02003f3db94a0dfadec?branch=f33
https://src.fedoraproject.org/rpms/systemd/c/39055121170430fa599f454533543cec89a79a58?branch=master

Zbyszek
___
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: GNU Guix

2020-09-29 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 29, 2020 at 06:26:46AM -0700, Kevin Fenzi wrote:
> On Tue, Sep 29, 2020 at 11:12:40AM +, Cuckoo's Calling via devel wrote:
> > Hello All,
> > 
> > I came across an amazing project called GNU Guix.
> > 
> > So, I made an animation to introduce the novel concepts of this project.
> > 
> > Here is the link for the video,
> > https://gnuguix-drive.mycozy.cloud/public?sharecode=YvERPGX14g5S
> > 
> > Please leave me a feedback on your experience.
> 
> This is not on topic for the fedora-devel list. 

I think that's just spam. There were more posts in unrelated threads.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 29, 2020 at 10:27:37AM +0200, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> > https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
> > in this particular case.
> 
> I looked at this extensively a couple of months ago.  There is also an
> ICANN recommendation along similar lines, but focusing more on stub
> resolver configuration and search path processing, which is a better fit
> for systemd-resolved.
> 
> The feedback I received from subject matter experts is that complying
> with these ICANN recommendations (for search path processing) would
> break about 60% of all deployed Kubernetes clusters (and not just inside
> containers).  I think some people have since started on updating
> Kubernetes practices and recommendations, but I expect that it will be a
> few more months until we see first effects.

No, I don't think anyone did this kind of research. But Kubernetes was a (the?)
primary motivation to optionally allow dotless lookups. (The assumption is
that if you're running k8s, you are not just going to install latest Fedora
there, but would do local configuration for the deployment anyway and can
include the override.)

> One problem with DNS is that you cannot take the standards and official
> recommendations and use them as a reference for a new DNS
> implementation.  Many of the specifications are very old, some are quite
> poor, several of the sub-protocols are very badly designed (like using
> timeouts for protocol version negotiation; obviously that one never made
> it into an RFC, but was still widely deployed), and the entire space is
> extremely politicized.  Not just by governments, but also by groups of
> individuals who for some reason cannot get along at all.

Yes, sadly.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote:
> On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro wrote:
> > You can do this, but again, you need to use the command line. E.g. 
> > 'resolvectl dns tun0 8.8.8.8'
> > 
> > We're actually no longer debating how systemd-resolved works; rather, 
> > we're now debating how NetworkManager chooses to configure 
> > systemd-resolved. systemd-resolved just does what it's told to do. It's 
> > actually NetworkManager that decides to split DNS according to routing 
> > by default as a matter of policy. It could do otherwise if it wanted 
> > to, but I think this is a good default. Nothing stops you from changing 
> > it though. :)
> 
> Michael,
> By what mechanism does NetworkManager "split DNS according to routing"? If it 
> hasn't already made a request from both your cleartext and your VPN 
> connection's DNS servers, it has no way of knowing what network should be 
> used 
> to get the right results. Routing and DNS are unrelated.

NetworkManager pushes DNS server configuration (and associated bits like domain
search and routing domains) over dbus to resolved. That way it "[tells resolved 
how
to] split DNS according to routing". Of course, after the name has been resolved
to an IP address, the packets to that IP address are routed too. So there is
"routing" in the sense of deciding which interface is appropriate for a given
DNS name and "routing" in the sense of deciding which interface is appropriate
for a given IP address.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 01:14:14PM -0400, Robbie Harwood wrote:
> Zbigniew Jędrzejewski-Szmek  writes:
> 
> > Pfff, now I'm confused. Here is a case where systemd-resolved
> > implements the standard, and some people were unhappy because they
> > were relying on sloppy implementations which don't follow the RFC.
> 
> Yes, welcome to software development!
> 
> Sometimes people care about the standard and sometimes the standard
> isn't helpful.  You can bemoan it, or belittle the users as you are
> doing here, but *that's how it is*.

I agree, but I was replying to a mail which said that systemd-resolved does
not follow the standard. In *this* particular case, that complaint is off
target.

> The only way you can find out which
> approach to take is to *figure out what the people in the space
> expect*.  In other words, it requires human contact and understanding of
> the problems - not just guessing in a vacuum.

There is more than one space... and different people have different
expectations. What systemd-resolved was doing seems the appropriate
thing for 90% of cases, but we also implemented an opt-in for the
other behaviour. So I don't think you're being fair when you're saying
"[I] bemoan it, or belittle the users", since I implemented the opt-in and
I didn't even say anything about the users.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 01:15:36PM -0400, Stephen John Smoogen wrote:
> On Mon, 28 Sep 2020 at 13:05, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> > > After reading https://github.com/systemd/systemd/issues/8967, I really
> > > don't think that systemd-resolved's benefits outweigh its harms as a
> > > default resolver for Fedora.  If someone wants to write a
> > > libfriendlydnsresolver and encourage/patch programs to use it instead of
> > > using glibc's resolver or reading resolv.conf, then that could be debated
> > > on its merits.  But the actual contents of /etc/resolv.conf should follow
> > > the relevant standards, and systemd-resolved does not.
> > >
> > > Perhaps systemd-resolved could change its mind and decide to comply with
> > > all relevant standards.  But until then, it seems inappropriate to me for
> > > it to be the default in Fedora.
> >
> > Pfff, now I'm confused. Here is a case where systemd-resolved implements
> > the
> > standard, and some people were unhappy because they were relying on sloppy
> > implementations which don't follow the RFC. Nevertheless, we added an
> > opt-in
> > switch to make this work. (Since this feature mostly matters in "special"
> > setups like k8s, where you need to do a lot of local setup anyway,
> > requiring
> > a one-line option seems to be reasonable).
> >
> 
> Hey for those of us in the peanuts gallery watching this play out.. could
> each of you point out which standards and RFC you are complying too. There
> are a lot of ones and funny enough.. they don't all agree with each other
> at times.

https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
in this particular case.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> After reading https://github.com/systemd/systemd/issues/8967, I really
> don't think that systemd-resolved's benefits outweigh its harms as a
> default resolver for Fedora.  If someone wants to write a
> libfriendlydnsresolver and encourage/patch programs to use it instead of
> using glibc's resolver or reading resolv.conf, then that could be debated
> on its merits.  But the actual contents of /etc/resolv.conf should follow
> the relevant standards, and systemd-resolved does not.
> 
> Perhaps systemd-resolved could change its mind and decide to comply with
> all relevant standards.  But until then, it seems inappropriate to me for
> it to be the default in Fedora.

Pfff, now I'm confused. Here is a case where systemd-resolved implements the
standard, and some people were unhappy because they were relying on sloppy
implementations which don't follow the RFC. Nevertheless, we added an opt-in
switch to make this work. (Since this feature mostly matters in "special"
setups like k8s, where you need to do a lot of local setup anyway, requiring
a one-line option seems to be reasonable).

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> * Andrew Lutomirski:
> 
> > Paul may well have been mixing different things here, but I don't
> > think you answered the one that seems like the most severe problem:
> > systemd-resolved removed perfectly valid DNSSEC records that were
> > supplied by the upstream server.  One might reasonably debate whether
> > Fedora's default DNS resolver configuration should validate DNSSEC,
> > but I think it should honor the DO bit in client requests and return
> > DNSSEC data.
> 
> FWIW, this is .

In an ideal world, we would just implement this missing functionality.
It's definitely on the TODO list, and there has been some preparatory
work done, but so far nobody found the time. If this is judged necessary,
we'll raise the priority of that work. Nevertheless, I don't think it is
such high priority — the number of people using DNSSEC is not too large,
and they are generally power-users who understand how to specify a different
server. So while definitely annoying, I didn't consider this a deal-breaker.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >Instructions were already posted by Vitaly, so I won't repeat that here.
> >I'll just note that the scriptlet in systemd.rpm looks for
> >'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> >the file is autogenerated.
> 
> Which is a terrible idea, as has been previously mentioned.  It really
> only indicates that the file was once touched my NetworkManager, not
> that it is currently managed.
> 
> If often let Anaconda set up a new system witha  NetworkManager-managed
> DHCP and then convert to a legacy network scripts-managed static IP
> later.  This doesn't change the DNS server or domain, so I don't bother
> editing resolv.conf to remove this comment.  I'm relatively certain that
> this is a common pattern.

Yeah, that test is far from ideal, but we need something. If you have
a constructive proposal how to improve it, I'm all ears.

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 01:45:02PM +0100, Tom Hughes wrote:
> On 28/09/2020 12:47, Zbigniew Jędrzejewski-Szmek wrote:
> 
> >You're mixing a few different things here. We decided to not enable
> >DNSSEC in resolved with this change, at least initially. For most
> >users, DNSSEC is problematic because various intermediary DNS servers
> >found in hotspots and routers don't support DNSSEC properly, leading
> >to hard-to-debug validation failures. DNSSEC support in resolved can
> >be enabled through resolved.conf. This may be a reasonable thing to do in
> >an environment where the configured dns servers are known to support dnssec
> >properly.
> 
> Well you're not just "not enabling it" really, for people like me that
> have already made the switch to systemd-resolved (in large part in
> search of better DNSSEC support) you're actually disabling it...
> 
> Having as I said experienced the trauma of trying to get DNSSEC working
> reliably I do understand how hard a problem is it however. I just need
> to remember to start adding a dropin to enable it again ;-)

What was the setup you were using? If this is something that we can
reliably detect, I think it it would make sense to adjust the scriptlet
that enables systemd-resolved to print a hint about needing to set DNSSEC=yes.
(Or maybe even set that itself?).

Zbyszek
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
> 
> >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
> 
> I was just hit by the first bug in systemd-resolved 4 days after I
> upgraded to fedora33. I will file a bug report for that, but I wanted
> to discuss something more fundamental.
> 
> systemd-resolved has a number of architectural flaws. When these were
> pointed out, bugs are not accepted and closed or ignored. Worse, I
> was told that systemd-resolved would not become the system DNS resolver,
> so I could just choose to not use it.
> 
> Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
> to systemd-resolved. I want to remove it from my system, but I cannot
> because it is not even a sub-package of systemd, it is part of the
> core systemd package. This goes against promises made in the past.

Hi,

in the end we decided to do a one-time "upgrade" of /etc/resolv.conf
through a scriptlet. Two reasons: one, the configuration is split between
/etc/resolv.conf, /etc/nsswitch.conf, and the enablement state of
systemd-resolved.service. We were already adjusting the other two, and
leaving old /etc/resolv.conf would likely lead to user confusion.
Also, without adjusting of /etc/resolv.conf, newly installed systems would be
different than upgraded ones in this fundamental regard. Overall, we think
it'll be better for users who don't care about the details of the dns
stack to fully swich to the new default. Power users and special setups
can undo the changes.

Instructions were already posted by Vitaly, so I won't repeat that here.
I'll just note that the scriptlet in systemd.rpm looks for
'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
the file is autogenerated.

> Not only that, this change apparently "obsoletes" /etc/resolv.conf,
> which is just not acceptable.

I'm not sure what you mean by that. It is true that /etc/resolv.conf
is not able to express split DNS. But it is still in place, with contents
that try to express the actual DNS configuration to the extent possible.
/etc/resolv.conf points to 127.0.0.53 as the resolver so that programs
which don't use the nss stack also go through systemd-resolved. The list
of remote dns servers can be queried from /run/systemd/resolve/resolv.conf
in the classic resolv.conf syntax, or over dbus.

> It is my opinion as a long time DNS RFC author and package maintainer
> that systemd-resolved is not a suitable DNS resolver. Downgrading
> DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I
> read on:
> 
> https://fedoraproject.org/wiki/Changes/systemd-resolved
> 
> that DNSSEC is now completely disabled. Again, this is completely
> unacceptable. DNSSEC is part of the core of DNS protocols. My fedora
> mail server uses DNSSEC based TLSA records to prevent MITM attacks
> on the STARTTLS layer, which is now completely broken. My IPsec VPN
> server uses dnssec validation using the specified nameserves in
> /etc/resolve.conf that now point to systemd-resolvd that does not
> return DNSSEC records and is completely broken:
> 
> paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
> 
> ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca 
> @127.0.0.53
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 65494
> ; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
> ; OPT=6: 01 02 04 ("...")
> ; OPT=7: 01 (".")
> ;; QUESTION SECTION:
> ;vpn.nohats.ca.   IN  A
> 
> ;; ANSWER SECTION:
> vpn.nohats.ca.10  IN  A   193.110.157.148
> 
> ;; Query time: 143 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Mon Sep 28 00:18:32 EDT 2020
> ;; MSG SIZE  rcvd: 81
> 
> libreswan will see this result as an attack, and fail to resolve DNS names
> in its configuration. My postfix daemon will hold on to mail because
> it cannot get a DNSSEC proof of denial of existence of TLSA records if
> all DNSSEC records are filtered - even for domains that don't use DNSSEC
> because the denial of existence of DNSSEC for a specific domain requires
> the return of DNSSEC records that systemd now does not return.
> 
> I am sorry that I did not follow the fedora list carefully enough to
> notice this feature when it was proposed.
> 
> This change is harmful to network security, impacts existing installations
> depending on DNSSEC security, and leaks private queries for VPN/internal
> domains to the open internet, and prefers faster non-dnssec answers
> over dnssec validated answers.  It fails various types of queries,
> misimplements part of the DNS protocol. Not only according to me, but
> to 20years+ developers of the bind software as well.

You're mixing a few different things here. We decided to not enable
DNSSEC in resolved with this change, at least initially. For most

Re: My Introduction

2020-09-27 Thread Zbigniew Jędrzejewski-Szmek
On Sun, Sep 27, 2020 at 09:13:54AM +, Antariksha Verma (Student Gurgaon) 
wrote:
> Hey, I am a new member of the Fedora family and have just joined the Python 
> SIG mailing list. My name is Antariksh Verma and I am 14 years old. I am 
> excited to work with and contribute to the Fedora family.

Hi and welcome to Fedora!

Zbyszek
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/python-devel@lists.fedoraproject.org


Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-25 Thread Zbigniew Jędrzejewski-Szmek
I'm missing some good statistics.

> * DWZ advantage: On the whole Fedora distro it saves 3.3% (5GB of the
> 157GB distribution size)

What is this comparing? Is this the size of binary rpm or the
installation-on-disk footprint?

I would love to see a comparison of numbers for three things:
- raw debuginfo without dwz or -fdebug-types-section
- debuginfo with dwz (current approach)
- debuginfo with -fdebug-types-section

For each of those three categories both measures (rpm size and on-disk size)
would be useful. Could you provide numbers like this for some subset of packages
(20-30 packages that produce debuginfo would be enough to get a good measure).

I find that 3.3% number strange — it would mean that dwz is
essentially useless, but maybe I'm misunderstanding how it's defined.
I think we need to get some better understanding what the effects of
various approaches are before discussing which to pick.

Zbyszek


> ** If the 3.3% size increase is a concern I can implement a different
> optimization ([https://whova.com/embedded/session/llvm_202010/1193947/
> talk (2)]) as a GCC post-processing phase which would require no
> changes in any DWARF consumers.
> * DWZ disadvantage: DWZ has currently less support across consumers
> (LLDB, llvm-dwarfdump, binutils readelf)
> * DWZ disadvantage: DWZ requires 8x times more complicated (LoC count)
> support in consumers than -fdebug-types-section.
> * DWZ disadvantage: DWZ cannot update LLVM .debug_names index which
> can be generated only by clang (it cannot be regenerated later for
> DWZ-compressed file)
> * DWZ disadvantage: DWZ DWARF-5 support is a work-in-progress. DWZ has
> been blocking DWARF-5 for Fedora for 3.5 years and only after I have
> now proposed to drop DWZ Mark Wielaard has started porting DWZ to
> DWARF-5. It can be expected next DWARF extensions will remain
> unsupported again. Even currently there is no plan to support DWARF-5
> features used by clang which may need -fdebug-types-section for
> clang-built binaries or no size optimization of clang-built debug info
> at all.
> * DWZ disadvantage: Compilation (linking) requires for C++ up to 2x as
> big disk space (as DWZ is processing files after linker and DWZ is
> incompatible with -fdebug-types-section)
> * DWZ disadvantage: Compilation (linking) is slower
> 
> This proposed DWARF format was originally submitted already for Fedora
> 18 as [[Features/DebugTypesSections]].
> 
> == Benefit to Fedora ==
> * Better compatibility with existing debugging and tracing tools,
> primarily [https://lldb.llvm.org/ LLDB].
> * Less resource-intensive rebuilds of C++ packages (in disk space,
> memory requirements and compilation time).
> 
> == Scope ==
> * Proposal owners: It affects all packages generating *-debuginfo.rpm,
> that is compiled (not scripted) languages.
> * Other developers: Report any possible debuginfo incompatibility 
> (unexpected).
> * Release engineering: [https://pagure.io/releng/issues #Releng issue
> number] (a check of an impact with Release Engineering is needed)
> * Policies and guidelines: All the needed changes should be done in
> [https://src.fedoraproject.org/rpms/redhat-rpm-config
> redhat-rpm-config]. The [https://src.fedoraproject.org/rpms/dwz dwz
> package] can be then retired.
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: The size differences are only for
> *-debuginfo.rpm which is outside of scope of the listed objectives.
> 
> 
> == Upgrade/compatibility impact ==
> As *-debuginfo.rpm have to exactly match NVRA of its binary package
> the compatibility is not relevant. Existing tools supporting DWZ will
> still support the DWZ file format in packages which have not been
> rebuilt.
> 
> == How To Test ==
> The change will update
> [https://src.fedoraproject.org/rpms/redhat-rpm-config
> redhat-rpm-config] by
> [https://people.redhat.com/jkratoch/redhat-rpm-config-fdebug-types-section.patch
> an -fdebug-types-section patch].
> 
> Then one can use rpmbuild to rebuild a package. For mock use
> -a|--addrepo with modified redhat-rpm-config.rpm (with increased
> NVRA). For packages already rebuilt in Koji nothing is needed.
> 
> Test programs like lldb and gdb if they still can print source code,
> function parameters, variables etc.
> 
> One should also verify integrated testsuites of tools like clang,
> lldb, gcc, binutils, gdb, elfutils or rpm are not regressing with the
> -fdebug-types-section option.
> 
> One can also compare *.debug files built with/without DWZ and/or
> -fdebug-types-section using
> [https://src.fedoraproject.org/rpms/libabigail libabigail] utility
> dwdiff but that will be rather done by the change owner.
> 
> == User Experience ==
> No user visible change. This affects what tools can developers use.
> 
> == Dependencies ==
> none
> 
> == Contingency Plan ==
> * Contingency mechanism: Revert the change in
> [https://src.fedoraproject.org/rpms/redhat-rpm-config
> redhat-rpm-config]. Fedora can continue using DWZ, 

Re: bodhi: permission for updates from side-tags with packages from several maintainers

2020-09-23 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Sep 23, 2020 at 12:05:38PM -, Michael J Gruber wrote:
> Hi there
> 
> I have a side-tag into which several maintainers have built their packages 
> successfully so that I can push a coordinated update.
> 
> Now, when I try to submit that update, bodhi cli gives an unqualified auth 
> error, and bodhi web tells me I need commit access for 2 of the 5 packages (I 
> have commit access for the other 3). Does it really make sense that I need 
> full commit access for a package in order to simply submit a package update 
> when that packages maintainer built into my side-tag for that sole purpose?
> 
> If that is bodhi's intended behaviour I'll ask for commit access, of course, 
> promising to use it for that specific purpose only.
> 
> Cheers
> Michael

Would it be possible to always allow the person who *created* the side-tag
to do all operations with builds from that side-tag?

Zbyszek
___
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: btrfs and default page sizes (4k vs 64k)

2020-09-18 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Sep 16, 2020 at 02:09:42PM -0400, Neal Gompa wrote:
> I'm annoyed in general that we still have problems like this, and I'm
> even more annoyed that I basically have no way to even test or deal
> with these things. We *still* do not have packager test machines, so I
> can't even figure out how to craft a workaround if there is one (and I
> suspect one is possible).

We do: 
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers.
There's one ppc64le on that list.

Zbyszek
___
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: Self Introduction: Matthew H.

2020-09-18 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 18, 2020 at 01:13:04PM +, proletarius101 via devel wrote:
> Hi,
> 
> My name is Matthew H. and I'm an open source enthusiast. I've contributed to 
> [RSSHub](https://github.com/DIYgod/RSSHub) (a RSS feed baker), 
> [Island](https://github.com/oasisfeng/island/) (a Work-profile based 
> container manager on Android), [Surgio](https://github.com/geekdada/surgio/) 
> (a proxy rule generator), etc. Now I'm planning to help package 
> [Hydroxide](https://github.com/emersion/hydroxide).
> 
> Good to know everyone.


Hi Matthew,

welcome to Fedora.

Zbyszek
___
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: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-18 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 18, 2020 at 09:31:59AM +0200, Bohdan Khomutskyi wrote:
> Hello Zbyszek,
> 
> > You haven't really answered the "why" part: why is it so important to
> save 50MB? And why is the effect on QA less important?
> 
> From my perspective, the storage on the installation medium should
> be efficiently used. Even though the optimization is just 50MiB, it
> is an optimization.
> 
> And this optimization is transparent in terms of content.
> 
> > And why is the effect on QA less important?
> 
> The QA team is only one group of users. We should rather orient at
> end users, and the way those users install Fedora.

Sorry, but that argument is not convincing. *Everything* we do has to
strike a balance. Making testing harder or slower also has an impact
on *users* — the stuff that they get will be less well tested.

Zbyszek
___
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: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]

2020-09-18 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 18, 2020 at 02:16:11AM +0200, Kevin Kofler wrote:
> Matthew Miller wrote:
> > I mean, some of y'all like to maintain and keep obscure dependency
> > packages up to date just for their own sake, and that's *awesome* -- but
> > we just can't hold everyone to that standard. At least, not if we want
> > more than a few dozen packagers.
> 
> That is a pretty strong assertion, with no facts to back it.
> 
> I think that packagers are more likely to be driven away by changes such as 
> Modularity that make packaging more and more complex, or even by the very 
> fact that the dependencies they need were taken private by their maintainer, 
> than by the very reasonable minimum standard we want to hold our packagers 
> to.
> 
> A private dependency is necessarily a form of technical debt that is 
> inevitably going to hurt us as soon as we want to package something else 
> that happens to depend on that same dependency. (Unless of course the 
> dependency really cannot be used for anything else than building that one 
> dependent package, in which case nobody is going to expect the maintainer to 
> make it work for anything else even if it is public, so that trivial case 
> need not be considered any further.) Hence, this risks driving away the 
> people who would be packaging the other dependent packages if the dependency 
> was readily available to them.

Fully agreed. The problem with modularized packages is that there is
no smooth transition between the states. A normal package, even if not 
maintained
fully, can be picked up by anyone at any time. Even by a non-packager: any user
can open a PR in pagure to fix some particularly annoying issue.
But once modularized as build-only, the package is not visible to users, is not
visible to other packagers, possibly loses out on any distro-wide mass changes,
and most importantly, trying to take it back out of the module is not smooth
at all.

> And that is just the impact on packagers. You also have to consider the 
> impact on end users. Do not forget that most packagers were users before 
> becoming packagers. Hiding packages from users or labeling them as 
> officially unsupported is going to make Fedora less attractive to users, 
> which in turn will lead to fewer people potentially becoming packagers.

I partially disagree about the "labeling them as officially
unsupported is going to make Fedora less attractive to users". If a package
*is* not fully supported, then I don't see users should not know this. In fact,
if I were to install a package as a user and see a message like
"Sorry, we don't have enough round tuits to handle bugs in this package.
Type «I understand» to proceed." then it could make an easy entry point for new
packagers.

Zbyszek
___
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: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-15 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 15, 2020 at 11:18:04AM +0200, Bohdan Khomutskyi wrote:
> Hello everyone,
> 
> Thanks for sharing your ideas and comments about this change.
> 
> Thanks to Mohan Boddu, I got RawHide DVD and netinstall images of
> RawHide with the optimization features enabled. Those test composes
> are available at the following locations:
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200828.n.0/
> (Plain SquashFS)
> 
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200908.n.1/compose/Server/x86_64/iso/
> (Plain SquashFS and different xz compression options)
> 
> To select images from the test composes, I applied a patch from
> https://github.com/rhinstaller/anaconda/pull/2829, so you can
> download and run those images yourself to test the change:
> 
> https://drive.google.com/drive/folders/1tGsoqFMg2A6dQZHfuQNb9uDqYu9XEiPI
> 
> The result of benchmark will supplement already available data I
> previously posted for Fedora Live images at
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
> 
> As a reminder, there are 2 levels for this optimization:
> 
> 1. Making the SquashFS filesystem on the DVD plain (i.e. without
> embedded EXT4 inside it) -- has the suffix plain-xz-128k.iso

This sounds excellent. We should get both better time and space efficiency.

> 2. In addition to #1, using a different compression parameters for
> the SquashFS filesystem on the installation medium -- has the suffix
> plain-xz-1M.iso

And this ones trades times for space. Considering that the space
difference is only ~50 MB, I don't think it's worth it, for all the
reasons outlined before.

You haven't really answered the "why" part: why is it so important to
save 50MB? And why is the effect on QA less important?

Zbyszek


> I propose to apply both of optimizations, using the highest possible
> compression ratio supported by SquashFS. The highest compression
> ratio in SquashFS corresponds to xz level 1 (out of 9 available
> presets).
> 
> Making the first change will reduce both x86-64 Boot and the x86-64
> DVD ISO by approximately 24 MiB. With both changes combined, the
> reduction of size will be 70 MiB.
> 
> Because the SquashFS filesystem on the Live installation medium is
> of bigger size, storage savings on the Live images are even higher
> (I documented it in
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS)
> 
> On 05/09/2020 12:43, Zbigniew Jędrzejewski-Szmek wrote:
> >On Thu, Aug 27, 2020 at 11:13:26AM -0400, Ben Cotton wrote:
> >>https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
> >...
> >>Based on the results above, I'd suggest selecting the following
> >>''optimal configuration'': XZ algorithm, with block size of 1MiB and
> >>without BCJ filter (plain xz -b 1M, without -Xbcj x86).
> >>On the right, you can see the impact of the compression algorithms on
> >>installation time.
> >>
> >>As can be seen from the picture on the right hand side, selecting
> >>'plain xz -b 1M configuration' has minimal impact on the installation
> >>time and CPU usage during the installation. The compression will
> >>result in +6.51% or, in real terms, +24.94s additional installation
> >>time, compared to the savings of 142 MiB on the installation media,
> >>== Benefit to Fedora ==
> >>* Reduction of the installation media size and the cost of storing and
> >>distributing Fedora.
> >>* Reduction of the CPU usage at build time. Depending on which
> >>compression parameters chosen.
> >Hi Bohdan,
> >
> >I think there's a misalignment of priorities.
> >
> >My evaluation is the following: users won't care. The image size difference
> >is not big enough for people to notice. OTOH, slower installation will
> >impact QA and VM installations. We're doing more and more automated
> >installations and tests, and this change impacts those tests negatively.
> >
> >>This increase in installation time will be compensated by the change
> >>in the installer:https://github.com/rhinstaller/anaconda/pull/2292
> >This PR is very interesting. But it seems that the more we optimize
> >things, the more slow decompression will be noticable. I.e. in some
> >way, right now, the slow decompression is obscured by the slow IO
> >speed, multiple levels of block device, or slow processing of the
> >uncompressed data. Any time the input or output speed is improved,
> >slow compression will be more of a bottleneck. So the approach of
> >increasing XZ compression levels has bad perspectives.
___
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: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

2020-09-14 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 14, 2020 at 12:53:57PM -0700, Josh Stone wrote:
> On 9/14/20 12:18 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 14, 2020 at 09:15:27PM +0200, Fabio Valentini wrote:
> >> On Mon, Sep 14, 2020 at 9:02 PM Josh Stone  wrote:
> >>>
> >>> On 9/14/20 11:40 AM, Fabio Valentini wrote:
> >>>> I agree. The only thing to keep in mind for semver-incompatible -devel
> >>>> package updates is to check dependent packages, and either patch them
> >>>> to use the new version (like in rawhide), or create compat packages if
> >>>> necessary - so no broken dependencies are generated in the stable
> >>>> branches.
> >>>
> >>> Are we going to recommend that these devel packages are still not really
> >>> for end users? Otherwise, checking dependent packages is not sufficient.
> > 
> > I don't think those packages make sense for users. As a user I would use 
> > cargo
> > and download packages from the web.
> 
> I agree, but I think we still need to set that expectation.

rust packages are usually generated with rust2rpm. We could emit something in 
the
description template. This wouldn't help with existing packages (at least until
they are regenerated), but would help with new ones.

Zbyszek
___
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: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

2020-09-14 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 14, 2020 at 09:15:27PM +0200, Fabio Valentini wrote:
> On Mon, Sep 14, 2020 at 9:02 PM Josh Stone  wrote:
> >
> > On 9/14/20 11:40 AM, Fabio Valentini wrote:
> > > I agree. The only thing to keep in mind for semver-incompatible -devel
> > > package updates is to check dependent packages, and either patch them
> > > to use the new version (like in rawhide), or create compat packages if
> > > necessary - so no broken dependencies are generated in the stable
> > > branches.
> >
> > Are we going to recommend that these devel packages are still not really
> > for end users? Otherwise, checking dependent packages is not sufficient.

I don't think those packages make sense for users. As a user I would use cargo
and download packages from the web.

> Is there - or will there be - any use case for manually installing
> rust-*-devel packages outside of mock?
> If not, then I don't see a reason why this would change.

I guess as a developer of a package I could build this package in the
normal system, not in mock. 'fedpkg local' is very quick and it makes debugging
(both of the code and of the spec file) simpler.

Zbyszek
___
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: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

2020-09-14 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 14, 2020 at 10:10:30AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Rust_Crate_Packages_For_Release_Branches
> 
> == Summary ==
> 
> This Change proposal aims to enable shipping Rust crate packages
> (rust-$CRATE_NAME) on release branches of fedora.
> Currently, they are only available for rawhide, which makes building
> Rust packages for release branches difficult.

Should the update policy for rust-devel packages be relaxes in stable
releases to allow updates to follow rawhide, at least if there are
no major breaking changes?

Current update policy states that major version changes should be avoided
in after stable release. But rust upstreams tend to move quickly, so having
~1 year old packages in stable Fedora might not be too useful to build
newest upstreams. It might make sense to allow the rust-*-devel packages
to be updated more aggressively.

Zbyszek



> == Owner ==
> 
> * Name: [[User:decathorpe| Fabio Valentini]]
> * Email: 
> 
> 
> == Detailed Description ==
> 
> Following the general upwards trend in the Rust language's popularity,
> more and more applications and services in fedora are written in Rust.
> This includes some CoreOS services, PARSEC, some nice command line
> tools (e.g. ripgrep, bat, fedora-update-feedback, ...), and parts of
> the GNOME stack.
> However, because rust crate packages are currently only available on
> rawhide, packaging rust applications for release branches is difficult
> and involves more steps than usual.
> 
> This Change proposal aims to bring Rust packaging in line with the
> normal packaging workflows in fedora.
> 
> In particular, the following additional steps will become obsolete:
> 
> * use koji side tags for *every package build* on release branches
> * manual tagging and untagging of koji buildroot contents
> 
> Instead, rust packages can be built like any other package in fedora.
> 
> 
> == Benefit to Fedora ==
> 
> This Change lowers the bar for contributing to the Rust stack in
> fedora, because it will no longer be a special case that involves
> additional steps.
> 
> It will also make it possible to build Rust packages for release
> branches locally in mock without the need for custom mock buildroot
> configurations and / or third-party repositories.
> 
> == Scope ==
> 
> * Proposal owner(s):
> ** one-off change: submit PR to revert the special-case handling for
> rust-* packages in the mass branching releng script
> ** ongoing effort: help package maintainers with merging changes from
> rawhide (where appropriate) and creating compat packages (when
> necessary) - this is made easier by the strong SemVer compatibility
> guarantees of Rust crates
> 
> * Other developers:
> 
> Initially, there is no impact on other developers.
> However, as soon as fedora 34 is branched, building Rust applications
> on that release branch will be easier than without this change.
> This will require packagers to merge rawhide updates into release
> branches when appropriate (again, bringing Rust packaging in line with
> the rest of fedora).
> 
> I also expect there to be reduced load on koji due less side tags
> being in use concurrently, which will benefit all package maintainers
> in fedora.
> 
> * Release engineering: [https://pagure.io/releng/issue/9753 #9753]
> 
> Release engineering will need to remove special-case handling of
> rust-* packages from their mass branching script before
> f34 is branched off of rawhide.
> 
> * Policies and guidelines:
> 
> The Rust packaging Guidelines will need small adaptations.
> 
> They are already outdated, so Change owner(s) will update them to the
> current state of Rust packaging regardless.
> 
> * Trademark approval: N/A (not needed for this Change)
> 
> * Alignment with Objectives:
> 
> The fedora IoT Edition promotes PARSEC, which is comprised of Rust
> packages - its package maintainers will benefit from being able to
> update and build those packages faster and more easily for release
> branches.
> 
> == Upgrade/compatibility impact ==
> 
> There will be no impact on upgrades from previous fedora releases,
> since Rust crate packages will only be available for those users for
> the first time.
> 
> If for some reason a user installed rust-*-devel packages
> manually after downloading them from the rawhide repositories, they
> will be gracefully upgraded.
> 
> == How To Test ==
> 
> Users should be able to build Rust applications for fedora 34 without
> workarounds or special steps (both in mock locally and in koji - both
> scratch and non-scratch builds).
> 
> == User Experience ==
> 
> Users should not notice this change. However, I expect some
> application updates to be available for release branches faster, since
> it will be easier for package maintainers to create them.
> 
> == Dependencies ==
> 
> N/A (this only affects the Rust package stack and has no external 
> dependencies)
> 
> == Contingency Plan ==
> 
> * Contingency mechanism: untag and block rust-* packages
> in the 

Re: Proposing an EPEL packaging SIG

2020-09-14 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote:
> Reading this proposal and with the EPEL8 experience, where there was not
> even wiki page, where I could state that I don't care about EPEL and I
> had to reply into every BZ independently, wouldn't it make sense to move
> EPEL into its own dist-git namespace?
> 
> I guess that in the CVS days, having EPEL branch was fine. During PkgDB
> days, where we could assign maintainer to each branch, it was still
> fine. But since we lost this ability, isn't it time to rethink the
> setup?

We have the ability back, see the answers from Neal Gompa.

> I think this would give more power to EPEL SIG and give relieve
> to Fedora packagers.

What you are saying would make sense if there was only the EPEL SIG.
But we also have plenty of packagers who do care about their EPEL packages,
and they would be inconvenienced by such a split. It seems that there
are even people who like to keep one spec file for all branches, incl.
EPEL.

Zbyszek
___
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: [EPEL-devel] Re: Proposing an EPEL packaging SIG

2020-09-13 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 11, 2020 at 03:50:58PM -0700, Michel Alexandre Salim wrote:
> We discussed the proposal a bit at today's EPEL SC meeting; here's a
> revised proposal taking into account the suggestions from the meeting
> and earlier in this list.
> 
> ## The SIG
> - bstinson pointed out that epel-wranglers was started to address the
> same issue, we can resurrect that
> - we want to limit the access to epel* branches only, not all branches,
> as suggested both here and at the meeting. Any change the epel-
> wranglers want to make to the Rawhide branch can be done as a PR
>   - the EPEL branch will likely diverge from master over time anyway
> - the collaborator permission (available since August, yay) can be used
> for such granular access
>   - nirik pointed out that collaborators can't yet request new
> branches, if the proposal is approved we can work on making the `fedpkg
> request-branch` flow support this
>   - carlwgeorge suggested getting the group up and running first, and
> working on automation later
> 
> ## Workflow
> - no objection that I recall to having epel-wranglers automatically get
> access if the Fedora maintainers do not respond (so we can circumvent
> needing to do a non-responsive maintainer request)
>   - we probably won't have this automated at the beginning, see above
> - down the line, epel-wranglers need to decide on what to do with
> releases they no longer want to support (e.g. when everyone involved
> only cares about epel10 and epel9 and there's a CVE affecting epel8).
> the normal orphan process probably works - we announce the package is
> being orphaned by the group on epel-devel

+1 for the proposal. The group-maintenance approach is being used more
and more, and it seems good to use that also for EPEL. I'd be happy to
give access to any and all epel branches on my packages to the SIG.

Zbyszek

> Let's continue discussing the proposal in this thread, as suggested
> during the meeting.
> 
> Thanks all,
___
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 the Java Stack (also regarding ELN and RHEL)

2020-09-12 Thread Zbigniew Jędrzejewski-Szmek
On Sat, Sep 12, 2020 at 10:32:51AM +0200, Vitaly Zaitsev via devel wrote:
> On 11.09.2020 18:42, Zbigniew Jędrzejewski-Szmek wrote:
> > I'm not enthusiastic about build-time-only packages, but if the choice
> > is between that and retiring the packages (or hiding them in modules
> > which has the same effect), I'll take it.
> 
> This will be Modularity 2.0. All packages must be installable if the end
> user wants to do so.

The packages *would* be trivially installable. I didn't say that explicitly,
but you would always be able to install a package that has 
"Provides:fedora-build-time-only"
and then install any such packages on any system. (That is how they would
installed in mock or koji too.)

> Check header-only C++ libraries packaging. They provide only the -devel
> and virtual -static subpackages and can be easily installed in Koji/mock
> or directly.
> 
> Also check Rust packaging. They build crates to a separate packages and
> use them only for the static linkage.

Zbyszek
___
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 the Java Stack (also regarding ELN and RHEL)

2020-09-11 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 11, 2020 at 06:01:11PM +0200, Fabio Valentini wrote:
> On Fri, Sep 11, 2020 at 5:52 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Sep 11, 2020 at 11:03:39AM +0200, Hans de Goede wrote:
> > > An other more generic approach which has been brought up once or
> > > twice, but which not really has been discussed in much detail yet
> > > I believe is creating a fedora-builddep repository.
> > >
> > > ATM a normal user has 3 ursine Fedora repos installed:
> > >
> > > fedora
> > > fedora-updates
> > > fedora-updates-testing (disabled by default)
> > >
> > > What if we add a 4th repo called fedora-builddep:
> > >
> > > fedora
> > > fedora-updates
> > > fedora-updates-testing (disabled by default)
> > > fedora-builddep (rolling (within a release), disabled by default)
> > >
> > > So the idea is that all the maven deps which you need, but
> > > do not want to offer any end-user support on would go to
> > > fedora-builddep.
> >
> > If we absolutely must have build-only packages, we can do it more simply:
> > insert
> >   Requires: fedora-unmaintained-package
> > or
> >   Requires: fedora-buildonly-package
> > (name TBD), and beef up dnf a bit to explain that "this package cannot
> > be installed because it's only maintained at the level appropriate for
> > building packages...". I think there are two advantages: first, no need
> > for a separate repo, so there'll be less infra change and churn. Second,
> > this tag can easily set on each subrpm, without any central list to manage.
> 
> I'm not sure making things available only at build-time is going to
> help things. It's just "Modularity under a different name" ...
> Most Java packages are either directly or indirectly depended on by
> non-build-tool packages as well.
> You'd be surprised. Most of the distro directly or indirectly depends
> on the Java stack already - including the libvirt stack, libreoffice,
> some GNOME components, KDE components, etc. So most of those Java
> packages can't be built-time-only packages because they're actually
> required at runtime.
> The number of packages that are *really only ever needed to build
> other RPM packages and for no other reasons* is rather small.

You are probably right. Still, this would be useful to actually have this
surfaced. If a package marked build-time-only would be needed by anything
else, we would need to either unmark it (and have somebody on the hook
for maintaince) or drop the dependency somehow. And this would be vastly
better than build-time-only packages in modules.

I'm not enthusiastic about build-time-only packages, but if the choice
is between that and retiring the packages (or hiding them in modules
which has the same effect), I'll take it.

Zbyszek
___
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 the Java Stack (also regarding ELN and RHEL)

2020-09-11 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 11, 2020 at 11:03:39AM +0200, Hans de Goede wrote:
> An other more generic approach which has been brought up once or
> twice, but which not really has been discussed in much detail yet
> I believe is creating a fedora-builddep repository.
> 
> ATM a normal user has 3 ursine Fedora repos installed:
> 
> fedora
> fedora-updates
> fedora-updates-testing (disabled by default)
> 
> What if we add a 4th repo called fedora-builddep:
> 
> fedora
> fedora-updates
> fedora-updates-testing (disabled by default)
> fedora-builddep (rolling (within a release), disabled by default)
> 
> So the idea is that all the maven deps which you need, but
> do not want to offer any end-user support on would go to
> fedora-builddep.

If we absolutely must have build-only packages, we can do it more simply:
insert
  Requires: fedora-unmaintained-package
or 
  Requires: fedora-buildonly-package
(name TBD), and beef up dnf a bit to explain that "this package cannot
be installed because it's only maintained at the level appropriate for
building packages...". I think there are two advantages: first, no need
for a separate repo, so there'll be less infra change and churn. Second,
this tag can easily set on each subrpm, without any central list to manage.

Zbyszek
___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

2020-09-11 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 11, 2020 at 01:55:54AM -0700, John M. Harris Jr wrote:
> On Thursday, September 10, 2020 10:38:51 PM MST Zbigniew Jędrzejewski-Szmek 
> wrote:
> > On Thu, Sep 10, 2020 at 06:37:56PM -0700, John M. Harris Jr wrote:
> > 
> > > On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek
> > > 
>  wrote:
> > > 
> > > > On Thu, Sep 10, 2020 at 01:27:30PM +0200, alcir...@posteo.net wrote:
> > > > 
> > > > 
> > > > > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > > > > 
> > > > > 
> > > > > > > 
> > > > > > > These DNS addresses are bundled upstream in systemd. And they are
> > > > > > > used
> > > > > > > in the event of a misconfiguration of your network settings,
> > > > > > > isn't
> > > > > > > it?
> > > > > > > However they are easily customizable in
> > > > > > > /etc/systemd/resolved.conf
> > > > > > > (FallbackDNS option)
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > It's about the distribution's default setting, not a configuration
> > > > > > possibility.
> > > > > 
> > > > > 
> > > > > 
> > > > > "Which servers are used (or any at all) as a fallback is a
> > > > > compile-time
> > > > > as well as a runtime option. If you don't like the upstream defaults,
> > > > > then please work with downstream to pick different options or make
> > > > > the
> > > > > choices locally in your configuration files."
> > > > > 
> > > > > As a concerned user, you can configure the FallbackDNS option in
> > > > > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google
> > > > > and
> > > > > so on will never be contacted.
> > > > > 
> > > > > Obviously the distribution can put different DNS in systemd at
> > > > > compile
> > > > > time, or provide a default resolved.conf file where FallbackDNS is
> > > > > uncommented and filled.
> > > > 
> > > > 
> > > > 
> > > > Exactly. With my maintainer hat on: this is a non-issue. We consider
> > > > current defaults (a working fallback configuration out of the box that
> > > > has a very minor information leak) better than the proposed (a
> > > > non-working
> > > > fallback configuration). If you need to, provide the trivial two-line
> > > > dropin file to override this locally.
> > > 
> > > 
> > > Zbyszek,
> > > 
> > > I'm definitely not suggesting something that is "non-working". That said,
> > > not  having any DNS servers configured indicates that remote lookup
> > > should not be used, not that a random DNS server should be picked by the
> > > resolver itself. When there are no DNS servers, the expected behavior is
> > > that no external servers are used for lookup.
> > 
> > 
> > There are no environments where remote lookup SHOULD NOT not be used. There
> > are remote environments where it MUST NOT be used, and environments where
> > it is expected to work. For the former, just emptying /etc/resolv.conf is a
> > halfway measure that doesn't do enough so strong filtering with namespaces
> > or routing must be provided anyway. In the second case, we want to have
> > working networking (even if your local crappy dns router forgets to attach
> > a dns server to the dhcp lease or such).
> 
> When you have no configured DNS servers, remote lookup SHOULD NOT be used. 
> Only local domain resolution should be used. This is how it has been for 
> decades, and there's no reason to change this. That's expected functionality.
> 
> We have working networking even without DNS. If there are no DNS servers 
> configured, no remote DNS servers should ever be contacted by the resolver.

You position is very clear. Let's agree to disagree.

Zbyszek
___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

2020-09-10 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Sep 10, 2020 at 06:37:56PM -0700, John M. Harris Jr wrote:
> On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek 
> wrote:
> > On Thu, Sep 10, 2020 at 01:27:30PM +0200, alcir...@posteo.net wrote:
> > 
> > > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > > 
> > > > > 
> > > > > These DNS addresses are bundled upstream in systemd. And they are
> > > > > used
> > > > > in the event of a misconfiguration of your network settings, isn't
> > > > > it?
> > > > > However they are easily customizable in /etc/systemd/resolved.conf
> > > > > (FallbackDNS option)
> > > > 
> > > > 
> > > > It's about the distribution's default setting, not a configuration
> > > > possibility.
> > > 
> > > 
> > > "Which servers are used (or any at all) as a fallback is a compile-time
> > > as well as a runtime option. If you don't like the upstream defaults,
> > > then please work with downstream to pick different options or make the
> > > choices locally in your configuration files."
> > > 
> > > As a concerned user, you can configure the FallbackDNS option in
> > > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
> > > so on will never be contacted.
> > > 
> > > Obviously the distribution can put different DNS in systemd at compile
> > > time, or provide a default resolved.conf file where FallbackDNS is
> > > uncommented and filled.
> > 
> > 
> > Exactly. With my maintainer hat on: this is a non-issue. We consider
> > current defaults (a working fallback configuration out of the box that
> > has a very minor information leak) better than the proposed (a non-working
> > fallback configuration). If you need to, provide the trivial two-line
> > dropin file to override this locally.
> 
> Zbyszek,
> 
> I'm definitely not suggesting something that is "non-working". That said, not 
> having any DNS servers configured indicates that remote lookup should not be 
> used, not that a random DNS server should be picked by the resolver itself. 
> When there are no DNS servers, the expected behavior is that no external 
> servers are used for lookup.

There are no environments where remote lookup SHOULD NOT not be used. There
are remote environments where it MUST NOT be used, and environments where it
is expected to work. For the former, just emptying /etc/resolv.conf is a halfway
measure that doesn't do enough so strong filtering with namespaces or routing
must be provided anyway. In the second case, we want to have working networking
(even if your local crappy dns router forgets to attach a dns server to the
dhcp lease or such).

Zbyszek
___
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 the Java Stack (also regarding ELN and RHEL)

2020-09-10 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Sep 10, 2020 at 12:12:05PM -0400, Robbie Harwood wrote:
> Mikolaj Izdebski  writes:
> > On Thu, Sep 10, 2020 at 3:46 PM Alexander Scheel  wrote:
> >> Hi Joe,
> >> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton  wrote:
> >> > I'm writing as the Red Hat engineering manager responsible for Maven and
> >> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my
> >> > team.  I want to give a broad response to some of the points here:
> >> >
> >> > 1.  The team has two missions in Fedora:
> >> >
> >> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is
> >> > to provide developers with the most popular Java build systems which are
> >> > reviewed, tested, and updated through the release lifecycle.
> >> >
> >> > b) We design, develop and document tooling that enables anyone to
> >> > package Java software with a simple, efficient and scalable process. We
> >> > are also active members of Java SIG, collaborating on complex changes
> >> > and guiding new contributors.
> >> >
> >> > 2.  We are committed to maintaining the Ant and Maven modules in
> >> > Fedora.  We have always expected to make them available as default
> >> > streams and in the buildroot so they can be available and consumed by
> >> > non-modular packages, but we completely respect the decisions of FESCo
> >> > to disallow default streams and of other contributors to adopt and
> >> > maintain the non-modular packages.  We are not going to promise to
> >> > commit time and resources to maintain the non-modular packages.
> >>
> >> As a reminder (as in my RHEL devel-list reply): there are no default
> >> module streams in Fedora. There is also no Ursa Major/Prime, so were
> >> they to exist, there would still be no way for non-modular packages to
> >> use them.
> >
> > There are default module streams in Fedora 31.
> 
> Fedora 31 is most likely EOL in about two months.  I really hope you're
> not targeting your future development against it.

This exchange summarizes the situation nicely.

Modularity can be considered an over-complicated hyped-through-the-roof
bundling mechanism.

For a long time Fedora has very strongly discouraged bundling in the sense of
subsumming one package into another to have a custom build of a dependency.

The disapproval of bundling is not because it doesn't work: it does, and in
fact with some crappy libraries it's the least bad solution. The disapproval
is motivated by the fact that bundling doesn't scale and that it subtracts from
the ecosystem. Instead of us all cooperating and each bugfix helping all
users of a given dependency, a maintainer of a bundled library is only helping
themselves and their package.

Bundling is not inherently bad: currently the policy even allows it as
a workaround if using the system-wide package is not feasible. It is a
pragmatic choice to allow it as a last resort. But the effect of bundling
on other packages must be minimized any conflicts or confusion with the
system version avoided.

With Modularity, we threw this accumulated wisdom away.
In two ways: by encouraging private^Wbuild-only dependencies and by
letting bundled^Wmodularized rpms shadow normal rpms.

For Maven packaging the appeal of Modularity is clearly the privatization of
the dependency tree, which obviously undercuts the ecosystem of packages.

The Java ecosystem collapsed so quickly because it was already weak
— hundreds of packages on the shoulders of one person. But even in a stronger
ecosystem, with enough packages modularized, the packaging ecosystem of
mutual cooperation would collapse.

For some other modules, the appeal is the overriding of package deps, which
means that the modular rpms don't have to worry about getting it deps precisely
declared, at the cost of breaking the deps declared in other packages.

If there wasn't Modularity and instead Maven would bundle it's deps into
one huge srpm, the effect on the ecosystem would be the same. As with
bundling, Modularization gives short-term relief at a very high long-term
cost. We should avoid modularization like we avoid bundling.

Zbyszek
___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

2020-09-10 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Sep 10, 2020 at 01:27:30PM +0200, alcir...@posteo.net wrote:
> On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > > 
> > > These DNS addresses are bundled upstream in systemd. And they are
> > > used
> > > in the event of a misconfiguration of your network settings, isn't
> > > it?
> > > However they are easily customizable in /etc/systemd/resolved.conf
> > > (FallbackDNS option)
> > 
> > It's about the distribution's default setting, not a configuration
> > possibility.
> 
> "Which servers are used (or any at all) as a fallback is a compile-time
> as well as a runtime option. If you don't like the upstream defaults,
> then please work with downstream to pick different options or make the
> choices locally in your configuration files."
> 
> As a concerned user, you can configure the FallbackDNS option in
> /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
> so on will never be contacted.
> 
> Obviously the distribution can put different DNS in systemd at compile
> time, or provide a default resolved.conf file where FallbackDNS is
> uncommented and filled.

Exactly. With my maintainer hat on: this is a non-issue. We consider
current defaults (a working fallback configuration out of the box that
has a very minor information leak) better than the proposed (a non-working
fallback configuration). If you need to, provide the trivial two-line dropin
file to override this locally.

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


Summary/Minutes from today's FESCo Meeting (2020-09-09)

2020-09-09 Thread Zbigniew Jędrzejewski-Szmek
Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-09/fesco.2020-09-09-14.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-09/fesco.2020-09-09-14.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-09/fesco.2020-09-09-14.00.log.html

Meeting summary
---
* init process  (zbyszek, 14:00:28)

* #2470 F34 Self-Contained Change: Reduce installation media size by
  improving the compression ratio of SquashFS filesystem  (zbyszek,
  14:02:05)
  * AGREED: REJECTED (0, 0, -8)  (zbyszek, 14:13:52)

* Next week's chair  (zbyszek, 14:13:59)
  * ACTION: cverna will chair next meeting  (zbyszek, 14:15:15)

* Open Floor  (zbyszek, 14:15:21)
  * https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist
(zbyszek, 14:18:45)

Meeting ended at 14:21:28 UTC.

Action Items

* cverna will chair next meeting
___
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-09-09)

2020-09-09 Thread Zbigniew Jędrzejewski-Szmek
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-09-09 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 =

#2416 Update 3rd party repo policy
https://pagure.io/fesco/issue/2416
APPROVED (+6, 0, 0)

= Followups =

= New business =

#2470 F34 Self-Contained Change: Reduce installation media size by
  improving the compression ratio of SquashFS filesystem
https://pagure.io/fesco/issue/2470

= 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. 
___
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: BZ + Firefox: browser freezes when choosing close reason?

2020-09-05 Thread Zbigniew Jędrzejewski-Szmek
On Sat, Sep 05, 2020 at 02:50:28PM +0200, Till Hofmann wrote:
> Hi all,
> 
> I'm having a weird problem with Bugzilla: Whenever I want to close an
> issue and I click on the reason menu (the one that shows NOTABUG,
> NEXTRELEASE etc.), my browser freezes. Is anyone else seeing this issue?

Yep, I usually see this. It seemed fairly consistent over I'd say a few
months, but for the last few days I haven't seen it.

> I've tried to search for similar bug reports, but searching for
> "bugzilla firefox bug status" obviously doesn't result in anything useful.
> 
> I've seen this for a couple of weeks now. This is on Fedora 32 with
> Firefox 80.0.1.

I have firefox-80.0.1-1.fc32.x86_64, and right now I don't see this.
So there must be some other factor involved.

Zbyszek
___
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: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-05 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Aug 27, 2020 at 11:13:26AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
...
> Based on the results above, I'd suggest selecting the following
> ''optimal configuration'': XZ algorithm, with block size of 1MiB and
> without BCJ filter (plain xz -b 1M, without -Xbcj x86).
> On the right, you can see the impact of the compression algorithms on
> installation time.
> 
> As can be seen from the picture on the right hand side, selecting
> 'plain xz -b 1M configuration' has minimal impact on the installation
> time and CPU usage during the installation. The compression will
> result in +6.51% or, in real terms, +24.94s additional installation
> time, compared to the savings of 142 MiB on the installation media,

> == Benefit to Fedora ==
> * Reduction of the installation media size and the cost of storing and
> distributing Fedora.
> * Reduction of the CPU usage at build time. Depending on which
> compression parameters chosen.

Hi Bohdan,

I think there's a misalignment of priorities.

My evaluation is the following: users won't care. The image size difference
is not big enough for people to notice. OTOH, slower installation will
impact QA and VM installations. We're doing more and more automated
installations and tests, and this change impacts those tests negatively.

> This increase in installation time will be compensated by the change
> in the installer: https://github.com/rhinstaller/anaconda/pull/2292

This PR is very interesting. But it seems that the more we optimize
things, the more slow decompression will be noticable. I.e. in some
way, right now, the slow decompression is obscured by the slow IO
speed, multiple levels of block device, or slow processing of the
uncompressed data. Any time the input or output speed is improved,
slow compression will be more of a bottleneck. So the approach of
increasing XZ compression levels has bad perspectives.

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


Summary/Minutes from today's FESCo Meeting (2020-09-02)

2020-09-02 Thread Zbigniew Jędrzejewski-Szmek
Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-02/fesco.2020-09-02-14.01.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-02/fesco.2020-09-02-14.01.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-02/fesco.2020-09-02-14.01.log.html

Note that there's an approved ticket at the bottom.

Meeting summary
---
* init process  (zbyszek, 14:01:32)

* #2454 Proposal: Require compiler / annobin updates to use rawhide
  gating  (zbyszek, 14:02:53)

* #2416 Update 3rd party repo policy  (zbyszek, 14:04:04)
  * LINK:

https://pagure.io/fork/zbyszek/fesco/fesco-docs/blob/4ae171e2c3f68346b7b7d1c0d5fedc66cb9b25dd/f/fesco/modules/ROOT/pages/Third_Party_Repository_Policy.adoc
(zbyszek, 14:09:08)

* Next week's chair  (zbyszek, 14:11:57)
  * ACTION: zbyszek will chair next meeting  (zbyszek, 14:12:15)

* Open Floor  (zbyszek, 14:12:19)
  * LINK: https://pagure.io/fesco/issue/2452   (zbyszek, 14:13:32)

Meeting ended at 14:16:02 UTC.


Action Items

* zbyszek will chair next meeting


Other Approved Tickets
--

https://pagure.io/fesco/issue/2452
F34 Self-Contained Change: Policy for Modules in Fedora and Fedora ELN
APPROVED (+7, 0, -2)
___
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: services impact on startup times

2020-09-02 Thread Zbigniew Jędrzejewski-Szmek
On Sat, Aug 29, 2020 at 09:27:33PM -0600, Chris Murphy wrote:
> Hi,
> 
> These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso
> in a VM. The numbers are different on bare metal but correlate.
> 
> The only standout is rngd.service. That's a pretty big single hit,
> percentage wise. And I don't know if we even need it anymore. Among
> the rest, perhaps atd.service and crond.service could be disabled by
> default on new installations, in favor of systemd timers.

I think that with the recent-ish kernel changes to make /dev/urandom
non-blocking, rngd should not be installed by default.


As for crond and atd, I think we can keep them installed by default,
but inactive. I.e. make them socket activated or path activated, so that
they are only started if people install actual crontabs or run at.

We would also need to convert any packaged cronfiles into systemd
timers. But it seems that this is already mostly done. On my machine,
/etc/cron.weekly/98-zfs-fuse-scrub is the only real crontab entry.

Those are not big programs, but each thing that is running on a
machine has some small impact... 

I see the appeal of keeping them functional by default: there are countless
manual on the web, and even if people use them nowadays much less than in the
past, it'd still be nice to make this "just work" for people who follow them.


In the past, I saw pcp as a fairly big offender. I'm not sure if it
still installed by default.

Zbyszek
___
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: systemd-resolved

2020-09-02 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 01, 2020 at 08:17:49AM -0400, Nico Kadel-Garcia wrote:
> > >> Big Brother will be happy. :-)
> > >
> > > Sure, those two companies will be thrilled, I'm sure. This is a huge
> > > disservice to our users. Why in the world does systemd try to force DNS
> > > servers when none are configured? If no DNS servers are configured, there
> > > should be no DNS servers in use.
> >
> > Standard DNS has a hierarchical structure with roots and delegation.
> > The idea of asking somebody to do DNS resolution for you comes from the 
> > widespread
> > tendency to centralize everything (i.e. inability to understand how the 
> > Internet was
> > originally designed).
> 
> Hiding it inside yet another systemd structure without following the
> existing standards is, sadly, typical of systemd. It also puts at risk
> restricted environments where providing no DNS is deliberately used to
> restrict outbound network use, such as virtual machines or chroot
> cages without an enabled /etc/resolv.conf. That includes the "mock"
> build environment where "pip install" is kept network disabled by the
> lack of DNS.

Other sentences in this paragraph have already been disambiguated by others,
so I'll reply only to the part about mock:
That's not how mock works (for the last few years).
$ mock --shell
# ip route
default via 127.0.0.1 dev lo proto static 
# dig fedoraproject.org @8.8.8.8
(hangs for the duration of timeout)

Relying on lack of resolv.conf configuration in the buildroot to
prevent network use would be very brittle and easily circumvented,
even by accident if some tool included IP addresses internally.

Zbyszek
___
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: systemd-resolved

2020-09-02 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Sep 01, 2020 at 07:50:46AM +0800, Ed Greshko wrote:
> I don't think the DHCP server for the QEMU VMs is supplying a domain.  
> However, Network Manager
> will add a "search" option to resolv.conf when "hostname" returns a FQDN.

Ed opened https://bugzilla.redhat.com/show_bug.cgi?id=1874419. To follow
up on this from a slightly different perspective:

NM *does* support pushing "search domains" into systemd-resolved, and in
general this is expected to work. For example, I now have a company
VPN configured using NM, and the "redhat.com" search domain is active:

$ resolvectl status tun0
Link 35 (tun0)
  Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
 ...
  Current DNS Server: 10.38.5.26   
 DNS Servers: 10.45.248.15 
  10.38.5.26   
  DNS Domain: redhat.com   

$ resolvectl query www www.redhat.com
www: 23.211.151.51 -- link: hub0
 2a02:26f0:1300:186::d44   -- link: hub0
 2a02:26f0:1300:190::d44   -- link: hub0
 (e3396.dscx.akamaiedge.net)

-- Information acquired via protocol DNS in 263.0ms.
-- Data is authenticated: no
www.redhat.com: 2a02:26f0:1300:190::d44-- link: hub0
2a02:26f0:1300:186::d44-- link: hub0
23.211.151.51  -- link: hub0
(e3396.dscx.akamaiedge.net)

-- Information acquired via protocol DNS in 2.4ms.
-- Data is authenticated: no

(It says "hub0" because the address is public, so it would not be
routed through tun0. The relevant part is that "www" gets treated as
"www.redhat.com" by resolved.)


What does *not* happen, is the domainname part of a hostname received
via DHCP being installed as a search domain. In the case of a lease
received via DHCP by NetworkManager, it's NetworkManager that decides
what config to push to resolved. As discussed in
https://bugzilla.redhat.com/show_bug.cgi?id=1874419, automatically
installing the domain name as search domain this is not expected and
probably not a good idea as a default.

Zbyszek
___
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-09-02)

2020-09-01 Thread Zbigniew Jędrzejewski-Szmek
 

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-09-02 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 =

#2460 Non-responsive maintainers: ...
https://pagure.io/fesco/issue/2460
DECISION:
affix
amitshah
ggillies
ignotusp
luismartingil
mbartos
mhabrnal
mildew
nguzman
robled
sspreitz
svahl
are deemed non-responsive and their packages have been orphaned (+3, 0, 0).

(A few other names were initially listed in the ticket, but have responded and
their status has been cleared.)

= Followups =

#2454 Proposal: Require compiler / annobin updates to use rawhide gating 
https://pagure.io/fesco/issue/2454

#2416 Update 3rd party repo policy 
https://pagure.io/fesco/issue/2416

= New business =

(none)

= 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. 
___
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: Proposed Modular Policy for Fedora ELN

2020-08-24 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Aug 24, 2020 at 09:02:55AM -0400, Stephen Gallagher wrote:
> On Mon, Aug 24, 2020 at 8:56 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Mon, Aug 24, 2020 at 08:45:49AM -0400, Stephen Gallagher wrote:
> > > On Fri, Aug 21, 2020 at 1:57 PM Miro Hrončok  wrote:
> > > >
> > > > On 21. 08. 20 10:07, Zbigniew Jędrzejewski-Szmek wrote:
> > > > >> Josh listed some of the key reasons behind default streams: that
> > > > >> enterprise customers don't like to learn new commands. So default
> > > > >> streams allowed us to package content with shorter-than-RHEL-lifetime
> > > > >> and still `yum install foo` would install something the customer 
> > > > >> could
> > > > >> use.
> > > > > I guess that "shorter-than-RHEL-lifetime" is the big differentiator, 
> > > > > i.e.
> > > > > normal rpms cannot be yanked from the distribution, but a module can 
> > > > > be.
> > > >
> > > > Actually AFAIK modules shipped at GA cannot be yanked from the 
> > > > distribution
> > > > either. Certainly not in Fedora.
> > >
> > > That is correct; the modules cannot be removed from the distribution,
> > > but the encapsulation of them in a separate delivery mechanism enables
> > > the support *policy* to be different. (In particular, it's acceptable
> > > from a technical perspective for customers of RHEL to keep using an
> > > EOL module if they cannot transition in time; they just have to accept
> > > the risks.)
> >
> > Well, that confirms what I wrote in the part that was snipped:
> > > But technically there isn't much difference, and it's only policy that 
> > > sets
> > > those two cases apart. So instead of using default modules, why not 
> > > adjust the
> > > policy and use non-modular rpms with plain Obsoletes?
> > >
> > > (In fact, this simpler approach could be argued to be better, since the 
> > > technology
> > > to put Obsoletes in rpms is well established and understood and works 
> > > nicely, while
> > > stream Obsoletes are only being conceived.)
> >
> > I'll ask again: why not?
> 
> Well, among other things, RPM-level `Obsoletes:` will remove the
> packages from the end-user system, which exactly contradicts what I
> just said above.

We use fedora-obsolete-packages to remove packages from end-user systems.
Users can opt-out of installation of fedora-obsolete-packages and retain
packages that would be obsoleted [*].

The same mechanism could be used RHEL, for example by having 
'rhel-is-up-to-date.rpm'
installed by default, with newer versions doing the obsoletes for packages
that have been dropped. Users *may* stop the upgrade of rhel-is-up-to-date,
but then they know their system is using outdated packages. DNF will even
nicely tell them which ones.

This is: a) simple, b) well-understood, c) already implemented.

Zbyszek

[*] Right now fedora-obsolete-packages has Provides:libsolv-self-destruct-pkg(),
so this muddies the situation a bit. Let's assume that the packages in RHEL
would not have that set.
___
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: Moving tcpdump from /usr/sbin to /usr/bin

2020-08-24 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Aug 24, 2020 at 02:54:29PM +0200, Michal Ruprich wrote:
> Hi,
> 
> after a discussion with upstream, I will be moving tcpdump binary from
> /usr/sbin to /usr/bin, similar to how wireshark does this. If you can
> think of any reason why not to do this, please let me know.

Please provide a compat symlink to ../bin/tcpdump though. People
occasionally use the full path to various utilities (in scripts, or
in systemd units, in makefiles, etc.)

Zbyszek
___
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: Proposed Modular Policy for Fedora ELN

2020-08-24 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Aug 24, 2020 at 08:45:49AM -0400, Stephen Gallagher wrote:
> On Fri, Aug 21, 2020 at 1:57 PM Miro Hrončok  wrote:
> >
> > On 21. 08. 20 10:07, Zbigniew Jędrzejewski-Szmek wrote:
> > >> Josh listed some of the key reasons behind default streams: that
> > >> enterprise customers don't like to learn new commands. So default
> > >> streams allowed us to package content with shorter-than-RHEL-lifetime
> > >> and still `yum install foo` would install something the customer could
> > >> use.
> > > I guess that "shorter-than-RHEL-lifetime" is the big differentiator, i.e.
> > > normal rpms cannot be yanked from the distribution, but a module can be.
> >
> > Actually AFAIK modules shipped at GA cannot be yanked from the distribution
> > either. Certainly not in Fedora.
> 
> That is correct; the modules cannot be removed from the distribution,
> but the encapsulation of them in a separate delivery mechanism enables
> the support *policy* to be different. (In particular, it's acceptable
> from a technical perspective for customers of RHEL to keep using an
> EOL module if they cannot transition in time; they just have to accept
> the risks.)

Well, that confirms what I wrote in the part that was snipped:
> But technically there isn't much difference, and it's only policy that sets
> those two cases apart. So instead of using default modules, why not adjust the
> policy and use non-modular rpms with plain Obsoletes?
>
> (In fact, this simpler approach could be argued to be better, since the 
> technology
> to put Obsoletes in rpms is well established and understood and works nicely, 
> while
> stream Obsoletes are only being conceived.)

I'll ask again: why not?

Zbyszek
___
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: Proposed Modular Policy for Fedora ELN

2020-08-21 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Aug 20, 2020 at 02:17:09PM -0400, Stephen Gallagher wrote:
> On Thu, Aug 6, 2020 at 10:46 AM Miro Hrončok  wrote:
> >
> > On 05. 08. 20 21:36, Stephen Gallagher wrote:
> > > FESCo has requested that I submit the module policy once more to the
> > > Fedora development list for discussion. Feedback is welcome.
> > >
> > > == Requirements for Default Streams
> > > * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN
> > > permits defaults streams that adhere to the policy below.
> >
> > Since this has been discussed at lengths at FESCo and this is the first 
> > time it
> > has been brought here (thanks for doing it, Stephen), let me summarize my
> > concerns with allowing default modular streams in ELN.
> >
> > I would like to know if my concerns are valid or if I am just biased. Sorry 
> > for
> > the long email.
> >
> >
> > Fedora has experimented with default modular streams for several releases 
> > and we
> > seemed to be at an agreement that the experiment has failed:
> >
> > See https://pagure.io/fesco/issue/2406 which includes links to relevant 
> > previous
> > discussions on the topic. Admitting that default modular streams are bad 
> > took as
> > nearly two years, despite a few loud and persistent individuals pointing it 
> > out
> > since the beginning.
> >
> > While I understand the original idea behind the concept of default modular
> > streams concept, shipping defaults via non-modular content has been proven
> > superior to default modular streams -- it has been proven that default 
> > modular
> > streams cannot be better than nonmodular defaults and that they can only 
> > try to
> > be as good as them, while they are currently technologically failing to do 
> > that:
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D2LQ6C6FHDS2LMKPDGCLFJDNHAPA6Q2B/
> >
> >
> > The currently proposed modularity objective for Fedora admits that this 
> > won't be
> > fixed until ta least Fedora 35 and later:
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RF4GUWFIDIASBDKS2RUVDHTSAWCMCWL4/
> >
> > The current modularity tech-lead strongly discourages default modular 
> > streams:
> >
> > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310
> > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122502
> >
> 
> Those comments were from Daniel when talking about Fedora as it exists
> today. Not about ELN. Yes, he discourages their use in Fedora.
> However, ELN has a mission to be a bridge to future RHEL and that
> distribution has committed to default streams as a business necessity
> for multiple reasons (among them support lifecycle which is much
> harder to address via non-modular content).

Modularity that exists in Fedora today is also the Modularity as it
exists in ELN. We use the same DNF and associated tools everywhere, and
I hope nobody is proposing to diverge on that.
The arguments that were made in those comments apply to ELN too
equally well.

I don't think that "RHEL ... has committed to default
streams as a business necessity" is really true. The long reply that
Terry Bowling sent in parallel makes it clear that RH wants a certain
*user experience* (existing tools and commands continue to work, more software 
is available).
Technical details like whether there is a default stream or not are not
mentioned. If the default stream is replaced by non-modular rpms, users
are not likely to notice or care.

> > Yet despite all this, we got a proposal to allow default modular streams in 
> > ELN.
> > The messaging about this proposal suggests that later, default modular 
> > streams
> > might be proposed for Fedora as well.
> >
> It was written that way *at your request*. You specifically asked for
> a proposal for "Fedora" that we could initially apply only to "Fedora
> ELN". It seems disingenuous to now use that as an argument against it.

First, I don't remember Miro making such a request. I looked at the meeting [1]
notes where we agreed to take the Change-proposal route:

14:19:36  mhroncok: Once it's fleshed out, I can submit it as a 
Self-Contained Change, if you like
14:19:45  For ELN
14:19:53  sgallagh, I think that's acceptable
14:20:03  +1
14:20:04  sgallagh: I wasn't going to "require" this, but I would 
certainly appreciate that, thanks
14:20:04  sgallagh: yeah, that probably would be the best... so 
it follows our standard processes
14:20:04  we can also approve it essentially out of band since ELN 
rolls
14:20:09  sgallagh++
14:20:09  mhroncok: Karma for sgallagh changed to 7 (for the current 
release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:20:36  #action sgallagh to submit Self-Contained Change 
Proposal once ready

[1] 
https://meetbot-raw.fedoraproject.org/teams/fesco/fesco.2020-06-24-14.04.log.html

Second, for the sake of discussion, even if Miro did request this,
with all the respect I have for Miro, his opinion is just that 

Re: fedora-review fails due to no annobin in mock

2020-08-19 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Aug 19, 2020 at 08:15:21PM -, Artur Iwicki wrote:
> Recently (happened today and happened a month ago), whenever I try to run 
> fedora-review for a Review Request that includes a C/C++ program, the mock 
> build fails immediately due to gcc/g++ not being able to find the annobin 
> plugin.
> > cc1plus: fatal error: inaccessible plugin file plugin/annobin.so expanded 
> > from short plugin name annobin: No such file or directory
> 
> Downloading the SRPM of the package I want to review, adding "BuildRequires: 
> annobin" and running fedora-review on this modified SRPM works, though 
> obviously it's a rather tedious workaround.

As a work-around, you can do 'mock -i annobin', and then 'fedora-review -b 
nnn -o " -n"',
no need to modify the srpm.

Zbyszek
___
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: Coin4 build failure

2020-08-07 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Aug 06, 2020 at 07:58:10PM -0500, Richard Shaw wrote:
> /builddir/build/BUILD/coin-6enkw/src/xml/expat/xmlparse.c:94:3: error:
> #error You do not have support for any sources of high quality entropy
> enabled. For end user security, that is probably not what you want.

> Your options include:
> * Linux + glibc >=2.25 (getrandom): HAVE_GETRANDOM
> * Linux + glibc <2.25 (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM
> * BSD / macOS >=10.7 (arc4random_buf): HAVE_ARC4RANDOM_BUF
...

The first one is the one you want. So the question is how to get the
compilation script to detect that. Maybe just -DHAVE_GETRANDOM will work?

Zbyszek
___
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: Switching package to fragmented default configuration

2020-08-04 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Aug 04, 2020 at 07:05:45PM +0200, Miroslav Lichvar wrote:
> On Tue, Aug 04, 2020 at 04:32:35PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > It's nice to not require any files in /etc (so for example the admin
> > can do 'rm -rf /etc/*' to restore vendor defaults). So instead of
> > using /etc/chrony.conf to load other files, please consider just
> > building this logic directly into the code. There is also no need to
> > make those config paths configurable.
> 
> That's possible (the paths could be hardcoded in the systemd unit
> file), but is it a good idea to force the users to use the new system?
> If someone has a modified config, or is using one of the many ansible
> roles for configuring NTP for example, why should it stop working? We
> don't have to break configuration tools that just generate a config
> from scratch.

Backwards compatiblity should be kept obviously. In systemd we look at
{/usr,/usr/local,/etc,/run}/foo.conf and
{/usr,/usr/local,/etc,/run}/foo.conf.d/*.conf, so foo.conf is the main
config file, while the "drop-ins" in /etc/ have higher priority and
server as overrides. This is backwards compatible with having just
/etc/foo.conf.

> > > My concern is that it will basically break all existing tools that
> > > need to check and/or modify the configuration (e.g. anaconda). They
> > > will need to know the naming of the files which have specific settings
> > > in order to override them, or implement a parser duplicating the
> > > chronyd logic to figure out which files are loaded from where.
> > 
> > The whole goal of the config-in-dropin-files-logic is that anaconda
> > wouldn't parse existing config, it would just write
> > /etc/chrony.d/50-anaconda.conf that would override only the parts it
> > cares about.
> 
> The trouble is that a fragment having a different name cannot disable
> servers specified in a different fragment. If anaconda wanted to
> override the default servers, it would need to know the name of the
> fragment. In some cases users/vendors/products may want to specify
> additional servers, sometimes replace them.

This can be handled by having a directive that means "wipe previous
config for this setting". In systemd we handle this by treating an
empty assignment as special:
SystemCallFilter=open
SystemCallFilter=
SystemCallFilter=write
SystemCallFilter=read close
is equivalent to SystemCallFilter=write read close.

> > Also, please don't invent a new logic — just follow the same one that
> > systemd does [1]. This has the advantage that if something *needs* to
> > look all of config, it can reuse what an existing loader. Also, admins
> > don't need to learn a new set of rules. Ideally,
> > 'systemd-analyze cat-config chrony.conf' would just work.
> 
> I was following the liboverdrop logic, which probably adopted the
> systemd convention. For printing the whole configuration there is now
> a "chronyd -p" command. The systemd cat-config command seems to expect
> the ini-style syntax. That's not going to work here.

Zbyszek
___
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: Switching package to fragmented default configuration

2020-08-04 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Aug 04, 2020 at 05:11:49PM +0200, Miroslav Lichvar wrote:
> I'm considering to split the default configuration file in the chrony
> package to make it easier for vendors, products, and configuration
> tools to override some specific settings (like the default NTP
> servers) by dropping a file into a directory, instead of having to
> modify a packaged config file. It seems to be a modern trend, used
> by many packages in Fedora, and I have received some RFEs to adopt
> in chrony.
> 
> The default /etc/chrony.conf would just have a single directive
> loading configuration fragments from /etc/chrony.d and
> /var/lib/chrony.d (and maybe also /var/run/chrony.d).

It's nice to not require any files in /etc (so for example the admin
can do 'rm -rf /etc/*' to restore vendor defaults). So instead of
using /etc/chrony.conf to load other files, please consider just
building this logic directly into the code. There is also no need to
make those config paths configurable.

As to the locations to look at: /usr/lib or /usr/share (packaged
distro defaults), /usr/local/lib or /usr/share (local installed
defaults), /etc (admin overrides), /run (temporary overrides) are the
standard prefixes to look at. /var/lib is for persistent application
state, not config.

> My concern is that it will basically break all existing tools that
> need to check and/or modify the configuration (e.g. anaconda). They
> will need to know the naming of the files which have specific settings
> in order to override them, or implement a parser duplicating the
> chronyd logic to figure out which files are loaded from where.

The whole goal of the config-in-dropin-files-logic is that anaconda
wouldn't parse existing config, it would just write
/etc/chrony.d/50-anaconda.conf that would override only the parts it
cares about.

Also, please don't invent a new logic — just follow the same one that
systemd does [1]. This has the advantage that if something *needs* to
look all of config, it can reuse what an existing loader. Also, admins
don't need to learn a new set of rules. Ideally,
'systemd-analyze cat-config chrony.conf' would just work.

> Also,
> I'm not sure how user-friendly this is for regular users who modify
> the configuration manually.
> 
> Are there any recommendations for switching an existing single-config
> package to a fully fragmented configuration? Is it worth the trouble,
> or do you have any other suggestions?

Yes, it's definitely worth the trouble, it makes many things easier and
more robust.

Zbyszek

[1] We don't have a nice description of the logic anywhere. systemd.unit(5)
is the canonical source, but there there are many complications which
don't matter in the general case. Actually zram-generator.conf(5) which
was added recently seems to be a better reference:
https://github.com/systemd/zram-generator/blob/master/man/zram-generator.conf.md.
___
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: Proposal to Add: Log In/Out Blocker Criteria

2020-08-04 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Aug 04, 2020 at 09:18:56AM -0400, Ben Cotton wrote:
> On Tue, Aug 4, 2020 at 8:48 AM Kamil Paral  wrote:
> >
> > Actually, I'd make this even simpler. We already have a Beta criterion 
> > related to logging out (among others):
> > https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#Shutdown.2C_reboot.2C_logout
> >
> > So let's just include logging in as well, and we're done:
> > "Shutting down, rebooting, logging in and logging out must work using 
> > standard console commands and the mechanisms offered (if any) by all 
> > release-blocking desktops."
> >
> > We'd also update the "Work?" footnote:
> > "Similar to the Basic criterion for shutting down, shutdown and reboot 
> > mechanisms must take storage volumes down cleanly and correctly request a 
> > shutdown or reboot from the system firmware. Logging in must transfer the 
> > user from the login screen/prompt to his/her working environment, and 
> > logging out must return the user to the environment from which they logged 
> > in, working as expected."
> >
> Simple is good. I like this approach.

+1

Maybe "their" and not "his/her" — "his/her" is already starting to feel dated.

Zbyszek
___
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: systemd-resolved

2020-07-28 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Jul 28, 2020 at 11:22:58AM -0500, Michael Catanzaro wrote:
> I agree we should not replace /etc/resolv.conf if it's not already a
> symlink (although this will not be a common case, since by default
> it is a symlink managed by NetworkManager).
> 
> On Tue, Jul 28, 2020 at 11:07 am, Neal Gompa  wrote:
> >We can be smart here and replace the file when we detect that it's
> >managed by NetworkManager. Otherwise we won't replace it.
> 
> Currently we actually don't touch it at all, which is not good
> because it means systemd-resolved will not be managing resolv.conf
> on upgraded systems. We should replace it with a symlink to systemd
> if (and only if) it's managed by NetworkManager.

Right now there's the following scriptlet:

grep -q 'Generated by NetworkManager' /etc/resolv.conf 2>/dev/null && \
 
  echo -e '/etc/resolv.conf was generated by NetworkManager.\nConsider removing 
it to let systemd-resolved manage this file.' \
  
  || :
  
I.e. only a hint is emitted. I'm open to suggestions how to improve it.

Zbyszek
___
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: systemd autofs support (Was: Re: Btrfs by default status updates, 2020-07-26)

2020-07-27 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Jul 27, 2020 at 08:27:24PM +0100, Tomasz Kłoczko wrote:
> On Mon, 27 Jul 2020 at 20:05, Zbigniew Jędrzejewski-Szmek 
> wrote:
> [..]
> 
> > > So (a bit off-topic) what was wrong with autofs as a separate small
> > process
> > > started only when it was necessary? Do you remember that?
> >
> > Having automount support directly in pid1 allows automounts to be part
> > of the unit graph — with dependencies and triggering and failure actions.
> > The code to talk to the kernel interface is rather simple. The part
> > to tie into the rest of the unit framework is bigger. Having a separate
> > daemon would only make that bigger part even more complicated.
> >
> 
> Still it does not explain why automonting cannot be just a regular unit
> with a separated process.
> That way it still can be part of the "the unit graph", and both systemd
> units and SMF services are using dependencies.
> As communication with kennel space is done over /de/autofs and just checked
> and autofs and systemd are using that interface almost the same way.

It probably could. The general reason to keep things built into pid1
is that the code to communicate state to the separate process and failure
back to the main process would be more code than the actual "business logic"
running in the separate process. But let's not discuss this here — if 
we start discussing systemd design, we'll have another megathread on 
fedora-devel, and I don't think anyone wants that. systemd-devel is
a more appropriate place.

> At the moment it seems that the autofs bit is used only to mout per logged
> user tmpfs which looks like it could be mounted/umounted using the user
> systemd unit WITHOUT automounter. Am I right? If yes, using the automonter
> is kind of overkill because all that could be done without autofs. Instead
> have in kernel autofs and in userspace communication over /dev/autofs thi
> could be done with a top 0.5KB systemd unit yext file which will execute
> mount/umount commands with some exact params.

It is also used for anything which has x-systemd.automount, so the list is
open-ended.

Zbyszek
___
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: Btrfs by default status updates, 2020-07-26

2020-07-27 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Jul 27, 2020 at 07:20:16PM +0100, Tomasz Kłoczko wrote:
> On Mon, 27 Jul 2020 at 18:35, Zbigniew Jędrzejewski-Szmek 
> wrote:
> [..]
> 
> > > Why the heck dist kernel cannot be without ANY fs support? I've been
> > using
> > > such a kernel (sic!) 15y ago !!!
> >
> > Tomasz,
> > take a step back... This is just a kernel config change, no reason to
> > get angry.
> >
> > > Why is it still automonter hardcoded into the kernel even if it is
> > > completely useless on a typical single workstation?
> > It is used by systemd for various less-frequently used mount points
> > and automount entries can be configured in /etc/fstab.
> >
> 
> Really?
> (my jaw is on the floor crashed into the pieces)
> I must honestly confess that in the meantime systemd swallowed autofs as
> well!
> 
> So (a bit off-topic) what was wrong with autofs as a separate small process
> started only when it was necessary? Do you remember that?

Having automount support directly in pid1 allows automounts to be part
of the unit graph — with dependencies and triggering and failure actions.
The code to talk to the kernel interface is rather simple. The part
to tie into the rest of the unit framework is bigger. Having a separate
daemon would only make that bigger part even more complicated.

> Because with some bits of the autofs user space process in systemd when
> someone would be using automonter maps loaded over LDAP (going over glibc
> NSS layer) it will be some redundancy between those parts.

You can still have the automount daemon. For the cases where you want
use automounts defined in LDAP that's totally appropriate.

> PS. I think that now I have the proper impuls/reason to port SMF to Linux.
> kloczek

:)

Zbyszek
___
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: Btrfs by default status updates, 2020-07-26

2020-07-27 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Jul 27, 2020 at 06:24:06PM +0100, Tomasz Kłoczko wrote:
> On Mon, 27 Jul 2020 at 18:00, Chris Murphy  wrote:
> [..]
> 
> > + btrfs driver is now built-in to the kernel, rather than as a module
> >
> 
> Classic .. from frying pan to open fire.
> 
> Why the heck dist kernel cannot be without ANY fs support? I've been using
> such a kernel (sic!) 15y ago !!!

Tomasz,
take a step back... This is just a kernel config change, no reason to
get angry.

> Why is it still automonter hardcoded into the kernel even if it is
> completely useless on a typical single workstation?
It is used by systemd for various less-frequently used mount points
and automount entries can be configured in /etc/fstab.

Zbyszek

> (which is still probably most of the cases when Fedora is used now).
> Currently dracut can generate initrd with loading correct root fs module
> and even block layer (nvme/sata) or network layer network card module if
> boot is done with loading by grub kernel and initrd over network on using
> NFS on root fs.
> Why do people who choose other FSess like xfs or ext4 or even f2fs for some
> embedded systems are forced to have wasted available small memory footprint
> by things which can be loaded as modules on demand?
> 
> Only because with such a kernel it could not be possible to say that Fedora
> is supporting btrfs as default fs? (and buy this it would make all those
> talks about default fs obsolete?).
> Why Fedora cannot have only btrfs as default *proposed by
> anaconda/kickstart* FS?
> 
> kloczek
> -- 
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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


Re: ar (binutils) segfaulting in Rawhide - known bug?

2020-07-27 Thread Zbigniew Jędrzejewski-Szmek
On Sun, Jul 26, 2020 at 11:03:58PM -0600, Jeff Law wrote:
> On Sun, 2020-07-26 at 09:39 -0600, Jerry James wrote:
> > On Fri, Jul 24, 2020 at 6:41 PM Kevin Fenzi  wrote:
> > > On Fri, Jul 24, 2020 at 04:55:31PM -0600, Jeff Law wrote:
> > > > What would help would be if someone could untag that version of 
> > > > binutils so that
> > > > it doesn't show up in the buildroots anymore.  It's clearly fubar'd.
> > > 
> > > Done.
> > 
> > H.  Yet my most recent build attempt, just now, failed with a
> > linker segfault on all arches:
> > 
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1546752
> > 
> > This is with:
> > annobin-9.24.2-fc33
> > binutils-2.35-1.fc33
> > gcc-10.2.1-1.fc33
> > glibc-2.31.9000-21.fc33
> As Kevin mentioned in a followup, he's untagged the 2.35 build so this should 
> be
> working again.
> 
> I think I see the root cause in the linker now.  It's probably an uncommon
> scenario, but I doubt binutils is the only affected package.
> 
> The even better news is I think we can go ahead and green light the mass 
> rebuild
> for Monday.  Two reasons.  One, I expect the preconditions necessary to trip 
> the
> bug to be uncommon.  Two, I think we can reliably detect a broken binary by 
> the
> existence of absolute symbols in the dynamic symbol table.
> 
> The latter in particular means we've got a method where we can find affected
> packages while Nick and I iterate on the linker fix.  So even if the bug leaks
> into packages, we can find them and do targeted rebuilds.

The problem with that is that if broken builds land in the buildroot of
other packages, those dependent packages might either a) fail to build,
b) be built incorrectly, for example because feature detection fails.
Situation a) happens in mass rebuilds quite a lot anyway, so it's not
a big issue, since the build would just be repeated. But b) is more serious.
Even if you detect that a package was faulty and needs to be rebuilt,
we might have to also rebuild all packages using that faulty package
as a build dependency, recursively.  This quickly becomes messy :(

Zbyszek
___
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: Dropping elfutils-libelf-devel-static and elfutils-devel-static subpackages

2020-07-25 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jul 24, 2020 at 05:00:16PM +0200, Fabio Valentini wrote:
> > BTW. Can Obsoletes ever be removed? We have an Obsoletes: libelf <=
> > 0.8.2-2 on elfutils-libelf since the original cvsdist import of 2004
> > because there used to be a different libelf implementation (with a dead
> > upstream these days). Can I remove that? Or is it better to keep it
> > "just in case"?
> 
> Obsoletes for removed / renamed packages can usually be safely removed
> after two stable fedora releases had them.

I think it's a good idea to keep them around to make it easier to
upgrade from older versions, even if the upgrade is not officially
supported. The "two release" rule is the minimum, and usually it
doesn't hurt in any way to keep such obsoletes for a while (though
not indefinitely).

Zbyszek
___
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: Remove all non UK/USA English spell checker variants from default Fedora installation

2020-07-19 Thread Zbigniew Jędrzejewski-Szmek
On Sat, Jul 18, 2020 at 03:21:41PM +0200, Kevin Kofler wrote:
> Germano Massullo wrote:
> > Since the huge list is brought by hunspell-en, can we just ship Fedora
> > with hunspell-en-GB and hunspell-en-US ?
> 
> I would even argue for shipping en_US only. It is the default language of 
> the distribution. Why would British be any more worth shipping than any 
> other language out there?

+1. en_US the default and the most commonly used English dialect, with
en_US messages often used by people who are not native speakers. All
other dialects are mostly of interest for speakers of that dialect and
don't need to be shown by default.

Zbyszek
___
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 in 6th gear

2020-07-16 Thread Zbigniew Jędrzejewski-Szmek
In the FESCo meeting summary email sent out today there were 10
changes approved. I had the feeling that this is more than usual,
so I took a look at the wiki.

Tally (systemd-wide and self-contained):
F20: 14 + 22
F21: 28 + 34
F22: 21 + 15
F23: 12 +  7
F24: 20 + 23
F25:  9 + 11
F26: 17 + 22
F27: 20 + 15
F28: 31 + 19
F29: 23 + 20
F30: 25 + 24
F31: 21 + 21
F32: 23 + 20
F33: 40 + 18 (and growing)

Seems that this be a busy release :)

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


Summary/Minutes from yesterday's FESCo Meeting (2020-07-15) + additional approved tickets

2020-07-16 Thread Zbigniew Jędrzejewski-Szmek
= Yesterday's Meeting =

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-15/fesco.2020-07-15-14.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-15/fesco.2020-07-15-14.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-15/fesco.2020-07-15-14.00.log.html

Meeting summary
---
* init process  (zbyszek, 14:00:22)

* #2429 F33 System-Wide Change: Make btrfs the default file system for
  desktop variants  (zbyszek, 14:03:54)
  * LINK:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED_status=ON_DEV_status=ON_QA_status=VERIFIED_status=RELEASE_PENDING=Fedora=kernel=OP=OP=product=component=alias=short_desc=status_whiteboard=CP=CP=OR_id=11221750=substring=substring=substring=substring=substring=Fedora_format=advanced_desc=btrfs_desc_type=allwordssubstr=btrfs=btrfs=btrfs=btrfs=btrfs
(zbyszek, 14:12:49)
  * LINK: https://github.com/rhinstaller/anaconda/pull/2728
(King_InuYasha, 14:34:25)
  * AGREED: APPROVED (+8, 0, -1)  (zbyszek, 14:35:39)

* #2441 F34 System-Wide Change: RPM-level auto release and changelog
  bumping  (zbyszek, 14:37:33)
  * AGREED: We'll continue the discussion in the ticket and on the
mailing list and return to this next week (+6, 0, 0)  (zbyszek,
14:43:40)

* #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros -
  Detached rpm changelogs  (zbyszek, 14:44:17)
  * We'll continue the discussion in the ticket and on the mailing list
and return to this next week  (zbyszek, 14:46:54)

* #2445 Proposal: Make the "shortcut" decision process require a
  specific request and assent  (zbyszek, 14:47:04)
  * ACTION: bcotton to adjust the PR based on discussion  (zbyszek,
15:01:20)

* Next week's chair  (zbyszek, 15:01:36)
  * ACTION: ignatenkobrain will chair next meeting  (zbyszek, 15:01:54)

* Open Floor  (zbyszek, 15:02:01)
  * LINK:

https://fedoraproject.org/wiki/Infrastructure/2020-post-datacenter-move-known-issues
(nirik, 15:03:54)

Meeting ended at 15:10:16 UTC.


Action Items

* bcotton to adjust the PR based on discussion
* ignatenkobrain will chair next meeting


= Discussed and Voted in the Ticket (2nd batch) =

#2435 F33 Self-Contained Change: Enable EarlyOOM on Fedora KDE
https://pagure.io/fesco/issue/2435
APPROVED (+6,0,-0)

#2436 F33 System-Wide Change: OpenLDAP without Non-threaded Libraries
https://pagure.io/fesco/issue/2436
APPROVED (+6,0,-0)

#2438 F33 Self-Contained Change: Make the unversioned %{__python} macro error 
by default
https://pagure.io/fesco/issue/2438
APPROVED (+6,0,-0)

#2439 F33 System-Wide Change: IBus 1.5.23
https://pagure.io/fesco/issue/2439
APPROVED (+4,0,-0) as a self-contained change.

#2442 F33 System-Wide Change: Introduce Storage Instantiation Daemon
https://pagure.io/fesco/issue/2442
APPROVED (+4,1,-0) as a self-contained change.



On Wed, Jul 15, 2020 at 06:44:56AM +, Zbigniew Jędrzejewski-Szmek wrote:
> = Discussed and Voted in the Ticket =
> 
> #2431 F33 System-Wide Change: Cleanup GNOME Hidden Boot Menu Integration
> https://pagure.io/fesco/issue/2431
> APPROVED (+7, 0, 0)
> 
> #2432 F33 System-Wide Change: NetworkManager keyfile instead of ifcfg-rh
> https://pagure.io/fesco/issue/2432
> APPROVED (+5, 0, 0)
> 
> #2433 F33 System-Wide Change: Disable dmraid-activation.service on first run 
> if no dmraid sets are found
> https://pagure.io/fesco/issue/2433
> APPROVED (+6, 0, 0)
> 
> #2434 F33 System-Wide Change: Remove device-mapper-multipath from the Fedora 
> workstation livecd
> https://pagure.io/fesco/issue/2434
> APPROVED (+7, 0, 0)
> 
> Please note that there's a bunch of tickets which are close to
> approval, but for which the one-week voting period ends in the
> afternoon today. In the very likely case that they are approved, I'll
> include their announcement in today's meeting summary.
___
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: changing the subject format of change proposal announcements

2020-07-16 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Jul 15, 2020 at 11:49:13AM -0700, Samuel Sieb wrote:
> On 7/15/20 3:30 AM, Daniel P. Berrangé wrote:
> >FCP33: Support PARSEC [Self-Contained]
> >FCP33: PostgreSQL 31 [Self-Contained]
> >FCP33: Policy for Modules in Fedora and Fedora ELN [Self-Contained]
> >FCP33: Golang 1.15 [Late, System-Wide]
> >FCP33: X.org Utility Deaggregation [Self-Contained]

"F33: ..." would be even better.

Zbyszek
___
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-15)

2020-07-15 Thread Zbigniew Jędrzejewski-Szmek
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-15 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 =

#2431 F33 System-Wide Change: Cleanup GNOME Hidden Boot Menu Integration
https://pagure.io/fesco/issue/2431
APPROVED (+7, 0, 0)

#2432 F33 System-Wide Change: NetworkManager keyfile instead of ifcfg-rh
https://pagure.io/fesco/issue/2432
APPROVED (+5, 0, 0)

#2433 F33 System-Wide Change: Disable dmraid-activation.service on first run if 
no dmraid sets are found
https://pagure.io/fesco/issue/2433
APPROVED (+6, 0, 0)

#2434 F33 System-Wide Change: Remove device-mapper-multipath from the Fedora 
workstation livecd
https://pagure.io/fesco/issue/2434
APPROVED (+7, 0, 0)

Please note that there's a bunch of tickets which are close to
approval, but for which the one-week voting period ends in the
afternoon today. In the very likely case that they are approved, I'll
include their announcement in today's meeting summary.


= Followups =


= New business =

#2429 F33 System-Wide Change: Make btrfs the default file system for desktop 
variants
https://pagure.io/fesco/issue/2429

#2441 F34 System-Wide Change: RPM-level auto release and changelog bumping
https://pagure.io/fesco/issue/2441

#2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached 
rpm changelogs
https://pagure.io/fesco/issue/2440

#2445 Proposal: Make the "shortcut" decision process require a specific request 
and assent
https://pagure.io/fesco/issue/2445


= 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. 
___
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: gdb says "Unexpected size of section `.reg-xstate/...` in core file

2020-07-13 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Jul 13, 2020 at 10:25:36AM +0200, Jan Kratochvil wrote:
> On Sat, 11 Jul 2020 16:52:41 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > warning: Unexpected size of section `.reg-xstate/59286' in core file.
> > #0  0x7f552f8b3b95 in raise () from /lib64/libc.so.6
> > (gdb)
> > 
> > Is this gcc, gdb, binutils, something else?
> 
> gdb is older than kernel and you have too new CPU.
>   https://stackoverflow.com/a/62866856/2995591

Thanks, that looks promising.

> You did not say versions + CPU you use.

It's a VM (libvirt, kvm, uefi). /proc/cpuinfo shows xsave is present:

vendor_id  : GenuineIntel
cpu family : 6
model: 94
model name   : Intel Core Processor (Skylake, IBRS)
stepping : 3
microcode: 0x1
cpu MHz: 2591.998
cache size : 16384 KB
physical id: 0
siblings : 1
core id: 0
cpu cores  : 1
apicid   : 0
initial apicid : 0
fpu: yes
fpu_exception  : yes
cpuid level: 13
wp : yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm 
constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx 
ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes 
xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault 
invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid 
ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap 
clflushopt xsaveopt xsavec xgetbv1 xsaves arat umip md_clear arch_capabilities
vmx flags: vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb 
flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest shadow_vmcs 
pml
bugs   : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf 
mds swapgs itlb_multihit srbds
bogomips   : 5183.99
clflush size   : 64
cache_alignment: 64
address sizes  : 40 bits physical, 48 bits virtual

The guest is 5.8.0-0.rc2.20200622git625d3449788f.1.fc33.x86_64, and has
gdb-9.2-2.fc33.x86_64 which is the latest rawhide build... Does gdb need 
updating?

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


gdb says "Unexpected size of section `.reg-xstate/...` in core file

2020-07-11 Thread Zbigniew Jędrzejewski-Szmek
Hi,

I'm not sure if this is a bug and if it is, where it is...

$ coredumpctl gdb
...
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib/systemd/systemd-oomd'.
Program terminated with signal SIGABRT, Aborted.

warning: Unexpected size of section `.reg-xstate/59286' in core file.
#0  0x7f552f8b3b95 in raise () from /lib64/libc.so.6
(gdb)

Is this gcc, gdb, binutils, something else?

Zbyszek
___
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: X.org Utility Deaggregation - Fedora 33 Self-Contained Change proposal

2020-07-11 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jul 10, 2020 at 03:55:20PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
> 
> == Summary ==
> 
> The collection packages
> `xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}` will be
> retired, and the individual utilities within them will be packaged
> separately.

> Typically not all of the utilities in
> a given package will be needed simultaneously, and the version numbers
> of the package do not logically reflect the upstream version of any
> particular component. Most of the packages that require a particular
> component Require that specific component name, as opposed to the
> collection package. In addition, some of the components (notably
> `luit` and `edid-decode`) are not in fact X.org packages anymore but
> have other upstreams.

Such aggregate packaging is against the packaging guidelines. So yeah,
splitting them up seems like a good thing.

> == Feedback ==
> It is not strictly necessary to retire the collection packages, they
> could instead be converted to metapackages like `xorg-x11-drivers`
> that simply Require all the things they used to Provide. However, as
> the majority of consumers of these utilities depend on the specific
> utility and not the collection, retiring them should require touching
> quite few consumers. On the other hand, the upgrade migration path is
> more difficult if the collections are retired. I'm open to either
> approach.

Retaining the metapackages is easier, but it requires some (very small)
ongoing maintenance. So I'd vote for for retiring them, if you can update
all the refs, repoquery below.

> == Upgrade/compatibility impact ==
> If the collection packages are retired, the new packaging will need to
> Obsolete the old collection packages.

Ideally, have Obsoletes from all the new replacement packages so that dnf
knows to install them all on upgrades.

Repoquery:
$ for i in xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}; do echo == 
$i; dnf repoquery --whatrequires $i; echo; done
== xorg-x11-apps
InventorXt-0:2.1.5-72.fc32.x86_64
ddd-0:3.3.12-34.fc32.x86_64
plasma-workspace-0:5.19.3-1.fc33.x86_64
slim-0:1.3.6-16.fc33.x86_64
squeak-vm-0:4.10.2.2614-23.fc32.x86_64
xmonad-core-0:0.15-5.fc32.x86_64

== xorg-x11-font-utils
cmatrix-x11-fonts-0:1.2a-6.fc32.x86_64
iso8859-2-100dpi-fonts-0:1.0-40.fc32.noarch
iso8859-2-75dpi-fonts-0:1.0-40.fc32.noarch
iso8859-2-misc-fonts-0:1.0-40.fc32.noarch
libdockapp-fonts-0:0.7.3-1.fc33.x86_64
nethack-bitmap-fonts-core-0:3.6.6-1.fc33.noarch
nxagent-0:3.5.99.24-1.fc33.x86_64
urw-base35-bookman-fonts-0:20170801-14.fc32.noarch
urw-base35-c059-fonts-0:20170801-14.fc32.noarch
urw-base35-d05l-fonts-0:20170801-14.fc32.noarch
urw-base35-gothic-fonts-0:20170801-14.fc32.noarch
urw-base35-nimbus-mono-ps-fonts-0:20170801-14.fc32.noarch
urw-base35-nimbus-roman-fonts-0:20170801-14.fc32.noarch
urw-base35-nimbus-sans-fonts-0:20170801-14.fc32.noarch
urw-base35-p052-fonts-0:20170801-14.fc32.noarch
urw-base35-standard-symbols-ps-fonts-0:20170801-14.fc32.noarch
urw-base35-z003-fonts-0:20170801-14.fc32.noarch
xorg-x11-fonts-100dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-75dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-1-100dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-1-75dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-14-100dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-14-75dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-15-100dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-15-75dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-2-100dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-2-75dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-9-100dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-ISO8859-9-75dpi-0:7.5-24.fc32.noarch
xorg-x11-fonts-Type1-0:7.5-24.fc32.noarch
xorg-x11-fonts-cyrillic-0:7.5-24.fc32.noarch
xorg-x11-fonts-ethiopic-0:7.5-24.fc32.noarch
xorg-x11-fonts-misc-0:7.5-24.fc32.noarch

== xorg-x11-server-utils
arandr-0:0.1.10-4.fc33.noarch
classification-banner-0:1.7.0-8.fc33.noarch
gdm-1:3.37.1-2.fc33.x86_64
i-nex-0:7.6.1-2.fc32.x86_64
kdelibs3-0:3.5.10-105.fc33.x86_64
lutris-0:0.5.7-1.fc33.x86_64
lxde-common-0:0.99.2-11.fc33.noarch
lxrandr-0:0.3.2-3.fc32.x86_64
ocaml-camlimages-0:4.2.5-22.fc33.x86_64
plasma-workspace-0:5.19.3-1.fc33.x86_64
policycoreutils-sandbox-0:3.0-4.fc33.x86_64
urw-base35-bookman-fonts-0:20170801-14.fc32.noarch
urw-base35-c059-fonts-0:20170801-14.fc32.noarch
urw-base35-d05l-fonts-0:20170801-14.fc32.noarch
urw-base35-gothic-fonts-0:20170801-14.fc32.noarch
urw-base35-nimbus-mono-ps-fonts-0:20170801-14.fc32.noarch
urw-base35-nimbus-roman-fonts-0:20170801-14.fc32.noarch
urw-base35-nimbus-sans-fonts-0:20170801-14.fc32.noarch
urw-base35-p052-fonts-0:20170801-14.fc32.noarch
urw-base35-standard-symbols-ps-fonts-0:20170801-14.fc32.noarch
urw-base35-z003-fonts-0:20170801-14.fc32.noarch
xfce4-session-0:4.14.2-1.fc33.x86_64
xkeycaps-0:2.46-27.fc32.x86_64
xorg-x11-xinit-0:1.4.0-6.fc32.x86_64
xpra-0:4.0.2-1.fc33.x86_64

== xorg-x11-utils

Re: Btrfs in Silverblue

2020-07-10 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jul 10, 2020 at 09:34:36AM -0600, Chris Murphy wrote:
> On Fri, Jul 10, 2020, 6:07 AM Lennart Poettering 
> wrote:
> 
> > On Fr, 10.07.20 06:50, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek 
> > wrote:
> > > >
> > > > I haven't seen any mention of Silverblue in the Btrfs discussions.
> > Will Silverblue also switch to Btrfs if the change is approved?
> > > >
> > > > I've tested installing Silverblue 32 and Rawhide with the default
> > Btrfs partitioning suggested by Anaconda, and in both cases the system
> > failed to boot after installation. It couldn't mount the Btrfs subvolumes.
> > > >
> > > > Is that a known issue or should I report it as a bug?
> > > >
> > >
> > > The expectation is that Silverblue will follow along with Workstation,
> > > yes. We do know about the bug and have a fix proposed to Anaconda:
> > > https://github.com/rhinstaller/anaconda/pull/2720
> >
> > Instead of passing this in each time on the kernel cmdline, maybe just
> > use "btrfs subvol set-default" to se the default subvolume to mount,
> > after mkfs.
> >
> > That makes things a lot more robust, as btrfs will then just work like
> > any other fs even if you insert the root subvol in between like
> > anaconda apparently does.
> >
> > I think there's big value in allowing short kernel cmdlines that are
> > as similar as possible everywhere, instead of blowing it up with
> > different switches for every single case.
> 
> 
> I agree with all of the above, but there is a contra argument. There is
> something to be said about having an understandable system, one that self
> describes how it's assembled, and boots. Changing the default subvolume
> obscures this, and now one of the "connect the dots" steps of boot becomes
> a dot on a completely different page in another book.
> 
> Therefore I'm not certain.

I agree with both of you, but I think the concept of default subvolume
is fairly natural and does not make things more confusing. When I pause
to think about this, I know that the root subvolume is "just a subvolume",
but by default I think of the the root subvolume as the partition itself
and the other subvolumes as less important.  So elevating the root subvolume
to be the default subvolume feels right.

Zbyszek
___
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: PSA: dnf autoremove cleans fedora-repos-modular

2020-07-09 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Jul 09, 2020 at 08:40:52AM -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 7:45:07 AM MST Igor Raits wrote:
> > On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
> > > Unless I'm mistaken, it should only be present if the user manually
> > > installed
> > > it, and opted into modularity, right?
> > 
> > 
> > No, it should be installed by default.
> 
> What was the point of breaking it out into a separate package, if it's still 
> going to be installed on end users' systems by default?

The goal is to have continuity in behaviour and avoid surprises for
users. Existing systems behave as before, new installations get the
full set of packages available, but users who wish to may opt out.
This is also what got approved by FESCo.

> I can obviously see it 
> being removed on systems currently using modular repos as an issue, but I'm 
> not sure it makes sense to throw it on for systems not currently using it.

It is being removed without taking into account if the user has any
modular packages installed. But even if they don't, that's not what we
want/agreed to do, see above.

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

2020-07-09 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Jul 07, 2020 at 09:44:47PM +0200, Markus Larsson wrote:
> 
> 
> 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.

+1

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

Yeah, that's how I understood the reference. Right now I don't see a
particularly strong reason to change the name, so I'm mildly negative.
But if enough people find the name offensive, I'll reconsider.

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

2020-07-09 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Jul 08, 2020 at 11:31:20AM -0400, Matthew Miller wrote:
> On Wed, Jul 08, 2020 at 03:48:23PM +0200, Till Maas wrote:
> > Just had another idea, how about instead of branch down from the rawhide
> > branch to new branched to make Rawhide always use the fxy version that
> > it develops. So instead of creating branched f33 later we would rename
> > master to f33 now and then once we need to branch we branch of Rawhide
> > as f34? There could still be a symbolic ref called rawhide for the
> > latest rawhide for convenience. What do you think?
> 
> I do like this, because it reflects the actual process. However, it does ask
> something of our git forge web front end: what would it show by default?

I don't see much benefit from this. First, I disagree that it reflects
the process better. In almost all cases I know development is done in
the master branch, and changes from there are often either
fast-forwarded or cherry-picked into the other branches. Second, I
don't see what improvement this would bring. If we were to change the
branching pattern, that we have been successfully using for years and
that people are accustomed to, there should be some clear reason.

A change of the branching pattern is not helpful to this change,
because we would still need *some* constant name for the
master/rawhide/latest branch, so the new renamed name will still be
visible to users and used for various purposes.

And mixing the two makes the (already complicated) process of renaming more
likely to fail.

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


nodebug kernel repo file missing

2020-07-08 Thread Zbigniew Jędrzejewski-Szmek
https://fedoraproject.org/wiki/RawhideKernelNodebug
links to
http://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo
which gives 404 now. The kernels seems to be there though. But without
the repo file it's not easy to enable.

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

2020-07-07 Thread Zbigniew Jędrzejewski-Szmek
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.

(*) If there are two installations with overlapping kernel versions, the UI
is not going to be great, because there will be entries like
Fedora 33 (Workstation) 5.11.21-23.fc33.amd64 08a5690a2eed47cf92ac0a5d2e3cf6b0
Fedora 33 (Workstation) 5.11.21-23.fc33.amd64 949499494994999393939ad2ad99
Fedora 33 (Workstation) 5.10.11-18.fc33.amd64 08a5690a2eed47cf92ac0a5d2e3cf6b0
Fedora 33 (Workstation) 5.10.11-18.fc33.amd64 949499494994999393939ad2ad99
i.e. the entries for the two installations will be interleaved. So the
user needs to remember that e.g. 08a5690a2eed47cf92ac0a5d2e3cf6b0 is the
installation with ext4 and 949499494994999393939ad2ad99 the one with
btrfs.

Zbyszek
___
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-legal-list] Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

2020-07-04 Thread Zbigniew Jędrzejewski-Szmek
On Sat, Jul 04, 2020 at 05:20:48PM +0200, Iñaki Ucar wrote:
> On Sat, 4 Jul 2020 at 16:20, Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > > > Would the maintainer consider switching the whole thing to LGPLv3?
> > > > This would preserve the freeness of his code and be much less hassle
> > > > for everyone involved, with no interpretation of new legal texts 
> > > > required.
> > >
> > > LGPL has other implications towards proprietary software, and that's
> > > what the authors specifically want to protect, so that's a hard line.
> >
> > I'm not sure what you mean. LGPL keeps the code free but allows it to be
> > freely combined with software under different licenses, which is what we
> > want in this case.
> 
> Yeap, but it's more permissive also with the FlexiBLAS interface (the
> one that enables hooking into the duplicated BLAS/LAPACK interface,
> the one that BLAS/LAPACK consumers are not using), and this is what
> the authors do not want.

OK. Thanks for the clarification.

Maybe talk with the authors and tell them that a few functions to provide
this extra interface are not important enough to create all the hassle with
GPLv3 for a commonly used library and that LGPL would protect their code
almost as well? I assume that they want their library to be widely used,
and this strict licensing will be a constant source of problems because
many existing scientific packages are using more liberal licensing and will
not want to change their licensing to accommodate flexiblas.

> > > Wouldn't the Classpath Exception [1] be appropriate here? This
> > > wouldn't require the interpretation of a new legal text.
> >
> > Classpath exception talks about "executable". This isn't very precise,
> > but at least in normal speech, a library is not an executable, so the
> > classpath exception would not cover other libraries which link to
> > flexiblass. So for example, numpy would not be covered by the exception.
> 
> True. But what about the "Linking over a controlled interface
> exception"? That sounds like exactly this case:
> https://www.gnu.org/licenses/gpl-faq.en.html#LinkingOverControlledInterface

Yep, that seems like it would work. The first para contains a legal
interpretation of GPLv3 and thus doesn't belong in the exception text.
But the rest is OK.

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


  1   2   3   4   5   6   7   8   9   10   >