Re: How to change FAS username and email

[Andrew Toskin]

> 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 account
> system. See https://github.com/fedora-infra/noggin/issues/105

Is there a ballpark estimate on when we'll switch to the new account system?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

How to change FAS username and email

[Andrew Toskin]

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 confirm that the accounts will stay linked when updating my email.

2. I'm also considering changing my FAS nick/username; it's an oblique 
reference to something that I don't want to use as my name anymore. I asume 
this would require submitting a ticket to Pagure, but I'm not sure which 
section to file it under.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Andrew Toskin]

> 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 today, and now BleachBit appears in search 
results, with a working app icon and everything. Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Andrew Toskin]

> 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 /usr/share/pixmaps/bleachbit.png

Is that larger size good enough on its own, or does there need to be a separate 
icon that's exactly 128×128 pixels too? Does AppStream expect the icon to be 
installed at a specific location, or is any standard icon path acceptable?

I don't know about adding a high-contrast icon, or where that would usually get 
installed to. But probably I would need to recommend that the upstream creates 
one.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Andrew Toskin]

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.

  https://src.fedoraproject.org/rpms/bleachbit/blob/master/f/bleachbit.spec

The upstream metainfo file is included in the resulting package, which is 
installed on my f32 x86_64 workstation.

  ↪ rpm --query --list bleachbit | grep 'meta'
  /usr/share/metainfo/org.bleachbit.BleachBit.metainfo.xml

And the bleachbit package is now stable in Bodhi for f31 through f33 and EPEL8.

  https://bodhi.fedoraproject.org/updates/?packages=bleachbit

However, even after installing BleachBit, killing and restarting GNOME 
Software, and/or rebooting my computer, searching for "bleachbit" in GNOME 
Software returns no results. Curiously, I do see BleachBit listed under the 
Installed tab in Software, although even there it's still missing the app icon.

Am I missing something? I'd thought the .metainfo.xml file was all that was 
needed for GUI apps to appear in our "app store".

~ Andrew / FAS: terrycloth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Andrew Toskin]

> 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 at the end of `fedpkg retire` all that 
needs to be done, or do I also need to build on Koji and push to Bodhi like a 
regular package "update"?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

How to retire a package only for Fedora 32+

[Andrew Toskin]

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 to *halfway* retire is 
gnome-shell-extension-no-topleft-hot-corner, which allows you to disable the 
"hot corner" in GNOME Shell. As of GNOME 3.34, you can now do this from GNOME 
Tweaks, so the No Topleft Hot Corner extension is obsolete... Having it 
installed does no harm, but it's redundant.

This means the extension was actually obsoleted in Fedora 31, though the 
Packaging Guidelines say not to deprecate packages in a stable branched release 
of the distro. So I would have liked to retire the package only for Fedora 32+ 
-- the extension may still be useful in EPEL 7 and 8.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: orphaning bleachbit

[Andrew Toskin]

> 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 Toskin
FAS: terrycloth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: orphaning bleachbit

[Andrew Toskin]

> 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 learn the ropes before handing off control.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Package with open and closed dual license

[Andrew Toskin]

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 have been spotty. I'm 
guess these have all only been automatically triggered for a few years, and the 
last successful build was for F28.

  https://koji.fedoraproject.org/koji/packageinfo?packageID=12707
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Package with open and closed dual license

[Andrew Toskin]

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 about whether VeraCrypt had evolved 
enough that it would build if you just omitted the TrueCrypt files (unlikely) 
-- but worse: Many of the old TrueCrypt files have been modified, so license 
comments at the top claim *portions* of the file will have the old or the new 
license depending on who wrote which lines when. Eww :(

...Would it be allowed in RPM Fusion, then?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Package with open and closed dual license

[Andrew Toskin]

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 licenses is approved 
for Fedora, that code can be included in Fedora under the approved license(s) 
(but only under the terms of the approved license(s)).

In particular, does that mean the spec `License:` tag should only list the 
Fedora-approved license? Or should I still list both? Or does this mean the 
package is not allowed in Fedora?

I'm looking specifically into VeraCrypt, the open-source fork from TrueCrypt. 
It's released under the Apache License v2.0 (free), but for some reason also 
maintains the old TrueCrypt 3.0 freeware license as an option...

https://www.veracrypt.fr/code/VeraCrypt/tree/License.txt

Thanks,
~ Andrew (FAS: terrycloth)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Andrew Toskin]

