Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

On Tue, 2 Apr 2024 at 10:40, Aoife Moloney wrote: > Switch the default desktop experience for Workstation to KDE Plasma. > The GNOME desktop is moved to a separate spin / edition, retaining > release-blocking status. If this is an April fools joke -- it's a weird one, and a day too late.

Re: SPDX Statistics - Please Please Me edition

On Mon, 26 Feb 2024 at 15:44, Stephen Smoogen wrote: > I wonder if you have it from a group you are in or if it was the general > creep of time that has added you to a lot of packages? I'm a packager and a provenpackager, so I'm a bit confused why I'm on so many packages as a separate

Re: SPDX Statistics - Please Please Me edition

On Fri, 16 Feb 2024 at 15:07, Miroslav Suchý wrote: > * 23711 spec files in Fedora I was looking through the list for any of my packages, and I've found that I'm "maintaining" long dead packages like https://src.fedoraproject.org/rpms/GConf2 According to that I have "commit" ACLs, but I

argyllcms orphaned

Hi all, I've orphaned argyllcms -- I'm no longer using the package, and haven't worked on color management for some time. If anyone wants to take on the package the upstream source is chucked over the wall (no source control) every few months, and it sometimes needs patches to fix the Linux

Re: [Fedora-legal-list] SPDX short name for "Redistributable, no modification permitted" (firmware)

On Mon, 16 Oct 2023 at 09:46, Daniel P. Berrangé wrote: > Or possibly we end up with a mixture of (2) and (3) where most firmware > are under an umbrella but a few oddballs with unusual terms justify a > dedicated LicenseRef. I'm also interested from a LVFS firmware point of view. At the moment

Re: Packaging guidelines - validation of AppStream metadata files

On Wed, 27 Sept 2023 at 22:41, Kevin Fenzi wrote: > I'm not sure at all that it would be possible to do at compose-time... > composes are taking around 3.5-4hours and thats after I have done > a lot to speed them up, but might be worth some benchmarking > to see how much slower it would be. If we

Re: Packaging guidelines - validation of AppStream metadata files

On Wed, 27 Sept 2023 at 13:23, Mattia Verga via devel wrote: > Can't this script be moved to run in Openshift as cron-based? Yes! In fact, that's what I proposed about a decade ago when I wanted to include the data in the metadata like Debian does. I do think it should be managed by someone in

Re: Packaging guidelines - validation of AppStream metadata files

On Tue, 26 Sept 2023 at 03:16, Neal Gompa wrote: > So a stopgap solution was implemented: appstream-data. Richard Hughes > maintains a local mirror of the full Fedora repositories and generates > the appstream data from that using scripts[1] and extra data[2] to > produce the ap

Re: Adding Passim as a Fedora 40 feature?

On Thu, 7 Sept 2023 at 11:36, Fabio Valentini wrote: > All systemd services that have an "enabled by default" preset need to do that: > https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_enabling_services_by_default It's not exactly enabled by default -- it's autostarted

Re: Adding Passim as a Fedora 40 feature?

mit: commit 44a1d6df6cf40912ea07bd7e71bc69bc0742e814 (HEAD -> main, origin/rawhide, origin/main, origin/HEAD) Author: Richard Hughes Date: Fri Aug 25 20:53:33 2023 +0100 Split out a -libs subpackage :100644 100644 bc51e57 3ad7ccc Mpassim.spec ...but for some reason didn't do the buil

Re: Adding Passim as a Fedora 40 feature?

On Wed, 6 Sept 2023 at 18:36, Adam Williamson wrote: > NetworkManager has the same concept, but of course it depends on apps > that use data *caring* about it. It sounds like passimd should be a thing that cares too -- https://github.com/hughsie/passim/issues/13 Richard.

Re: Adding Passim as a Fedora 40 feature?

On Wed, 6 Sept 2023 at 19:12, Adam Williamson wrote: > This message says you're "thinking of adding Passim", but in point of > fact, it appears to have been added to the package set already, and as > of fwupd-1.9.5-2.fc40 (built two days ago), fwupd hard requires it, It hard requires the -lib --

