Re: FSL license

[Tom Hughes via devel]

On 30/05/2020 12:00, Ankur Sinha wrote:


However, the License that the Oxford University has released it under
has certain clauses that make me unsure if it is OK for inclusion in
Fedora. Could someone please have a look?

https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/Licence


The "solely for non-commercial use" is a field of use
restriction which rules it out.

Tom

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

Re: Need assistance to build ispc

[Tom Hughes via devel]

On 09/06/2020 08:54, Kalev Lember wrote:


The build failed with:

/builddir/build/BUILD/ispc-1.13.0/src/bitcode_lib.cpp: In member function 'void 
BitcodeLib::print() const':
/builddir/build/BUILD/ispc-1.13.0/src/bitcode_lib.cpp:61:17: error: variable 
'type' set but not used [-Werror=unused-but-set-variable]
61 | const char *type = nullptr;
   | ^~~~

cc1plus: all warnings being treated as errors

This means that the compiler found a tiny warning (unused variable) but 
treated it as an error because -Werror was set during the build.


What I would suggest doing is looking into how to disable -Werror (it 
could be a configure flag) or perhaps just patch it out for Fedora 
builds. -Werror makes a lot of sense for upstream where they want to 
make sure their build is warning free, but not for a distribution such 
as Fedora where we introduce new changes all the time (each compiler 
adds new, different warnings) and it's completely impractical to have 
-Werror turned on for our builds.


It looks to be hard coded upstream:

  https://github.com/ispc/ispc/blob/master/CMakeLists.txt#L355

so I suggest just adding to the spec:

  sed -i 's| -Werror | |g' CMakeLists.txt

as is already being done for some other flags.

Tom

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

Re: The future of legacy BIOS support in Fedora.

[Tom Hughes via devel]

On 30/06/2020 15:00, Florian Weimer wrote:

* Jóhann B. Guðmundsson:


Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes it beg the question if now would not be the time to stop
supporting booting in legacy bios mode and move to uefi only supported
boot which has been available on any common intel based x86 platform
since atleast 2005.


Even for virtualization?  Not sure if that can be done.


Good point. Certainly libvirt still defaults to legacy BIOS and I don't
think UEFI is even possible without manually editing the XML definition 
for the machine.


Tom

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

Re: The future of legacy BIOS support in Fedora.

[Tom Hughes via devel]

On 30/06/2020 14:56, Igor Raits wrote:


I think there are many people still install OS in the legacy mode, but
I don't really have numbers. One thing we should definitely do if we
deprecate legacy BIOS is to properly warn users that still use this
configuration, develop tooling for them if possible for migration and
do not allow upgrades that will simply break their system.


Certainly until very recently I have tended to do legacy BIOS installs
even on new machines - it's only really in the last few months that I've
started using UEFI by default instead.

I assume that we're only talking about new installs here anyway. I'm
pretty sure switching an existing install would be something for
advanced users only and might not really be possible in many cases
due to the need to fine space for an EFI system partition.

Tom

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

Re: The future of legacy BIOS support in Fedora.

[Tom Hughes via devel]

On 30/06/2020 15:25, Marcin Juszkiewicz wrote:

W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze:

On 30/06/2020 15:00, Florian Weimer wrote:

* Jóhann B. Guðmundsson:


Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes it beg the question if now would not be the time to stop
supporting booting in legacy bios mode and move to uefi only
supported boot which has been available on any common intel based
x86 platform since atleast 2005.


Even for virtualization?  Not sure if that can be done.


Good point. Certainly libvirt still defaults to legacy BIOS and I
don't think UEFI is even possible without manually editing the XML
definition for the machine.


New installs for x86-64 VM can be BIOS of UEFI for quite some years.
For both i440fx and q35 variants.


I literally did an F31 install to a new instance two days
ago and don't recall being offered any option.

Same for F32 actually - the install failed but I had got as
far as creating the machine without being asked.

Tom

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

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

[Tom Hughes via devel]

On 01/07/2020 11:53, Richard W.M. Jones wrote:

On Tue, Jun 30, 2020 at 10:30:21AM -0400, Owen Taylor wrote:

So, this was discussed quite a bit in
https://pagure.io/fedora-workstation/issue/71 and the conclusion that
the Workstatopn Working Group came to 3 months ago was that we didn't
want to do this. We basically understood that main way of using
thermald was to use the proprietary dptfxtract tool to extract a
profile from ACPI - and as such, thermald wasn't something Fedora
should install by default. This functionality can't be properly
integrated into Fedora and "just work" for users if it requires a
proprietary tool and extra steps.