One more time: both of the newly split packages have been marked as approved on 
Bugzilla, but I can't get anyone to do whatever final approval is needed for 
the old "sustmi" GNOME Shell extensions to become two separate packages in 
Fedora. I started this process back in October. 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/7124
> 
> I've also executed `fedpkg retire ...` for the old package on EPEL7, f27, and 
> master.
> And the package review requests for the newly split packages have passed. The 
> Bugzilla
> threads are here:
> 
> * HistoryManager Prefix Search -- 
> https://bugzilla.redhat.com/show_bug.cgi?id=1506428
> * WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429
> 
> I *think* I might be done with 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
> > * 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 single git repository. The two shell
> extensions
> > have nothing to do with each other, though, and upstream finally decided to 
> > split
> them
> > into separate repositories. So I think it now makes sense to also split 
> > them into
> separate
> > packages.
> > 
> > I'm not entirely clear on the procedure. This wiki page
> > 
> > 
> > https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitt...
> > 
> > talks at first about *font* packages, but otherwise seems relevant. So, I've
> started
> > by splitting and updating the spec files, and creating these review 
> > requests. As I
> > understand it, because the packages were already accepted into Fedora, and 
> > the
> extension
> > code hasn't changed, just the packaging, I think all a reviewer should 
> > really
> need to
> > check is whether the upgrade path is sane and works properly.
> > 
> > * HistoryManager Prefix Search --
> https://bugzilla.redhat.com/show_bug.cgi?id=1506428
> > * WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429
> > 
> > Please take a look, and let me know if I've missed anything.
> > 
> > Thanks,
> > ~ Andrew / terrycloth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Andrew Toskin]

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/7124

I've also executed `fedpkg retire ...` for the old package on EPEL7, f27, and 
master. And the package review requests for the newly split packages have 
passed. The Bugzilla threads are here:

* HistoryManager Prefix Search -- 
https://bugzilla.redhat.com/show_bug.cgi?id=1506428
* WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429

I *think* I might be done with 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
> * 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 single git repository. The two shell 
> extensions
> have nothing to do with each other, though, and upstream finally decided to 
> split them
> into separate repositories. So I think it now makes sense to also split them 
> into separate
> packages.
> 
> I'm not entirely clear on the procedure. This wiki page
> 
> 
> https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitt...
> 
> talks at first about *font* packages, but otherwise seems relevant. So, I've 
> started
> by splitting and updating the spec files, and creating these review requests. 
> As I
> understand it, because the packages were already accepted into Fedora, and 
> the extension
> code hasn't changed, just the packaging, I think all a reviewer should really 
> need to
> check is whether the upgrade path is sane and works properly.
> 
> * HistoryManager Prefix Search -- 
> https://bugzilla.redhat.com/show_bug.cgi?id=1506428
> * WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429
> 
> Please take a look, and let me know if I've missed anything.
> 
> Thanks,
> ~ Andrew / terrycloth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Andrew Toskin]

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 single git repository. The two shell 
extensions have nothing to do with each other, though, and upstream finally 
decided to split them into separate repositories. So I think it now makes sense 
to also split them into separate packages.

I'm not entirely clear on the procedure. This wiki page


https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages

talks at first about *font* packages, but otherwise seems relevant. So, I've 
started by splitting and updating the spec files, and creating these review 
requests. As I understand it, because the packages were already accepted into 
Fedora, and the extension code hasn't changed, just the packaging, I think all 
a reviewer should really need to check is whether the upgrade path is sane and 
works properly.

* HistoryManager Prefix Search -- 
https://bugzilla.redhat.com/show_bug.cgi?id=1506428
* WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429

Please take a look, and let me know if I've missed anything.

Thanks,
~ Andrew / terrycloth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unable to bring new package to bodhi

[Andrew Toskin]

If you're talking specifically about the Bodhi web UI, then I think I'm having 
the same problem: After I logged in, I clicked on Create > New Update, tried to 
search for my package, and got the message "unable to find any packages that 
match the current query".