Re: Adding Passim as a Fedora 40 feature?

On Thu, 31 Aug 2023 at 23:13, Marcus Müller wrote: > - using avahi for local peer discovery, how does this compare to good ole > bittorrent with > Protocol/Message Stream Encryption turned on, and DHT instead of a tracker? I think more than a few places would ban/block/report bittorrent traffic

Re: Adding Passim as a Fedora 40 feature?

On Thu, 31 Aug 2023 at 22:05, Björn Persson wrote: > The document doesn't say what design decisions were made based on the > assumption of a friendly network. Well, I can certainly add them -- this discussion was started so I can add any missing information. > All of those design decisions need

Re: Adding Passim as a Fedora 40 feature?

On Tue, 29 Aug 2023 at 21:03, Simo Sorce wrote: > You could have deltas, so that clients will not get the whole thing > every day, but deltas compared to what they have already (which would > be 0 bytes if thy are up to date). I'm trying to reduce the number of CDN accesses and the number of

Re: Adding Passim as a Fedora 40 feature?

On Tue, 29 Aug 2023 at 18:54, Simo Sorce wrote: > That depends on how you are going to handle re-installs of peers in the > network where the certificate will start mismatching ... In event of a mismatch I was going to ignore the peer; in most home networks there'll be dozens of devices all

Re: Adding Passim as a Fedora 40 feature?

On Tue, 29 Aug 2023 at 17:06, Vít Ondruch wrote: > The point was that `fwupdmgr get-devices` lists ~32 devices for my LP. I > can't imagine that the metadata for these 32 devices would take 2 MBs. > That is more likely data for all devices ever supported. It is the metadata for every device --

Re: Adding Passim as a Fedora 40 feature?

On Mon, 28 Aug 2023 at 21:50, Simo Sorce wrote: > It could be improved by using TOFU, so that the window of impersonation > is small, but requires clients to cache an association and then has > weird failure modes to be dealt with if one of the actors get re-imaged > or changes the cert for any

Re: Adding Passim as a Fedora 40 feature?

On Mon, 28 Aug 2023 at 21:14, Chris Adams wrote: > Without identification though, it doesn't do that, because there's no > way for client B to know it is really talking to client A - it could be > talking to client C with a man-in-the-middle attack and a different > self-signed cert pretending to

Re: Adding Passim as a Fedora 40 feature?

On Fri, 25 Aug 2023 at 12:42, Richard Hughes wrote: > I was thinking of adding Passim as a default-installed and > default-enabled dep of fwupd in the Fedora 40 release. Before I create > lots of unnecessary drama, is there any early feedback on what's > described in https://github

Re: Adding Passim as a Fedora 40 feature?

On Mon, 28 Aug 2023 at 11:05, Petr Pisar wrote: > V Fri, Aug 25, 2023 at 07:34:35PM +0100, Richard Hughes napsal(a): > > you need to reboot into the new firmware before the published firmware gets > > shared; > Won't this suppress an effeciency of the local sharing? Yes -- but

Re: Adding Passim as a Fedora 40 feature?

On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel wrote: > whats the benefit of this "self-signed TLS certificate" (as it does > not provide any "security")? Is this stub for something later ... ? It's a good question. It provides encryption (so client A can provide the file to client B

Re: Adding Passim as a Fedora 40 feature?

On Mon, 28 Aug 2023 at 15:53, Vít Ondruch wrote: > Sorry, I am probably missing something, but how this would help my > computer (or three I have at home)? One computer downloads the 2MB from the CDN and the other two download it from the first computer. This saves you 4MB in bandwidth, and

Re: Adding Passim as a Fedora 40 feature?

On Fri, 25 Aug 2023 at 19:34, Richard Hughes wrote: > Yes, that's what I have right now. I do need to split out a > passim-libs so that you can remove the daemon and just leave the tiny > client library. Something like this perhaps? diff --git a/passim.spec b/passim.spec index bc51e57

