Re: Does anybody care about gettext?

[Rafal Luzynski]

10.08.2019 13:12 Björn Persson  wrote:
> [...]
> Anyway, the answer is yes:
> 
> 220 GNU FTP server ready.
> USER anonymous
> 230-NOTICE (Updated October 13 2017):
> 230-
> 230-Because of security concerns with plaintext protocols, we still
> 230-intend to disable the FTP protocol for downloads on this server
> [...]

This answers the question, thanks.

Rafal
___
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: Does anybody care about gettext?

[Rafal Luzynski]

9.08.2019 22:10 Jerry James  wrote:
> On Fri, Aug 9, 2019 at 2:12 AM Alexander Ploumistos
>  wrote:
> > All the patches we carried were merged back in the latest upstream
> > version (0.20.1), but when I took a stab at it, I got a lot of errors
> > about the variable types and I did not know how to proceed.

I tried this as well and stumbled upon this bug:
https://savannah.gnu.org/bugs/?55356

> Alexander, try the attached spec file.  It leads to a successful build
> for me.  (Sorry for doing this in email, but I'm currently in a place
> where I can't make git pull requests.)  It may need a little tweaking
> still, and feel free to trim my verbose changelog entry if you decide
> to use any part of it. :-)

I am not Alexander but since I've already started working on this
I think I can take a look. Your spec file looks mostly good. I have
some doubts which may be completely wrong (I have never looked at the
internals of gettext before) but just in case here we go:

> %bcond_with jar
> %bcond_with java
> 

Before Jens' commit there was also a line:

%bcond_without check

If you remove it you enable the check phase unconditionally.

> [...]
> License: GPLv3+ and LGPLv2+ and GFDL

GFDL is a new thing here, I guess the public announce of the license
change will be needed.

> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz

Do we need to change ftp to https?

> # ensure 'ARCHIVE_FORMAT=dirxz'
> BuildRequires: xz

"BuildRequires: chrpath" removed here, really no longer needed?

> # for documentation
> BuildRequires: texlive-dvips
> BuildRequires: texinfo-tex

It worked for me without these packages although the results
might have been different due of that.

> BuildRequires: libacl-devel

Same here.

> # for the tests
> BuildRequires: glibc-langpack-de
> BuildRequires: glibc-langpack-en
> BuildRequires: glibc-langpack-fa
> BuildRequires: glibc-langpack-fr
> BuildRequires: glibc-langpack-ja
> BuildRequires: glibc-langpack-tr
> BuildRequires: glibc-langpack-zh

Good point.

> %package devel
> Summary: Development files for %{name}
> # autopoint is GPLv3+
> # libasprintf is LGPLv2+
> # libgettextpo is GPLv3+
> License: LGPLv2+ and GPLv3+ and GFDL

A comment why GFDL has been added here would be helpful.
Maybe it is not needed here?

> %package -n libtextstyle
> Summary: Text styling library
> License: GPLv3+
> [...]

Looks great. Are the licenses correct?

> # Eliminate hardcoded rpaths; workaround libtool reordering
> -Wl,--as-needed
> # after all the libraries.
> sed -e 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' \
> -e 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' \
> -e 's|CC=.g..|& -Wl,--as-needed|' \
> -i $(find . -name libtool)

Is this the reason why chrpath is no longer needed?

> %check
> # this takes quite a lot of time to run

Previously the %check was conditional (with "%if %{with check}").
See also my comment on top.

> %{_bindir}/envsubst
> %{_bindir}/gettext
> %{_bindir}/gettext.sh
> %{_bindir}/msgattrib
> %{_bindir}/msgcat
> %{_bindir}/msgcmp
> %{_bindir}/msgcomm
> %{_bindir}/msgconv
> %{_bindir}/msgen
> %{_bindir}/msgexec
> %{_bindir}/msgfilter
> %{_bindir}/msgfmt
> %{_bindir}/msggrep
> %{_bindir}/msginit
> %{_bindir}/msgmerge
> %{_bindir}/msgunfmt
> %{_bindir}/msguniq
> %{_bindir}/ngettext
> %{_bindir}/recode-sr-latin
> %{_bindir}/xgettext

Is it OK to list all these files explicitly?

> %files -n libtextstyle-devel
> %{_docdir}/libtextstyle/

In other subpackages the documentation (also in HTML format)
is moved to a directory htmldoc (although I am not sure why).

> %changelog
> * Fri Aug  9 2019 Jerry James  - 0.20.1-1
> - update to 0.20.1 release, all patches upstreamed

It would be nice to mention the bug report rhbz#1708013.

Also see this comment which suggests adding an upstream patch:
https://bugzilla.redhat.com/show_bug.cgi?id=1708013#c2

Regards,

Rafal
___
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: Help with broken UTF-8 on F30 (Rawhide) mock target

[Rafal Luzynski]

18.04.2019 21:16 jkone...@redhat.com wrote:
> [...]
> All the information can be found here:
> 
> https://github.com/rpm-software-management/mock/issues/250

The discussion contains the suggestion that adding glibc-all-langpacks
to BuildRequires fixes the problem. My other suggestion is that
maybe glibc-langpack-en is sufficient.

Regards,

Rafal
___
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: Fedora 30 Beta Freeze

[Rafal Luzynski]

5.03.2019 04:20 Mohan Boddu  wrote:
> [...]
> Finally, today is also the Software String freeze[7], which means that
> strings marked for translation in Fedora-
> translated projects should not now be changed for Fedora 30.

Thanks for the reminders. The link [1] says that the software string
freeze was one month ago. Today is the software translation deadline.
See also: Translation Tasks. [8]

Regards,

Rafal