I had to start my 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]?
> 
> 
> Reference
> 
> --
> 
> [1]
> http://koji.fedoraproject.org/koji/search?type=package=glob;...
> 
> [2] https://src.fedoraproject.org/rpms/gimp-luminosity-masks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Andrew Toskin]

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 yaderv
> 
> On Sun, Aug 06, 2017 at 08:10:02PM -0000, Andrew Toskin wrote:
> > There are a couple GNOME Shell extensions that I think ought to be 
> > orphaned. Since I
> already maintain a few other GNOME Shell extensions, I'd be happy to take 
> over.
> > 
> > In the Fedora repos, there are two "sustmi" packages, named for the
> upstream developer's GitHub handle. There's a single listing in the old PKGDB 
> --
> https://admin.fedoraproject.org/pkgdb/package/rpms/gnome-shell-extension-... 
> -- but
> it's two (sub?)packages:
> > 
> > * gnome-shell-extension-sustmi-windowoverlay-icons
> > * gnome-shell-extension-sustmi-historymanager-prefix-search
> > 
> > A look on Bugzilla shows requests to update the packages going as far back 
> > as 2013,
> which never got any response from the maintainer:
> >
> https://bugzilla.redhat.com/buglist.cgi?classification=Fedora...
> > 
> > The only new builds in Koji over the past few years have been automated mass
> rebuilds. From the changelog, it doesn't seem like there has been any manual 
> updates
> from the maintainer since 2012.
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=925824
> > 
> > I've tried commenting on the Bugzilla threads, and tried sending requests 
> > through
> PKGDB (just before it was deprecated), to be added as a co-maintainer, 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 list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Andrew Toskin]

There are a couple GNOME Shell extensions that I think ought to be orphaned. 
Since I already maintain a few other GNOME Shell extensions, I'd be happy to 
take over.

In the Fedora repos, there are two "sustmi" packages, named for the upstream 
developer's GitHub handle. There's a single listing in the old PKGDB -- 
https://admin.fedoraproject.org/pkgdb/package/rpms/gnome-shell-extension-sustmi/
 -- but it's two (sub?)packages:

* gnome-shell-extension-sustmi-windowoverlay-icons
* gnome-shell-extension-sustmi-historymanager-prefix-search

A look on Bugzilla shows requests to update the packages going as far back as 
2013, which never got any response from the maintainer:
https://bugzilla.redhat.com/buglist.cgi?classification=Fedora=Fedora=gnome-shell-extension-sustmi

The only new builds in Koji over the past few years have been automated mass 
rebuilds. From the changelog, it doesn't seem like there has been any manual 
updates from the maintainer since 2012.
https://koji.fedoraproject.org/koji/buildinfo?buildID=925824

I've tried commenting on the Bugzilla threads, and tried sending requests 
through PKGDB (just before it was deprecated), to be added as a co-maintainer, 
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 list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Andrew Toskin]

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 hardware temperature. This message is replaced with 
detected CPU temperature, by default, after you run sensors-detect.

Freon does not provide any warnings about the risk of using sensors-detect, 
though, not in the extension button or settings menu, or in its GitHub wiki. I 
only encountered warnings about risk when I looked at the man page before 
running the command.

On the upside, users would only know how to run `sensors-detect --auto` if they 
had already read the man page, likely including the risk warning, and if they 
see the Freon message and try running `sensors-detect` without arguments, then 
it triggers an interactive mode which also prints risk warnings. So I suppose, 
as long as I keep sensors-detect out of the package installation scriptlets, 
users should see a warning before anything risky happens.

I finally thought to just post an issue on the upstream GitHub (I believe this 
is the official repo):
https://github.com/groeck/lm-sensors/issues/17

The repo doesn't seem terribly active, though 
___
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

[Andrew Toskin]

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 of the RPM spec. And it would be more standard to move the 
gschemas there, so you should do it.

So, move the *.gschema.xml files, and then delete gschemas.compiled file. You 
could even delete the extension's own schemas subdirectory (under  
%{buildroot}/%{_datadir}/gnome-shell/extensions/%{UUID}/ ), because by then it 
should be empty.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

How risky is lm_sensors's sensors-detect nowadays?