Re: Adding Passim as a Fedora 40 feature?

On Fri, 25 Aug 2023 at 19:26, Marcus Müller wrote: > I fully agree with that assessment. "Here's a knob you turn that has the > potential to make > your firmware update 2s faster and is generally good for the ecosystem, but > you will have > set it on every machine you set up" will not lead to

Re: Adding Passim as a Fedora 40 feature?

On Fri, 25 Aug 2023 at 15:59, Peter Robinson wrote: > Is this something where you could enable it on one specific device and > have a systemd time to pull the metadata and it advertises it to the > network so you can designate a single device to run the service? Yes, not a bad idea at all. Can

Re: Adding Passim as a Fedora 40 feature?

On Fri, 25 Aug 2023 at 16:27, Stephen Smoogen wrote: > It depends on the scanning from ports open to unknown shared files to 'why > did our network costs go up so much?' Surely if you're on a local network with bandwidth costs you'd turn off avahi or lock down the firewall? Lots of stuff blasts

Re: Adding Passim as a Fedora 40 feature?

On Fri, 25 Aug 2023 at 16:00, Benson Muite wrote: > Better as optional rather than default-enabled. It would likely be > helpful for computers in an institutional setting where the LAN is well > controlled. So that's the thing; if it's default disabled then I can say with certainty that almost

Re: Adding Passim as a Fedora 40 feature?

On Fri, 25 Aug 2023 at 13:19, Stephen Smoogen wrote: > My understanding was that Microsoft found their own 'share updates' not > working as much as expected Hmm, I heard the opposite; can you give any more info? They have way more telemetry than we do, and I was told it would not "be feasible"

Re: Adding Passim as a Fedora 40 feature?

On Fri, 25 Aug 2023 at 13:50, Petr Pisar wrote: > I see you wrote "metadata". It's not the firmware itself .Sill my concert is > the same: what's a license of the metada? Can I redistribute them? The metadata is explicitly CC0-1.0 -- but even if we later did firmware one of the things I

Adding Passim as a Fedora 40 feature?

Hi all, I was thinking of adding Passim as a default-installed and default-enabled dep of fwupd in the Fedora 40 release. Before I create lots of unnecessary drama, is there any early feedback on what's described in https://github.com/hughsie/passim/blob/main/README.md please. The tl;dr: is I

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

On Wed, 10 May 2023 at 11:55, Zbigniew Jędrzejewski-Szmek wrote: > Especially not by making some small change contingent on moonshot proposals. > But I think that a) the current proposal is just a band-aid, and > b) to make things better we don't need to make huge changes. Okay, please open a

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

On Tue, 9 May 2023 at 10:22, Zbigniew Jędrzejewski-Szmek wrote: > This is both too much and not enough. Right; and I think a different Fedora feature proposal would be a good idea for the version of Fedora when we switch to UKIs. Where we can just have /boot/efi and not /boot -- but that's not

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

On Tue, 25 Apr 2023 at 07:05, Peter Robinson wrote: > While I believe this to be low impact I do believe it should be a > system wide change as it impacts all aarch64 and basically all the > x86_64 we actively care about. I guess you could argue it both ways -- I figured it was self contained as

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

On Mon, 24 Apr 2023 at 18:28, Daniel P. Berrangé wrote: > This refers to the minimum size being changed, but later it mentions > the default size being changed. Are the default & minimum sizes > effectively the same in this case ? I believe so. > nitpick - the github change linked is 512 MiB

Re: SPDX migration and BSD-4-Clause

Ok, thanks, much appreciated! Richard. On Tue, 28 Mar 2023 at 15:57, Miro Hrončok wrote: > > On 28. 03. 23 16:53, Richard Hughes wrote: > > Hi all, > > > > I've got a package that's a mixture of BSD-3-Clause and BSD-4-Clause > > (the original, old licence), and is