> [1] https://fedoraproject.org/wiki/Releases/30/Schedule
> [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
> [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
> [4] https://fedoraproject.org/wiki/Milestone_freezes
> [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
> [6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
> [7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy

[8] https://fedorapeople.org/groups/schedule/f-30/f-30-trans-tasks.html
___
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: The state of Zanata Python client (Python 3 support)

[Rafal Luzynski]

Hi,

Somebody fix me if I'm wrong but as far as I know Python Zanata
client has never been an official client of Zanata. It has always
been just community supported. The official client RPM package is
called zanata-client, its main command line tool is /usr/bin/zanata-cli,
and it is written in Java. This may be the proper solution for you
instead of the Python client. But both the official Zanata client and
whole Zanata have been... not really officially abandoned but just all
original developers no longer work on this.

There was a discussion recently that maybe Zanata should be totally
dropped and replaced with Weblate. Sorry for no links, I'm too tired
to find them now.

Now looking at your email address which says "@redhat.com" I think
that it should be me asking you about the future of Zanata because
it seems that the decisions have been made inside your company rather
than by the outer community.

HTH. Regards,

Rafal
___
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: REMINDER: Fedora 27 End of Life on 2018-Nov-30

[Rafal Luzynski]

Hi Ben,

26.11.2018 16:10 Ben Cotton  wrote:
> [...]
> [1]
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED_status=ON_DEV_status=ON_QA_status=VERIFIED_status=RELEASE_PENDING=Fedora_id=9748312_format=advanced=26

There is a small but severe typo: this URL finds a list of Fedora *26*
bugs still open. You should replace 26 with 27 and redo the rest of
your work. Otherwise there will be no change in the bugs of
Fedora *27*.

On the other hand it is really good that as a side effect you have
found and scheduled to close all Fedora *26* bugs still remaining open
even although they all should have been closed as EOL half a year ago.

Regards,

Rafal
___
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: Locales documentation - custom locale

[Rafal Luzynski]

9.11.2018 14:39 Dominik Grafenhofer  wrote:
> 
> Hi all,
> 
> I would like to create a new custom locale (basically irish english +
> monday as first day of the week).

Off-topic: does not en_GB.utf8 provide this functionality?

Is there a bug in the existing en_IE locale which needs a fix?

> Where can I find recent information
> on how locales are implemented in Fedora (I am on Fedora 29)? I found
> lots of outdated information, which was somewhat helpful, but also
> quite confusing.

Locales are implemented in glibc rather than Fedora. I don't remember
where I saw it written but the message was that since all existing
documentation is currently outdated the recommended way is to take a source
code of any existing locale [1] and rework it for your own needs.

The tool to build your own locale data is called localedef. You can
find some documentation at the command line:

localedef --help
man localedef
info localedef

The purpose of this tool is to allow the users to build and use their own
locales. You don't need the root privileges to use it. Therefore your idea
seems to be correct.

That said, I'm trying to find a simpler solution to your problem.

> Thank you,
> Dominik
> 
> Background: Gnome-shell does not allow to customize locale settings
> beyond choosing one locale setting globally (ui language, currency,
> first day of week,...).

I'm not sure but as far as I understand this, GNOME allows you to select
a locale for language (messages) and formats (I guess this is everything
else). Is it sufficient for you?

If not you may have to set the localization environment variables
(LC_MESSAGES, LC_TIME, LC_MEASUREMENT etc.) individually in your profile
scripts.

If really none of these options works then you will have to build your
own locale. Again, in order to use it you will have to set the environment
variables (e.g., path to your new locale) in your profile scripts.

Regards,

Rafal

[1] https://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales
___
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: mass-removal of LANG=anything-not-C.UTF-8 in packages

[Rafal Luzynski]

11.11.2018 21:33 Joël Krähemann  wrote:
> 
> Hi all,
> 
> I don't care as long you leave the C locale on the system.

IIUC, the C locale is built in and impossible to remove. When Zbyszek
said "remove anything-not-C.UTF-8" he probably meant removal of
actual national langpacks (including English) rather than removal
of other generic locales like C or POSIX.

I think that people were using en_US.UTF-8 as a way to force use of
UTF-8 which is possible with C.UTF-8 as well.

Regards,

Rafal
___
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: mass-removal of LANG=anything-not-C.UTF-8 in packages

[Rafal Luzynski]

6.11.2018 23:15 Zbigniew Jędrzejewski-Szmek  wrote:
> [...]
> Things are the way they are so that without the additional step of
> specifying glibc-minimal-langpack, one get's all the locales by
> default. This design was chosen for maximum backwards compatibility when
> the langpack split was being made.

This case has been discussed during this year's Flock. Indeed,
glibc-all-langpacks was introduced for backward compatibility when upgrading
the Fedora systems predating langpacks. But it is considered a bug that
glibc-all-langpacks is installed by default. The intention of splitting
langpacks was to have only selected locales installed rather than all.

> Installing no locales by default would probably be the default if we
> were starting from scratch today, but when the split was made, a
> different choice was made. I don't see enough benefit to revisit this.

Sure, this may need a separate discussion.

Regards,

Rafal
___
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: mass-removal of LANG=anything-not-C.UTF-8 in packages

[Rafal Luzynski]

6.11.2018 00:24 Zbigniew Jędrzejewski-Szmek  wrote:
> 
> Dear maintainers,
> 
> I'm working again on implementing
> https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot.
> [...]
> 
> Once that's done, I'll file the PRs to actually replace
> glibc-langpacks-all
> with glibc-minimal-langpacks in mock and koji.

Sorry if it's been discussed already before but one thing makes me wonder.
If glibc requires glibc-langpack and then we create glibc-minimal-langpack
which is empty and its only purpose is to provide glibc-langpack and thus
satisfy the dependency, then maybe we should just drop glibc-langpack
dependency from glibc and it would solve the problem? glibc-all-langpacks
could be removed rather than replaced with glibc-minimal-langpack.
The existence of glibc-minimal-langpack proves that glibc is able to work
without any external locale data.

Otherwise your change looks correct to me (although I am aware of the
objections expressed in this thread).

Regards,

Rafal
___
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: fedora-tagger sunset - week post F29 beta freeze

[Rafal Luzynski]

28.08.2018 14:28 Björn Persson  wrote:
> Mattia Verga wrote:
> > The Group tag would not fix exactly what I mean. I wouldn't want to create
> > groups of packages, but apply descriptive tags of the abilities of the
> > package.
> > For example, in some of the packages I maintain:
> > ccdciel: astronomy, astrophotography, imaging, telescope
> > skychart: astronomy, telescope, planetarium
> > kpmcore: administration, disk, partition, utility
> >
> > ... so that a user can search for those tags in a package manager, instead
> > of searching Google to find what software can do what he's searching for and
> > then search for that package in the package manager to find if Fedora ships
> > it.
>
> Why don't you just write your descriptions to include those words?
>
> One can already find CCDciel with "yum search all telescope", Skychart
> with "yum search all planetarium", and KPMcore with "yum search all
> partition". Searching for "astronom" (to catch both "astronomy" and
> "astronomer") finds both CCDciel and Skychart.
> [...]

I think that *.desktop file which is a core of what PackageKit and GNOME
Software define as an application is a good place for keywords. This is
how it already works: if you type a keyword into the GNOME Software search
box or just into the GNOME (systemwide) search box it will find applications
including those not yet installed. Another advantage is that the keywords
in the *.desktop file can be easily localized so a user may search using
the native language.

Unfortunately, ccdciel.desktop [1] does not use Keywords keyword. But we
can change it, that's how open source works. :-)

Yes, I know, the spec file format also provides i18n features so the rpm
file can be translated as well but this is seldom used. I don't think we
have an infrastructure to facilitate this.

Regards,

Rafal


[1]
https://github.com/pchev/ccdciel/blob/master/system_integration/Linux/share/applications/ccdciel.desktop
___
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: glibc-2.27.9000 and struct statx_timestamp

[Rafal Luzynski]

19.07.2018 00:10 Sandro Mani  wrote:
> 
>  Hi
> 
>  I'm hitting the following with qt5-qtbase:
> 
>  /usr/include/linux/stat.h:56:8: error: redefinition of 'struct
> statx_timestamp'
>   struct statx_timestamp {
>  ^~~
>  In file included from /usr/include/sys/stat.h:446,
>   from
> /builddir/build/BUILD/qtbase-everywhere-src-5.11.1/mkspecs/linux-g++/qplatformdefs.h:75,
>   from
> /builddir/build/BUILD/qtbase-everywhere-src-5.11.1/src/corelib/io/qfilesystemengine_unix.cpp:42:
>  /usr/include/bits/statx.h:25:8: note: previous definition of 'struct
> statx_timestamp'
>   struct statx_timestamp
>  ^~~
> 
> 
>  I.e. struct statx_timestamp in linux/stat.h (included directly by
> qfilesystemengine_unix.cpp) is conflicting with struct statx_timestamp in
> bits/statx.h included via sys/stat.h.
> 
>  This has begun with glibc-2.27.9000.
> 
>  Any ideas?

True, this change has been introduced with the upstream commit 93304f5 [1]
and has reached Fedora Rawhide since glibc-2.27.9000-38. [2]
Maybe /usr/include/linux/stat.h requires some conditional #ifdef including
the relevant part only if GLIBC < 2.28. But that's part of kernel, should
be reported and fixed upstream.

I think that Florian who is also active in this list should speak. For now
the simplest workaround for you is to downgrade glibc to something just few
days older.

Regards,

Rafal


[1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=93304f5
[2]
https://src.fedoraproject.org/rpms/glibc/c/6404b258962769f7c4d1108c52aece4b314ee27f?branch=master
___
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/message/WIIFDJYB5N4HA7CLWH7M4KRZOAOWZVF6/

Re: Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Rafal Luzynski]

28.02.2018 09:33 Nicolas Mailhot  wrote:
>
> Le mercredi 28 février 2018 à 00:11 -0500, Orcan Ogetbil a écrit :
> >
> > Shouldn't we consider having -devel packages Require gcc or gcc-c++?
> > What good is a header package without a compiler anyway?
> > This would also (indirectly) pull in the compiler and fix most of
> > these failed builds.
> >
>
> gcc is not the only compiler that reads header files

Also, do the header files actually *require* gcc to be present?
I know it makes sense to have both installed but there are potential
use cases where a user may need only the devel packages but not gcc:

- abrt may need devel packages to generate readable stack traces,
- a user may use a different compiler than gcc (e.g., compat-gcc-34).

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

23.02.2018 13:58 Jonathan Wakely <jwak...@fedoraproject.org> wrote:
>
>
> On 22/02/18 16:47 +0100, Rafal Luzynski wrote:
> >15.02.2018 12:02 Rafal Luzynski <digitalfr...@lingonborough.com> wrote:
> >>
> >>
> >> 9.02.2018 11:34 Rafal Luzynski <digitalfr...@lingonborough.com> wrote:
> >> > [...]
> >> > Please:
> >> > - backport the solution to F26 and F27 as well, this should be much
> >> > easier than in F28 (my pull requests may be helpful),
> >> > - mark my pull requests as merged/obsolete/whatever is appropriate,
> >> > - mark the bugzilla tickets as fixed (hopefully this is automatic).
> >>
> >> PING
> >>
> >> Any chance to fix compat-gcc-34 in F27 and F26 as well? Pull requests
> >> have been waiting for about 1.5 months now.
> >
> >PING^2
>
> Updates submitted for f26 and f27 now.

Indeed. Thank you Jakub, I have not noticed. And thank you Jonathan
for pushing it to bodhi, that made me notice the change.

> You might have noticed the GCC maintainer is a bit busy with rawhide,
> and compat-gcc-34 is not a high priority :-)

True, I've noticed and that's why I have prepared the patches and asked
in public anyone with sufficient privileges to accept them.

Thank you everybody for your participation and I hope it is correct now.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

15.02.2018 12:02 Rafal Luzynski <digitalfr...@lingonborough.com> wrote:
>
>
> 9.02.2018 11:34 Rafal Luzynski <digitalfr...@lingonborough.com> wrote:
> > [...]
> > Please:
> > - backport the solution to F26 and F27 as well, this should be much
> > easier than in F28 (my pull requests may be helpful),
> > - mark my pull requests as merged/obsolete/whatever is appropriate,
> > - mark the bugzilla tickets as fixed (hopefully this is automatic).
>
> PING
>
> Any chance to fix compat-gcc-34 in F27 and F26 as well? Pull requests
> have been waiting for about 1.5 months now.

PING^2

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

9.02.2018 11:34 Rafal Luzynski <digitalfr...@lingonborough.com> wrote:
> [...]
> Please:
> - backport the solution to F26 and F27 as well, this should be much
> easier than in F28 (my pull requests may be helpful),
> - mark my pull requests as merged/obsolete/whatever is appropriate,
> - mark the bugzilla tickets as fixed (hopefully this is automatic).

PING

Any chance to fix compat-gcc-34 in F27 and F26 as well? Pull requests
have been waiting for about 1.5 months now.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

9.02.2018 09:50 Jakub Jelinek <ja...@redhat.com> wrote:
> On Fri, Feb 09, 2018 at 09:48:30AM +0100, Rafal Luzynski wrote:
> > 9.02.2018 08:41 Kevin Kofler <kevin.kof...@chello.at> wrote:
> > >
> > >
> > > Rafal Luzynski wrote:
> > > > Requires: libstdc++.so.6
> > >
> > > That needs to be libstdc++.so.6()(64bit) on x86_64 and other 64-bit
> > > multilib
> > > architectures though.
> >
> > I know and this was going to be my next question: what magic
> > operator to use to generate the correct form for all architectures?
> > Or maybe there is no such operator and I should use some %if ... %else
> > to detect 32bit/64bit/multiarch?
>
> I believe there is none and in the compat-gcc-34 I've built yesterday I'm
> using %ifarch.

Sorry, I did not notice you built yesterday. That's nice!

Please:
- backport the solution to F26 and F27 as well, this should be much
  easier than in F28 (my pull requests may be helpful),
- mark my pull requests as merged/obsolete/whatever is appropriate,
- mark the bugzilla tickets as fixed (hopefully this is automatic).

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

9.02.2018 08:41 Kevin Kofler <kevin.kof...@chello.at> wrote:
>
>
> Rafal Luzynski wrote:
> > Requires: libstdc++.so.6
>
> That needs to be libstdc++.so.6()(64bit) on x86_64 and other 64-bit multilib
> architectures though.

I know and this was going to be my next question: what magic
operator to use to generate the correct form for all architectures?
Or maybe there is no such operator and I should use some %if ... %else
to detect 32bit/64bit/multiarch?

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

7.02.2018 14:58 Jonathan Wakely <jwak...@fedoraproject.org> wrote:
>
> On 07/02/18 02:09 +0100, Rafal Luzynski wrote:
> >[...]
> >Also, just to clarify: I still don't know whether it is correct to just
> >bump the required version of libstdc++, I just bump it because it has been
> >done so many times in the past.
>
> "libstdc++ < 7.0.0" seems to be an attempt to ensure that an
> ABI-compatible version of libstdc++ is used, and conservatively names
> a version that is known to be compatible (rather than assuming that
> all future versions will be compatible).
>
> The libstdc++ from GCC 8.x is ABI compatible with 3.4.x, so bumping
> the Requires: to 9.0.0 (allowing any GCC 8.x release) is fine.

Thank you for your review and the explanation, Jonathan.
Of course, the reason why I bumped to "libstdc++ < 8.0.0" is that
the version 8.0.0 has been pushed to Fedora only recently, after
I had written the patches.

> I'd be tempted to simply remove the version, so just have
> Requires: libstdc++, or maybe Requires: libstdc++ >= 3.4.0 because
> it's unlikely that libstdc++ will introduce an ABI break before that
> spec file becomes obsolete. But maybe I'm not conservative enough :-)

What about the things like:

Requires: libstdc++.so.6

or

Requires: libstdc++.so.6(GLIBCXX_3.4)

?

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Pull requests for compat-gcc-34

[Rafal Luzynski]

Hello,

I have opened 3 pull requests for compat-gcc-34:

https://src.fedoraproject.org/rpms/compat-gcc-34/pull-requests

fixing FTBFS errors in 3 currently existing Fedora releases.
Thank you all who helped me with this task. What is the next step
to make them actually merged? I have not received any feedback from
the maintainer, I believe he's just very busy.

Also, just to clarify: I still don't know whether it is correct to just
bump the required version of libstdc++, I just bump it because it has been
done so many times in the past.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Rafal Luzynski]

24.01.2018 10:08 nicolas.mail...@laposte.net wrote:
>
>
> Hi Rafal
>
>
> Does that mean it is finally possible for a user to set its default
> date format to ISO 8601 without switching its language to Danish English?
> [...]

No, this was not a part of my work. I was working only on how the
month names are spelled in different languages. I was not even aware
that the problem of ISO 8601 date exists. Does it solve your problem
if you set LC_TIME environment variable to en_DK or some other language?
It would allow you to keep the rest of the system in your default language.

Recently I have suggested to introduce en_EU instead of en_DK, this
could save some people from being confused and ask "what is that Danish
English and why should I use it". But that's a different story.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Rafal Luzynski]

24.01.2018 07:10 Florian Weimer <fwei...@redhat.com> wrote:
>
> On 01/22/2018 11:58 PM, Rafal Luzynski wrote:
> > I'd like to notify you that today I've finished my works on date
> > formatting in glibc, that means upstream. These changes are already
> > arriving to Fedora Rawhide (they should be there tomorrow) and will
> > be part of Fedora 28. They will be included in glibc 2.27 (to be
> > released on February 1), or in pre-release upstream version
> > 2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48).

BTW, thank you Florian for delivering it to Rawhide so quickly.

> Note that this is an ongoing effort.

That's true, the change is visible only in languages where the locale
data have actually changed. That's the reason why I'm asking the language
communities for their opinion before we apply the change. So far only
Polish language has been updated and there is some interest from
Belarisuan and Russian communities but no final approval yet.

> Some Romance languages will
> eventually use this to correct the incorrect spelling of “de April” into
> “d'April”. Once this happens, it will be necessary to change
> translation strings for these languages from “de %B” to “%B”, otherwise,
> the result will “de d'April”.

That's true. So far I have identified three languages where the change
will look like this: Asturian, Catalan, and Walloon.

> (Yes, the meaning of %B changed in a backwards-incompatible way, and
> glibc upstream deliberately implemented it this way.)

That's true. But another argument is that it has never been specified
whether %B is standalone or in-full-date-context. Probably because there
was no such need in Germanic languages. It seems that translators have
always treated this as a standalone version, probably except the Lithuanian
community.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Rafal Luzynski]

I'd like to notify you that today I've finished my works on date
formatting in glibc, that means upstream. These changes are already
arriving to Fedora Rawhide (they should be there tomorrow) and will
be part of Fedora 28. They will be included in glibc 2.27 (to be
released on February 1), or in pre-release upstream version
2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48).