[Andrew Toskin]

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 output of sensors-detect and the man page 
still say that there's a small but non-zero risk of serious hardware damage 
associated with some of the tests the program does. However, most of the 
trouble I see from running sensors-detect is from several years ago; starting 
in version 3.3.3, lm_sensors changed some of the default behavior to reduce the 
likelihood of future problems. I can't find anything more recent which 
describes the degree of any remaining risk. I also can't find anything about 
*what* the risk factors even are.

So. Does anyone here know the risk factors, and how much risk there really is 
today when even CentOS 7 uses lm_sensors 3.4?

I've used both Freon and lm_sensors without blowing up my computer, and it 
since `sensors-detect` is mandatory for Freon to work, it seems like it should 
be included in a %post scriptlet. But I don't want to damage unsuspecting 
users' hardware... 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

New packager, needing reviews for some GNOME Shell extensions

[Andrew Toskin]

I've just been sponsored into the packagers group, but I'm still fairly new. I 
started out with a few GNOME Shell extensions. I've been working on these for a 
little while now, and I believe they're ready to ship now -- I just need 
someone to do a final review, and then approve the packages.

* gnome-shell-extension-topicons-plus
https://bugzilla.redhat.com/show_bug.cgi?id=1394614

* gnome-shell-extension-freon
https://bugzilla.redhat.com/show_bug.cgi?id=1396790

* gnome-shell-extension-activities-configurator
https://bugzilla.redhat.com/show_bug.cgi?id=1397692

One issue that fedora-review complains about is the glib-schema -- this 
criterion is apparently out of date and shouldn't apply anymore.
https://bugzilla.redhat.com/show_bug.cgi?id=1409315

Everything else, as far as I know, should be okay.

I would offer to do a review *swap*, but I've already committed to reviewing 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

[Andrew Toskin]

> 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. Something
> like some extension did it until we patched it to try the default directory
> too -
> https://github.com/endlessm/coding-shell-extensions/commit/45e5c2b3bfaf86...

I tried adding a line to my RPM spec to delete the gschemas.compiled file, 
rebuilt and reinstalled the package. Trying to enable the extension failed, 
with the message "could not open file /.../gschemas.compiled"

So I guess that answers that. The compiled and XML version of the schema files 
are necessary where they are in the extension source.

If this is somehow wrong, then several shell extensions, including most of the 
ones I'm packaging right now, will need a bug report, and/or patches...
___
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

[Andrew Toskin]

> > * 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 gschemas.compiled file.

$ file schemas/gschemas.compiled
schemas/gschemas.compiled: GVariant Database file, version 0
___
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

[Andrew Toskin]

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 schema compilation here isn't strictly necessary but doesn't hurt 
anything. Skipping this step would be slightly more efficient, but only 
slightly.
* if the package includes *precompiled* gschema... remove it?

Correct me if I'm wrong.
___
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

[Andrew Toskin]

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

[Andrew Toskin]

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

But then why is this such a prominent "Issue" in the output review.txt file? 
And why does it warn me even when nothing in the spec, patches, and/or source 
files include the `glib-compile-schemas` command?
___
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

[Andrew Toskin]

> 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

[Andrew Toskin]

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 telling me.

Issues:
===
- glib-compile-schemas is run in %postun and %posttrans if package has
  *.gschema.xml files.
  Note: gschema file(s) in gnome-shell-extension-activities-configurator
  See:
  http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GSettings_Schema

I've read the linked wiki page, and I still don't understand what I'm supposed 
to *do*.

At first, I thought maybe I'm not supposed to do `glib-compile-schemas` myself, 
because rpmbuild will take care of it? Except one of my packages gets this 
fedora-review message, and the `glib-compile-schemas` command does not appear 
anywhere in my spec. And the source does not have a Makefile, nor any other 
build scripts which might sneakily compile schema files without my noticing. 
I've checked.

Then I thought maybe I'm just not supposed to include .gschema.xml files in the 
package at all? But that doesn't seem right either, because there are plenty of 
other GNOME Shell extensions in the Fedora repos that also include .gschema.xml 
files.

dnf repoquery --list "gnome-shell-extension-*" | grep -i gschema
___
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

[Andrew Toskin]

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 telling me.