Is there some background about why dptfxtract is proprietary?  (I see
that it's a program provided by Intel.)  Is it just because no one's
done the work to make a free equivalent or does it require some
secret/patented/whatever knowledge to work?


There is work being done to make thermald read the
tables from the BIOS directly, including supporting
more advanced features that dptfxtract doesn't. More
details here:

https://mjg59.dreamwidth.org/54923.html

and PR for thermald:

https://github.com/intel/thermal_daemon/pull/224

Tom

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

Orphaning og my nodejs packages

[Tom Hughes via devel]

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

Full list of affected packages:

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

Tom

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

Re: pagure pull-request email workflow

[Tom Hughes via devel]

On 21/07/2020 11:56, Mark Wielaard wrote:


Do you have to handle them on that pagure website? Is it possible to
handle these pull-request through email? Or is there a normal (git)
command line interface for these?


Pagure supports the same pull heads are things like github
so yes you can just fetch them and merge them in your local
fepdkg checkout if you want.

I normally just edit .git/config and add to the origin remote
an extra fetch:

fetch = +refs/pull/*/head:refs/remotes/origin/pull/*

then after fetching you can merge origin/pull/NNN.

Tom

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

Re: pagure pull-request email workflow

[Tom Hughes via devel]

On 21/07/2020 13:12, Mark Wielaard wrote:


I normally just edit .git/config and add to the origin remote
an extra fetch:

fetch = +refs/pull/*/head:refs/remotes/origin/pull/*

then after fetching you can merge origin/pull/NNN.


But this is very helpful! Thanks.

So with that I can easily do checks, adjustments, create my own
commits, do cherry-picks or merges, etc. But how does it interact with
the website? How do I sent comments? I see it comes with a mini-CI koji
run, does it add a tag to the commit as tested when it succeeds/fails?
How do I indicate which changes I made/pushed or which changes I would
like the submitter to make? How do I discard a pull if I determine it
isn't useful? etc.


You use the web site as far as I know.

Unlike github it doesn't even notice when you push a merge so
you still have to close the PR on the web site as well.


And if I wish to create a pagure pull request myself, do I simply push
to pull/NNN? How do I determine which NNN to use?


Well you push to a branch on your fork but then you have to
use the web site to open the PR I think.

I mean there is a pagure API through which you can likely do
all these things but AFAIK there is no CLI interface for it so
you have to hit it with curl or something ;-)

Tom

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

Re: pagure pull-request email workflow

[Tom Hughes via devel]

On 22/07/2020 13:19, Mark Wielaard wrote:


As you say, the web api is even more resourceful and we can integrate
some of those requests into the library: https://pagure.io/api/

The only thing that is not very nice are those pagure_tokens. I was
hoping you could get a temporary one through simple fedora kerberos
authentication. But the only way to create one seems to be through a
webbrowser: https://src.fedoraproject.org/settings#nav-api-tab
You can create one that is valid for 2 years, which is helpful, but
doesn't feel very secure. How do people manage those tokens?

And I really would like to see a mail backend (maybe simply accepting
gpg signed emails) so you don't have to be online just to deal with
these kind of pull requests.


Given it's all getting replaced by gitlab anyway it's probably
not worth spending a lot of time on it...

Tom

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

Re: pagure pull-request email workflow

[Tom Hughes via devel]

On 22/07/2020 15:59, Mark Wielaard wrote:


That is not how I understand the current situation. CPE has a proposal
to provide a forge for use by the fedora project possibly based on
gitlab, but pagure wouldn't go away. 


I think you may be behind the times. The pretend consultation is over
and the decision is made.

As I understand it both paguure instances (src.fpo and pagure.io) will
be replaced but I might be wrong. Certainly src.fpo will be.


   They are currently investigating
if they could provide such a gitlab forge in a way that would be
acceptable to the fedora project, which means self-hosted and based on
the free software edition. 


I believe they're still pretending to investigate that but it seems
clear the community edition doesn't have the features needed - the
exact features that the "consultation" decided only gitlab could
provide.


   Meanwhile, if they would
offer such a forge and it would replace our use of pagure then they
would be on the hook for providing integration with the tools fedora
uses for packaging workflows. Given that the pagure api is public and
open it seems fine to use it for more integration right now.


I don't imagine they will interpret that hook as extending to
implementing the pagure API for your custom scripts ;-)

Tom

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

[Tom Hughes via devel]

On 24/03/2020 12:08, Vít Ondruch wrote:


Dne 24. 03. 20 v 11:43 Tom Hughes via devel napsal(a):

On 24/03/2020 09:32, Aleksandra Fedorova wrote:


ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.


For those of us who know little about the details of RHEL and CentOS
can you elaborate on what is different in the way that they build their
packages compared to Fedora?



The attempt to explain this was in the following paragraph you have trimmed:


Ah OK I think I misunderstood.

I thought the above was saying there were fundamental architectural
differences in the way the builds worked, rather than just that people
might choose to make different choices in the spec file.

Tom

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Tom Hughes via devel]

On 06/04/2020 22:53, Stephen Gallagher wrote:


Changes in this version of the proposal[2]:

* Improve our explanation of why we are doing ELN in the first place


I agree that the proposal is now a lot clearer and I certainly see
how it furthers the first goral of seeing how Fedora trunk comes
together asn an EL build, modulo one concern below.

I don't understand how it helps evaluate something like a new
higher CPU baseline - nobody disputes that packages can be built
to a new baseline which is what this would prove. The argument
is about the effect on consumers of such a baseline and about
what proportion of users/machines would be cut off from further
upgrades and this proposal does nothing to help with that.


* Better describe what happens if packages don't build on ELN
* Explain our plan for when to use conditionals (this was getting a
larger share of the conversation than it warranted because we didn't
do a good job of explaining that they should be the exception and not
the rule)


As far as conditionals are concerned I think not defining %fedora
is a key mistake that will both lead to extra conditionals being
needed and also lead to ongoing undetected failures to build
packages in ELN with the latest features of the corresponding
Fedora packages.

Essentially packages will build as if they are on the oldest
possible Fedora rather than the newest possible Fedora because
spec files with a condition on %fedora will typically treat it
as zero when it is not defined.

That will mean that most %fedora conditions will need to be
extended with a %rhel condition and that in many cases new
features may silently not be enabled in ELN builds until that
is manually discovered and the condition is amended which seems
to be the exact opposite of what is required if the goal is to
see how "Fedora Future" builds in an EL environment.

To take just one example hundreds of nodejs packages would build
as if they are on Fedora 18 or earlier because they contain this:

%if 0%{?fedora} >= 19
ExclusiveArch:  %{nodejs_arches} noarch
%else
ExclusiveArch:  %{ix86} x86_64 %{arm} noarch
%endif

Now that is no longer required, and happens to be mostly harmless
because it just means they will hard code the arch list instead of
using the macro, but it's the kind of thing where ELN will wind
up building as if it's an ancient version of Fedora rather than as
if it is rawhide.


* Clarify that the time limit on PRs is only for determining if the
maintainer is responsive. If they reply, the timer is cleared.


It might be better to give some idea of what sort of time limit is
envisioned - as it stands the proposal would allow PRs to demand a
response within a day, or an hour or any other ludicrously short
time period. Presumably if it's about looking for inactive maintainers
then something akin to the non-responsive maintainer timelines would
be appropriate?

Tom

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Tom Hughes via devel]

On 15/04/2020 09:08, Florian Weimer wrote:


I cannot find documentation of the systemd stub resolver behavior: how
it handles search list processing, and how it decides which upstream
name servers to query.


As I understand the terminology the "stub resolver" in systemd-resolved
refers to the thing that listens on 127.0.0.53 and that won't do
anything clever with single label queries because it will expect
it is answering DNS queries - that is exactly the way that Ubuntu
uses it.


Most Kubernetes/OKD clusters assume that both single-label and
multi-label query names are forwarded over DNS (contrary to ICANN
recommendations), and that DNS servers are processed in listed order for
all queries (no parallel queries, no randomized server selection).  If
systemd-resolved behaves differently, it can make Fedora incompatible
with Kubernetes clusters.  (This is one reason why glibc still not
follows the ICANN recommendations.)


When accessed via nss-resolve single label queries will be subject
to search list processing but I don't believe multi label ones will.

Each interface can have DNS servers and search domains as well as
there being global ones. There can also be search domains with a
prefix of "~" which force queries for that domain to be sent to a
specific interface (this is how the VPN thing works).

I'm not sure what happens if there are multiple interfaces with
no specific routing but I think it may try them all?

It definitely doesn't use the servers on an interface in any
particular order, but I didn't think glibc did either? It has a
current server but will sometimes change it based on how well
they are responding or something.


Is this expected to work with the Red Hat VPN out of the box, or do we
have to disable all this and use a custom configuration?  Has this been
discussed with Infosec?  It looks like this will break their DNS
sinkholing for domains such as REDHAT[.]CO (not COM).


I think so long as the VPN interface has ~redhat.co in it's search
list then queries for that domain will be forced to the servers for
that interface if that's what is required?


Will the built-in DNS server still support DNSSEC without validation,
passing through the records if they are requested by the client over the
DNS interface?  The section above is not clear.


I don't think so no. I happen to have a query to hand which fails
validation due to a bug in systemd-resolved and I get SERVFAIL when
querying 127.0.0.53 even with +cdflag on the dig command.

Tom

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Tom Hughes via devel]

On 15/04/2020 09:29, Tom Hughes via devel wrote:

> I'm not sure what happens if there are multiple interfaces with
> no specific routing but I think it may try them all?

Found the documentation now - it does try them all. Full details
from systemd-resolved(8) are:

   Lookup requests are routed to the available DNS servers, LLMNR and
   MulticastDNS interfaces according to the following rules:

   ·   Lookups for the special hostname "localhost" are never routed to
   the network. (A few other, special domains are handled the same
   way.)

   ·   Single-label names are routed to all local interfaces capable of IP
   multicasting, using the LLMNR protocol. Lookups for IPv4 addresses
   are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are
   only sent via LLMNR on IPv6. Lookups for the locally configured
   host name and the "_gateway" host name are never routed to LLMNR.

   ·   Multi-label names with the domain suffix ".local" are routed to all
   local interfaces capable of IP multicasting, using the MulticastDNS
   protocol. As with LLMNR IPv4 address lookups are sent via IPv4 and
   IPv6 address lookups are sent via IPv6.

   ·   Other multi-label names are routed to all local interfaces that
   have a DNS server configured, plus the globally configured DNS
   server if there is one. Address lookups from the link-local address
   range are never routed to DNS. Note that by default lookups for
   domains with the ".local" suffix are not routed to DNS servers,
   unless the domain is specified explicitly as routing or search
   domain for the DNS server and interface. This means that on
   networks where the ".local" domain is defined in a site-specific
   DNS server, explicit search or routing domains need to be
   configured to make lookups within this DNS domain work. Note that
   today it's generally recommended to avoid defining ".local" in a
   DNS server, as RFC6762[3] reserves this domain for exclusive
   MulticastDNS use.

   If lookups are routed to multiple interfaces, the first successful
   response is returned (thus effectively merging the lookup zones on all
   matching interfaces). If the lookup failed on all interfaces, the last
   failing response is returned.

   Routing of lookups may be influenced by configuring per-interface
   domain names and other settings. See systemd.network(5) and
   resolvectl(1) for details. The following query routing logic applies
   for unicast DNS traffic:

   ·   If a name to look up matches (that is: is equal to or has as
   suffix) any of the configured search or route-only domains of any
   link (or the globally configured DNS settings), the "best matching"
   search/route-only domain is determined: the matching one with the
   most labels. The query is then sent to all DNS servers of any links
   or the globally configured DNS servers associated with this "best
   matching" search/route-only domain. (Note that more than one link
   might have this same "best matching" search/route-only domain
   configured, in which case the query is sent to all of them in
   parallel).

   ·   If a query does not match any configured search/route-only domain
   (neither per-link nor global), it is sent to all DNS servers that
   are configured on links with the "DNS default route" option set, as
   well as the globally configured DNS server.

   ·   If there is no link configured as "DNS default route" and no global
   DNS server configured, the compiled-in fallback DNS server is used.

   ·   Otherwise the query is failed as no suitable DNS servers could be
   determined.

   The "DNS default route" option is a boolean setting configurable with
   resolvectl or in .network files. If not set, it is implicitly
   determined based on the configured DNS domains for a link: if there's
   any route-only domain (not matching "~.") it defaults to false,
   otherwise to true.

   Effectively this means: in order to preferably route all DNS queries
   not explicitly matched by search/route-only domain configuration to a
   specific link, configure a "~."  route-only domain on it. This will
   ensure that other links will not be considered for the queries (unless
   they too carry such a route-only domain). In order to route all such
   DNS queries to a specific link only in case no other link is
   preferable, then set the "DNS default route" option for the link to
   true, and do not configu

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Tom Hughes via devel]

On 15/04/2020 09:53, Florian Weimer wrote:

> Thanks.  Does this mean that no search list processing happens, for
> neither single-label names (per for the first paragraph), nor for
> multi-label names (per the routing description)?  Or is this process
> described in some other context?

That text doesn't mention search list processing because I assume
it is describing what happens to each name after any domain from the
search list has been added but resolved.conf(5) says:

   Domains=
   A space-separated list of domains. These domains are used as search
   suffixes when resolving single-label host names (domain names which
   contain no dot), in order to qualify them into fully-qualified
   domain names (FQDNs). Search domains are strictly processed in the
   order they are specified, until the name with the suffix appended
   is found. For compatibility reasons, if this setting is not
   specified, the search domains listed in /etc/resolv.conf are used
   instead, if that file exists and any domains are configured in it.
   This setting defaults to the empty list.

   Specified domain names may optionally be prefixed with "~". In this
   case they do not define a search path, but preferably direct DNS
   queries for the indicated domains to the DNS servers configured
   with the system DNS= setting (see above), in case additional,
   suitable per-link DNS servers are known. If no per-link DNS servers
   are known using the "~" syntax has no effect. Use the construct
   "~."  (which is composed of "~" to indicate a routing domain and
   "."  to indicate the DNS root domain that is the implied suffix of
   all DNS domains) to use the system DNS server defined with DNS=
   preferably for all domains.

That is about the global option but the same logic applies to per-interface
search lists I assume.

Tom

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Tom Hughes via devel]

On 15/04/2020 09:48, Florian Weimer wrote:

>>> Is this expected to work with the Red Hat VPN out of the box, or do we
>>> have to disable all this and use a custom configuration?  Has this been
>>> discussed with Infosec?  It looks like this will break their DNS
>>> sinkholing for domains such as REDHAT[.]CO (not COM).
>>
>> I think so long as the VPN interface has ~redhat.co in it's search
>> list then queries for that domain will be forced to the servers for
>> that interface if that's what is required?
> 
> Does OpenVPN log the list of these domains somewhere?  Or do they have
> to be configured manually?

I think a lot will depend on exactly how it is setup. My openvpn
setups on linux tend to use an up script to configure DNS things
so my VPN to home just has an up script that does:

resolvectl dns $1 172.16.15.1 172.16.15.2 172.16.15.5
resolvectl domain $1 ~compton.nu ~15.16.172.in-addr.arpa 
~d.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa
resolvectl flush-caches

To set the DNS servers on the interface and force routing of
certain domains to it.

I'm not sure OpenVPN itself has any way to do DNS setup automatically
on linux but the NetworkManager integration might, I don't use that
though.

Tom

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Tom Hughes via devel]

On 15/04/2020 10:14, Vitaly Zaitsev via devel wrote:

On 14.04.2020 21:23, Ben Cotton wrote:

Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.


I've tested systemd-resolved on my laptop for a month. It worked very,
very unstable. Sometimes it stopped responding and I needed to manually
restart its service.


I too have been using it increasingly both on Fedora and on a
fleet of Ubuntu 18.04 machines and don't recognise that experience
at all.

I also (modulo one bug which is now fixed upstream) find it to be
much better at handling DNSSEC than either bind or unbound.

Tom

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Tom Hughes via devel]

On 16/04/2020 11:46, Florian Weimer wrote:

* Lennart Poettering:


Long story short: if you experienced issues with DNSSEC on with
resolved today, then be assured that with DNSSEC off things are much
much better, and that's how we'd ship it in Fedora if it becomes the
default.


Would you please clarify what switching DNSSEC off means?  Just no
validation, or no DNSSEC support at all?


If I'm understanding what is expected correctly then it looks to me
like it is actually broken regardless of whether or not DNSSEC is
switched on...

Adding +dnssec to the dig flags results in some additional flags
being set in the OPT section of the response but it does not
cause RRSIG records to be returned and whether DNSSEC is on or
off makes no difference to that.

Tom

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

Re: Fedora 33 System-Wide Change proposal: Node.js 14.x by default

[Tom Hughes via devel]

On 08/05/2020 21:18, Stephen Gallagher wrote:

On Sat, May 2, 2020 at 6:26 PM Miro Hrončok  wrote:


On 01. 05. 20 22:21, Ben Cotton wrote:

* Proposal owners:
The packages are already built for Fedora 33 in a non-default module
stream. On June 14th, 2020, the nodejs-14.x packages will become the
default in Fedora 33 (either by making the 14.x module stream be the
default stream or by rebuilding the packages as non-modular, depending
on other factors).


Will there be an attempted mass rebuild of the dependent packages?


We're going to request a side-tag and rebuild all of the `nodejs-*`
packages. Anything that fails will need to have an FTBFS bug filed.


Why? We're never done that for Node.js upgrades before, and it's
only the binary modules which actually need to be rebuilt...

Tom

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

Re: Fedora 33 System-Wide Change proposal: Node.js 14.x by default

[Tom Hughes via devel]

On 11/05/2020 13:02, Stephen Gallagher wrote:

On Fri, May 8, 2020 at 6:03 PM Tom Hughes  wrote:


On 08/05/2020 21:18, Stephen Gallagher wrote:

On Sat, May 2, 2020 at 6:26 PM Miro Hrončok  wrote:


On 01. 05. 20 22:21, Ben Cotton wrote:

* Proposal owners:
The packages are already built for Fedora 33 in a non-default module
stream. On June 14th, 2020, the nodejs-14.x packages will become the
default in Fedora 33 (either by making the 14.x module stream be the
default stream or by rebuilding the packages as non-modular, depending
on other factors).


Will there be an attempted mass rebuild of the dependent packages?


We're going to request a side-tag and rebuild all of the `nodejs-*`
packages. Anything that fails will need to have an FTBFS bug filed.


Why? We're never done that for Node.js upgrades before, and it's
only the binary modules which actually need to be rebuilt...



Well, we don't have a way of detecting which are binary modules and
which aren't, so far as I know.


I have a list in the script I normally use to rebuild them.


Also, assuming packages are following the guidelines, they should all
at least have the %{__nodejs} -e 'require("./")' test enabled, so we
can at least find out if there are any Node.js modules that cannot
even load.


Excuse me while I try and stop laughing.

I guess it will get of a few hundred more node modules anyway
which is something.

Tom

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

Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Tom Hughes via devel]

On 12/05/2020 14:13, Petr Pisar wrote:

On Tue, May 12, 2020 at 12:47:51PM +, virgo wrote:

I recommend you to ask the question about v2 support on Fedora Bugzilla for=

  the

libcgroup package
.

Prior to the top post, I went through the Bugzilla tickets, with these
parameters:

* component=libcgroup
* order=changeddate DESC
* product=Fedora
* query_format=advanced

and the hits dating back to 2015[fn:1] were just a dozen, none making mention
of v2. So, I am not sure whether opening feature requests would help.


Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
compatible with cgroup v2, then libcgroup package is not compatible with
Fedora and this is a bug and should be reported to the Fedora's Bugzilla.


That's not really true. Fedora now defaults to v2 but you can still
choose to boot to v1 instead and systemd still supports both.


By the way, what would you and (and others) recommend as a replacement for
libcgroup-tools?[fn:2]


No idea. I don't use cgroups for anything on purpose. As far as I know,
cgroups membership in Fedora is defined by systemd's logind. Whether it suits
your needs, I have no idea. I also think it's possible to manage the
membership manually by editing files in cgroup2 pseudo file system.


Yes as I understand it you're not supposed to fiddle with cgroups
manually, you're supposed to use systemd-run or something and let
systemd do the necessary.

It would probably help if the original user described what his goal
was rather than the low level details of how he achieved that with
cgroups v1.

Tom

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

Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Tom Hughes via devel]

On 12/05/2020 15:06, virgo wrote:


Let’s say I want to compile `pandoc` with modifications of my own and many non-
default compiler options. At the same time, on the same machine, I still want
to do other stuff. `cgexec` et al. helped a lot to cap the memory and CPU usage
of tasks like that, without needing container and virtual machines setups.
Nowadays, I am into `systemd-nspawn` because it requires minimal configuration
from my end. It is still a hammer deployed to kill an ant. In pages like
`systemd.resource-control(5)`, one can read:

 See the New Control Group Interfaces[1] for an introduction on how to
**make use of resource control APIs from programs.**

Great! But I do not know how to make programs consuming those APIs. The tools
talked about in this thread helped a lot and I am searching for replacement
that would fit with my low-proficiency in Devops.


Well the easy way is not to use any programmatic APIs but just
use systemd-run instead, for example:

  systemd-run --user --scope -p MemoryHigh=1M make

Will run make with the MemoryHigh property (documented on the
man page you mentioned) set to a specified value.

Tom

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

Re: Help with gcc10-arm-only problem

[Tom Hughes via devel]

On 01/03/2020 16:44, Sergio Pascual wrote:


The package build in all arches except in arm an the error is:

/builddir/build/BUILD/libindi-1.8.1/libs/indibase/inditelescope.cpp: In 
member function 'bool INDI::Telescope::processTimeInfo(const char*, 
const char*)':
/builddir/build/BUILD/libindi-1.8.1/libs/indibase/inditelescope.cpp:1647:17: 
error: 'stime' was not declared in this scope; did you mean 'ctime'?

  1647 |                 stime(&raw_time);
       |                 ^
       |                 ctime
make[2]: *** [CMakeFiles/indidriverstatic.dir/build.make:352: 
CMakeFiles/indidriverstatic.dir/libs/indibase/inditelescope.cpp.o] Error 1


For some reason, stime works in all arches except in arm. Any hint?


I'm not sure why as stime as been deprecated in glibc so shouldn't
be available to use on any architecture.

The code needs to be updated to use clock_settime instead.

Tom

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

Re: bodhi web interface (not associating bugzilla entries)

[Tom Hughes via devel]

On 19/03/2020 10:19, José Abílio Matos wrote:


when entering a new update through the web interface of bodhi I do
not get the list of open bugs in bugzilla, no mater the wait. There is a
rotating symbol as it happens to select the build(s) but I continues without
any output.


Are you using a browser extension like uMatrix that may be blocking
the cross domain query from bodhi to bugzilla?

Tom

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

[Tom Hughes via devel]

On 24/03/2020 09:32, Aleksandra Fedorova wrote:


ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.


For those of us who know little about the details of RHEL and CentOS
can you elaborate on what is different in the way that they build their
packages compared to Fedora?


* Other developers:
*: Anyone who wants to produce different content for the ELN compose
will need to implement the new macros in their specfile. The
overwhelming majority of packages will require no modification.


What is the impact on "other developers" who don't want to do those
things? Is there an expectation that Fedora packagers will make any
necessary changes to ensure their packages build in this environment
and continue to respond to issues to keep them building there?

Tom

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

Re: It’s time to transform the Fedora devel list into something new

[Tom Hughes via devel]

On 21/04/2023 18:52, Matthew Miller wrote:


"Mailing list mode" was a specific thing in earlier versions of Discourse —
it sent a notification for every message posted. This is kind of like going
to Hyperkitty and saying "subscribe me to all 600 lists". I don't recommend
that. Instead, choose specific tags that you want to subscribe to, just as
you would subscribe to individual mailing lists.


It's still a thing in current versions, it just doesn't seem to be
available in the Fedora installation.

It also doesn't have to send you everything as you can mute those
things you don't want to include.

Having to positively opt in to certain tags seems like a terrible
idea as you're bound to miss lots of things when people create new
tags that you don't even know exist. I'd much rather get everything
by default and then opt out of the things I'm not interested in.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to check if a package is retired?

[Tom Hughes via devel]

On 25/04/2023 08:55, Florian Weimer wrote:


The xorg-x11-drv-fbturbo is supposed to have been retired (see
).   How can I
check if this is actually the case?


A retired packaged should have a commit in srcgit that removes
all the contents and adds a dead.package file with a description of
the reason for retirement, like:

https://src.fedoraproject.org/rpms/npm/c/7304877c50a9a02238cf7a40e269e256090fd001

As far as I can see  xorg-x11-drv-fbturbo does not have that and
is still live.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Tom Hughes via devel]

On 25/04/2023 09:40, Florian Weimer wrote:

* Jarek Prokop:


Personally, I have accounts on many, many Discourse instances, but I
don't think there is a single one I read somewhat regularly.  I find the
mailing list mode and the notifications rather unpredictable.  Maybe an
alternative client could help (nndiscourse?), but as far as I understand
it, there's no real API, so that's kind of hard?


I could find an API docs, and I could retreive posts.json from our
Fedora instance

https://docs.discourse.org/

So the question is, what is a "real API" that you would consider OK?


There has to be a login procedure, and it needs to be geared towards
alternative clients.  We currently have only this:

| To become authenticated you will need to create an API Key from the
| admin panel.

So its seems to be restricted to admin-approved integrations, and is not
intended for writing clients.


It is possible to allow users to generate their own API keys without
any admin involvement but there's no direct web interface to create
one - the client has to make a call to /user-api-key/new with certain 
parameters - full details are here:


https://meta.discourse.org/t/user-api-keys-specification/48536

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Plans for dhclient / ISC dhcp?

[Tom Hughes via devel]

On 30/05/2023 11:41, Peter Robinson wrote:

On Tue, May 30, 2023 at 11:10 AM Richard W.M. Jones  wrote:


https://github.com/libguestfs/libguestfs/issues/121

We use dhclient to get a DHCP address inside a minimal appliance.
To get this out of the way: NetworkManager or systemd are not options.

It seems as if the ISC dhcp package has been EOL'd upstream:

https://www.isc.org/dhcp/

I wonder what our plans are for this package, such as whether we are
recommending moving to dhcpcd:

https://roy.marples.name/projects/dhcpcd

(we package this already, as does Debian), or another suggested
replacement, or if another team is going to maintain the code, or if
we will just keep packaging the last ISC version in Fedora?


Upstream has replace it with Kea: https://www.isc.org/kea/


That's a server - it doesn't replace the client component.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Plans for dhclient / ISC dhcp?

[Tom Hughes via devel]

On 30/05/2023 11:57, Florian Weimer wrote:

* Richard W. M. Jones:


I wonder what our plans are for this package, such as whether we are
recommending moving to dhcpcd:

https://roy.marples.name/projects/dhcpcd


systemd-networkd has an integrated DHCP client, hasn't it?


It does yes, and it's what I use on most machines.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Tom Hughes via devel]

On 22/12/2022 19:18, Michael Catanzaro wrote:
On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson 
 wrote:

Could we not go for 30 seconds?


Personally I think 30 seconds is way too long for desktop users. But 
it's a lot better than 2 minutes, so if that's what we settle on, I 
won't complain.


The thing is that it's not really two minutes anyway, it's more
like eight minutes because each time the timer expires systemd
sends a stronger signal and restarts the timer until it eventually
gets to SIGKILL.

So in the worst case where a process is stuck in D wait then
you get all the way to the SIGKILL phase and then wait two minutes
for that before it eventually gives up and continues.

At least that is what usually seems to happen when I run into
this problem.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Tom Hughes via devel]

On 23/12/2022 11:45, Naheem Zaffar wrote:



On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel 
mailto:devel@lists.fedoraproject.org>> 
wrote:


On 23/12/2022 09:20, Mattia Verga via devel wrote:
 > I know this is way harder, but the right approach would be having
a way
 > to tell systemd what processes can be killed and what other processes
 > must not be forced off in any case, then display a user friendly
message
 > which inform the user that the system cannot be forced off ATM
"because
 > I'm doing this or that". In the worst case, the user can choose
to pull
 > the plug themselves.

I agree. Terminating the PackageKit service while updates are being
installed can result in a broken system.


Is there a way to be smarter about all this?

1. Set default at 15s or something short.
2. For services known to require longer (older pinephone modem firmware, 
libvirtd), allow a larger timeout for that specific service only
3. For services that should NOT be terminated have a mechanism for them 
to not be cut off


Despite the title of this change I believe the proposal is only
to change the default timeout and a service would still be able to
set a different timeout in it's service file.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: valgrind on Fedora

[Tom Hughes via devel]

On 16/01/2023 08:12, Florian Festi wrote:

On 1/16/23 07:10, Gordon Messmer wrote:

Does anyone have any hints for improving the information I get from
valgrind?

Have you installed the debuginfo packages for the packages involved?
See man debuginfo-install


Making sure debuginfod fetching works should also do it as valgrind
has support for that.

If that doesn't work then some examples would help, at least if you're
getting a partial trace, so that we can get some idea of what component
it is not able to unwind.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: valgrind on Fedora

[Tom Hughes via devel]

On 16/01/2023 08:52, Gordon Messmer wrote:

On 2023-01-16 00:31, Tom Hughes via devel wrote:


If that doesn't work then some examples would help, at least if you're
getting a partial trace, so that we can get some idea of what component
it is not able to unwind. 



==29692== 30 bytes in 2 blocks are definitely lost in loss record 917 of 
2,602

==29692==    at 0x484386F: malloc (vg_replace_malloc.c:393)
==29692==    by 0x14806539: ???
==29692==    by 0x14BA7D87: ???
==29692==    by 0x14BA7DFC: ???
==29692==    by 0x14B86D88: ???
==29692==    by 0x146ED193: ???
==29692==    by 0x1475E205: ???
==29692==    by 0x1475E71A: ???
==29692==    by 0x1475ED49: ???
==29692==    by 0x146EF09F: ???
==29692==    by 0x4A5D0E7: g_type_create_instance (gtype.c:1931)
==29692==    by 0x4A42C1F: g_object_new_internal (gobject.c:2228)
==29692==    by 0x4A44247: g_object_new_with_properties (gobject.c:2391)
==29692==    by 0x4A44FF0: g_object_new (gobject.c:2037)
==29692==    by 0x146F5395: ???
==29692==    by 0x145D820C: ???
==29692==    by 0x145E06E3: ???
==29692==    by 0x1276D0: pk_backend_load (pk-backend.c:569)
==29692==    by 0x135D1A: pk_engine_load_backend (pk-engine.c:967)
==29692==    by 0x119468: main (pk-main.c:219)


I suspect this is a result of libraries being opened and closed
dynamically - for performance reasons valgrind doesn't resolve names
until it prints the trace and if the library in question has been
closed by then it will normally be unable to resolve names from it.

Try using --keep-debuginfo=yes to make valgrind cache debuginfo
for libraries that have been closed.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 mass rebuild is finished

[Tom Hughes via devel]

On 24/01/2023 07:28, Jeff Law wrote:



On 1/24/23 00:16, Jakub Jelinek wrote:

On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:

I have some packages failed.
One of them libtins. Problem is that:

error: 'uint32_t' is not a member of 'std';

Is it normal? Is it GCC 13 change?


See
https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
Some libstdc++ headers included  in older versions
as an implementation detail but no longer do.

Including stdint.h will introduce ::uint32_t type among others,
but not std::uint32_t, if you use the latter, you need to
include .
I've got a partial list of packages affected by the ongoing header 
cleanups in libstdc++:


mapnik was affected as well but I fixed it last night.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packages with breaking APIs

[Tom Hughes via devel]

There is already precedent for doing it with catch and I've said
that I plan to do it again so I don't know what more you want.

Tom

On 01/02/2023 10:13, Benson Muite wrote:

Packages with breaking APIs between major version changes often keep
maintaining the older version for some time after the new version is
released.  An example is FFTW which has both FFTW (version 3) and FFTW2
(version 2) within Fedora:
https://packages.fedoraproject.org/search?query=fftw

Is it reasonable to package versions with newer APIs separately? Of
particular interest are:
i) Catch
a) Existing v2.3.10 https://src.fedoraproject.org/rpms/catch
b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2165410
ii) MbedTLS
a) Existing v2.28.2 https://src.fedoraproject.org/rpms/mbedtls
b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2154347
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packages with breaking APIs

[Tom Hughes via devel]

On 01/02/2023 11:51, Neal Gompa wrote:

On Wed, Feb 1, 2023 at 12:46 PM Benson Muite  wrote:


For Catch, there was an upgrade from 1 to 2. Similarly for FFTW, the
main package uses the name FFTW, but it was FFTW3 before hand. Maybe one
could use Catch3 or Catch2v3? Then change names later once more packages
use the v3 interface?


Normally older versions are broken out into versioned legacy packages
and the main package is upgraded. Then reverse dependencies are either
upgraded or pinned as needed.


Which is what we did for catch before - there is catch1 and catch now.

The slight complication/confusion is that the upstream repository is
actually called Catch2 now though it's on v3.x but version one is in
the same repository, just on a Catch1.x branch.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Update of catch to Catch2 v3

[Tom Hughes via devel]

As discussed a few weeks ago the Catch testing framework has
a slightly weird naming scheme, namely:

* Catch (v1.x, actually a branch in Catch2 repository)
* Catch2 v2.x
* Catch2 v3.x

Since Catch2 was released we have had catch1 and catch packages
to support both v1.x and v2.x users.

I have now added catch2 (for Catch2 v2.x) and upgraded the catch
package to Catch2 v3.x in rawhide and f38.

What this means is that if your package uses catch-devel to build
that you probably need to update your BuildRequire to catch2-devel
when you next build it - unless your upstream supports v3.x of
course.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update of catch to Catch2 v3

[Tom Hughes via devel]

On 24/02/2023 07:48, Vitaly Zaitsev via devel wrote:

On 22/02/2023 12:37, Tom Hughes via devel wrote:

I have now added catch2 (for Catch2 v2.x) and upgraded the catch
package to Catch2 v3.x in rawhide and f38.


All my catch-dependent packages are now failing due to the missing 
catch.hpp header:


Did you miss the bit where I said you needed to change
your BR to catch2-devel unless upstream has v3 support?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update of catch to Catch2 v3

[Tom Hughes via devel]

On 28/02/2023 11:24, Vitaly Zaitsev via devel wrote:

On 24/02/2023 09:42, Tom Hughes wrote:

Did you miss the bit where I said you needed to change
your BR to catch2-devel unless upstream has v3 support?


What about Fedora ELN? catch2-devel is not available there.


Nothing to do with me. I don't do ELN.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: KB layout switching does not work in TB on Rawhide

[Tom Hughes via devel]

On 02/03/2023 08:43, Olivier Fourdan wrote:


TB still uses Xwayland?


By default, yes.

If you install thunderbird-wayland then you will get an
alternative native Wayland version.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: unfixed CVE-2024-39929 in exim

[Tom Hughes via devel]

On 15/07/2024 16:46, Marius Schwarz wrote:


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

Luckily is not a RCE, but we have an unpatched CVE in Exim .. can 
someone pls poke the right person for it?

There was no reaction to the exim accouncement on OSS and to the bugreport.


It was only reported yesterday!

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

[Tom Hughes via devel]

On 07/08/2024 12:54, Richard W.M. Jones wrote:

On Wed, Aug 07, 2024 at 01:09:01PM +0200, Vít Ondruch wrote:

With new RPM, I hit the limit in two packages:

https://koschei.fedoraproject.org/package/rubygem-abrt

https://koschei.fedoraproject.org/package/rubygem-pg


Is it RPM, or is it "rspec"?  Seems to be some sort of Ruby tool.


The first one is something I assume the test is doing... Perhaps
these ones using deliberately silly paths?

https://github.com/voxik/abrt-ruby/blob/5cd42e6cf6024e80cdccdf8c3ba2128f2717ab69/spec/abrt_handler_spec.rb#L122

The second one is less clear  - it doesn't seem to be using the
%postgresql_tests_run macro to start a postgres server for testing
so I assume the ruby tests are starting one themselves but in
a directory that has a long enough name that the socket name
is too long?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build failure due to glib change

[Tom Hughes via devel]

On 01/09/2024 23:26, Alexander Ploumistos wrote:


I can sort of understand the rationale behind that, but I'd like
someone who is more actively involved with C++ to give some advice if
this is something I should be reporting to the glib folks, or if I
should just change the writable string pointers to read-only in
text.cc and (hopefully) be done with it.


Change the pointers - you were essentially getting an accidental
cast from const char to char but logically speaking if the string
is const then advancing by one codepoint doesn't magically stop
it being const.

The new behaviour of glib is to preserve the constness of the
pointer as it advances which seems correct to me.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Minified JS and CSS in Node packages

[Tom Hughes via devel]

On 03/07/2023 16:41, Demi Marie Obenour wrote:


Would it be possible to ensure that Node packages contain only actual source
code, as in “the preferred form for making modifications” (quote from GNU GPL,
I forget which version)?


The simple answer is maybe in principle but in practice it's
very hard as numerous previous threads will tell you.

The tar balls from the npmjs registry which constitute the
released versions of node packages frequently contain such
things often without the original source or any of the tooling
to build from it.

The alternative is packaging from the upstream git but even
then, and even if it is well maintained with version tags, there
are often huge dependency chains to get all the tools needed to
actually do the builds.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Minified JS and CSS in Node packages

[Tom Hughes via devel]

On 03/07/2023 17:09, Demi Marie Obenour wrote:

On 7/3/23 11:59, Tom Hughes wrote:

On 03/07/2023 16:41, Demi Marie Obenour wrote:


Would it be possible to ensure that Node packages contain only actual source
code, as in “the preferred form for making modifications” (quote from GNU GPL,
I forget which version)?


The simple answer is maybe in principle but in practice it's
very hard as numerous previous threads will tell you.

The tar balls from the npmjs registry which constitute the
released versions of node packages frequently contain such
things often without the original source or any of the tooling
to build from it.

The alternative is packaging from the upstream git but even
then, and even if it is well maintained with version tags, there
are often huge dependency chains to get all the tools needed to
actually do the builds.


I thought Fedora policy required shipping actual source code, in
which case this alternative is the only option allowed.


Yes you're right, and there's long been a question of exactly
what constitutes that with javascript packages.

When I was packaging and reviewing Node stuff I certainly tried
to do so where it was in any way feasible.

Minimisers weren't usually too bad - you can always just skip them
after all - but once you start dealing with transpilers it can get a
lot harder plus you often wind up having to write your own build script
because the upstream one is using one of a dozen different Node based 
tools each of which has hundreds of dependent modules you would need to

package.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restore access to torrent-file-editor package

[Tom Hughes via devel]

On 24/07/2023 14:40, Leigh Scott wrote:

You probably got removed for inactivity, see 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UG3UOKBVJLUWZYEHWL52KPMITPEPEBNF/


Looks like it: https://pagure.io/find-inactive-packagers/issue/36

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: old RPM code in my package - safe to remove this bit ?

[Tom Hughes via devel]

On 30/11/2023 00:14, Michal Schorm wrote:


I've stumbled upon this piece of code in my package:
   # Define license macro if not present
   %{!?_licensedir:%global license %doc}

https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/mariadb.spec#_322

Git blame points out 7 year old commit:
https://src.fedoraproject.org/rpms/mariadb/c/e3d4b2f14e5e0cb7b42b468ffb9de6ff39e3d248?branch=rawhide

The RPM docs says the %license 'Virtual File Attribute' was added in
version 4.11, which has been added to Fedora years before the commit
above:
https://src.fedoraproject.org/rpms/rpm/c/2970ed07c98c8929eca0bdfebda389af5a2ef92d?branch=rawhide

I tried to remove the line and I haven't noticed any differences in
output of "rpm -q -d " and "rpm -q -L " before and after.

I'm not even sure what the line is trying to do - I read it as "under
some condition, create %license global macro with value %doc".


It's just making %license an alias for %doc if your building
for a release old enough that %license isn't supported, as
detected by checking if %licensedir is defined.

It hasn't been needed for a long time.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: old RPM code in my package - safe to remove this bit ?

[Tom Hughes via devel]

On 30/11/2023 00:28, Michal Schorm wrote:

On Thu, Nov 30, 2023 at 1:19 AM Tom Hughes via devel
 wrote:

It hasn't been needed for a long time.


Good, thanks. Off it goes. :)


It's just making %license an alias for %doc if your building
for a release old enough that %license isn't supported, as
detected by checking if %licensedir is defined.


Why is it checked through the %licensedir macro, and not the %license
VFT instead?
If %doc VFT could be used as an actual value for a macro, I'd assume
it could be used in conditional too. (to verify whether such VFT
exists)


Well you said it yourself, that %license is a keyword and not
a macro so you probably can't check if it's defined.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change of cronie and crontabs CIS compliance

[Tom Hughes via devel]

On 06/12/2023 11:08, Ondrej Pohorelsky wrote:

The only difference is that if you have populated the cron.deny list, 
after update it gets saved as .rpmsave and cron.allow is created.

If the cron.deny is blank, it will get replaced.
Also, if you had cron.allow populated before, it will stay this way and 
blank cron.allow.rpmnew is created.


Surely there is one more change though?

Namely that users who could previously run crontab to create
cron jobs can no longer do so unless they have been added to
the cron.allow file.

That seems like a breaking change to me?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)

[Tom Hughes via devel]

On 21/12/2023 14:33, Steven A. Falco wrote:

On 12/21/23 08:53 AM, Neal Gompa wrote:
On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott  
wrote:


I'm -1 for this change, it shouldn't be enabled by default as it will 
cause issues for users using router mac filtering.


What this seems to state is that the MAC address would be unique for
each SSID, but once it's picked, it would be locked in. That should
still make router-level MAC filtering possible, since the MAC address
would be stable for that network.


What would happen on a network where I've set up the DHCP server in my 
router to map mac addresses to static IP addresses?  Sounds like I'd 
have to disable the feature, at least on my home network.


Either that or you would make a one off change to your DHCP server
to use the new per-network MAC address instead of the old one.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

License correction for rapidjson

[Tom Hughes via devel]

The license for rapidjson has been corrected from:

  MIT

to:

  MIT and BSD-3-Clause

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Monday's FESCo Meeting (2024-01-15)

[Tom Hughes via devel]

On 16/01/2024 10:43, Florian Weimer wrote:


We still don't have approval for the toolchain updates that we need for
the mass rebuild (notably Changes/GNUToolchainF40).


As far as I can see there isn't even a Fesco ticket for it?

The fields in https://discussion.fedoraproject.org/t/100414 for ticket
numbers are just placeholders and there's nothing in the fesco issue
tracker that I can see.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build error with GCC 14, not even a warning in GCC 13

[Tom Hughes via devel]

On 16/01/2024 23:49, Richard Shaw wrote:
On Tue, Jan 16, 2024 at 5:36 PM Aleksei Bavshin 
mailto:aleba...@fedoraproject.org>> wrote:


Ah, I misread the include path. It's our package that is too old :(
https://src.fedoraproject.org/rpms/rapidjson/pull-request/4
 should
help.

It doesn't look like the pull request has gotten any attention. Perhaps 
it's time to initiate the non-responsive maintainer process?


Right because the other two PRs I've merged in the last couple of
weeks, including one today, are not evidence of responsiveness?

That PR is on my to look at list but rather obviously it needs
more work than the other ones.

I'm not really keen on packaging a random git snapshot because
there's no way to know how good or bad it is but I realise that
due to upstream being a pain it may be necessary here.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HEADSUP boost and tbb rebuilds starting in a side tag

[Tom Hughes via devel]

On 20/01/2024 16:07, Jerry James wrote:


Upstream has this in src/tbb/CMakeLists.txt:

if (CMAKE_SIZEOF_VOID_P EQUAL 8)
 set(TBB_PC_NAME tbb)
else()
 set(TBB_PC_NAME tbb32)
endif()

That makes the pkgconfig file install as tbb32.pc.  I don't know why
upstream is doing that.  Maybe so 64-bit and 32-bit installs can
coexist on the same system?


The correct way to do that is to install in /usr/lib{,64}/pkgconfig
instead of /usr/share/pkgconfig I think?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Figure out what killed an app (rhbz#2253099)

[Tom Hughes via devel]

On 31/01/2024 10:08, Milan Crha wrote:


I tried to investigate a rawhide bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2253099
which is about Evolution being killed "by something". That's the thing,
I do not know what killed it, thus even why it had been killed. It's
even not killed after certain steps, it's killed "randomly", on various
occasions.

I did search the internet, but they usually expect the killer is the
OOM service, which logs about the action either in the dmesg or in the
journal, but in this case there is no sign about whom killed it in
either of these logs.

The evolution terminal just says:

Killed


At the end of of the day it means a SIGKILL was sent to the process
and that's not something that is logged anywhere as a matter of course
so you're reliant on whatever sends it saying so.

You're right that OOM is the usual cause so if you've ruled that out
you need to think about other things.

The problem is that SIGKILL is deliberately a very hard stop that
nothing can trap so normal things like using strace or gdb to catch
who went it aren't going to work.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: OpenSSL 3.2.1 available in rawhide

[Tom Hughes via devel]

On 09/02/2024 13:34, Jarek Prokop wrote:

Since the error from the scratch build says "invalid CA certificate" I 
thought to use some openssl "verification" command,

this one seems like I'm on the right path.

I have tried more permutations of the command with certificates 
available in the `spec/ssl/` directory, including using `-untrusted` 
with various certs, all seem to fail the same.


Any idea what's up or how to fix it?


As you say it doesn't like the CA certificate:

% openssl verify -verbose -CAfile ca-cert.pem server-cert.pem
CN=ca_mysql2gem
error 79 at 1 depth lookup: invalid CA certificate
error server-cert.pem: verification failed

That CA certificate doesn't have the CA:TRUE constraint set
which might be the problem?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Question about conditional BuildRequires lines

[Tom Hughes via devel]

On 14/02/2024 14:54, Richard W.M. Jones wrote:


https://src.fedoraproject.org/rpms/rapidjson/pull-request/7

I don't think what Tom is saying there is correct, or is it?


The answer is that I'm wrong about it breaking things, because
koji uses the unpacked spec file to install dependencies not the
requires from the srpm.

However the guidelines whilst not mentioning this case do prohibit
the use of %{_isa} in BRs because it produces incorrect dependencies
in the srpm - the only real difference is that this case give you
a missing dependency rather than a broken one.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Question about conditional BuildRequires lines

[Tom Hughes via devel]

On 14/02/2024 15:48, Richard W.M. Jones wrote:

On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:

On 14/02/2024 14:54, Richard W.M. Jones wrote:


https://src.fedoraproject.org/rpms/rapidjson/pull-request/7

I don't think what Tom is saying there is correct, or is it?


The answer is that I'm wrong about it breaking things, because
koji uses the unpacked spec file to install dependencies not the
requires from the srpm.

However the guidelines whilst not mentioning this case do prohibit
the use of %{_isa} in BRs because it produces incorrect dependencies
in the srpm - the only real difference is that this case give you
a missing dependency rather than a broken one.


I was hoping that people with more experience would comment on the
bug, and they did, so thanks.

The issue we have is that valgrind is simply not a package on RISC-V.
Valgrind requires upstream porting work which is only partially
complete (and IIRC not upstream yet).  I don't know any other way to
express this other than using:


As it happens I'm an upstream valgrind developer and yes there
are patches around but they're not merged yet.

I'm not saying I won't take the patch I was just surprised it
was allowed and/or worked and was trying to find out more details
before I did anything.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dmesg restricted to root in Rawhide

[Tom Hughes via devel]

On 28/02/2024 10:05, Marcin Juszkiewicz wrote:

W dniu 27.02.2024 o 22:27, Justin Forbes pisze:

In practice, this isn't that much of a lockdown for most fedora users.
We give the default user on a system wheel access which means both
'sudo dmesg' and 'journalctl -k' work as is.

You wish...

$ id
uid=1003(marcin) gid=1006(marcin) 
groups=1006(marcin),10(wheel),11(cdrom),18(dialout),39(video),63(audio),100(users),135(mock),948(render),960(libvirt),986(wireshark),1003(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

$ dmesg
dmesg: read kernel buffer failed: Operation not permitted
$ uname -a
Linux puchatek.local 6.8.0-0.rc5.41.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC 
Mon Feb 19 14:19:27 UTC 2024 x86_64 GNU/Linux


Which proves what? You did "dmesg" not "sudo dmesg" or "journalctl -k".

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Confused about what to do about a ticket

[Tom Hughes via devel]

On 26/08/2022 14:48, Ron Olson wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=2114563 was reported against Swift 
on Rawhide. I fixed the issue and responded on 8/4 that the Koji build was 
successful, but I got two additional, presumably automated, notes from Ben 
Cotton and Miro that suggest something else needs to be done. Since this is/was 
a rawhide build there’s nothing to “fedpkg update” as I recall, so I guess what 
I’m asking is what should I do to make it clear that Swift is working for 
Rawhide/F37? I admit I’ve always been kind-of unsure how Rawhide works insofar 
as I’ve never submitted a “formal update” to it (i.e. the aforementioned 
“fedpkg update” command).


Well it was reported before branching and you fixed it but
didn't actually close it so it looks like it is still an active
bug and hence got automatically moved to F37 and added as a
blocker to the FTBFS bug.

If it was fixed before branching, as appears to be the case then
the fix is in F37 now so you can just close it NEXTRELEASE.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Explicit dependency on systemd-rpm-macros now required?

[Tom Hughes via devel]

On 14/09/2022 12:11, Florian Weimer wrote:

I see some new build failures in rawhide related to systemd RPM macros:

Processing files: opencryptoki-3.18.0-4.fc38.s390x
error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
error: File must begin with "/": %{_unitdir}/pkcsslotd.service
[…]
RPM build errors:
 File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
 File must begin with "/": %{_unitdir}/pkcsslotd.service
Child return code was: 1
EXCEPTION: [Error()]

Is this a package problem (missing dependency on systemd-rpm-macros), or
is this something that should be fixed at the buildroot level?


Guidelines say yes, you do need a BR on that:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Failed RPM database migrations

[Tom Hughes via devel]

I have one machine that has failed.

It was an upgrade from 35 to 36 done using dnf distro-sync
but I have plenty of others done the same way that worked.

One difference is that it's a machine that wasn't upgraded
until August while other ones were done back in May as a
result of which the upgrade was:

  from rpm-4.17.1-3.fc35.x86_64
to rpm-4.17.1-3.fc36.x86_64

while other machines were more like:

  from rpm-4.17.0-4.fc35.x86_64
to rpm-4.17.0-10.fc36.x86_64

Tom

On 28/10/2022 11:49, Richard W.M. Jones wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
https://bugzilla.redhat.com/2042099

The RPM database is supposed to move from /var/lib/rpm to
/usr/lib/sysimage/rpm.  This was supposed to happen automatically when
you upgraded the rpm package from an earlier version to 4.17.0-10.fc36
(Feb-Mar 2022).

On several machines it is reported that the migration was only half-
completed.  The symptoms are that the RPM database is still in
/var/lib/rpm (/usr contains symlinks to it).  See typical output from
failed & successful migrations at the end of the email.

So _if_ you have rpm >= 4.17.0-10.fc36 installed:

  - Do you see the symptom of a failed migration?  Or does it appear
to be successful?  (Or neither case??)

  - Did you:
 * Install F37 or Rawhide from scratch?
 * Upgrade using ordinary dnf update or similar?
 * Upgrade using dnf system-upgrade?
 * Some other install/upgrade method?

Rich.


** After a failed migration: **

$ ls -la /var/lib/rpm
total 339004
drwxr-xr-x.  2 root root  4096 Feb 16  2022 .
drwxr-xr-x. 76 root root  4096 Aug 23 13:28 ..
-rw-r--r--.  1 root root 0 Oct 18 14:28 .migratedb
-rw-r--r--.  1 root root 347095040 Oct 26 16:50 rpmdb.sqlite
-rw-r--r--.  1 root root 32768 Oct 27 15:28 rpmdb.sqlite-shm
-rw-r--r--.  1 root root 0 Oct 26 16:50 rpmdb.sqlite-wal
-rw-r--r--.  1 root root 0 Feb 16  2022 .rpm.lock

$ ls -la /usr/lib/sysimage/rpm
total 8
drwxr-xr-x. 2 root root 4096 Oct  5 12:05 .
drwxr-xr-x. 3 root root 4096 Feb  9  2022 ..
lrwxrwxrwx. 1 root root   34 Oct 18 14:28 .migratedb -> 
../../../../var/lib/rpm/.migratedb
lrwxrwxrwx. 1 root root   36 Oct 18 14:28 rpmdb.sqlite -> 
../../../../var/lib/rpm/rpmdb.sqlite
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-shm -> 
../../../../var/lib/rpm/rpmdb.sqlite-shm
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-wal -> 
../../../../var/lib/rpm/rpmdb.sqlite-wal
lrwxrwxrwx. 1 root root   33 Oct 18 14:28 .rpm.lock -> 
../../../../var/lib/rpm/.rpm.lock


** After a successful migration: **

$ ls -la /var/lib/rpm
lrwxrwxrwx. 1 root root 26 Sep  5 13:35 /var/lib/rpm -> 
../../usr/lib/sysimage/rpm

$ ls -la /usr/lib/sysimage/rpm
total 316324
drwxr-xr-x. 2 root root91 Sep 17 23:03 .
drwxr-xr-x. 3 root root17 Aug  9 14:27 ..
-rw-r--r--. 1 root root 323878912 Oct 27 16:12 rpmdb.sqlite
-rw-r--r--. 1 root root 32768 Oct 28 10:45 rpmdb.sqlite-shm
-rw-r--r--. 1 root root 0 Oct 27 16:12 rpmdb.sqlite-wal
-rw-r--r--. 1 root root 0 Sep  5 13:53 .rpm.lock




--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Failed RPM database migrations

[Tom Hughes via devel]

The reason it hadn't completed is that rpmdb-migrate.service
was enabled on that machine.

Enabling (and starting) that service made it complete.

Tom

On 28/10/2022 12:24, Tom Hughes via devel wrote:

I have one machine that has failed.

It was an upgrade from 35 to 36 done using dnf distro-sync
but I have plenty of others done the same way that worked.

One difference is that it's a machine that wasn't upgraded
until August while other ones were done back in May as a
result of which the upgrade was:

   from rpm-4.17.1-3.fc35.x86_64
     to rpm-4.17.1-3.fc36.x86_64

while other machines were more like:

   from rpm-4.17.0-4.fc35.x86_64
     to rpm-4.17.0-10.fc36.x86_64

Tom

On 28/10/2022 11:49, Richard W.M. Jones wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
https://bugzilla.redhat.com/2042099

The RPM database is supposed to move from /var/lib/rpm to
/usr/lib/sysimage/rpm.  This was supposed to happen automatically when
you upgraded the rpm package from an earlier version to 4.17.0-10.fc36
(Feb-Mar 2022).

On several machines it is reported that the migration was only half-
completed.  The symptoms are that the RPM database is still in
/var/lib/rpm (/usr contains symlinks to it).  See typical output from
failed & successful migrations at the end of the email.

So _if_ you have rpm >= 4.17.0-10.fc36 installed:

  - Do you see the symptom of a failed migration?  Or does it appear
    to be successful?  (Or neither case??)

  - Did you:
 * Install F37 or Rawhide from scratch?
 * Upgrade using ordinary dnf update or similar?
 * Upgrade using dnf system-upgrade?
 * Some other install/upgrade method?

Rich.


** After a failed migration: **

$ ls -la /var/lib/rpm
total 339004
drwxr-xr-x.  2 root root  4096 Feb 16  2022 .
drwxr-xr-x. 76 root root  4096 Aug 23 13:28 ..
-rw-r--r--.  1 root root 0 Oct 18 14:28 .migratedb
-rw-r--r--.  1 root root 347095040 Oct 26 16:50 rpmdb.sqlite
-rw-r--r--.  1 root root 32768 Oct 27 15:28 rpmdb.sqlite-shm
-rw-r--r--.  1 root root 0 Oct 26 16:50 rpmdb.sqlite-wal
-rw-r--r--.  1 root root 0 Feb 16  2022 .rpm.lock

$ ls -la /usr/lib/sysimage/rpm
total 8
drwxr-xr-x. 2 root root 4096 Oct  5 12:05 .
drwxr-xr-x. 3 root root 4096 Feb  9  2022 ..
lrwxrwxrwx. 1 root root   34 Oct 18 14:28 .migratedb -> 
../../../../var/lib/rpm/.migratedb
lrwxrwxrwx. 1 root root   36 Oct 18 14:28 rpmdb.sqlite -> 
../../../../var/lib/rpm/rpmdb.sqlite
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-shm -> 
../../../../var/lib/rpm/rpmdb.sqlite-shm
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-wal -> 
../../../../var/lib/rpm/rpmdb.sqlite-wal
lrwxrwxrwx. 1 root root   33 Oct 18 14:28 .rpm.lock -> 
../../../../var/lib/rpm/.rpm.lock



** After a successful migration: **

$ ls -la /var/lib/rpm
lrwxrwxrwx. 1 root root 26 Sep  5 13:35 /var/lib/rpm -> 
../../usr/lib/sysimage/rpm


$ ls -la /usr/lib/sysimage/rpm
total 316324
drwxr-xr-x. 2 root root    91 Sep 17 23:03 .
drwxr-xr-x. 3 root root    17 Aug  9 14:27 ..
-rw-r--r--. 1 root root 323878912 Oct 27 16:12 rpmdb.sqlite
-rw-r--r--. 1 root root 32768 Oct 28 10:45 rpmdb.sqlite-shm
-rw-r--r--. 1 root root 0 Oct 27 16:12 rpmdb.sqlite-wal
-rw-r--r--. 1 root root 0 Sep  5 13:53 .rpm.lock






--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Failed RPM database migrations

[Tom Hughes via devel]

On 28/10/2022 13:31, Richard W.M. Jones wrote:

On Fri, Oct 28, 2022 at 12:29:30PM +0100, Tom Hughes wrote:

The reason it hadn't completed is that rpmdb-migrate.service
was enabled on that machine.

[was not, I guess?]


Yes ;-)


Enabling (and starting) that service made it complete.


Interesting.  The current state of that service is:

○ rpmdb-migrate.service - RPM database migration to /usr
  Loaded: loaded (/usr/lib/systemd/system/rpmdb-migrate.service; disabled; 
vendor preset: enabled)
  Active: inactive (dead)

There are no log entries for this service, but my logs only go back to
around April which is probably too late to see anything.

After starting the service:

Oct 28 13:29:33 systemd[1]: Starting rpmdb-migrate.service - RPM database 
migration to /usr...
Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/.migratedb'
Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/rpmdb.sqlite-shm'
Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/rpmdb.sqlite'
Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/rpmdb.sqlite-wal'
Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/.rpm.lock'
Oct 28 13:29:35 rpmdb_migrate[1722092]: removed directory '/var/lib/rpm'
Oct 28 13:29:35 rpmdb_migrate[1722468]: '/var/lib/rpm' -> 
'../../usr/lib/sysimage/rpm'
Oct 28 13:29:35 systemd[1]: rpmdb-migrate.service: Deactivated successfully.
Oct 28 13:29:35 systemd[1]: Finished rpmdb-migrate.service - RPM database 
migration to /usr.
Oct 28 13:29:35 systemd[1]: rpmdb-migrate.service: Consumed 2.433s CPU time.

... and the migration has been successful.  So at least we know how to
fix this.  Although it's quite curious that the service was installed
and supposed to run but didn't.


The idea is that the service is enabled (not sure off hand what is
supposed to do that) but not started, so that it runs when you reboot
and completes the migration as part of the boot.

When it runs it removes /var/lib/rpm/.migratedb which was created
by the rpm scripts and hence prevents the service running on future
boots as it's no longer needed.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Change update

[Tom Hughes via devel]

On 07/11/2022 17:46, Miroslav Suchý wrote:


 8.

After you migrate your SPEC file, please add the string “SPDX” to
the entry of the packages’ %changelog. This is the easiest way to
detect the migration has been done. The second best option is to add
it to the dist-git commit message.


What do we do if the SPDX tag is the same as the existing license
tag (eg ISC) though? Do we just add a dummy change/commit entry that
mentions SPDX to confirm we've reviewed it?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: convert everything to rpmautospec?

[Tom Hughes via devel]

On 07/04/2024 16:15, Zbigniew Jędrzejewski-Szmek wrote:


I think it's time to switch to rpmautospec completely.
Thus, the proposal:
- new packages MUST use rpmautospec
- packagers SHOULD convert their packages
- provenpackagers MAY convert existing packages
   (e.g. when they want to push some fix or separately from other
work)
- people submitting pull requests against src.fp.o MAY also
   include a conversion in the pull request and packagers SHOULD
   merge it.


-1 for existing packages certainly - none of my git commit logs
are written with the expectation that they will double as package
changelogs so doing so may break the changelog.

I don't really want it for new packages either but at least
there I would know I needed to use the commit log in that way.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: convert everything to rpmautospec?

[Tom Hughes via devel]

On 08/04/2024 10:28, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote:

On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote:

-1 for existing packages certainly - none of my git commit logs
are written with the expectation that they will double as package
changelogs so doing so may break the changelog.


Yes, I think rpm changelog is for users of the package and git log
is for the maintainers. Most of the time the entries apply to both,
but sometimes they don't.


This was already answered to some extent, but since it seems to a
common misconception, I'll reply here again:

%autochangelog is designed to keep the separation between git log and
%changelog. Generally, only some git log entries end up with a
matching entry in the autogenerated %changelog, see
https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#skipping-changelog-entries.


Yes I read the documentation last night after some of the clarifications
and I'm much less opposed now and considering trying it out next time
there is a new release for one of my packages.

I think things might have gone better if things had been phrased
as reminding people of how it all worked, and that it is in fact now
policy to use it (which had passed me by) rather than coming straight
out with threats to use proven packagers which I suspect got people's
backs up and led to some of the swift negative responses.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: convert everything to rpmautospec?

[Tom Hughes via devel]

On 08/04/2024 14:47, Fabio Valentini wrote:


It is already supposed to be default / preferred since this Fedora 38 Change:
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default


I find that quite interesting because while I may have read it at
the time I had certainly long since forgotten that.

The problem I think what that change is that it's essentially about
changing policy and getting all packagers to move to a new way of
doing things but at a practical level all it did was update some
documentation - nothing it in actual provides for outreach or bringing
the change to the attention of packagers in any way so it's perhaps
not surprising that it seemingly didn't really achieve it's objective
leading us to this attempt to try again.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 40 apache now giving errors

[Tom Hughes via devel]

On 24/04/2024 02:28, Xose Vazquez Perez wrote:


# mkdir /etc/systemd/system/httpd.service.d/

# vi /etc/systemd/system/httpd.service.d/override.conf
[Service]
ProtectHome=false


Better than just opening up whole trees again would
be to use ReadWritePaths= to specify which paths should
be allowed for writing.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Testing package version is spec file

[Tom Hughes via devel]

On 08/05/2024 18:38, Brad Smith wrote:


I help maintain a package where upstream changed the process to
generate installed documentation. In version 1.30 and newer, the spec
file needs to use process A; in versions older than 1.30 (e.g. 1.29.x,
etc) the spec file needs to use process B. I am struggling to find a
workable solution to testing the version like this.


Why do you need to? When you update the spec file to 1.30 you
change it to use the new method surely.

Why do you need one spec file that can do both versions?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Spec file using github repo - not tarball

[Tom Hughes via devel]

On 08/05/2024 21:36, Kenneth Goldman wrote:


Is it possible for a .spec file to clone a github.com repo rather than
download a tarball?  Can someone link to a working example?


No, but github can give you a tar ball for any ref you want so why
would you need/want to?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Firefox 126.0 with DBus service

[Tom Hughes via devel]

On 15/05/2024 09:52, Ian McInerney via devel wrote:


Also, don't new enabled-by-default services need approval from either FESCO or 
the Workstation WG according to the packaging docs 
(https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/)? I 
know the page seems to focus on systemd services, but it does mention DBus 
services in a few place on the page, so I thought it would apply to DBus 
services that are automatically enabled as well.


Only exceptions need approval, and something which meets the
criteria above would not need an exception.

The main time an exception is needed is for services which
listen to the network.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Firefox 126.0 with DBus service

[Tom Hughes via devel]

On 15/05/2024 13:06, Michael J Gruber wrote:


Is this used by Gnome search unconditionally? I might want to use Gnome
but not a background indexer/tracker/search engine. Threw me off back then
when KDE introcuced something like that.


Go to "Search" in the Gnome settings and you can control which
search providers are enabled.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Spec file using github repo - not tarball

[Tom Hughes via devel]

On 21/05/2024 16:37, Dominik Wombacher wrote:


I have a case were upstream excludes the test suite from the export [1].
But I want the tests to be part of the package build to validate that 
everything is fine.
So this requires a bit of local git clone and create an own archive file.
I can't just grab the archive from the GitHub release in that case.


The automatic tar ball URLs on github just do a git archive and are
separate to uploaded release artifacts. Just use a URL like:

  https://github.com/OWNER/PROJECT/archive/REVISION/NAME.tar.gz

where tag can be any tag or head or commit hash. More here:

https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_commit_revision

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Tom Hughes via devel]

On 20/06/2024 15:03, Stephen Gallagher wrote:


Honestly, I'd like to pitch that we retarget Fedora at x86_64-v3 (yes,
three) and recommend creation of a Fedora "Hardware Life Extension"
Remix that can provide rebuilds of (a subset of) Fedora that they want
to run on ancient hardware. It could be something similar to Fedora
ELN, where a subset of the main repo that might be useful on old
hardware can be rebuilt (though unlike ELN, I suggest that this should
be an entirely separate infrastructure not maintained by the Fedora
Project). Such a project could then live or die based on willingness
to maintain it and stop holding back Fedora as a whole.


I definitely think going to v2 would be reasonable bit I tink
forcing v3 might be a step too far.

While my desktop is v4 and my laptop is v3 I have two other
machines at home which are only v2 one of which is only five
years old having been built then to replace a 32 bit machine
when Fedora was dropping 32 bit x86 support.

Having checked a couple of dozen machines at work that are
running either F39 or F40 it's roughly a 50/50 split between
ones which are v2 and ones with are v3. There are even three
v1 machines there though one is redundant and the other two
do really need replacing.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Tom Hughes via devel]

On 20/06/2024 16:34, Simon Farnsworth wrote:


For Pentium and Celeron branded processors, v2 also loses Skylake, Icelake,
Haswell,  Cometlake, Broadwell and others, even when their matching Core
branded processors support x86-64v2 or x86-64v3.

That means that you lose all Pentium Silver processors, including the latest
releases in that line, all Pentium Gold processors released before 2022, and
all Celeron processors released before 2020.


I have a Celeron N3160 which is a 2016 processor bought by me
in 2019 and that reports as v2.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: 2FA policy for provenpackagers is now active

[Tom Hughes via devel]

On 24/06/2024 18:26, Stephen Gallagher wrote:


Not really an issue if you have GSSAPI set up on your system. Such as
by installing fedora-chromium-config-gssapi (for Chrome/Chromium
users) or by using Firefox which is set up for GSSAPI out-of-the-box.


I've never seen Firefox use my kerberos ticket, it always asks me
to login. That doesn't bother me though because I have my password
manager readily available there, unlike at the command line.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora & AI Survey Now Live Until July 16th

[Tom Hughes via devel]

Survey: Please select at most 5 answers
User: Selects 2 answers
Survey: Please rank all items
User: Remembers why they hate surveys and gives up

To be clear as there are only two items where I think there is
any chance of AI being useful I am unable to rank the others.

Tom

On 01/07/2024 18:33, Aoife Moloney wrote:

Hi folks,

Thank you for contributing to our discussion on what kinds of questions 
are useful for us to ask our community on the subject of AI in the 
Fedora ecosystem [1]. We've created a short survey [2] based on the 
questions that were proposed that we feel are general enough for 
everyone to feel comfortable answering, and from the answer we receive, 
the council and other governing bodies of the project can start 
formalising some AI-related focus areas and develop solid guidelines for 
the use of AI in the project ecosystem.


The deadline is July 16th, it shouldn't take more than a few minutes of 
your time to complete, and I will be sending some reminders between now 
and the closing date too.


A quick reminder that this is not our annual contributors survey, and 
that survey will be launching soon with a section around AI too. I want 
to offer an advance apologies for any survey-related fatigue, but when 
it comes to creating AI guidelines for the project and understanding how 
our community is doing and feels about the project, this AI survey and 
the contributor survey is truly the best way to get that feedback and 
create actionable stuff 'n' things from your direct responses.




Kindest regards,
Aoife


[1] 
https://discussion.fedoraproject.org/t/ai-survey-questions-what-should-we-be-asking/118338 
[2] https://fedoraproject.limequery.com/142117?lang=en 


--

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im 

IRC: amoloney






--
Tom Hughes (t...@compton.nu)
http://compton.nu/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora & AI Survey Now Live Until July 16th

[Tom Hughes via devel]

On 01/07/2024 20:07, Aoife Moloney wrote:

I would also like to add that we deliberately took a positive tone for 
this survey as it is far too easy to find (many) negatives for AI (and 
for good reason!), and we wanted to try to look at the benefits we could 
get from AI instead if applied properly and wit the best interest of 
Fedora driving the use of AI in parts of the projects ecosystem.


Well I guess if you're only interested in positive responses then
we can say the survey design is a success - just a shame that the
results will be meaningless.

I understand why surveys have to use closed form questions with a
fixed set of responses but it should always be possible to opt out
of questions and, ideally, to explicitly indicate that you do not
agree with any of the proposed responses, otherwise you are artificially
restricting the results to the set of concepts that were (either
deliberately or subconsciously) in the mind of the survey creator.

At the very least the question needs to be changed to not indicate
that two answers are required if five are!

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

mapnik soname bump in rawhide

[Tom Hughes via devel]

I've updated mapnik in rawhide to 4.0.0 which includes an soname bump.

I've rebuilt python-mapnik and opened a PR for viking to fix it to build
against mapnik 4 which I believe covers all the downstream users.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Tom Hughes via devel]

On 27/06/2022 08:53, Richard W.M. Jones wrote:

On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote:

Dear Richard,

If the only problem is legacy (and unsafe) ciphersuites, loading the legacy
provider will solve this problem.


Any clues on how to do that?


https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

[Tom Hughes via devel]

On 27/06/2022 10:02, Richard W.M. Jones wrote:

On Mon, Jun 27, 2022 at 09:11:29AM +0100, Tom Hughes wrote:

On 27/06/2022 08:53, Richard W.M. Jones wrote:

On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote:

Dear Richard,

If the only problem is legacy (and unsafe) ciphersuites, loading the legacy
provider will solve this problem.


Any clues on how to do that?


https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers


Results unclear.  Loading legacy + default doesn't seem to give any
errors, but I still see the same errors in the tests.  I might be
loading these providers in the wrong way however.

The code is here:
https://github.com/rwmjones/cpython/commits/python-2.7-openssl-3


That looks about right, or at last it looks very similar to
what I did elsewhere.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

[Tom Hughes via devel]

As I said before I don't care that much what the policy is but I do
care very much that Fedora keeps changing it.

Twice now I have had to go and reconfigure my networks after a Fedora
upgrade has changed the MAC assignment policy.

My vote is therefore to leave it as it is so that I don't have to go
and change everything again!

Basically I don't care what the MAC of a machine is but I care very
much if it changes because I have to update DHCP so that it can
continue to issue the correct IPs and DNS for IPv6 addresses which
change when the MAC changes.

Tom

On 25/06/2022 20:06, Vipul Siddharth wrote:

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

The `systemd-udev` package installs
`"/usr/lib/systemd/network/99-default.link"`,
which sets `Link.MACAddressPolicy=persistent`. This proposal is to
change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address.
This is particularly important for bridge and bond devices.

This change can either only apply to bridge/bond devices, or to
various software devices. That is to be discussed.

== Owner ==

* Name: [[User:thaller|Thomas Haller]] (NetworkManager)
* Email: 
* Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
* Email: 


== Detailed Description ==

On Fedora, udev by default changes the MAC address of a wide range of
software devices.
This was introduced by systemd 242 in early 2019 (Fedora 31), when
`MACAddressPolicy=` was
extended to affect more types of devices.

With `MACAddressPolicy=persistent` udev's aim is to provide a stable
MAC address, otherwise
the kernel will assign a random one. However, that can cause problems:

Firstly, software devices are always created by some tool that has
plans for the device. The tool may not
expect that udev is going to change the MAC address and races against
that. The best solution
for the tool is to set the MAC address when creating an interface.
This will prevent
udev from changing the MAC address according to the MACAddressPolicy.
Otherwise, the tool should wait for udev to initialize the device to
avoid the race. In theory, a
tool is always advised to wait for udev to initialize the device.
However, if it were not for MACAddressPolicy,
in common scenarios udev doesn't do anything relevant for software
devices to make that necessary.

Secondly, for interface types bridge and bond, an unset MAC address
has a special meaning
to the kernel and the MAC address of the first port is used. If udev
changes the MAC
address, that no longer works.
Now the generated MAC address is not directly discoverable as it is
based on `/etc/machine-id`
([https://www.man7.org/linux/man-pages/man5/machine-id.5.html
machine-id(5)]), among
other data. Even if there were a tool to easily calculate the MAC
address, it could be cumbersome
to use it without logging into the machine first. The MAC address can
directly affect the
assigned IP address, for example when using DHCP. When booting a new
virtual machine, the user might
know the MAC address of the (virtual) "physical" interfaces. When
bonding/bridging those
interfaces, the bond/bridge would get one of the well known MAC
addresses. `MACAddressPolicy=persistent`
interferes with that.

The goal of persistent policy is to provide a stable MAC address. Note
that if the
tool or user who created the interface would want a certain MAC address, they
have all the means to set it already. That applies regardless whether
the tool is
iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor
systemd-networkd
rely on udev's MACAddressPolicy for setting the MAC address. This
behavior is mostly
useful for plain `ip link add`, but it's unclear which real world user
wants this behavior.

Of course, the user is welcome to configure the MAC address in any way
they want. Including,
dropping a link file that sets `MACAddressPolicy=persistent`. The
problem is once udev sets a MAC address,
it cannot be unset. Which makes this problematic to do by default.

While Fedora inherited this behavior from upstream systemd, RHEL-9
does not follow this behavior
([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf2e694bfbc2b02a456c1056f252e/0028-udev-net-setup-link-change-the-default-MACAddressPol.patch#L43
centos9],
[https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For
RHEL-8, this doesn't
apply because the systemd there is too old to change the MAC address
of most software devices.

This could be either implemented by patching
`/usr/lib/systemd/network/99-default.link`
to have a different policy, or by dropping a link file with higher
priority. In the latter
case, that override could be shipped either by udev or even by NetworkManager.

Another option is to change the scope of this proposal to only change to
`MACAddressPolicy=none` fo

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

[Tom Hughes via devel]

On 27/06/2022 17:05, Thomas Haller wrote:


On Mon, 2022-06-27 at 13:09 +0100, Tom Hughes via devel wrote:


Twice now I have had to go and reconfigure my networks after a Fedora
upgrade has changed the MAC assignment policy.


Interesting. Are you sure it was twice? I thought it changed "only"
once in F31 (2019).


No it has just changed again in F36 at least for bridges, back
to what it was before the previous change I believe.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: MAC Address Policy none (System-Wide Change)

[Tom Hughes via devel]

On 27/06/2022 17:09, Tom Hughes via devel wrote:

On 27/06/2022 17:05, Thomas Haller wrote:


On Mon, 2022-06-27 at 13:09 +0100, Tom Hughes via devel wrote:


Twice now I have had to go and reconfigure my networks after a Fedora
upgrade has changed the MAC assignment policy.


Interesting. Are you sure it was twice? I thought it changed "only"
once in F31 (2019).


No it has just changed again in F36 at least for bridges, back
to what it was before the previous change I believe.


I've had a look through the git log for my DNS and taking one
machine as an example:

 initially - bridge had MAC of 00:b0:c2:02:4c:f3 from member
Aug 2015 (F22) - bridge changed to 1a:81:14:46:3c:c7
Jan 2020 (F31) - bridge changed to fe:e3:75:bd:6a:8c
May 2022 (F36) - bridge changed back to 1a:81:14:46:3c:c7

Only the first one corresponds to a member, so I think F22 is
where persistent addresses were first introduced. I'm not sure
what happened in F31 than then got reverted in F36.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Tom Hughes via devel]

On 02/07/2022 11:35, Marius Schwarz wrote:


Am 02.07.22 um 10:37 schrieb Adam Williamson:


Probably not, no. Lennart hasn't maintained PA upstream or downstream
for a long time. The current downstream maintainer is Wim Taymans (I
think).


Can we change the defaults for PA inside bugzilla to Wim and transfer 
the open tickets to him?
it does not make sense to have Leonard as default assignee if the 
accoutn is disabled.


Well that is just a matter of who is the main-admin of the package
so the package owner can change it.

Strictly speaking Lennart is still the main-admin on pulseaudio
though Wim is also a committer so would have been cced on the bug
if it was a pulseaudio bug.

But it isn't a pulseaudio bug, it's a pavucontrol bug, and Wim is
not a committer there which is why he isn't cced.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Tom Hughes via devel]

On 04/11/2020 18:12, Ben Cotton wrote:


= Phase 1: Analysis =
For this change, we will start by creating a list of all packages that
have a build-time dependency on make.  This will be done by analyzing
spec files and also by rebuilding all packages in Fedora with make
removed from the buildroot to see which packages fail to build.  Once
we have this list, we will remove packages that already have
BuildRequires:make in their spec file, and this final list[1] will be
all the packages that need to be updated in Phase 2.

[1] 
https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br_make.txt


Could we have a list that includes maintainer names please so that
people who want to can fix their packages before automation gets
less loose on them?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Tom Hughes via devel]

On 04/11/2020 19:06, Tom Hughes via devel wrote:

On 04/11/2020 18:12, Ben Cotton wrote:


= Phase 1: Analysis =
For this change, we will start by creating a list of all packages that
have a build-time dependency on make.  This will be done by analyzing
spec files and also by rebuilding all packages in Fedora with make
removed from the buildroot to see which packages fail to build.  Once
we have this list, we will remove packages that already have
BuildRequires:make in their spec file, and this final list[1] will be
all the packages that need to be updated in Phase 2.

[1] 
https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br_make.txt 



Could we have a list that includes maintainer names please so that
people who want to can fix their packages before automation gets
less loose on them?


Also I'm suspicious about the quality of that list because it
includes packages of mine that only use make via cmake and which
do BR cmake which in turn requires make.

Tom

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Tom Hughes via devel]

On 04/11/2020 19:14, Neal Gompa wrote:


When did this happen? CMake should not be requiring Make at runtime,
especially now that the CMake macros let you trivially use either Make
or Ninja.


No idea, but "rpm -q --requires cmake" says it does.

And I only sue %cmake macros which is turn invoke cmake which
then I assume then invokes make, so it seems correct to me that
it requires it.

Tom

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Tom Hughes via devel]

On 04/11/2020 19:46, Tom Stellard wrote:

On 11/4/20 2:10 PM, Tom Hughes via devel wrote:


Also I'm suspicious about the quality of that list because it
includes packages of mine that only use make via cmake and which
do BR cmake which in turn requires make.


For the purposes of this proposal, your packages still need to 
BuildRequires: make.  I don't want to depend on this kind of indirect 
dependency to keep things working, because it can be fragile.


So instead I'm supposed to somehow know what tools the tools
that I use choose to invoke under the covers? Where does that
insanity end exactly? Do I have to require gas because gcc
will use it to assemble the code it generates?

Tom

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Tom Hughes via devel]

On 04/11/2020 20:31, Tom Stellard wrote:

On 11/4/20 3:22 PM, Tom Hughes wrote:

On 04/11/2020 19:46, Tom Stellard wrote:

On 11/4/20 2:10 PM, Tom Hughes via devel wrote:


Also I'm suspicious about the quality of that list because it
includes packages of mine that only use make via cmake and which
do BR cmake which in turn requires make.


For the purposes of this proposal, your packages still need to 
BuildRequires: make.  I don't want to depend on this kind of indirect 
dependency to keep things working, because it can be fragile.


So instead I'm supposed to somehow know what tools the tools
that I use choose to invoke under the covers? Where does that
insanity end exactly? Do I have to require gas because gcc
will use it to assemble the code it generates?



No, in that case gcc needs to Require: gas, because it is a run-time
dependency of that package.

CMake will still work if make is not installed.  Packages that use
cmake + Ninja should require those packages, and packages that use
cmake + make should require those packages too.


I don't choose either. I just run cmake and it chooses what to
use as it's default build tool. If I told it to use a specific
build tool then I would see your point, but for the default one
it seems reasonable that it should require it as it has made
the decision to use it.

Otherwise if cmake was to change it's default to ninja then
every package would have to be changed not just one...

Tom

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

Re: Heads up: proj 7.2.0 + gdal 3.2.0

[Tom Hughes via devel]

On 05/11/2020 11:24, Sandro Mani wrote:

I'll be building proj-7.2.0 together with gdal-3.2.0 in rawhide shortly. 
I'll do a round of test builds in this copr [1], and then build 
everything (and rebuild dependent packages) in a rawhide side-tag and 
then merge it.


That's definitely going to cause some breakage as I believe proj 7 has
finally removed the old legacy API which at least some other things like
mapnik are still using.

I believe there is an upstream patch for mapnik now but I'll have to
see if it can be backported to the release version...

Tom

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

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

[Tom Hughes via devel]

On 05/11/2020 11:56, Kevin Kofler via devel wrote:


CMake actually just generates the makefiles, you still run make directly (as
with autotools).

The makefiles then do several complex things, possibly including running
make with different arguments (and also calling back into CMake by running
cmake with special arguments multiple times), to handle the progress
reporting, but the initial make invocation comes from the specfile.


Not using the new %cmake_build etc macros it doesn't. Those invoke
cmake which then invokes make.

Tom

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

Re: patch applied without package maintainers' approve

[Tom Hughes via devel]

On 09/11/2020 14:50, Honggang LI wrote:

On Mon, Nov 09, 2020 at 02:39:22PM +0100, Dominik 'Rathann' Mierzejewski wrote:

On Monday, 09 November 2020 at 14:23, Honggang LI wrote:

On Mon, Nov 09, 2020 at 08:03:59AM -0500, Neal Gompa wrote:

On Mon, Nov 9, 2020 at 8:03 AM Honggang LI  wrote:


hi

I'm one of package maintainers of rdma-core. There is a patch
applied without any maintainers' review/approve. I had sent two emails
to patch committer to ask him/her to push the change to upstream.
But never get response.

The patch maybe useful or fix something. But the divergence between
upstream and Fedora rawhide is what I don't want to see, because
such divergence is source of regression issues.

What I should to do with that commit? Just blindly revert it?


Send it upstream yourself. If you don't like the divergence, help fix
it by sending the patch upstream and working with them.


To be honest, the patch was applied without any PR or bugzilla opened,
just very simple inline comment, I don't really understand the patch.

That is why I did not submit it to upstream.


Can you be more specific? Which patch are you talking about?
I can see only one patch in the package and it was committed by you:
https://src.fedoraproject.org/rpms/rdma-core/c/55352ca3c535f31dfce9ab7779ee4d26980604be


commit 59a8e2e0d0ddba785fc79c4731e0b8685893458b
Author: Peter Robinson 
Date:   Tue Sep 15 00:26:18 2020 +0100

 Split out libibverbs to a core sub package for libpcap IB support to 
minimise deps for users that don't require IB support


Well that's a packaging issue so it's not something that
would normally go upstream, or does upstream have a spec
file that you are using?

I mean I absolutely agree that it shouldn't have been done
using PP powers without at least trying to talk to the package
maintainers first if that is what happened, but it doesn't
look like something where upstreaming is a concern.

Tom

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

Re: The default fs.inotify.max_user_watches limit is too low.

[Tom Hughes via devel]

On 18/11/2020 09:58, Miro Hrončok wrote:

On 11/18/20 10:13 AM, Gargoyle wrote:


If not, then perhaps the default should be significantly increased 
with the aim of removing the problem for new users with modern 
desktop/laptop machines which probably have 4GB+ RAM. I've not 
rebooted my machine overnight and netbeans is now up to 13,000 watches 
and tracker-miner upto 4,500. So in less than 24 hours I have exceeded 
16K watches.


Perhaps an new default value in the region of 32K - 64K would be more 
appropriate?


See also https://bugzilla.redhat.com/show_bug.cgi?id=1575156

I wonder how was this fixed.


Seems I must have run into it on my work machine as well, due to
vscode by the looks of it, and I increased the limit significantly
as a result.

Tom

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

Re: video meeting to discuss Matrix/Element and IRC

[Tom Hughes via devel]

On 19/11/2020 19:25, Adam Williamson wrote:


I mean, I'm an old fogey too, but at *some* point we do have to accept
that new things can be actively better.


True.


I honestly can see exactly zero downsides to using a Matrix setup as
compared to using IRC, and a giant pile of upsides, starting with "I no
longer need to dedicate a small portion of my brain to remembering how
my IRC bouncer setup works and maintaining it".


Well my experience when I looked at matrix desktop clients
before was that they needed more screen real estate to be
usable than IRC clients, which is certainly one downside and
probably a direct consequence of rich media support.

There's also the fact that unless I can get it to talk to all
the same chat systems I have pidgin talking to I would need to
be running two clients instead of one.

I am interested though, and did actually explore the idea of
running my own home server and what I could bridge it to (so
not that different to running my own bouncer now...) recently.

Anyway I just looked at the three clients that were suggested
earlier - all three are using Qt which makes them virtually
unusable on a wayland/gnome desktop as far as I can see as the
resize handles are so small they're impossible to use.

More amusingly one of them crashed as soon as I logged in and
a second went into a "your window is too small mode" as soon
as I resized it to match my IRC client.

The third was better, but rendered the conversation in that
left/right style of SMS clients, which is horrible for a chat
room.

No doubt there are others I can try...

Tom

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

Re: video meeting to discuss Matrix/Element and IRC

[Tom Hughes via devel]

On 19/11/2020 19:49, Neal Gompa wrote:


The GNOME-based one is Fractal, which is not available in Fedora as of
right now. That said, the Qt based ones are in way better shape than
the GNOME one. And QGnomePlatform should make them work reasonably
well...


My problem, at least on this hidpi laptop, is that the bit of the
window edge that I need to grab to resize it is only about one pixel
wide so virtually impossible to grab. Native gnome windows have a
much wider area I can grab.

It might be better on my desktop that isn't hidpi and has a mouse
instead of a trackpad.

Tom

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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Tom Hughes via devel]

On 25/11/2020 10:47, Wim Taymans wrote:


but I don't want to test all this


This is ok, I can understand that you don't want to deal with possible audio 
problems. You
will have to install pulseaudio again and opt out. You will have to hope that 
other people
do sufficient testing. It is a bit strange when you are running rawhide, but 
hey.


I think a key problem is that this is a feature that can only really
be tested in a desktop environment and not many people run rawhide on a
desktop, so if it's only testable in rawhide how much testing will it
really get.

That's probably why people are so keen to be able to test it in F33 or
to delay it for a further cycle.

Tom

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