What has been changed:

* strftime() family (including stftime_l(), wcstime(), wcstime_l(),
strptime() etc.): there are new format specifiers: %OB, %Ob, %Oh.
It has been specified that the currently existing format specifiers:
%B, %b, and %h generate the month names (%B--full month names, %b
and %h--abbreviated month names) in a grammatical form required when
the month is used as a part of a complete date (that means: together
with the day number) while the new format specifiers with %O (note:
this is O letter, the uppercase o, not the zero digit, 0) will generate
the month names in a grammatical form required when the month is named
by itself (without a day number, usually standalone). In most of the
languages there is no difference between those two forms. However,
there is a group of languages (about 20) where the correct form used in
the full date is a genitive case while standalone months must be
in a nominative case.

* strptime(): just accepts the new format specifiers: %OB, %Ob,
and %Oh; each of them recognizes any form of the month name.

* nl_langinfo() family (including nl_langinfo_l()): there are new
constants supported: ALTMON_1, ALTMON_2, … ALTMON_12, and also (kinda
undocumented): _NL_WALTMON_1, _NL_WALTMON_2, …, _NL_WALTMON_12;
_NL_ABALTMON_1, _NL_ABALTMON_2, …, _NL_ABALTMON_12; _NL_WABALTMON_1,
_NL_WABALTMON_2, …, _NL_WABALTMON_12. These new constants generate
the same month names as strftime() with %OB, %Ob, and %Oh format
specifiers (month names standalone, which means a nominative case
in some languages). The old constants MON_1, MON_2, …, MON_12,
ABMON_1, ABMON_2, …, ABMON_12 generate the same month names
as strftime() with %B, %b, and %h format specifiers--nothing new,
it has been the same since forever. But from now these constants
will generate the month names in a form used when the month name
is a part of a complete date. That means they are unsuitable to
generate the list of months standalone.

