Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

Matthew Miller wrote: > But that's policy as well. It would be reasonable to have a different > policy, like "build and soft dependencies are okay from base -> secondary, > but not hard runtime requirements". But a build-time dependency often automatically results in a hard runtime dependency, e.

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

Ken Dreyer wrote: > On Fri, Nov 13, 2020 at 3:23 PM Matthew Miller > wrote: >> That reason was _mainly_ to erase the inside Red Hat, >> community-around-the-edges distinction. That was a huge success and >> Fedora wouldn't be interesting without that. But I think the _technical_ >> choice was in

Re: Unable to disable SysRq

Robert Marcano via devel wrote: > Two times in a week I have killed all processes trying to use Alt+i. Ts > is to easy to press the Alt and the PrtScr at the same, starting that > way the SysRq i command. > > So before staring to write a kernel patch to add an option where the > SysRq is only trig

Re: Two questions on updates

Fabio Valentini wrote: > Normal updates need at *least* +2 karma so they can be pushed to > stable *manually*. Uh, last I checked, normal updates need only +1 (and that's a good thing, many updates don't even get +1 in a reasonable time frame, let alone +2). Only critical path packages and (IIRC

Re: Two questions on updates

Fabio Valentini wrote: > You are kinda right, yet you are not. > The minimum for *autokarma* is +1 for normal updates, +2 for critpath > updates. But the message "This update can be pushed to stable if the > maintainer wishes" does not refer to autokarma (update getting pushed > automatically by bo

Re: video meeting to discuss Matrix/Element and IRC

Matthew Miller wrote: > As mentioned, we're looking at moving the Fedora Council's main chat to > Matrix. And as part of that, we're considering a hosted Element server -- > which obviously could go quite beyond just #fedora-council. Neal suggested > a video meeting to talk with interested people a

Re: video meeting to discuss Matrix/Element and IRC

Erich Eickmeyer wrote: > False. The bridges are bidirectional. As I understand it, the Matrix-IRC bridge is "bidirectional" in the sense that it relays messages both ways, but not in the sense that an IRC user would be able to connect to an arbitrary Matrix channel with an IRC client the way it

Re: video meeting to discuss Matrix/Element and IRC

Adam Williamson wrote: > The problem is that bridging to existing IRC channels severely dilutes > one of the main appeals of Matrix - being more welcoming to new users > familiar with modern chat system norms. Maybe the way to make everyone happy would be to bridge the other way round, i.e., an I

Re: %pretrans [package name]

Miro Hrončok wrote: > Try this (note the -n): > > %pretrans -n doc-en -p That would have to be: %pretrans -n sagemath-doc-en -p because -n takes the full subpackage name, not just the suffix. (That is normally the entire point of -n, to allow arbitrary names for subpackages.) Kev

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

Ben Cotton wrote: > This changes is to promote Fedora CoreOS to Edition status alongside > Workstation, Server and IoT. IMHO, Fedora CoreOS is still an experiment with way too many limitations and drawbacks to warrant Edition status. Don't get me wrong, it is nice to have a place for experiments

Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+

Ben Cotton wrote: > ...changes in default behavior, when 1. technically reasonable and 2. > not explicitly overridden by the user, should generally be made on > upgrade. I disagree. Upgrades should be as unsurprising as possible and keep user configuration as much as possible. Changes in defaults

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

Fabio Valentini wrote: > Is there a reason why "main" is proposed instead of "rawhide" on src.fp.o? > For all non-dist-git repositories I am fine with "main", but if we are > changing this anyway, "rawhide" would actually make more sense for > dist-git repos. > This would make the branch name actua

Re: Rawhide Repo needs downgradeable packages

Vít Ondruch wrote: > As a workaround, if you use `keepcache=True` in dnf.conf, you'd have > copies of everything you previously installed on your system. I still don't understand why this is not the default. Even for stable releases, because without it, you can easily obtain only the ancient GA

Re: How do really work RAID1 on btrfs?

Sergio Belkin wrote: > So, let's say we have 3 small disks: 4GB, 3G, and 2GB. > > If I create one file of 3GB I think that > 3 GB is written on 4GB disk, it leaves 1 GB free. > 3 GB of copy is written on 3 GB disk, it leaves 0 GB Free. > > So, I create one file of 1GB that is written on 4GB disk

Re: How do really work RAID1 on btrfs?

PS: I wrote: > The optimum size can theoretically be achieved by using the following > physical partitioning: > * x GB on the 4 GB disk and the 3 GB disk, > * y GB on the 4 GB disk and the 2 GB disk, and > * z GB on the 3 GB disk and the 2 GB disk, > for a total of x+y+z GB, where x, y, and z solv

Re: Rawhide Repo needs downgradeable packages

Marius Schwarz wrote: > it will eat disk space. If you have 0ad laying around in 3 different > version, that's 1 GB each. Sure, but that is usually not the scarce resource. And if you need the disk space, you can always clear the cache manually. Deleting data should not be the default action. >

Re: End of CentOS Linux: What about Fedora?

Jaroslav Prokop wrote: > But apparently some already took on this task [0]. > [0] https://github.com/hpcng/rocky The official website is: https://rockylinux.org/ (Still somewhat under construction, of course.) It was started by the original founder of CentOS with the aim of going back to the roo

Re: End of CentOS Linux: What about Fedora?

Gordon Messmer wrote: > The release announcement was confusing, in that it used "rolling > release" to describe something that doesn't resemble the common > definition of that term. > > CentOS Stream isn't a rolling release. It will have distinct major > releases. It just won't have point releas

Re: End of CentOS Linux: What about Fedora?

One more aspect I missed in my previous reply: Gordon Messmer wrote: > CentOS Stream […] [i]s also not going to have short release intervals. It > will be released every three years, and maintained for five years. That is still only half of the 10 years that were originally announced for CentOS

Re: gpg-agents all over the place

Sam Varshavchik wrote: > I miss the days when gpg needed a passphrase it simply prompted a message > on standard output, turned off tty echo, and just read the password that I > typed in. > > But that was too simple, primitive, and bulletproof. I guess that things > can't be as simple any more, an

Re: gpg-agents all over the place

Sam Varshavchik wrote: > But, for some reason that I do not understand, the existing terminal > interface always gets broken. Well, how prompts in terminal emulator sessions in the GUI should work is a design decision. Some people (like you, apparently) expect them to behave the terminal way (so

Re: End of CentOS Linux: What about Fedora?

Robin Opletal wrote: > I think this wouldn't be that much of a problem - what I think is bad is > that CentOS Stream security updates aren't going to come before RHEL's > will, and they will essentially be backported, at least as I understood > it. That would be a forward-port then, not a backport

Re: Chromium built in rawhide does not render most strings

Neal Gompa wrote: > QtWebEngine *is* Chromium, so it would make sense that it exhibits the > same problem. To be clear (and I know you know this, but your readers might not know), QtWebEngine (qt5-qtwebengine) and Chromium (chromium) are distinct packages (none of them depends on each other), ea

Re: How to handle ABI breakage in Rawhide

Florian Weimer wrote: > That's not actually true, though, and it does not make much sense. If > upstream commits to an ABI, versioning is not even required technically. Hardly any upstream actually commits to an ABI *forever*. Even if the ABI has not changed for 10 years, that does not mean that

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

Nico Kadel-Garcia wrote: > It seems that the problem existed as well with earlier versions of > rpmbuild, say on RHEL 7, but the warning messages about "files listed > twice" weren't generated. And various slightly differently named > README.md and LICENSE.md files make it not as obvious as one mig

Re: I quit packaging

Emmanuel Seyman wrote: > * routino That one has actually been maintained by Dan Horák for a while. Volker is/was only co-admin. (I am still co-admin, too. I used to be the primary maintainer, Dan picked it up from me a few years ago.) Kevin Kofler __

Re: I quit packaging

Volker Fröhlich wrote: > I don't want to be a package maintainer anymore. Too bad! Thank you for your contributions so far! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fe

Re: F36 Change: DIGLIM (System-Wide Change proposal)

Nico Kadel-Garcia wrote: > On Sun, Dec 26, 2021 at 1:10 AM Dan Čermák > wrote: >> >> Ben Cotton writes: >> >> *snip* >> >> > == Upgrade/compatibility impact == >> > The user should ensure that software (not updated) from the old >> > distribution is packaged and the package header is signed, or

Re: F36 Change: DIGLIM (System-Wide Change proposal)

Matthew Miller wrote: > 1. There is a mechanism for users to add their own digest lists, if they >want. The change proposal could be a little more clear on how this >would work. There is no way I am going to jump through hoops to whitelist software I compiled myself, or installed from a t

Re: F36 Change: DIGLIM (System-Wide Change proposal)

Mattia Verga via devel wrote: > I do not see how this change goes against the definition of Free > Software. It doesn't deny a user to install any software they want, it > is about preventing unwanted/unsolicited/malevolent software from being > installed without user (admin) approval. But there i

Re: F36 Change: DIGLIM (System-Wide Change proposal)

Ben Cotton wrote: > ** Maintain the following patch sets for the Linux kernel, and > possibly have them accepted in the upstream kernel: > *** > [//lore.kernel.org/linux-integrity/20210409114313.4073-1- roberto.sa...@huawei.com/ > IMA execution policies] *** > [//lore.kernel.org/linux-integrity/202

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

Ben Cotton wrote: > == Summary == > Changing the default fonts for various languages to Noto Fonts as much > as possible, to make consistency on the text rendering. > > == Owner == > * Name: [[User:Tagoh|Akira TAGOH]] > * Email: Considering that DejaVu had been chosen as the default font for its

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

Kevin Kofler via devel wrote: > I see in this table that there are still a bunch of languages using > non-Noto fonts where there appears to be a Noto equivalent available, > e.g., https://fonts.google.com/noto shows me Devanagari, Bengali, and > Tamil on the first page whereas your tab

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

Akira TAGOH wrote: > Unfortunately Noto Sans Math doesn't have enough coverage to represent > math (as und-zmth orthography defined in fontconfig). I won't do it > (even if I do, it won't be picked up as a math font) and keep STIX as > a default math font this time for all the generic families. OK

Re: sphinx: Intention to orphan package

Miro Hrončok wrote: > On 13. 01. 22 14:13, Richard Shaw wrote: >> On Thu, Jan 13, 2022 at 6:34 AM Sergio Arroutbi > > wrote: >> >> Hello. >> >> I recently assumed the sphinx package maintenance for Fedora. >> >> >> As far as I can tell mariadb is the only co

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

Robert-André Mauchin wrote: > Sorry for the necro but there seems to be a problem with this change. It > broke multiple packages at the linking stage: > https://bugzilla.redhat.com/show_bug.cgi?id=2043178 It breaks ALL packages using gold to link, and the "fix" is to explicitly add a macro to gen

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

Kevin Kofler via devel wrote: > It breaks ALL packages using gold to link, and the "fix" is to explicitly > add a macro to generate gold-compatible output or to stop using gold. Also > affects qt5-qtwebengine: > https://bugzilla.redhat.com/show_bug.cgi?id=2043178#c10 And

RFE: CMake AutoRequires?

Hi, when working on finally fixing Trojitá to build (it had been FTBFS since F34, so removal was impending), I have noticed that the Akonadi contacts plugin was not getting built because of missing transitive build dependencies: https://bugzilla.redhat.com/show_bug.cgi?id=2046299 https://bugzil

Re: CVE-2021-4034: why is pkexec still a thing?

Adam Williamson wrote: > But that was then, and this is now. Does anything in Workstation use > pkexec? Does anything in KDE use it? Not sure. KDE stuff SHOULD use kdesu for this purpose, if it needs to run as root at all to begin with. But some application developer might have preferred pkexec

Re: CVE-2021-4034: why is pkexec still a thing?

Adam Williamson wrote: > Anyway, my point is not really pkexec vs. sudo for interactive use, but > whether pkexec is actually needed by default on all of our editions for > non-interactive use. It's not an easy question to answer since our > packaging doesn't distinguish between something needing *

Re: RFE: CMake AutoRequires?

Dan Čermák wrote: > There is something like that already in place: > https://src.fedoraproject.org/rpms/cmake/blob/rawhide/f/cmake.req > > But I guess it does not produce the requires that you expect it should? That cmake.req script produces only dependencies on cmake-filesystem and nothing else

Re: RFE: CMake AutoRequires?

Fabio Valentini wrote: > Sure, but is this doable? CMakeLists.txt files are very complex and > border on a Turing-complete language. Technically, CMake *is* a Turing-complete language – if and only if you use recursive functions. > Does cmake support passing in "-D foo" options and returning a l

Re: CVE-2021-4034: why is pkexec still a thing?

Lennart Poettering wrote: > The IPC message is the *full* vulnerable surface, and that's as minimal as > it can get. And that's great. But that message can actually open a whole new vulnerability, compared to a monolithic program running completely as root. E.g., I have seen several D-Bus-activa

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

Ben Cotton wrote: > The current mingw32 and mingw64 cross-toolchains provided by Fedora > target the MSVCRT (Microsoft Visual C++ Runtime). Since Visual Studio > 15 & Windows 10, the default and recommended runtime is UCRT. See also > [https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt MSVCRT

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

For the record: https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > MSVCRT […] Works out of the box on every Microsoft Windows versions. This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. The original Windows 95, with or without the only service pack released

Re: the meaning of pkgconfig's Libs fields

Zbigniew Jędrzejewski-Szmek wrote: > 3. We autogenerate a dependency on /usr/bin/pkg-config for -devel. > Logic is reversed here: the -devel package **provides** something > that it consumed by pkg-config. Dependencies are from a consumer to > the providing entity. The idea there is that packages

Re: the meaning of pkgconfig's Libs fields

Zbigniew Jędrzejewski-Szmek wrote: > Well, that is the reverse of how we do things in general. If I want to > look for libraries using pkg-config, I install pkg-config. If I want > to look for libraries using 'gcc test.c -lfoo', then I install gcc. > > What we have now is like saying that .h files

Re: the meaning of pkgconfig's Libs fields

Robbie Harwood wrote: > k5crypto and com_err are internal libraries used across the different > interfaces krb5 provides - they're not intended for external > consumption, and upstream doesn't support their direct use by other > applications. Then they belong in Libs.private, not Libs. > So you'r

Re: the meaning of pkgconfig's Libs fields

Zbigniew Jędrzejewski-Szmek wrote: > I think Suggests would be OK. Even Recommends seems like too much. You may > be using clang++ to compile the code, or just accessing headers from > doxygen, or maybe testing an alternate version of g++ from copr, i.e. with > a different package name… Suggests i

Re: CVE-2021-4034: why is pkexec still a thing?

Lennart Poettering wrote: > CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646, > CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629, > CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, … > > These are all env var cleanup issues in su/sudo context. And the environment variable cleanup

Re: Action Required: Bugzilla - API Authentication changes

Miro Hrončok wrote: > From: Jeff Fearn […] > If you attempt to use an old method to authenticate to the API after this > change has been made, the API_KEY or password supplied will be treated as > potentially compromised and invalidated immediately. If you supplied your > password then you will ne

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

Marc-André Lureau wrote: > Fwiw, given that the primary use case for a cross-toolchain is for > developer needs, I think it is reasonable to have only UCRT target in the > future. > > Projects releasing for Windows should probably natively build and test > their releases with Msys2, and they can d

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

Marc-André Lureau wrote: > I have honest doubts about projects doing releases for Windows without > ever running it. WINE can be helpful for testing, or I can just let those Windows users who asked for the Windows build to begin with test it. ;-) Kevin Kofler

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

Miro Hrončok wrote: > this is about the following Fedora change: > > https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect > > In the tracking bugzilla, the relevant comment is: > > https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4 > > If I understand this correctly, the current

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

Marc-André Lureau wrote: > Release build should be tested on Windows. It is easy to build and test > natively with msys2 nowadays, or build for other targets. Why not use > that? Because I do not have a computer running Windows, nor a Windows license. Kevin Kofler

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

Kevin Kofler via devel wrote: > Marc-André Lureau wrote: >> Release build should be tested on Windows. It is easy to build and test >> natively with msys2 nowadays, or build for other targets. Why not use >> that? > > Because I do not have a computer running Windows,

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

Neal Gompa wrote: > (Sidebar, I wish the target would be renamed from mingw to windows, Well, in addition to the trademark concerns, that would also lose the distinction from Cygwin. > because it's kind of confusing when we don't even rely on a glibc-nt > port...) That would not really be *Mini

Re: Orphaned packages looking for new maintainers

Miro Hrončok wrote: > gstreamer1 orphan, uraeus, wtaymans1 weeks > ago > gstreamer1-plugins-baseorphan, uraeus, wtaymans1 weeks > ago > gstreamer1-plugins-goodorphan, uraeus, wtaymans1 weeks > ago How did the gstreamer1 stack

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

Jaroslav Mracek wrote: > I am really sorry but this suggestion is incorrect. Basically we have 3 > major misunderstandings - what is rich deps and how it is evaluated, what > DNF stores in the history database and how SAT solver in libsolv works. > Rich deps are very complex things with multiple op

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

Am Freitag, 11. Februar 2022 13:50:57 CET schrieb Jaroslav Mracek: On Tue, Feb 8, 2022 at 7:30 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: Hmm, but why is metadata of repository needed? IIUC, all deps (including rich) are part of the package header, i.e. are in the RPM database fo

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

Miro Hrončok wrote: > It was actually announced: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FV53ADNJB5STFN3YAEEXEVHMIA6DMXCN/ > > But for reasons I don't understand, it was pushed to rawhide without using > a side tag and without doing rebuilds :( > >

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

Miro Hrončok wrote: > Another thing I'd like to understand from your POV is why would packagers > actually *need* exactly-versioned Recommends. Could you please give me an > example use case? I understand why they might *assume they need* it, > because packaging is complex and this might seem like

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

Kevin Fenzi wrote: > As a release engineer trying to get a rawhide compose, I do find this a > big deal. (Another f37 compose just failed because of this issue). Well, as I already pointed out more than once, the real issue there is that the Rawhide compose fails due to a broken dependency. This

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

Miro Hrončok wrote: > kdelibs > kdelibs3 So they both hit this error: /usr/include/jasper/jas_log.h:122:46: error: expected primary-expression before 'int' 122 | static inline jas_logtype_t jas_logtype_init(int class, int priority) | ^~~ /usr/

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

Kevin Kofler via devel wrote: > Miro Hrončok wrote: >> kdelibs >> kdelibs3 > > So they both hit this error: > > /usr/include/jasper/jas_log.h:122:46: error: expected primary-expression > before 'int' > 122 | static inline jas_logtype_t j

Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64

Michal Schorm wrote: > The time had to come, when two packages would generate the same hash. Well, yes, depending on hash codes being globally unique is broken by design. Hash collisions exist. They can happen both by accident (because hash functions cannot possibly be injective because the rang

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

Mamoru TASAKA wrote: > kdelibs3 also seems to be okay with above, but ppc64le build only failed: > https://koji.fedoraproject.org/koji/taskinfo?taskID=82799185 > Looking at build.log , it looks like parallel make issue. Yes, try just resubmitting the build, hopefully it will not hit the race cond

Re: GNOME (and Cinnamon) issues in Rawhide: status report, including gnome-bluetooth soname issues

Adam Williamson wrote: > Since the builds have been in a compose, we can't untag them from > Rawhide, we can only move forwards. Why can we not make an exception to this stubborn policy in cases like this? We did not have this rule a few years ago and things worked out just fine. And these days,

Re: GNOME (and Cinnamon) issues in Rawhide: status report, including gnome-bluetooth soname issues

Adam Williamson wrote: > AFAIK we've always had that rule. It's always been policy that we don't > untag once a build has been in a successful compose. I don't think this > changed "a few years ago", unless I'm misremembering. Not always: The policy that disallows Rawhide going backwards was suppo

Re: GNOME (and Cinnamon) issues in Rawhide: status report, including gnome-bluetooth soname issues

Kevin Fenzi wrote: > About a year ago I asked fesco to add > > "In exceptional cases, releng may untag packages." > > https://pagure.io/fesco/fesco-docs/pull-request/40 Well, this is very vague, because nothing defines what an "exceptional case" is. Kevin Kofler ___

Re: Rpm: provide a static library in package

Denis Fateyev wrote: > The "ustl" upstream, for which I maintain the RPM package, has recently > switched from providing a shared library to a static library. Generally, you do not want to follow such a change, but force the build system to build a shared library instead, even if it is not the up

Re: Rpm: provide a static library in package

Denis Fateyev wrote: > Unfortunately, the shared library support is explicitly removed by the > upstream: > https://github.com/msharov/ustl/issues/100#issuecomment-1040553883 > https://github.com/msharov/ustl/commit/7366ab143d9bd0f48c59931c0c58529eb5179c27 This is just lame. I do not understand t

Re: Devtoolset for epel7 for build in Copr

Dmitry Butskoy wrote: > Second, the alternate Springdale Linux repo > http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ seems to > have all the ones (which are provided in sources by RedHat), but cannot > be used in Copr. Springdale provides devtoolset-3-elfutils there, and it > in some

Re: future of dual-boot on the desktop

Chris Murphy wrote: > A work around is having GRUB set an NVRAM variable indicating the next > boot should be Windows. That's an instruction to the firmware, so > there's no intermediary, thus measured boot works. The next boot (from > Windows) would boot Fedora again. GRUB can't get or set EFI var

Re: CPU does not support x86-64-v2?

Florian Weimer wrote: > Fedora doesn't require this yet. … and will hopefully not do so any time soon! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedor

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

Ben Cotton wrote: > == Summary == > exclude_from_weak_autodetect enables autodetection of unmet weak > dependencies (Recommends or Supplements) of installed packages and > blocks installation of packages satisfying already unmet dependencies. > In other words: When you don't have the recommended pa

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

Neal Gompa wrote: > On Thu, Sep 16, 2021 at 4:02 PM Miro Hrončok wrote: >> >> On 16. 09. 21 21:43, Fabio Valentini wrote: >> > For exmple, if I remember correctly, mozilla-openh264 / gstreamer >> > support for it are installed as weak dependencies with post-GA package >> > updates. >> >> Why exact

Re: Fedora ? Java: The Death of Two SIGs

Richard W.M. Jones wrote: > The bug above is a bit worrying though. I don't think anyone ever > tried to address those issues. I don't know enough to say if they're > real or nice to haves, but they seem serious. I have never seen any handwritten JNI code doing any of the things the bug wants y

Re: Fedora 💔 Java: The Death of Two SIGs

Robert Marcano via devel wrote: > I think the only way the Java ecosystem to survive in Fedora outside of > OpenJDK and some core components is to allow bundling (Even JavaScript > bundling is already allowed), but how do to it without compromising > security? The problem is that Java projects typ

Re: Fedora 💔 Java: The Death of Two SIGs

Florian Weimer wrote: > * Kevin Kofler via devel: > >> (And for the record, I also think that Go and Rust should not work >> that way either! It is possible to build shared libraries of Go code, >> at least one Go toolchain supports it.) > > There is no stable Go A

Re: Fedora 💔 Java: The Death of Two SIGs

Florian Weimer wrote: > Interesting. Could you provide an example of such a dynamically linked > binary? OCaml is interesting in that it does not use standard ELF .so files, but its own dynamic linking mechanism (those .cma files). This is a typical OCaml library (the ocaml-facile constraint sa

Re: Fedora ? Java: The Death of Two SIGs

Richard W.M. Jones wrote: > OCaml library code can in principle be dynamically linked, eg: > > $ rpm -ql ocaml-extlib | grep cmxs > /usr/lib64/ocaml/extlib/extLib.cmxs > $ file /usr/lib64/ocaml/extlib/extLib.cmxs > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64, > versio

Re: Packaging NW.js

Richard Shaw wrote: > I'm not familiar with packaging stuff like this so could use some > pointers: > > https://github.com/nwjs/nw.js Ewww! So people like Electron so much that they redid essentially the same thing (duct-taping together Chromium and Node.js, taking advantage of the fact that bo

Re: Fedora ? Java: The Death of Two SIGs

Stephen John Smoogen wrote: > I think Kevin's comment is meant more towards the way the language > packages itself versus the rpm packaging of the language. Going from > Kevin's comments on languages over the years, a 'good' language should > not require such sort of rebuilding. The OCaml language

Re: Fedora 💔 Java: The Death of Two SIGs

Robert Marcano via devel wrote: > Even in the case of SCM repositories committed binaries, allowing > bundling would help a lot, Well, we cannot allow just using the bundled binaries! There are various technical and legal concerns that make this a no go. But: > add some kind of automation that r

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

Michal Srb wrote: > Unlike RPM repositories, Maven repositories can easily hold multiple > versions of libraries. Once a JAR is built, the resulting bytecode will > work with current and future JVMs. There is no need to mass-rebuild JARs > every 6 months. And there is certainly no need to try to ru

Re: Strange soversion checks in rpmlint 2.x

Vitaly Zaitsev via devel wrote: > By the way, SOVERSION can consist of more than one digit. It can be > 0.5.2 and this is not an error: > https://autotools.io/libtool/version.html Other build systems such as CMake are even more flexible than libtool and allow arbitrary combinations of major versi

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

Peter Boy wrote: > A valid point, but only in case the app that consumes the maven artefact > in unmaintained. Many applications are maintained and never (or very rarely, only when they encounter some issue with the version they currently use) bother bumping their dependencies after adding them

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

Mario Torre wrote: > On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel wrote: >> And that is actually a problem rather than a solution. Maven artifacts >> are basically write once only. Everything depends on a hardcoded version >> which, once uploaded, is normally neve

Re: bodhi updates skipping updates-testing entirely

Fabio Valentini wrote: > There seems to be some inconsistency with how our update workflow > currently works. When an update gets enough positive karma "pre-push" > (still in "pending → testing" state) so that it can be pushed to > stable, bodhi changes its state to ("pending → stable"), making it

Re: Fedora minimum hardware requirements

Marius Schwarz wrote: > Am 14.10.21 um 22:09 schrieb Zbigniew Jędrzejewski-Szmek: >> I think that those numbers (20GB+2GB) are quite reasonable for the >> stated purpose of "install and run successfully". I think that people > The smallest device Fedora runs on, will propably be the Pinephone. > >

Re: libcurl-minimal

Steve Grubb wrote: > I'd like to suggest making libcurl-minimal very minimal for security > reasons. The main curl package has many security issues (CVE's) > constantly. But usually, the problem is in some obscure feature/protocol. > Looking at the packages that depend on libcurl with rpmreaper, mo

Re: Fedora minimum hardware requirements

Nico Kadel-Garcia wrote: > On Sun, Oct 17, 2021 at 3:36 PM Chris Murphy > wrote: >> >> On Sat, Oct 16, 2021, 10:01 PM Kevin Kofler via devel >> wrote: >>> >>> The Fedora 34 netinst image is still 450 times the size of a floppy! >> >>

Re: Fedora minimum hardware requirements

I am going to reply to the parent and grandparent post at once, starting with the parent post: Stephen John Smoogen wrote: > This conversation is one that seems to happen to computer people as > they age. I remember in the early 1990's that the Sun 4.1 installer > was incredibly bloated and requi

Re: bodhi updates skipping updates-testing entirely

Fabio Valentini wrote: > This sounds like you didn't read my whole post. > Because I don't want to make updates going from "pending -> stable" > directly impossible, Well, several of the people who replied do want that, if I understand their replies correctly. I think your original proposal that

Re: Qt package licenses

Neal Gompa wrote: > The only exception I'm aware of is the KDE Free Qt exception: > https://kde.org/community/whatiskde/kdefreeqtfoundation/ > > This exception governs how the license is actually governed, rather > than how it's executed, though I believe that's where the current > license stanza

Re: Qt package licenses

Jerry James wrote: > Currently they have "LGPLv2 with exceptions or GPLv3 with exceptions". That is definitely wrong/outdated. > I believe that most or all of them should have one of these two instead: > > - LGPLv3 or GPLv2+ > - LGPLv3 or GPLv2+ with exceptions GPLv2+ is wrong, the text actuall

Re: Fedora minimum hardware requirements

Marius Schwarz wrote: > no printersupport Uh, you can actually attach a printer directly to a PinePhone, either using the convergence dock or USB C directly. > ATM, i still see a long way to go for Linux on Phones, but Android > didn't do it overnight either. I have been using a PinePhone as my

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

> == Owner == > * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] > * Email: zbys...@in.waw.pl > * Name: Lennart Poettering > * Email: mzsrq...@0pointer.net > All binaries (executables and shared libraries) are annotated with an > ELF note that identifies the rpm for which this file was built.

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

Zbigniew Jędrzejewski-Szmek wrote: > How so? It was rejected with the request to enhance the motivation section > and to answer some specific questions about upgrades. This has been done. > Why do you say an update to a proposal that answers the issues that were > raised should not be resubmitted?

<    2   3   4   5   6   7   8   9   10   >