SPDX migration and BSD-4-Clause

Hi all, I've got a package that's a mixture of BSD-3-Clause and BSD-4-Clause (the original, old licence), and is current labelled "License: BSD" -- but I get the following: license-fedora2spdx BSD Warning: more options on how to interpret BSD. Possible options: ['BSD-1-Clause',

Re: Test upgrades from F37 to F38 - it will take you just a minute

On Wed, 22 Feb 2023 at 12:03, Steve Cossette wrote: > Downgrading: > fwupd x86_64 1.8.10-1.fc38 fedora 1.8 > M Mea culpa. I'm doing a new upstream release tomorrow, and will build both as 1.8.11-1 -- I guess the drawbacks of %autorelease. From an upgrade

Re: Pre-review of a new python package: uswid

Many thanks all; I've fixed up all the issues I think and submitted an actual review here: https://bugzilla.redhat.com/show_bug.cgi?id=2167067 Richard. ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email

Pre-review of a new python package: uswid

Hey all, I'm building python-uswid as a rpm as it's going to be needed by the fwupd-efi package at build time in the near future. I'm also the upstream maintainer, so I'm not against changing upstream and then tagging a new release if there's something that needs to be fixed to build a Fedora

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, 3 Jan 2023 at 13:46, Florian Weimer wrote: > > BuildError: Error running GIT command "git clone -n > > https://src.fedoraproject.org/rpms/fwupd.git > > /var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd", > > see checkout.log for details > | fatal: the remote end

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Fri, 30 Dec 2022 at 19:02, Ben Cotton wrote: > Version: 1.2.3 > Release: %autorelease > %autochangelog I tied this on a package this morning and got: BuildError: Error running GIT command "git clone -n https://src.fedoraproject.org/rpms/fwupd.git

Re: future of dual booting Windows and Fedora, redux

On Tue, 26 Jul 2022 at 19:06, Chris Murphy wrote: > b. Add a user space utility modifies system NVRAM such that the next boot > (only) will directly boot the Windows bootloader. In fwupd we add a Boot target and sets BootNext to run the capsule update loader. 99.99% of the time it works

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

On Thu, 30 Jun 2022 at 10:41, Dominik 'Rathann' Mierzejewski wrote: > ... *when* they are sandboxed ... > Unfortunately, in many cases, they aren't. I don't think that "some apps have lots of holes punched in the sandbox, but can be locked down easily using a GUI tool, where the majority are

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Thu, 7 Apr 2022 at 09:43, Lennart Poettering wrote: > Also, why would a boot menu need a particularly fancy user experience? Being honest, I think the simplicity of sd-boot is a feature, not a failure. Richard. ___ devel mailing list --

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski wrote: > > and on its way out. As it ages, maintainability has decreased, and > > the status quo of maintaining both stacks in perpetuity is not viable > > for those currently doing that work. > Have you tried getting more people

fwupd-efi package review

Hi all, I'm wanting to update the fwupd package in Fedora rawhide to the recently released 1.6.0, but this release splits out the EFI binary to a new source package. I've created https://bugzilla.redhat.com/show_bug.cgi?id=1953508 for the new package review process and would appreciate a reviewer

Re: Request for advice on KiCAD appdata

On Wed, 2 Dec 2020 at 16:13, Steven A. Falco wrote: > There is a bug report [1] that KiCAD doesn't show up in the GNOME Software or > KDE Discover managers. I ran desktop-file-validate on the kicad.desktop file > and got a hint that there is no registered main category. That just means it's

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

On Thu, 10 Sep 2020 at 12:38, Neal Gompa wrote: > Because Red Hat customers put the SELinux policy developers into > no-win situations: they complain about AVC denials that don't actually > significantly break anything in *their* app My response to that would be to ship a "AVC ignore-list"

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

On Thu, 10 Sep 2020 at 10:17, Tom Hughes wrote: > > Speaking from personal experience, I've wasted days over the last > > decade trying to debug a locally installed system service that was not > > working where there were no messages in any of the logs (e.g. no AVCs) > > -- and turning off

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

On Tue, 8 Sep 2020 at 16:29, Ben Cotton wrote: > NOTE: Runtime disable is considered deprecated by upstream, and using > it will become increasingly painful (e.g. sleeping/blocking) through > future kernel releases until eventually it is removed completely. Speaking from personal experience,

Re: New libxmlb 0.2.0 which breaks API and ABI

On Wed, 19 Aug 2020 at 14:57, Mohan Boddu wrote: > It seems like gnome-firmware also needs it and due to that both > rawhide and branched composes failed today. I had no idea, my apologies! Richard ___ devel mailing list --

New libxmlb 0.2.0 which breaks API and ABI

Hi all, I'm going to build the recently released libxmlb 0.2.0 into rawhide and F33. It has two consumers (fwupd and gnome-software) both of which I own, and I'll rebuild them at the same time. Any problems please shout. RIchard. ___ devel mailing list

Bumping library soname in F33?

Hi all, I maintain a library that's bumped soname upstream (libxmlb) that is used just by gnome-software and fwupd in Fedora. Both users would just need recompiling against the new ABI as they already have the right #ifdefs in place. I'm intending to do this for F34 now it's been branched, but is

Re: BleachBit is available in the repos, but does not appear when searching in GNOME Software

On Thu, 13 Aug 2020 at 08:29, Artur Iwicki wrote: > We also have an icon size requirement. Do you have the latest appstream-data installed? I believe it went to stable a few days ago. Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: Fedora 33 Mass Rebuild

On Mon, 3 Aug 2020 at 14:02, Mohan Boddu wrote: > Failures can be seen > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html Most of those are the libcroco->gettext breakage, no? We're not going to be rebuilding all affected packages manually are we?! Richard./

Re: The future of legacy BIOS support in Fedora.

On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr wrote: > This is not something that's beneficial here, it's only > harming our users. That seems exceedingly myopic to me. I'm guessing you've not been following the last few years of security research, where attacking the firmware is now the best

Re: The future of legacy BIOS support in Fedora.

On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr wrote: > needlessly disables a lot of kernel functionality It disables functionality which can destroy platform security. > You cannot load kernel modules you've built If you can build and insert your own kernel module you can do almost anything

Re: TPM2 for disk encryption, clevis

On Wed, 8 Jul 2020 at 09:59, Marius Vollmer wrote: > As I understand it, there is a lot of evolving OS specific subtlety > involved, so I am asking specifically how this would look on current > Fedora and what to expect in the near future. Just a heads-up; the PCR0 changes when you upgrade the

Re: Packaging firmwares

On Fri, 26 Jun 2020, 22:21 Florian Weimer, wrote: > Is FirmwareUpdate.efi really firmware in Fedora's sense? Won't it run > on the host CPU? > This is flashed hardware!? Can't mellanox just use the LVFS to distribute firmware rather than having to install a package of blobs you're going to use

Re: Avoiding the automatic /usr/bin/python3 dep

On Thu, 25 Jun 2020 at 14:57, Miro Hrončok wrote: > What you need is to disable is the "shebang dependency generator" from RPM. > The > easiest way is to use: > https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/ > %global __requires_exclude

Avoiding the automatic /usr/bin/python3 dep

Hi all, In fwupd we ship 4 *tiny* python scripts that are useful for ODMs and other people working with low level firmware blobs. In https://src.fedoraproject.org/rpms/fwupd/pull-request/2 it was suggested we split them off as a subpackage to avoid the /usr/bin/python3 dep which is unwanted on

Re: [External] Re: Fedora+Lenovo

On Fri, 1 May 2020 at 06:22, Joe Doss wrote: > Yes!!! This works on my T490s! Phew! Do we know why it's not been promoted to stable yet? Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Change the way to acquire the keys for package upgrades [changed]

On Fri, 3 Apr 2020 at 07:48, Samuel Sieb wrote: > The problem is that in the past there have been some packages that have > had to be updated first to successfully do the upgrade. So we list them with versions and do a deterministic check. Being told over and over and again "you need to make

Re: Announcing start of DNF 5 development

On Fri, 6 Mar 2020 at 01:59, Neal Gompa wrote: > caches are not, and that *does* need to be fixed. The library > interface for DNF already has APIs for this, PackageKit doesn't use > them. I'm 100% okay with a pull request to fix this, as long as the same cache promises are met, i.e. PackageKit

Orphaning argyllcms

Hi all, I've orphaned argyllcms. The current version fails to build in Fedora 32 and I no longer use these tools. The Fedora package is also a few minor versions out of date. For anyone wanting to take over this package be aware upstream is pretty hostile for Linux packaging. For instance, you

Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem

On Tue, 7 Jan 2020 at 18:07, Martin Kolman wrote: > IIRC the speedups in compression and decompression > speed we got for RPMs[0] with zstd were pretty nice If it helps the argument, at the moment 99.7% of the time building the AppStream metadata is spent decompressing the RPMs. If zstd helps

Re: powertop vs upower, troubleshooting battery remaining

On Tue, 3 Sep 2019 at 00:48, Chris Murphy wrote: > This is an hp spectre running Fedora 30 Workstation. On Fedora 29, > there was fairly close agreement between powertop and upower and the > time estimates were sane. If you downgrade back to a F29 live session, is it sane again? If the answer is

Re: Heads up: No more snap plugin in gnome-software

On Thu, 11 Jul 2019 at 21:02, Neal Gompa wrote: > If an update occurs even within stable > releases, I would expect it to have a chance to break. We don't break plugin ABI in stable GNOME releases. e.g. 3.32.1 will be the same internal ABI as 3.32.x. In development releases (e.g. 3.33.x) all

Re: Heads up: No more snap plugin in gnome-software

On Thu, 11 Jul 2019 at 14:52, Neal Gompa wrote: > My understanding of the situation was that Canonical is working on a > separate experience tailored for Ubuntu because they have extra needs, > but all of it was built on GNOME Software in the first place. No, it's also a new codebase:

Heads up: No more snap plugin in gnome-software

Hi all, In Fedora 31 I'll be disabling the snap plugin from GNOME Software. It's never been enabled in RHEL and so this change only affects Fedora. It's also not installed by default and so this change should only affect a few people. It's also not really a FutureFeature, it's a RemovalOfFeature

Re: Unretire osslsigncode

On Tue, 4 Jun 2019 at 03:59, Marek Marczykowski-Górecki wrote: > Any objections? None whatsoever. I use an old version of this in my UEFI work. If you get it building in Fedora 30 I'd be happy to co-maintain. Richard ___ devel mailing list --

Re: Can we maybe reduce the set of packages we install by default a bit?

On Tue, 9 Apr 2019 at 19:27, Lennart Poettering wrote: > Hmm? Can you elaborate? Why does fwupd's runtime have something to do > with display flickers? Not grokking the connection? More information in https://github.com/hughsie/fwupd/commit/75b965d01d80d70ae51816acd4d4cafdaf792e99 -- in the case

Re: Can we maybe reduce the set of packages we install by default a bit?

On Tue, 9 Apr 2019 at 19:21, Lennart Poettering wrote: > Very similar is actually "fwupd", why does that need to run all the > time? Seems like something that should be bus activatable, and > exit-on-idle, but why run it all the time? It does exit on idle, if you don't have hardware that is

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On Wed, 13 Mar 2019 at 14:37, Miroslav Suchý wrote: > > Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a): > > ..makes it harder for other programs such as packagekit > > and gnome-software that all need to adopt for the new paths. > Not exactly true. It's completely true, Kalev is spot on. GNOME