What needs to be changed:

* In Fedora: literally, nothing. The changes belong to upstreams
and I'm writing here in hope that some upstream developers are here
as well or you can forward the message to them. But of course
upstream software eventually lands in Fedora (as well as in other
distros). You may add "Requires: glibc >= 2.27" to the packages
which rely on this new feature, that means if their upstreams required
any changes in nl_langinfo() or strftime() calls.

* Translators: if you want this feature to be supported in your
language please notify me ASAP. There will be no change in the
languages for which the locale data in glibc are not changed.
So far only Polish language has been updated. Here is the list of
languages which probably need the update (the list may be incomplete):
Armenian, Asturian, Belarusian, Catalan, Croatian, Farsi, Greek,
Kashubian, Lithuanian, Ossetian, Russian, Scottish Gaelic,
Silesian, Sorbian (Upper and Lower), Ukrainian, Walloon.
These languages probably do not need the change but should put
their attention: Bosnian, Czech, Finnish, Serbian, Slovak.

* Applications using nl_langinfo() to display months: well, you
shouldn't use this function. This is a low-level function useful
to implement strftime(). But if you really want to you can but
you should stop using MON_* (and ABMON_*) and switch to ALTMON_*
(and _NL_ABALTMON_*) instead. You should detect whether it is
supported at compile time or at runtime. Well, it's tricky,
isn't it? Therefore it's better to use strftime().

