Re: How to change FAS username and email

> On Fri, Jan 22, 2021 at 12:33:50AM +0100, Miro Hrončok wrote: >> This is not possible. You can only create a new account and ask at >> https://pagure.io/fedora-infrastructure/issues to transfer your >> group memberships. > > It is likely, however, that it will be supported in our upcoming new

How to change FAS username and email

I'm having a hard time finding anything about this... 1. I need to change my email address. As I recall, when my Fedora account was first created, it was supposed to automatically link to my existing Red Hat Bugzilla account as long as they both used the same email. Right? I just want to

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

> Do you have the latest appstream-data installed? I believe it went to > stable a few days ago. > > Richard. Turns out this was the problem. appstream-data had maybe lagged a little behind, so the new BleachBit package didn't show up in Software right away. I updated all system packages again

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

> We also have an icon size requirement. The app needs to provide an icon > that's at > least 64x64 (or maybe even 128x128?). The package does contain an icon, a 256×256 pixel PNG with a transparency channel. - https://github.com/bleachbit/bleachbit/blob/master/bleachbit.png - Installed to

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

I contributed an AppStream .metainfo.xml file to the upstream developers. https://github.com/bleachbit/bleachbit/blob/master/org.bleachbit.BleachBit.metainfo.xml Which seems to pass validation during builds based on my RPM spec.

Re: How to retire a package only for Fedora 32+

> The Guidelines say to run "fedpkg retire" on all branches you want the > package to be retired on, starting with the oldest one. Since you > already started with "master", you'll still have to switch to the f32 > branch and run "fedpkg retire" there as well. Is the implied `git push` at the end

How to retire a package only for Fedora 32+

I'm aware of the `fedpkg retire` command, but that seemingly retires the package entirely, and even auto pushes the changes to my package repo. (I will now need to revert this or something -- I'd assumed there would at least be a prompt to confirm before doing a git push...) The package I want

Re: orphaning bleachbit

> I'm already a packager, and I'd be willing to take over BleachBit. This way > you > don't have to wait for Silvia to learn the ropes before handing off control. Oops, I'm used to having my email client do the signature for me, but I responded here in HyperKitty... Name: Andrew T

Re: orphaning bleachbit

> I intend to orphan bleachbit soon. If anyone is interested please let me > know and I will transfer the package. > > https://src.fedoraproject.org/rpms/bleachbit > > Mukundan. I'm already a packager, and I'd be willing to take over BleachBit. This way you don't have to wait for Silvia to

Re: Package with open and closed dual license

Kevin Kofler wrote: > try tcplay, a BSD-licensed interoperable implementation that is > already packaged in Fedora. tcplay hasn't been maintained in a while. Upstream hasn't pushed any commits since 2014. https://github.com/bwalex/tc-play And the history of builds for new releases of Fedora

Re: Package with open and closed dual license

Oh, sorry, I hadn't thought to try searching for previous threads about VeraCrypt in particular. And, looking at it again, the dual license here is tricky, because it looks like the old TrueCrypt files are still TrueCrypt-licensed, while the new files are Apache-licensed. I wondered briefly

Package with open and closed dual license

Sorry if this has already been discussed, but I couldn't find a thread dealing with this exact situation... I'm considering a new package that is dual-licensed under a free and a nonfree license. The Fedora Licensing Guidelines say: > If code is multiple licensed, and at least one of the

Re: Package review requests: Splitting the "sustmi" GNOME Shell extensions into separate packages

. I'd like to be done with it now :) ~ Andrew Toskin / FAS: terrycloth > Update: I'm still working on splitting the "sustmi" GNOME Shell extension > subpackages into their own packages. I've opened an issue on the releng > pagure page: > > https://pagure.io/releng/issue/7

Re: Package review requests: Splitting the "sustmi" GNOME Shell extensions into separate packages

th my part of the process, but I haven't gotten any feedback in a little while. Is there anything else I need to do? Thanks, ~ Andrew Toskin / terrycloth > I'm the RPM package maintainer for these two GNOME Shell extensions: > > * gnome-shell-extension-sustmi-windowoverlay-icons > *

Package review requests: Splitting the "sustmi" GNOME Shell extensions into separate packages

I'm the RPM package maintainer for these two GNOME Shell extensions: * gnome-shell-extension-sustmi-windowoverlay-icons * gnome-shell-extension-sustmi-historymanager-prefix-search They're both currently subpackages of the main "sustmi" package, because upstream had been developing them in a

Re: Unable to bring new package to bodhi

updates from the bodhi command line tool instead. ~ Andrew Toskin > For some odd reasons, I am unable to update via bodhi even though the > package is already built[1]. > > Is it a bug from the infrastructure as the database failed to list new > package [2]? > > >

Re: "sustmi" GNOME Shell packages should be orphaned -- I'd like to take over

How do we proceed from here? I see the wiki talks about how to voluntarily orphan one's own package, and how to take over a package that has *been* orphaned. But I don't see instructions about how to declare a clearly abandoned package as orphaned. ~ Andrew Toskin FAS: terrycloth > /cc yad

"sustmi" GNOME Shell packages should be orphaned -- I'd like to take over

er, but I haven't gotten any response either. These packages have been badly neglected for a long time, and no longer work at all on any supported Fedora release. I'd like to get them back in shape. ~ Andrew Toskin FAS: terrycloth ___ devel mailing lis