Re: Removal of glibc-langpacks-all -> 1.0?kB

On Sat, 2 Feb 2019 at 10:29, Mamoru TASAKA wrote: > It may be wrong, however as fwupd-1.2.4 uses g_format_size(), I guess that > this failure is due to recent g_format_size() output change (in glib2-2.59.X): Aha! Thanks, that sounds exactly right. Much appreciated. Richard.

Removal of glibc-langpacks-all -> 1.0?kB

Hi all, One of my package builds (fwupd) in F30 is failing in the unit tests, with this failure comparing the expected output of a to_string() function: - Size: 1.0 kB + Size: 1.0?kB I assume it's due to the removal of glibc-langpacks-all from the buildroot.

Re: F30: System-Wide Change proposal: DNF UUID

On Tue, 8 Jan 2019 at 08:57, Lennart Poettering wrote: > Yes, Tom's proposal makes sense. Calculate the UUID you submit as > HMAC(machined_id, CONCAT(fixedappuuid, unixtime/432000)) Out of interest, how is using a HMAC different to just using the machine-id appended with a salt, sha256'd?

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

On Thu, 20 Dec 2018 at 10:16, Hans de Goede wrote: > So I say +100 to just pushing the changes directly, as said > people can always revert them. Completely agree. For my packages I'd totally prefer things just magically be done without any action on my part. Richard.