* Applications using strftime() to format dates: if you display
a full date, including both the day number and the month name,
that is when the format specifier is "%d %b %Y" or "%B %e %Y"
or anything looking like that--no change is required. The only
case is when you display the month name standalone, whether it's
full ("%B") or abbreviated ("%b", "%h"), even when the year
number is included ("%B %Y"). This should be changed to "%OB"
and "%Ob".

* Other libraries than glibc which wrap or reimplement the same API
(like glib2 or gnulib): should enable this or apply the changes
to their implementation. By "enable" I mean "define the new
constants and do not raise an error when you see them or when
you see the %O[Bbh] format specifiers in strftime()".

* Other programming languages: the same as above, that means:
if your language just calls nl_langinfo() and strftime()
then make sure it calls it properly, defines the new constants
and does not raise errors, or if it implements the same feature
then the changes must be applied to your implementation.

* Testers: make sure the dates are displayed correctly, especially

Re: RFC: Dropping %{?_isa} hack

[Rafal Luzynski]

19.01.2018 04:54 Michael Cronenworth  wrote:
> [...]
> Yes. Yes. There are cases where the 64-bit binary doesn't run and the 32-bit
> one
> does. There are cases where the software is 32-bit only and no longer
> supported but
> still needed to export data.
>
> Until Microsoft decides to abandon 32-bit we will still need it.

Working with Windows developers (developing applications for Windows,
not Windows itself :-) ) I must confirm that 32-bit applications
for Windows are still pretty common. Because "why should we rebuild
our binaries for 64 bits if 32-bit binaries work everywhere while
64-bit ones not necessarily."

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Glibc collation update and sync with cldr

[Rafal Luzynski]

5.01.2018 00:22 R P Herrold <herr...@owlriver.com> wrote:
>
>
> On Fri, 5 Jan 2018, Rafal Luzynski wrote:
>
> > be the same as the default "C" locale or slightly different. I'm not
> > aware of any Fedora package where the order of the config files does
> > matter
>
> apache cares in /etc/httpd/conf.d/ with virtual host
> enablement on ports along with multiple vhosts
> [...]

Sorry, I was not precise enough. I meant only files placed in
/etc/ld.so.conf.d which may (and usually do) belong to different
packages. So, again, I'm not aware of any Fedora package which puts
a config file into /etc/ld.so.conf.d and cares about whether this
config file is processed by ldconfig before or after other config
files.

Of course, other utilities may have also other config files and may
have some rules of their order. They are not changed. This is a change
only in ldconfig utility which belongs to glibc.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Glibc collation update and sync with cldr

[Rafal Luzynski]

4.01.2018 20:19 nicolas.mail...@laposte.net wrote:
>
>
> Hi,
>
> Shouldn't iso definition files (or unicode.org files) have their own package,
> so they are not buried deep inside glibc, and it is clear a periodic upstream
> sync is necessary ?
>

I'm afraid it would be a huge effort to implement this because,
as you have already noticed, the locale data are already buried
deep inside glibc upstream. The process would require unbundling
them and then either repackaging from the same source or update
from CLDR if CLDR is newer than glibc. It's easier to contribute
upstream and get a complete glibc tarball with CLDR data updated.

OTOH, the locale data from glibc are already split into subpackages
(langpacks) but the aim is not to distribute them all together
(e.g., in a Live DVD) and not to force the user to install them all.
They are still built from the same tarball.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Glibc collation update and sync with cldr

[Rafal Luzynski]

4.01.2018 16:59 Jan Kurik  wrote:
> [...] Therefore, all
> characters added in later Unicode versions are missing and not sorted
> at all which causes bugs like [[1]].

Seems like a link is missing.

While at this, there is one more change in glibc, not directly related
with this one but kinda similar. The ldconfig utility now forces the
"C" sorting order while processing the files from /etc/ld.so.conf.d
directory. Previously the sorting order was locale dependent which could
be the same as the default "C" locale or slightly different. I'm not
aware of any Fedora package where the order of the config files does
matter, there was an example from Debian where they allow installing
multiple versions of the same library and they add numerical prefixes
to the file names to enforce the order. However, I hope this heads up
is worth posting.

Links:

https://sourceware.org/bugzilla/show_bug.cgi?id=22505
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7d38eb3
https://sourceware.org/ml/libc-alpha/2017-12/msg00048.html

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: adding display authorization to other accounts is broken

[Rafal Luzynski]

