Re: Chromium built in rawhide does not render most strings

Florian Weimer wrote: > Right, and the glibc 2.33 versions all call fstatat64 in the end (system > call number 0x106). That would be: #if !defined(__NR_newfstatat) #define __NR_newfstatat 262 #endif from:

Re: poppler soname bump in rawhide

Marek Kasik wrote: > Thanks for pointing me to this fork, I was not aware of it. I've > prepared my own pull request already: > https://src.fedoraproject.org/rpms/diffpdf/pull-request/1 > > Looking at it now, it seems that CI failed for it. I'm going to have a > look at that. You probably don't

Re: Chromium built in rawhide does not render most strings

Florian Weimer wrote: > It's not. It may be a completely different system call. > > Is there a way to get logging of filtered system calls from the sandbox? What I'd suggest doing is strace-ing the rendering process in the version built against glibc 2.32 vs. the version built against glibc

Re: Proposal: gate stable release critical path updates on openQA test results

Matthew Miller wrote: > And, also hopefully also a rare occasion, but if this were enabled (and > the definitions up to date), problems like > https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/thread/CAS6KHTZLR6LUNWEVK3BOIO6HVNQDETZ/#N5HJDKMTGOTL44BT2HZ43LE6Q23345IQ >

Re: Chromium built in rawhide does not render most strings

Kevin Kofler via devel wrote: > So now I had a new idea how to figure out what difference the version of > glibc we are compiling against can make: track down the symbol version: > nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.2 | > grep '@GLIBC_2\.33' >

Re: poppler soname bump in rawhide

Marek Kasik wrote: > I've also removed the Qt4 frontend which we've maintained for > compatibility. Relevant package maintainers were contacted and some of > them already switched to Qt5. For diffpdf, it looks like it needs to be upgraded to this fork: https://gitlab.com/eang/diffpdf (The

Re: Chromium built in rawhide does not render most strings

Florian Weimer wrote: > It's not. It may be a completely different system call. So now I had a new idea how to figure out what difference the version of glibc we are compiling against can make: track down the symbol version: nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.2 |

Re: Proposal: gate stable release critical path updates on openQA test results

Stephen Gallagher wrote: > Just to be clear: We're working under the assumption that autopush and > the other policies we have in place now *reduces* the rate at which > mistakes are made with the lowest amount of maintainer overhead. And that is the basic assumption that I have a hard time

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

Zbigniew Jędrzejewski-Szmek wrote: > In more mundane words: a signature will be shipped in the rpm for each > file separately? And what will be done with this signature on the > destination machine: will it be kept in the rpms database or something > more? As I understand it, yes. > What is the

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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: Summary/Minutes from today's FESCo Meeting (2020-11-11)

David Cantrell wrote: > * #2475 proposal: let's develop the idea of a new repo for > lightly-maintained packages (dcantrell, 15:16:41) This suggestion keeps coming up again and again, but the repetition does not make it any more practical. A small handful individual maintainers wants to use

Re: Proposed updates to the FESCo updates policy document

Kevin Fenzi wrote: > The one actual proposed change is to allow releng to untag builds that > have already gone out in rawhide composes. This was forbidden by the > existing policy. Worded like in the above quote: Finally! But when I see the actual wording in the proposed changes, I see that we

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

Matthew Miller wrote: > Well, except, it clearly *does* work that way. We have many > lightly-maintained packages in practice. Do we really? Which are those packages? The one that keeps getting brought up is Tomcat, but I can tell you from my personal experience that the Fedora Tomcat package

Re: Proposed updates to the FESCo updates policy document

Kevin Fenzi wrote: > We have been over this. If anyone could untag anything they felt like it > would make it much more difficult for everyone to integrate their > changes with the rest of the collection. That issue is simply not something we have observed at any time back when this untagging

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