Re: Fedora Lifecycles: imagine longer-term possibilities

On Wed, 14 Nov 2018 at 11:26, Daniel P. Berrangé wrote: > It is not so much whether we "care", but rather whether we have enough > time in the day to get the expected work done. I can't magic up more > time to work no matter how much I care to. Exactly my situation too. Richard.

Re: Fwd: Re: Vagrant: can we make it show up in Software?

On Fri, 19 Oct 2018 at 11:38, Matthew Miller wrote: > What about a "Command Line tools for Developers" section in Software? We've got a developers top level, so I think a CLI tools subsection would be fine. Richard. ___ devel mailing list --

Re: Fwd: Re: Vagrant: can we make it show up in Software?

On Fri, 19 Oct 2018 at 09:36, Vít Ondruch wrote: > I was always under impression, that we don't want to show CLI apps in > Software. Not sure what was the reasoning behind, but I can imagine that: > * we don't want Python to show up in Software (for example) Right, agreed. > * screenshots of

Re: GNOME 3.30.0 megaupdate

On Wed, 5 Sep 2018 at 16:19, Stephen Gallagher wrote: > I'd be *strongly* disinclined to give a Freeze Exception for a GNOME > mega-update. So you'd rather we ship GA with early pre-release builds of GNOME that have had little-to-no testing? From a downstream point of view I'm not going to fix