20.12.2017 17:07 Przemek Klosowski  wrote:
>
>
> The primary logged-in session is of course authorized to access the main
> X11/wayland display, but it's often useful to add display authorization
> to other accounts. For instance, looking at disk space with 'baobab'
> works better as root because some areas of the filesystem are not
> readable to normal users (*). I used to do such authorization by
>
> xhost +si:localhost:root
>
> but it recently stopped working:
> https://bugzilla.redhat.com/show_bug.cgi?id=1527754 . Is there another
> way of authorizing display access for other accounts? If not, this is a
> fairly painful regression.

The same here:

https://pagure.io/system-config-language
https://bugzilla.redhat.com/show_bug.cgi?id=1274451

and AFAIUC the answer is that the applications should use polkit to
run privileged operations while being able to display regular user's GUI.

Regards,

Rafał
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Help Reviewing a FreeOTP (Android) Pull Request in Korean

[Rafal Luzynski]

6.12.2017 15:47 Nathaniel McCallum  wrote:
>
>
> Do you speak (I think) Korean and English? Can you code? If so, I
> could use your help.
>
> The Fedora-associated FreeOTP project has received this pull request:
> https://github.com/freeotp/freeotp-android/pull/165
>
> The comments and commit descriptions are almost entirely in Korean and
> I don't know how to make heads or tails of them. Communication with
> the patch submitter is also difficult since I don't speak Korean and
> they don't speak English. However, I'd really like to give the
> submitter a fair shot.
>
> Is there anyone in the Fedora community that would be willing to
> assist? This is a great opportunity to demonstrate the diversity of
> open source!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Crossposting to trans@ in hope someone may help.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Developers - help promote Fedora -- Booth Demo Opportunity 11/12 November

[Rafal Luzynski]

Hi Brian,

Are you sure it's 11/12 November?  Their web page says 15-19.

BTW, I'm unable to help you for multiple good reasons.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Strange situation with Wine on Fedora 27

[Rafal Luzynski]

12.07.2017 12:38 Thomas Goffin  wrote:
> 
>  Thanks for reaction, the problem was in the duplicate:
>   
>  * gstreamer1-1.12.1-1.fc27
>  * gstreamer1-1.12.0-1.fc27
>   

Actually your duplicate was:

* gstreamer1-1.12.1-1.fc27.i686
* gstreamer1-1.12.0-1.fc27.x86_64

as you wrote:

>  > # dnf install wine ... Error: Transaction check error:
>  >   file /usr/share/doc/gstreamer1/NEWS from install of
>  > gstreamer1-1.12.1-1.fc27.i686
>  > conflicts with file from package gstreamer1-1.12.0-1.fc27.x86_64

It should be possible to install both i686 and x86_64 packages if
they were in exactly the same version. You were unlucky to try
to install wine in the transient moment when gstreamer1 was available
in two unmatching versions for i686 and x86_64. The reasons could be:
build failure for one architecture but not for another, build still
in progress, mirrors not yet synchronized. I guess the install
would be successful if you retried it today.

>  Maybe it will be a good idea to use 'installonly_limit=1' into a dnf
> configuration sometimes.

I don't think it would work. These packages were for different
(although compatible) architectures. wine is known for requiring
32-bit dependecies on x86_64 platform.

Shortly saying: everything is OK, you were unlucky.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Non responsive maintainer fab

[Rafal Luzynski]

23.05.2017 11:40 James Hogarth  wrote:
>
>
> On 23 May 2017 at 09:17, Vascom  wrote:
> > Yes, I am tried few days ago. He is not response.
> >
>
>
> Give him a time, life gets busy at times and we are but volunteers.

If you look at fab's list of packages [1] it's huge. And he
has updated some of them not so long ago so he is probably not
definitely unresponsive.

Regards,

Rafal

[1] https://admin.fedoraproject.org/pkgdb/packager/fab/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Deprecated net-tools? Mass bug filing?

[Rafal Luzynski]

> Dnia 18 maj 2017 o 23:19 Reindl Harald <h.rei...@thelounge.net> napisał(a):
>
>
>
>
> Am 18.05.2017 um 23:13 schrieb Rafal Luzynski:
> > On 18 May 2017 at 11:03, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> >> It's not just packages with explicitly published dependencies. It's a
> >> lot of configuration tools with implicit dependencies, whose authors
> >> didn't imagine at the time of authorship that basic utilities like
> >> "/sbin/ifconfig". These tools may be entirely local and outside of
> >> RPM's, or may never have bothered to declare what they thought was an
> >> implicit provision as part of running on an RPM based Linux. For
> >> example, I note on the older systems I have immediate access to that
> >> ifconfig is used in the python "virtinst" and "uuid" modules.
> >
> > If there are implicit dependencies what about converting them to
> > explicit so they will be easier to find in future?
>
> a) how do you find them

I will not. :-) One can only ask the packagers to add these
dependencies explicitly if they know they are implicit or one
can spot accidentally. Somehow Nico discovered that virtinst
and uuid use ifconfig. Unfortunately, I have no good and reliable
way to find all dependencies.

> b) you can't cover "These tools may be entirely local" anyways

That's true for any dependency.

> c) net-tools is just fine and as long as iproute can't
> provide 100% backward behavior it's unacceptable as replacement
>
> sysadmins don't give a damn waht a replacement can do additionally - the
> first step to replace something is *behave identical* and after that
> consider enhancements - period

It's been agreed that the aim is not to remove net-tools, at least
not in a predictable future. Adding explicit dependencies should
not change anything except making it easier to find them in future.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Deprecated net-tools? Mass bug filing?

[Rafal Luzynski]

On 18 May 2017 at 11:03, Nico Kadel-Garcia  wrote:
> It's not just packages with explicitly published dependencies. It's a
> lot of configuration tools with implicit dependencies, whose authors
> didn't imagine at the time of authorship that basic utilities like
> "/sbin/ifconfig". These tools may be entirely local and outside of
> RPM's, or may never have bothered to declare what they thought was an
> implicit provision as part of running on an RPM based Linux. For
> example, I note on the older systems I have immediate access to that
> ifconfig is used in the python "virtinst" and "uuid" modules.

If there are implicit dependencies what about converting them to
explicit so they will be easier to find in future?

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Rafal Luzynski]

12.05.2017 20:50 Mattia Verga  wrote:
> [...]
> I tried with 'dnf repoquery --disablerepo="updates" -l *.x86_64 | grep
> "/usr/bin" &> filelist.txt' but it seems to only list files for packages
> I've installed on my system.