Re: How risky is lm_sensors's sensors-detect nowadays?

Friday, 24 March 9:27 a.m. -, Jeff Bastian wrote: > Can Freon check if sensors-detect has been run before, and if not, pop > up a dialog box asking to run it and warn about the risks? Yes, if you haven't run `sensors-detect` yet, Freon says that you need to do so instead of showing the

Re: fedora-review complains about gschema files in an RPM package

Just realized I never posted my final update to this thread, so in case anyone else ever wanders here looking for answers: Any precompiled glib schema file is not needed -- if the *.gschema.xml file(s) are moved to %{buildroot}/%{_datadir}/glib-2.0/schemas/ at the end of the %install section

How risky is lm_sensors's sensors-detect nowadays?

I'm working on packaging Freon, a GNOME Shell extension that displays hardware temperature in the top bar. Freon relies on lm_sensors, and needs the `sensors-detect` command to be run before it will work. The interactive

New packager, needing reviews for some GNOME Shell extensions

a couple other packages, and made an offer to a few more. Thanks, ~ Andrew Toskin FAS username: terrycloth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedora-review complains about gschema files in an RPM package

> On Feb 25, 2017 16:15, "Michael Catanzaro" > Interesting... guess I'm wrong then! > > I think that can be deleted? > > > It's possible that the extension searches for the schema source (not sure > if I'm getting the terminology right) in a specific directory.

Re: fedora-review complains about gschema files in an RPM package

> > * if the package includes *precompiled* gschema... remove it? > No, because these don't exist (at least I don't think so). All > installed gschemas are compiled at once based on the schemas installed > on the system, and there are no precompiled schemas. A few of packages' sources include a

Re: fedora-review complains about gschema files in an RPM package

I'd just like to confirm what actions I need to take for my RPM specs, then, if any. Does this sound right? * if the package source includes a .gschema.xml file, it's okay, and needed, so leave it alone. * if the package source includes a Makefile, which compiles the gschema file, then the

Re: fedora-review complains about gschema files in an RPM package

> It used to be important. The review criteria should be updated. Do you > want to file a bug with fedora-review? Looks like there's already an open bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1409315 ___ devel mailing list --

Re: fedora-review complains about gschema files in an RPM package

> gsettings schema compilation is automatically handled these days with an > rpm file trigger that glib2 sets up. There's no need to add > glib-compile-schemas %postun and %postrans scripts any more (but they > won't hurt either and are required for EPEL7 if you want to keep the > same spec file).

Re: fedora-review complains about gschema files in an RPM package

> I could help edit the wiki if only someone ...if only someone would explain to me what this is about ** ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

fedora-review complains about gschema files in an RPM package

I'm a new Fedora packager; my very first packages have not yet been accepted. I'm working on RPM packages for a few GNOME Shell extensions. Things are mostly going well, except that `fedora-review` complains about gschemas in the packages, and I'm not entirely sure what this is supposed to be

fedora-review complains about gschema files in an RPM package

I'm a new Fedora packager; my very first packages have not yet been accepted. I'm working on RPM packages for a few GNOME Shell extensions. Things are mostly going well, except that `fedora-review` complains about gschemas in the packages, and I'm not entirely sure what this is supposed to be

Re: /sbin/nologin in /etc/shells

Er, let me clarify: Much of the discussion here, as I see it, has been about how to preserve a user account, but block user access to that account. My question is: If it were really important to make sure the user could no longer access the system at all, why not just delete the account?

Re: /sbin/nologin in /etc/shells

We've discussed how and whether it's best practice to disallow a user from logging into an account they previously had access to. But now I'm sorta curious about the opposite situation: What's the use case for blocking a user from accessing their account, rather than just deleting the account

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

Adam Williamson wrote: > Next time maybe I'll just say 'screw this' and go play golf instead, if this > is the thanks I get for trying to help people out. Others have thanked you, actually, but parts of this email chain have gotten a little heated, so I guess it's worth repeating: Thanks for

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

This is the first I've heard of any recommendation like this. If running `dnf upgrade` from a graphical console is such a big and well-known risk, then why isn't it mentioned in the dnf documentation? I've posted about this on the dnf Bugzilla.

Re: Rules regarding whitespace inside .spec files

> A better approach if you care about readability is to stop trying to use > one spec across everything. You don't need any > %if clauses at all if you do that. Well, I have not yet even written anything new to the spec file. This is a fork of an official Fedora package, and I'm still trying to

Re: Rules regarding whitespace inside .spec files

That's unfortunate. The spec file I've forked has certain tags *inside* of %if blocks. Things like this: %if %{?system_cairo} BuildRequires: pkgconfig(cairo) >= %{cairo_version} %endif In some of the longer blocks, no indentation makes it much harder to tell where the %if begins and ends. Is

Rules regarding whitespace inside .spec files

I'm new to RPM packaging. I've recently forked a repository, and one of the first things I tried to do was clean up formatting of the .spec file. Particularly the %if blocks were hard to follow because the previous author did not use any indentation at all. However, it seems like maybe

Seeking a package sponsor for Firefox Developer Edition

d. Thanks, ~Andrew Toskin ("terrycloth" on GitHub and FAS) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org