Re: Got NVMe hardware? I need you!

On Mon, 20 Aug 2018 at 20:13, Jason L Tibbitts III wrote: > but would you prefer that I append something to my machine ID > so that I can send the others? Yes please, just change the last two digits. I think it always has to be 32 hex chars in size, but it doesn't have to be a machine ID. >

Got NVMe hardware? I need you!

Hi all, I've started to look at adding firmware updates for NVMe hardware to the LVFS project (realistically for Fedora >= 31, so don't get too excited). Before I know which vendors to approach, and what I need to ask for, I need to get some statistics about the NVMe hardware the "typical linux

Re: [HEADS UP] Removal of GCC from the buildroot

On Tue, 10 Jul 2018 at 13:35, Tomasz Kłoczko wrote: > IMO even if he has some potential I'm guessing that he is still > relatively young and if it is true he may still need proper mentoring Not cool, you stepped over the line. Igor has done some great work in Fedora in the last few months.

Re: F29 System Wide Change: Modules for Everyone

On Wed, 4 Jul 2018 at 14:17, Zbigniew Jędrzejewski-Szmek wrote: > - pkcon ? > - Gnome Software ? I've been talking internally about this. The idea is for pkcon and GNOME Software to have a superficial view of what modules are, but not to actually expose all the nitty-gritty detail. It's on my

fwupd license change