I tried:

dnf repoquery --disablerepo=updates -l \*.x86_64 ...

and it seems to have worked. You need a backslash before an asterisk,
otherwise it is substituted with *.x86_64 files from your current
directory.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Cannot dnf group remove "Cinnamon Desktop"

[Rafal Luzynski]

10.05.2017 20:02 Jorge Gallegos <k...@blegh.net> wrote:
>
>
> On Tue, May 09, 2017 at 12:09:48PM +0200, Rafal Luzynski wrote:
> [...]
> > 2. I guess that dnf history undo would do the job.
>
> Hrm, I haven't looked at dnf history, fwiw this is the rough timeline of
> events:
>
> 1. install fedora 23 workstation (comes with gnome)
> 2. dnf group install "Cinnamon Desktop"
> 3. live with it for a year or so
> 4. fedora-upgrade to fedora 24, then to 25
> 5. found the alleged bug

It looks too tricky. I thought you installed Cinnamon Desktop only
recently, played with it for few hours and now decided to uninstall.
With hundreds of upgrades, packages obsoleted and replaced, possibly
with many installs/removals during the lifetime of the system it
may not be worth the effort to try to uninstall Cinnamon as a group.
Simply it may be easier to install a new system from scratch.

If you want to continue your efforts my suggestion is to try to
figure out how the dependency chain looks like (which packages make
systemd and dnf require Cinnamon) find the best place to break it
and remove some packages forcefully with "rpm -e --nodeps", then
try to dnf group remove "Cinnamon Desktop" (hopefully will work
because you have forcefully broken the dependency chain), then
as soon as you uninstall Cinnamon make sure you install any other
desktop, like GNOME or whatever you prefer. It should pull all
requirements including those you have forcefully removed.
Your system will become unstable during that process, your graphics
subsystem may crash and may be unable to boot so better work
on a text console and better do not reboot until you will have
finished.

I'm not sure it will work, I never tried this. I tried performing
similar crazy tasks and usually it took several days sometimes
with success and sometimes without, always with a conclusion it
would be better to install a new system from scratch.

Again, think if it's worth the effort.

Best regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Cannot dnf group remove "Cinnamon Desktop"

[Rafal Luzynski]

Hi,

8.05.2017 16:40 Jorge Gallegos  wrote:
> [...]
> [root@ragnia ~]# dnf group remove "Cinnamon Desktop"
> Last metadata expiration check: 2:18:50 ago on Mon May 8 07:18:18 2017.
> Dependencies resolved.
> Error: The operation would result in removing the following protected
> packages: dnf, systemd, systemd-udev.

1. Have you fixed your problem already?
2. I guess that dnf history undo would do the job.
3. What is your Fedora version (or what is your distro if it is
not Fedora) and what desktop environment did you have installed
before installing Cinnamon Desktop? My guess is that Cinnamon
replaced (uninstalled) some components of your previous desktop
which are required by whole OS. So now when you uninstall Cinnamon
you also uninstall those obligatory components. Instead (or rather
before) uninstalling them you'd have to reinstall your previous
desktop. But that's my guess only.

It may be a bug or it may not be a bug. We will not know without
trying to reproduce. Or it may be a bug but not worth fixing because
probably a workaround exists and probably switching desktops is
considered too advanced to be worth making easier.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF translation

[Rafal Luzynski]

I think that developers should be asked this question.
As DNF is a software originally made by Fedora people
I think it's correct to crosspost to devel@fpo hoping to
get an answer from the DNF authors or at least from
somebody who can explain what they meant.

Just to summarize the story: somebody please explain
us what is "a payload factory" in this context.

Regards,

Rafal

29.04.2017 03:07 Daniel López  wrote:
> 
> 
>  sometimes payload is used as capacity 
> 
>   
> 
>  i think it means the number exceeds the capacity for , lets say, certain
> number of  packages.
> 
>   
> 
>  Not really sure. Have you solved it already?
> 
>   
> 
>   
> 
> 
>  -
>  De: Máximo Castañeda 
>  Enviado: miércoles, 12 de abril de 2017 07:30:11 a. m.
>  Para: Fedora Translation Project List
>  Asunto: Re: DNF translation
>   
>  FWIW, I've translated it to something that back in English would be
>  like "no data manager found for %s".  From the code[1], it looks like
>  there are different types of repos or downloadable "stuff" (payload),
>  that can each have a different "manager" (factory), such as a normal
>  rpm and a deltarpm.
> 
>  [1]
> https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L104
> https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L104
> 
>  2017-04-12 13:39 GMT+02:00 Zdenek Chmelar :
>  > Hello all
>  >
>  > The DNF project has one sentence which I'm not able to reasonably
>  > translate. I think I do not understand the sentence meaning properly. I
>  > have checked French and German translations in order to understand the
>  > meaning better but those languages didn't translate that sentence yet.
>  >
>  > So what's the magic sentence I speak about?
>  > "no matching payload factory for %s"  (message with number #547)
>  >
>  > If anyone could explain what means "payload factory" in relation to DNF, I
>  > would be very thankful ;-)
>  >
>  > Thanks
>  > Z.
>  > ___
>  > trans mailing list -- tr...@lists.fedoraproject.org
>  > To unsubscribe send an email to trans-le...@lists.fedoraproject.org
>  ___
>  trans mailing list -- tr...@lists.fedoraproject.org
>  To unsubscribe send an email to trans-le...@lists.fedoraproject.org
> 

 

> ___
>  trans mailing list -- tr...@lists.fedoraproject.org
>  To unsubscribe send an email to trans-le...@lists.fedoraproject.org
> 

 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Rafal Luzynski]

Thank you for your tips, Christopher. This is probably the most
complete guide that can be included in a short post.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Rafal Luzynski]

25.04.2017 06:16 Globe Trotter  wrote:
> [...]
>  However, if there is going to be an issue with getting it accepted in Fedora
> because it has not been around for a while and because it is likely hardly
> used by people (because it is at best for WM environments), then I don't know
> if I should even proceed.

No, I misunderstood the history of the project because the
GitHub repo says it's been created 23 days ago and has no
releases so far. Having read your more explanations I think
it's probably only a matter of some technical rework.

The project may not be accepted in Fedora because of the
legal reasons. Otherwise I may be wrong but I don't think
there is any threshold of minimum days since being started,
minimum number of users etc.

>  Ideally, of course, it appears that the best course would be to version the
> software in github itself. I have to figure out how to do this, and would
> appreciate any pointers in this regard. I only know very basic commands in
> git. 