Issues:
===
- glib-compile-schemas is run in %postun and %posttrans if package has
  *.gschema.xml files.
  Note: gschema file(s) in gnome-shell-extension-activities-configurator
  See:
  http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GSettings_Schema

I've read the linked wiki page, and I still don't understand what I'm supposed 
to *do*.

At first, I thought maybe I'm not supposed to do `glib-compile-schemas` myself, 
because rpmbuild will take care of it? Except one of my packages gets this 
fedora-review message, and the `glib-compile-schemas` command does not appear 
anywhere in my spec. And the source does not have a Makefile, nor any other 
build scripts which might sneakily compile schema files without my noticing. 
I've checked.

Then I thought maybe I'm just not supposed to include .gschema.xml files in the 
package at all? But that doesn't seem right either, because there are plenty of 
other GNOME Shell extensions in the Fedora repos that also include .gschema.xml 
files.

dnf repoquery --list "gnome-shell-extension-*" | grep -i gschema

I could help edit the wiki if only someone 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Andrew Toskin]

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? Deleting the 
user does not (necessarily) delete their data, so what's the use case for 
keeping the account at all in such a situation?

> 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
> altogether?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Andrew Toskin]

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 altogether?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Andrew Toskin]

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 starting this 
discussion. I learned something, and I'm not the only one :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Andrew Toskin]

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.

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

I'm having a hard time finding anything about this in the Fedora Wiki either. 
If you could recommend any particular reading that could explain this some 
more, I'd appreciate it.

I tried to read every message in this email thread, but I'm still not clear: It 
seems the bug that inspired the original post is based on certain graphics 
hardware, but you still say it's best not to run system updates from a 
graphical session at all anyway. Is most of the risk related specifically to X 
and the large software stack that runs on it, or is it simply a problem of 
numbers, where more running processes means more things could crash while dnf 
installs updates? Fedora Workstation users are apparently recommended to use 
GNOME Software's reboot/update feature; what's the recommended way to update 
all packages on instances of Fedora Server or Fedora Cloud?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rules regarding whitespace inside .spec files

[Andrew Toskin]

> 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 make sense of 
everything. All the tags contained inside %if blocks, and all the patches and 
so on, existed before I started. So I assume the Mozilla packaging team knows 
some things that I don't.

Really, I think another great solution would be to make the RPM spec file more 
whitespace-agnostic. Why allow indentation for %macros, but ban it for tags?

But, point taken: I'll see if splitting into multiple spec files would make 
things easier to manage.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Rules regarding whitespace inside .spec files

[Andrew Toskin]

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 there a way to convert tags like "BuildRequires:" into %macros so that they 
*can* be indented?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Rules regarding whitespace inside .spec files

[Andrew Toskin]

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 indentation breaks 
tags. %if blocks that only contained other %macros inside seem to work okay, 
but if I have any leading whitespace on the lines for tags such as `Source1:` I 
get errors like this...

> error: line 102: Unknown tag: Source1: firefox-45.0a2.tar.bz2

...and removing the leading whitespace removes the error.

I'm having a hard time finding anything that explicitly says whether or not 
leading whitespace is allowed in the spec file, so I'm hoping that I'm just 
making some silly and simple mistake. Otherwise, not being able to indent 
inside %if blocks is going to make working on this spec file more painful than 
it could / should be.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Seeking a package sponsor for Firefox Developer Edition

[Andrew Toskin]

Hello! I'm interested in learning about RPM packaging for Fedora, and I'd like 
to see the "Developer Edition" release channel for Firefox (formerly called 
Firefox Aurora) available in the Fedora repositories. So my partner Bob and I 
are working on packaging firefox-dev. Our spec file repository is forked from 
the Fedora package for the regular release of Firefox. It's not in a working 
state yet, but you can see our progress on GitHub -- 
https://github.com/Bob131/firefox-dev/

And we have a Copr here -- 
https://copr.fedoraproject.org/coprs/bob131/firefox-dev/

Firefox Developer Edition and regular Firefox are able to share the same user 
profile (the bookmarks, preferences, etc) or use separate profiles, we're 
aiming to allow both versions of Firefox to coexist on the same system. 

Bob and I are both fairly new to the packaging process, so any help will be 
appreciated.

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