Hi all, Just a small unimportant notice that I'm required to do: fwupd changed license from "GPLv2+ AND LGPLv2+" to just "LGPLv2+". The library was always the LGPL bit, so this doesn't affect any other things linking to libfwupd. Richard. ___ devel

Re: Announcing DNF 3 development

On 26 March 2018 at 09:16, Tom Hughes wrote: >> Will it FINALLY use one copy of metadata for all system users? > Do you have a proposal as to how that might be possible in a > secure way? I think he means removing the duplication of the cache between PackageKit and dnf. The

Package name of flask_oauthlib

Hi, I've packaged up flask_oauthlib to use for a project I'm developing, and am close to submitting it for a Fedora package review. I'm wondering if the underscore should be used, and the package guidelines tell me to ask here. The source package could either be: * python-flask_oauthlib *

Re: Appstream metadata compose failures

On 4 March 2018 at 12:25, Michael Schwendt wrote: > This new opt-in style has never been a good idea. The software features > an "All" button, which doesn't show all packages, which is misleading. It's not misleading; gnome-software is an application installed, not a package

Re: Appstream metadata compose failures

On 2 March 2018 at 14:10, Kalev Lember wrote: > I believe the answer is to work with upstream to provide updated icons. Right, or patch them in the srpm. Working upstream is obviously better than all the distros having to do the same thing... > I would personally be a bit

Re: Appstream metadata compose failures

On 2 March 2018 at 14:44, Robert-André Mauchin wrote: > Also, with what command can I check if my package is now ok? From memory, I think you can do "appstream-builder name-of-the-file.rpm" and if it makes it into the example.xml.gz file then it passed all the checks.

Re: -z defs linker flag activated in Fedora rawhide

On 25 January 2018 at 14:52, Florian Weimer wrote: >> ../src/fu-device-locker.c:49:1: internal compiler error: in >> ix86_expand_prologue, at config/i386/i386.c:14572 > Yes, this is: https://bugzilla.redhat.com/show_bug.cgi?id=1538648 Agreed. > I can perhaps put a workaround

Re: Upstream installs AppData file in /usr/share/appdata

It's not a huge deal, appstream searches both locations. Metainfo is best, but a low priority fix IMHO. Richard On 25 Jan 2018 14:42, "Neal Gompa" wrote: On Thu, Jan 25, 2018 at 9:39 AM, Samuel Rakitničan wrote: > Hi, > > I have a package

Re: -z defs linker flag activated in Fedora rawhide

On 25 January 2018 at 14:28, Richard Hughes <hughsi...@gmail.com> wrote: > Was there a test mass rebuild? If so, how many packages need fixes? I > got bitten by this just now and it would have been nice to fix the > problems upstream before Fedora rebuilds just started failing. Rep

Re: -z defs linker flag activated in Fedora rawhide

On 25 January 2018 at 14:21, Michael Cronenworth wrote: > This should go through a Fedora Change workflow. I am unaware of a Fedora > Change for this. Was there a test mass rebuild? If so, how many packages need fixes? I got bitten by this just now and it would have been nice to

Re: Proven packagers - stop messing with other people packages!!

On 4 December 2017 at 15:22, David Kaspar [Dee'Kej] wrote: > For what? Creating more work for me? :) I think maybe it's time to take a step back and reconsider what it is to be a Fedora "contributor". You don't _own_ anything; we're all working together as a team. Richard.

Re: Proven packagers - stop messing with other people packages!!

On 4 December 2017 at 14:17, David Kaspar [Dee'Kej] wrote: > 4) He found a fix for it, created a new patch and added it into the package > I maintain/own. Did you say thanks? To any proven packagers out there, feel free to fix bugs in any of the packages I own. Richard

Re: Missing font information at wiki

On 23 November 2017 at 20:34, Will Crawford wrote: > There are still some dinosaurs who don't use GNOME. AppStream is a cross distro and cross desktop specification. It's used by Muon, Discover and Apper on KDE, AppCenter on Elementary OS and also desktop neutral

  1   2   3   4   5   6   7   >