You should choose what is your preferred releasing model
and your spec file must be adapted to the source repo.
It's easier for you because you work on both sides.

I also consider myself as the beginner in git but here
are some links I think may be useful:

* If you'd like to import your project to GitHub again,
now with whole history:

https://help.github.com/articles/importing-a-repository-with-github-importer/

* About releases in GitHub:

https://help.github.com/articles/about-releases/

Also click in this page: Working With Tags and Creating Releases

* Linking to releases - this will be useful when you will access your
release source code from the spec file:

https://help.github.com/articles/linking-to-releases/

* I also recommend reading About branches. When making a release
you should create a release branch which will not be updated unless
you find a bug in an old release and want to make a bugfix release.
Normally your current work should be pushed to master:

https://help.github.com/articles/about-branches/

I hope this helps.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Rafal Luzynski]

25.04.2017 02:47 Nico Kadel-Garcia <nka...@gmail.com> wrote:
>
>
> On Mon, Apr 24, 2017 at 7:39 PM, Rafal Luzynski
> <digitalfr...@lingonborough.com> wrote:
> > 23.04.2017 19:23 Christopher <ctubb...@fedoraproject.org> wrote:
> >>
> >> You can set the name of the file via the GitHub API when you download it.
> >>
> >> For jQuery (packaged as js-jquery), I use:
> >> https://github.com/jquery/jquery/archive/%{version}/jquery-%{version}.tar.gz
> >>
> >> This will work for any GitHub project which tags released versions:
> >>
> >> https://github.com///archive//.tar.gz
> >> [...]
> >
> > I'm afraid this will not work because (according to the GitHub
> > repo) this project has 0 release tags. Also the archive has been
> > created only 23 days ago. Isn't it too early to package a project
> > which has not yet ever been released upstream?
>
> Been there, done that. It assumes that other people are following your
> own model of how source control or product releases work.

Of course, there are multiple ways to manage product releases.
The spec file must be adapted to the way the source repo is managed.

Globe Trotter has already explained in another post that he is also
upstream so he is able to rework both sides and choose the most
comfortable way.

> [...]
> I'll note that it is not "incorrect" to import a project without full
> history and logs. True, it discards history. [...]

I meant that a "correct" way to import is the way according to what
the maintainer wanted. History, at least partial, and tags help
maintaining the releases. Again, there are multiple ways to achieve
the result but I guess that release tags are what Globe Trotter
would like.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Rafal Luzynski]

23.04.2017 19:23 Christopher  wrote:
> 
>  You can set the name of the file via the GitHub API when you download it.
> 
>  For jQuery (packaged as js-jquery), I use:
>  https://github.com/jquery/jquery/archive/%{version}/jquery-%{version}.tar.gz
> 
>  This will work for any GitHub project which tags released versions:
> 
> https://github.com///archive//.tar.gz
> [...]

I'm afraid this will not work because (according to the GitHub
repo) this project has 0 release tags. Also the archive has been
created only 23 days ago. Isn't it too early to package a project
which has not yet ever been released upstream?

Also:

> [...]
>  On Sun, Apr 23, 2017 at 11:38 AM Globe Trotter  mailto:itsme_...@yahoo.com > wrote:
>
> >I am trying to package the following from github for fedora. (Actually, I
> > have been using my own RPM for years so it is hopefully not a major task).
> > 

If you say you have been using your own RPM file for this project
for years then maybe the project is not as young as this GitHub
repo suggests? Maybe it's just been imported incorrectly, without
the full history and tags, maybe it has another proper source
repo which should be used instead?

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Rafal Luzynski]

24.04.2017 12:47 Milan Crha  wrote:
> [...]
> I know I can do this for packages I maintain, but I though it would
> make sense to think of it globally. Maybe?
>
> Bye,
> Milan

If I may drop my 2¢… this sounds good to me for large packages,
for example LibreOffice, glibc and KDE which do it already and
Evolution as a good candidate to implement this change.

But for small packages which have not so many translatable
messages producing dozens of small RPMs ~1 kilobyte each or even
less would doesn't sound like a good solution. So I suggest to
introduce this feature but not globally and obligatorily for
all packages.

Additionally, I think that for some purposes installing all
languages for some specific applications would be useful so
I also suggest providing something like glibc-all-langpacks.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Nested rich-dependencies in rpm

[Rafal Luzynski]

13.04.2017 08:57 Björn 'besser82' Esser <besse...@fedoraproject.org> wrote:
>
>
> Am 13.04.2017 um 02:38 schrieb Rafal Luzynski:
> > [...]
> > Could it at least try to recognize the current desktop environment
> > and prefer the matching backend rather than loading them in this
> > hardcoded order?
> >
> > Rafal
>
> I'm working on getting such a functionality into libyui; my current
> mock-up is based on ENV:${XDG_CURRENT_DESKTOP}. I'll file a PR during
> later today to libyui.

Thank you, that's exactly what I was thinking about.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Nested rich-dependencies in rpm

[Rafal Luzynski]

12.04.2017 18:20 Björn 'besser82' Esser  wrote:
> [...]
> if TTY it instantly uses libyui-ncurses
> else it *tries* to load - and uses the first available -
> GUI-backend in the following order:
>
> libyui-qt
> libyui-gtk
> libyui-ncurses

Could it at least try to recognize the current desktop environment
and prefer the matching backend rather than loading them in this
hardcoded order?

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Rafal Luzynski]

31.10.2016 22:35 Chris Murphy  wrote:
> [...] And if I refresh, it appears to be
> downloading a lot of data all over again - I just don't know what and
> have no good way to troubleshoot this, but the refresh is taking a
> long time, maybe 30 minutes.

That's definitely not the answer for the end users but 'pkmon'
command may at least tell you what it's downloading and what's
the progress.

Regards,

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

[Rafal Luzynski]

5.10.2016 22:21 Dan Book  wrote:
> [...] I'd like to add that at least the MATE and Cinnamon spins, possibly
> others, do not include PackageKit and instead expect users to update using
> yumex-dnf or dnf itself. So ideally an offline update mechanism can be added
> to dnf, and then exposed in yumex-dnf. But we may have to consider installing
> PackageKit in those spins. My concern with this is that PackageKit and dnf do
> not share history and many users are used to using dnf.

What about implementing yumex-pk, I mean another tool forked from
yumex but backed by PackageKit, and eventually dropping dnf and
leaving PK as the only tool, both commandline and GUI?

I know we have GNOME Software which already does it but in
more high level and less power user oriented manner.

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org