Emmanuel Seyman wrote: > * Kevin Kofler via devel [13/11/2020 00:52] : >> >> The one that keeps getting brought up is Tomcat, but I can tell you from >> my personal experience that the Fedora Tomcat package has always been >> working just fine (not only as a build depen

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

Fabio Valentini wrote: > I completely agree. This is one of the reasons I switched away from > ubuntu years ago (with its 4 (?) tiers of support + repos for its > packages ...). I agree, Fedora did the Core-Extras Merge back in the day for a reason. Kevin Kofler

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

Pierre-Yves Chibon wrote: > Every single package that failed to build from source and that people > refused to see orphaned and retired when it was pointed out that they are > in fact not really maintained ? As I have already mentioned more than once when the FTBFS policy has been discussed, a

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

Matthew Miller wrote: > On Fri, Nov 13, 2020 at 10:52:57PM +0100, Kevin Kofler via devel wrote: >> > I completely agree. This is one of the reasons I switched away from >> > ubuntu years ago (with its 4 (?) tiers of support + repos for its >> > packages ...). &

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,

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

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

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

Re: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

Michael Catanzaro wrote: > There is one release so far this year, qtwebkit-5.212.0-alpha4, based > on WebKitGTK 2.12. Security support for 2.12 ended in September 2016. > So that is the status of your "less outdated" version. The last Qt 4 WebKit was branched from WebKit master in early August

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

Petr Pisar wrote: > That's because cmake executes make (if CMakeList does not override it). 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

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

Ben Cotton wrote: > This change will remove make from the default buildroot in Koji and mock. What is the point of removing a package that is used by almost all package builds from the default buildroot? It is just a pointless backwards incompatibility. > * Reduce the BuildRoot download size

Re: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

Sandro Mani wrote: > Soo, this opened a bit a can of worms, as qt-mobility (clearly being of > the qt4 era dead upstream) is not going to support proj7. Can't we get it to build without proj? Does QtWebKit or anything else actually need the parts that wrap proj? Kevin Kofler

Re: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

Sandro Mani wrote: > But I'll also expand the analysis to the entire qt4 stack and see what > comes out. Dropping the entire Qt 4 stack is a non-starter. I am keeping the qt4 package secure with backported security fixes. I see no reason to drop it. Qt4WebKit is a different matter, though I

Re: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

Kevin Kofler via devel wrote: > Sandro Mani wrote: >> Soo, this opened a bit a can of worms, as qt-mobility (clearly being of >> the qt4 era dead upstream) is not going to support proj7. > > Can't we get it to build without proj? Does QtWebKit or anything else > actually

Re: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

Christian Stadelmann wrote: >> The following packages will be retired: >> arora >> […] >> rekonq > > Is there any reasons why they should retired and not also being obsoleted? > (Just asking, not suggesting. I don't really know the process but what > happens if someone still has arora installed,

Re: qt-mobility -> qtwebkit, and qt4 removal (was Re: Heads up: proj 7.2.0 + gdal 3.2.0)

Michael Catanzaro wrote: > Well that only halfway removes QtWebKit. There is also the Qt5 version > of the package that needs to be removed as well. The Qt 5 version is less outdated and there is still hope that it can be brought up to date (upstream does not look dead:

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

Ben Cotton wrote: > == Summary == > We want to add signatures to individual files that are part of shipped > RPMs. These signatures will use the Linux IMA (Integrity Measurement > Architecture) scheme, which means they can be used to enforce runtime > policies to ensure execution of only trusted

Re: Proposal: gate stable release critical path updates on openQA test results

Stephen Gallagher wrote: > I think you've got this backwards, Kevin. This is about disabling the > autopush if any of those tests fail. So the result would be that > critical path packages would get 1) more testing before the existing > autopush occurs and 2) if any of those tests fail, it won't

Re: Proposal: gate stable release critical path updates on openQA test results

Adam Williamson wrote: > So here's an idea I was thinking about over the RH shutdown: I propose > we gate stable release critical path updates on the openQA tests. -1 We already enforce too strict requirements on updates, *especially* those that deliberately or accidentally end up in the

Re: Proposal: gate stable release critical path updates on openQA test results

Pierre-Yves Chibon wrote: > This is basically what this thread is asking. If we make a test mandatory, > no updates will be pushed when this test fails unless the failure is > waived. > > So it seems we are all in agreement! Not all. I am still opposed to this. We already have too many mandatory

Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

Miro Hrončok wrote: > symbol `.gnu.debuglto_.debug_line_str' required but not present This is causing a whole chain of breakage in Rawhide: The above bug prevents building binutils, which prevents fixing: https://bugzilla.redhat.com/show_bug.cgi?id=1916925 which in turn prevents rebuilding

Re: Backwards-incompatible RPM format change in Fedora 34?

Florian Weimer wrote: > With rpm-4.15.1-3.fc32.1.x86_64, I get this error: > > $ rpm -qip > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm > error: /var/tmp/rpm-tmp.6iU66n: signature

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

Patrick マルタインアンドレアス Uiterwijk wrote: > I'd like to point out that after many requests, I have updated the change > page for this significantly, with more details as to the goals (and > non-goals) of this feature, and answers to many other questions asked. Sorry, but these clarifications only

Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

Nico Kadel-Garcia wrote: > I see a "Source1" tarball from github. If a github published archive > isn't reasonable for a Source tarball, there are a *lot* of other > .spec files that would need to be rejected. As per: https://fedoraproject.org/wiki/Bundled_Libraries#Treatment_of_Bundled_Libraries

Re: Proposal: gate stable release critical path updates on openQA test results

Adam Williamson wrote: > As feedback on this was mostly positive, I went ahead and did the work. > The PR for the Greenwave policy has been merged already, as that does > not in itself cause any actual behaviour change: > https://pagure.io/fedora-infra/ansible/pull-request/349 > > The PR for

Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

Miro Hrončok wrote: > See also: > https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master This is a blatant violation of Fedora packaging guidelines and ought to be reverted immediately. Kevin Kofler

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Miro Hrončok wrote: > 1. Untested changes > > Packager pushes a "simple update" to dist git without checking if it even > builds. It doesn't. Packager has no time to fix this, so they move on for > now. Or they submit a build but never check if it actually built. > Provenpackagers who need to

Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

Nico Kadel-Garcia wrote: > You mean like "python-s3transfer", which bundles multiple multiple > python modules together for no intelligible reason, requiring > hand-tuning of packages like "awscli" which have to seek out the > relocated modules? > > The guideline has sometimes been ignored for

Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

Florian Weimer wrote: > This is closer to the existing policy, I think: > > Actually, the very first 2½ sentences at that link make my point even more clearly than the link I had posted: | Fedora packages SHOULD make every

Re: Self Introduction: Serhei Makarov

Benson Muite wrote: > Welcome. Your class scheduler: > https://github.com/serhei/course-scheduler > seems useful. Maybe it can be ported to C/C++/Ruby and packaged? Wouldn't Python 3 be the most straightforward porting target for that Python 2 code? Kevin Kofler

Re: Obsoletes/Provides question

Daniel P. Berrangé wrote: > On Tue, Jan 19, 2021 at 03:18:41PM +, Richard W.M. Jones wrote: >> On Tue, Jan 19, 2021 at 04:12:59PM +0100, Miro Hrončok wrote: >> > On 19. 01. 21 16:06, Richard W.M. Jones wrote: >> > >(2) Or adding: >> > > >> > >%package tar-filter >> > >Obsoletes:

Re: libelf now depends on openssl

Michael Catanzaro wrote: > I notice that WebKit, when built with WebRTC enabled, now crashes > during the build: > > https://bugs.webkit.org/show_bug.cgi?id=214812#c7 > > It's a symbol conflict between boringssl (used by libwebrtc) and > openssl. Do the boringssl symbols not have hidden

Re: Chromium built in rawhide does not render most strings

Tom Callaway wrote: > https://bugs.chromium.org/p/chromium/issues/detail?id=1164975 > > Please add in this info, it was on my TODO list, but clearly hasn't > happened yet. https://bugs.chromium.org/p/chromium/issues/detail?id=1164975#c8 Kevin Kofler

Re: Chromium built in rawhide does not render most strings

Florian Weimer wrote: > I suspect some of the preprocessor conditionals in > SyscallSets::IsFileSystem in > > > > need fixing. Unfortunately, the fix is more complicated

Re: Chromium built in rawhide does not render most strings

Florian Weimer wrote: > The fstat/fstat64 system call does not exist on arc and riscv/rv32. > glibc tries to consolidate the implementations as far as possible, so if > the kernel deprecates a system call and the replacement is already > supported by all architectures, glibc uses that, rather than

Re: Chromium built in rawhide does not render most strings

Kevin Kofler via devel wrote: > But the thing is, fstatat is not really a newer version of fstat, it > unfortunately has very different security properties. fstat allows > retrieving the stat metadata only of already open files (if you know or > guess the fd). On the other hand, fs

Re: thinking journal retention timelimits

Matthew Miller wrote: > Right now, we don't set MaxRetentionSec, so journal expiry on Workstation > is entirely based on disk usage. > > Logs can accidentally contain sensitive data, and it's just plain faster > to work with them when there's less. I propose we set this to something > like six

Re: How to handle a config(noreplace) file that needs to be updated

Nico Kadel-Garcia wrote: > So can *not touching someone else's config files*. If I've gone to the > trouble of locally or manually editing a config file, I generally > don't appreciate your package manually tweaking it inside your RPM > %post scripts in an unpredictable fashion. Replace it, or

Re: How to handle a config(noreplace) file that needs to be updated

Robert-André Mauchin wrote: > I have a project for which the config file (toml) has been significantly > changed, notably renamed sections. As such some older config parameters > won't work anymore. Tools like sed, ed, awk etc. in %post scriptlets can do wonders. Kevin Kofler

Re: runtime dependencies not in Requires spec section

Rex Dieter wrote: > It's a linked library, so *yes*, rpmbuild will add it. Depends on whether the application links directly to libQt5Svg.so.5 or whether it uses it only through the plugin-based imageformats API (libqsvg.so). (And there's also the iconengines/libqsvgicon.so plugin.)

Re: Chromium built in rawhide does not render most strings

Tom Callaway wrote: > I rebuilt chromium, but it did not resolve the issue. So what can we do to resolve the issue? Surely we cannot leave both Chromium and Falkon unable to render text forever. Kevin Kofler ___ devel mailing list --

Re: Fedora 34 Change: Remove Guile Support From Toolchain (Self-Contained Change)

Neal Gompa wrote: > Also "shrink the buildroot" for Make isn't a good enough reason to do > this, since we don't even include Make in the buildroot by default > anymore[1]. > > [1]: https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot But a lot of packages BuildRequire make, and the

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

Re: Proposal to deprecated `fedpkg local`

Vít Ondruch wrote: > While I typically tend to use editor from my host (I quite often use > GVim or GEdit, which are both GUI editors), I stumble upon the missing > `less` quite often. If there was way to somehow `mount` the editor from > host into the buildroot, but I can't think of any feasible

Re: Should opencv require scala on runtime?

Miro Hrončok wrote: > [~]$ repoquery --installed --whatrequires coin-or-Cbc > coin-or-Clp-0:1.17.6-2.fc33.x86_64 Why does Clp require Cbc? As far as I know, Cbc uses Clp, not the opposite. I see coin-or-Cbc goes through great lengths to bootstrap the circular dependency on Cbc, to manually set

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Michael Catanzaro wrote: > Alternative: use automated reverts instead of force pushes, and don't > worry about maintaining a clean history. Sure, it is possible to make an implementation with lower quality of implementation with possibly less work, by omitting the force pushes and the smart

Re: Proposal to deprecated `fedpkg local`

Robbie Harwood wrote: > Vít Ondruch writes: >> Just FTR, mock supports `--arch=ARCH` which will use emulation to >> allow you build whatever architecture localy. I have never used it >> myself, but I wanted to mention this. > > I recommend you try. Prepare to be underwhelmed by speed :)

Re: Proposal to deprecated `fedpkg local`

Otto Urpelainen wrote: > The other option of not using 'git add .' can also be described as > mentally filtering out all the irrelevant unstaged changes to find the > ones that should actually be added. That adds cognitive burden, slows > things down and leads to mistakes every now and then. It

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

Dominik 'Rathann' Mierzejewski wrote: > You can use crudini to manage .ini files. Works quite well. There's also > nmcli... You might also be able to work with kreadconfig5 and kwriteconfig5 from kf5- kconfig-core, though I have never tried those on NM configs. Kevin Kofler

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Petr Pisar wrote: > Technically you can make multiple builds from the very same branch and > commit. And some of the builds can pass and some fail. But only one of those will be the CI build used to make the decision. So all that is needed is to ensure that we cannot have a non-CI build that

Re: btrfs hash algorithm (should xxhash be the default?)

Matthew Miller wrote: > On Mon, Feb 01, 2021 at 01:24:53PM +, David Howells wrote: >> Matthew Miller wrote: >> > Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are >> > obviously much, much slower and probably not right for a default, but >> > should we consider making xxhash

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote: >> But it means that provenpackagers who want to bump and rebuild have to >> actually manually look at another branch (rawhide-build). > > No, why would they need

Re: Chromium built in rawhide does not render most strings

Florian Weimer wrote: > This is currently not a major consideration for system call design. We > can't add this downstream from the kernel if support just isn't there. > You have to solve these issues for porting to other architectures > anyway. So the upstream Linux kernel does not care about

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

clime wrote: > So if some other maintainer pushes his work to the server meanwhile, > this will just delete his work? Or what's the idea here? I guess the safe thing to do would be to wait and see whether that commit also fails to build (i.e., if the CI build fails, check whether the built

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Jonathan Wakely wrote: > Instead of force pushing or reverting anything in the rawhide branch, > why not just have two branches? > > Maintainers commit to one branch, and if the build is successful that > branch is automatically merged (as a fast-forward merge) to a > "rawhide-build" branch. > >

Re: Jami (formerly Ring) P2P softphone packaging?

Vitaly Zaitsev via devel wrote: > On 01.02.2021 19:49, Daniel Pocock wrote: >> Has anybody tested the Jami softphone from Savoir-Faire Linux? It was >> formerly known as Ring. > > Electron framework is forbidden on Fedora due to ffmpeg usage and it > cannot be built from sources without Internet

Re: x86_64-v2 in Fedora

Florian Weimer wrote: > Right, I have yet to encounter anyone who can't run the new el9 binaries > on their hardware. We had a few issues, but they were all > misconfiguration of hypervisors or software emulators. Let me introduce you to my notebook: [kevin@laptop64 ~]$ cat /etc/fedora-release

Re: x86_64-v2 in Fedora

Neal Gompa wrote: > Yeah, I think that proposal was not workable because of AVX2. The > x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the > current x86_64 baseline. All of these instructions were present in the > first Intel Macs launched in 2007, as I recall. Still means my

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

Otto Urpelainen wrote: > Also, if the intent is to get rid of the package completely, should not > adding it to fedora-obsolete-packages be required as well? Why? Adding working packages to fedora-obsolete-packages forces removing them from users' machines just because they are no longer in the

Re: F35 Change: Replace SDL 1.2 with sdl12-compat using SDL 2.0 (Self-Contained Change proposal)

Ben Cotton wrote: > This Change proposes to replace SDL 1.2 with sdl12-compat, which uses SDL > 2.0. FYI, it took me just a few minutes of casually browsing commits to spot a memory corruption bug in this code:

Re: F35 Change: Replace SDL 1.2 with sdl12-compat using SDL 2.0 (Self-Contained Change proposal)

Vitaly Zaitsev via devel wrote: > On 17.05.2021 16:19, Ben Cotton wrote: >> In order to help move SDL 1.2 games into the modern world, let's >> replace SDL 1.2 with sdl12-compat, which uses SDL 2.0. > > What about third-party **proprietary** games from Steam for example? sdl12-compat claims to

Re: RPM name collisions

Matthew Miller wrote: > I'm glad you mentioned this, because that's my thought too. DNF 5 with > modularity 2.0 :) Not the m-word again! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: When is pappl going to be good enough to replace cups?

Chris Murphy wrote: > Consumer printers have trended toward having an RGB only interface, > making it impossible to directly control them per channel. In effect, > the print driver is becoming part of the printer's firmware. My Canon PIXMA MG3650 is definitely a consumer printer (and a recent

Re: When is pappl going to be good enough to replace cups?

Zdenek Dohnal wrote: > CUPS discovery is designed to run on secure, private LAN, so it is > expected that you have a protection against somebody connecting to your > WIFI. That is (still) a reasonable assumption for a home WiFi WLAN on which a home printer is likely to be located. That is what

Re: When is pappl going to be good enough to replace cups?

Solomon Peachy wrote: > The legacy CUPS *direct-attached* model simply doesn't work with > containerized/sandboxed applications that are all the vogue these days. So this is yet another functionality regression coming from that containerization nonsense! Why do we all have to pay the price for

Re: When is pappl going to be good enough to replace cups?

Solomon Peachy wrote: > But by "settings" I was referring to things like ink density/droplet > size, weave patterns, dither modes, individual color channel curves, and > other minutae that matter for specialized photo/art printing on > near-arbitrary media. This tunability is where Gutenprint

Re: When is pappl going to be good enough to replace cups?

Solomon Peachy wrote: > On Tue, May 25, 2021 at 01:27:03AM +0200, Kevin Kofler via devel wrote: >> I do not see how that is the common use case. Why would I want to print >> from my telephone? I do not even normally print from my notebook! > > I don't think it's controve

Re: When is pappl going to be good enough to replace cups?

Solomon Peachy wrote: > On Mon, May 24, 2021 at 10:41:07PM +0200, Kevin Kofler via devel wrote: >> I have never connected directly to a remote printer. > > It works quite well in Fedora these days. Well, the printers I had when I had a use for remote printing did not support i

Re: When is pappl going to be good enough to replace cups?

Zdenek Dohnal wrote: > It is a library for printer applications [1], not a substitute for CUPS. > CUPS is still present and is going to be. > > There will be more printer applications coming into Fedora > (ps-printer-app f.e.) and one already is (lprint). > > > The purpose of the library is

  1   2   3   4   5   6   7   8   9   >