Re: Use immutable CRAN URLs

[Iñaki Ucar]

Hi Dominik,

On Wed, 31 Oct 2018 at 00:43, Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Tuesday, 30 October 2018 at 16:36, Iñaki Ucar wrote:
> > Kind reminder. Any update on this?
>
> Jason asked you to open a ticket in the Packaging Committee tracker
> and open a pull request against the guidelines. Have you done that?

I thought that the existence of the new macro was a precondition to
open an issue or a PR against the guidelines recommending it. That's
why I wrote the following:

On Wed, 24 Oct 2018 at 17:01, Iñaki Ucar  wrote:
>
> Great. I'll wait for that if you're going to push forward this new macro.

But if you confirm that this is not the case, I certainly
misunderstood Jason's email, so I'll do it right away.

-- 
Iñaki Ucar
___
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: IBM buying RedHat

[Peter Robinson]

On Wed, Oct 31, 2018 at 6:13 AM John Coughlan  wrote:
>
> Yea - Does IBM have any plans on keeping, or discarding any of RH’s open 
> source efforts…like this one? Can we as a community still expect the same 
> sort of, and level of involvement post sale as we have enjoyed before hand 
> from RH/IBM employees?

See the thread on the council list, basically it's too early to tell,
no one is worried as IBM has a long record of embracing open source
and it's way too early to tell, it's not due to close until H2 next
year. See Matthew's response and others. For the time being it's
continue as normal.

> -L0ft
>
> > On Oct 30, 2018, at 12:12 PM, Matthew Miller  
> > wrote:
> >
> > On Sun, Oct 28, 2018 at 07:44:12PM -0400, Neal Gompa wrote:
> >> It'd be nice if someone from up top would deign to come and talk to us
> >> directly...
> >
> > Communications are pretty carefully controlled for regulatory reasons, and
> > the fact is even those at the top don't know everything yet. And speculation
> > is basically right out. That said, I'm working on what I can do here. Are
> > there specific things you'd like to ask?
> >
> > --
> > Matthew Miller
> > 
> > Fedora Project Leader
> > ___
> > 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
> ___
> 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
___
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: Use immutable CRAN URLs

[Jason L Tibbitts III]

I've been trying to stay away from computers for a few days.  Just
catching back up with email.

- J<
___
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: Use immutable CRAN URLs

[Jason L Tibbitts III]

Spent a couple of seconds looking at this and have a couple of
questions.  Once I have answers it should take me only a couple of
minutes to give you something to test.

Does the source URL for CRAN not have any kind of file extension?

Could you provide a couple of sample packages for me to look at and use
in testing?  I don't know much of anything about R.

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

Translating the banner text

[scootergrisen]

During Fedora Workstation 29 installation there are some banners being 
shown like the ones on 
https://fedoraproject.org/wiki/How_to_Create_an_Anaconda_Banner


In the svg code i see some of the banners are translate into multiple 
language.
I would like to translate the banners for a more complete translation of 
the installer but where are the instructions/translations?

___
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: Translating the banner text

[mcatanzaro]

On Wed, Oct 31, 2018 at 10:18 AM, scootergrisen 
 wrote:
During Fedora Workstation 29 installation there are some banners 
being shown like the ones on 
https://fedoraproject.org/wiki/How_to_Create_an_Anaconda_Banner


In the svg code i see some of the banners are translate into multiple 
language.
I would like to translate the banners for a more complete translation 
of the installer but where are the instructions/translations?


Just want to add: the banners don't really look great, and it'd be nice 
to see them removed from the installer (or replaced). First there's the 
hot dog, which is fun but not very professional. Then the Rhythmbox one 
where "Music" gets cut off after "Mus" because the full width of the 
banner is not displayed


Michael
___
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: IBM buying RedHat

[David Sommerseth]

On 31/10/18 06:21, John Coughlan wrote:
> Yea - Does IBM have any plans on keeping, or discarding any of RH’s open 
> source 
> efforts…like this one? Can we as a community still expect the same sort of, 
> and level of 
> involvement post sale as we have enjoyed before hand from RH/IBM employees? 

Even though this is not an official source of any kind, I think the analysis
done here pretty well covers these questions for now:



-- 
kind regards,

David Sommerseth
___
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: Use immutable CRAN URLs

[Jason L Tibbitts III]

Looking at this further, this URL scheme is just terrible and will be
"fun" to make use of.

Basically you have to keep in mind that a tool like spectool can't trust
the filename that is sent by the remote web server and will instead use
only the filename extracted from the URL.

That means if you use something like this:

Source0: https://cran.r-project.org/package=%{packname}&version=%{version}

you'll get a filename like

package=webp&version=0.4

(for a random package, R-webp, that I grabbed).

And that's not a useful filename; rpm won't unpack it.

What you have to do is the somewhat painful:

Source0: 
https://cran.r-project.org/package=%{packname}&version=%{version}#/%{packname}_%{version}.tar.gz

Now, since we're going to hide this behind a macro, it's not the worst
thing in the world.  But it leaves questions:

* Is this guaranteed to continue to work in future?  I don't think that
  the remote host gets the URL fragment identifier at all so I think it
  should be OK, but I haven't really tested that.

* Since we need to know the extension, can we expect tar.gz or are there
  packages with other archive formats?

So, I think we can deal but I don't think CRAN considered this point at
all and that's unfortunate.

 - J<
___
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: Use immutable CRAN URLs

[Iñaki Ucar]

On Wed, 31 Oct 2018 at 18:25, Jason L Tibbitts III  wrote:
>
> Looking at this further, this URL scheme is just terrible and will be
> "fun" to make use of.
>
> Basically you have to keep in mind that a tool like spectool can't trust
> the filename that is sent by the remote web server and will instead use
> only the filename extracted from the URL.
>
> That means if you use something like this:
>
> Source0: https://cran.r-project.org/package=%{packname}&version=%{version}
>
> you'll get a filename like
>
> package=webp&version=0.4
>
> (for a random package, R-webp, that I grabbed).

Correct.

> And that's not a useful filename; rpm won't unpack it.

But that URL, for instance:

https://cran.r-project.org/package=simmer&version=3.0.0

returns a redirection (303) to the complete URL, with file extension.

> What you have to do is the somewhat painful:
>
> Source0: 
> https://cran.r-project.org/package=%{packname}&version=%{version}#/%{packname}_%{version}.tar.gz
>
> Now, since we're going to hide this behind a macro, it's not the worst
> thing in the world.  But it leaves questions:
>
> * Is this guaranteed to continue to work in future?  I don't think that
>   the remote host gets the URL fragment identifier at all so I think it
>   should be OK, but I haven't really tested that.

CRAN maintainers are pretty strict with this kind of stuff: if it
works now, it's guaranteed to continue to work.

> * Since we need to know the extension, can we expect tar.gz or are there
>   packages with other archive formats?

There are no other formats: every package is tar.gz. But, as I pointed
out above, the immutable URL is a redirection to the complete URL, so
you can still extract the extension.

>
> So, I think we can deal but I don't think CRAN considered this point at
> all and that's unfortunate.
>
>  - J<



-- 
Iñaki Ucar
___
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

[Bug 1644619] Upgrade perl-IRI to 0.009

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-IRI-0.009-1.fc28 has been pushed to the Fedora 28 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-3f62e4930b

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-de...@lists.fedoraproject.org

Re: Use immutable CRAN URLs

[Iñaki Ucar]

I missed the example in my last email. Here it is:

$ curl -I "https://cran.r-project.org/package=simmer&version=3.0.0";
HTTP/1.1 303 See Other
Date: Wed, 31 Oct 2018 17:39:46 GMT
Server: Apache/2.4.10 (Debian)
Location: 
https://cran.r-project.org/src/contrib/Archive/simmer/simmer_3.0.0.tar.gz
Content-Type: text/html; charset=iso-8859-1

That was an old version. The newest one:

$ curl -I "https://cran.r-project.org/package=simmer&version=4.0.1";
HTTP/1.1 303 See Other
Date: Wed, 31 Oct 2018 17:40:42 GMT
Server: Apache/2.4.10 (Debian)
Location: https://cran.r-project.org/src/contrib/simmer_4.0.1.tar.gz
Content-Type: text/html; charset=iso-8859-1

On Wed, 31 Oct 2018 at 18:32, Iñaki Ucar  wrote:
>
> On Wed, 31 Oct 2018 at 18:25, Jason L Tibbitts III  wrote:
> >
> > Looking at this further, this URL scheme is just terrible and will be
> > "fun" to make use of.
> >
> > Basically you have to keep in mind that a tool like spectool can't trust
> > the filename that is sent by the remote web server and will instead use
> > only the filename extracted from the URL.
> >
> > That means if you use something like this:
> >
> > Source0: https://cran.r-project.org/package=%{packname}&version=%{version}
> >
> > you'll get a filename like
> >
> > package=webp&version=0.4
> >
> > (for a random package, R-webp, that I grabbed).
>
> Correct.
>
> > And that's not a useful filename; rpm won't unpack it.
>
> But that URL, for instance:
>
> https://cran.r-project.org/package=simmer&version=3.0.0
>
> returns a redirection (303) to the complete URL, with file extension.
>
> > What you have to do is the somewhat painful:
> >
> > Source0: 
> > https://cran.r-project.org/package=%{packname}&version=%{version}#/%{packname}_%{version}.tar.gz
> >
> > Now, since we're going to hide this behind a macro, it's not the worst
> > thing in the world.  But it leaves questions:
> >
> > * Is this guaranteed to continue to work in future?  I don't think that
> >   the remote host gets the URL fragment identifier at all so I think it
> >   should be OK, but I haven't really tested that.
>
> CRAN maintainers are pretty strict with this kind of stuff: if it
> works now, it's guaranteed to continue to work.
>
> > * Since we need to know the extension, can we expect tar.gz or are there
> >   packages with other archive formats?
>
> There are no other formats: every package is tar.gz. But, as I pointed
> out above, the immutable URL is a redirection to the complete URL, so
> you can still extract the extension.
>
> >
> > So, I think we can deal but I don't think CRAN considered this point at
> > all and that's unfortunate.
> >
> >  - J<
>
>
>
> --
> Iñaki Ucar



-- 
Iñaki Ucar
___
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: IBM buying RedHat

[Raphael Groner]

> Yea - Does IBM have any plans on keeping, or discarding any of RH’s open 
> source
> efforts…like this one? Can we as a community still expect the same sort of, 
> and level of
> involvement post sale as we have enjoyed before hand from RH/IBM employees? 
> 
> -L0ft

Although I'm against this topic to get discussed on a development list, my 
interest would be how many stock shares [*} were hold by IBM before the 
announcement of the big merge. It's not commonly known that Red Hat is a 
company listed on stock market, as it turns out again. Significantly much money 
seems to base this company in capitalism.
Come on, new bosses come and go again, as a developer you shouldn't care where 
the money [**] has its sources. Just try to keep the good mindset against this 
still great project and famous community like Fedora obviously is. Or decide to 
leave, it's up to you.
Just my 5ct.
Raphael

[*] https://www.nasdaq.com/de/symbol/rht/stock-chart
[**] https://i.kym-cdn.com/photos/images/original/000/264/241/9e9.gif
___
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: Translating the banner text

[Alessio Ciregia]

On Wed, Oct 31, 2018, 6:55 PM  wrote:

>
> Just want to add: the banners don't really look great, and it'd be nice
> to see them removed from the installer (or replaced). First there's the
>

+1
___
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

Fedora updates-20181031.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/2 (x86_64)

New failures (same test did not fail in updates-20181030.0):

ID: 303943  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/303943
ID: 303944  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303944
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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

Fedora testing-20181031.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/2 (x86_64)

ID: 303945  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/303945
ID: 303946  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303946
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: Use immutable CRAN URLs

[Jason L Tibbitts III]

> "IU" == Iñaki Ucar  writes:

IU> https://cran.r-project.org/package=simmer&version=3.0.0

IU> returns a redirection (303) to the complete URL, with file
IU> extension.

303 is actually "See Other".  Which is odd as that's usually sent in
response to a PUT or POST, not a GET.  Maybe you can get the files via
POST as well; I'm not sure.

In any case, none of that has any effect on the filename that spectool
(really curl) will use.  It can't use data supplied by the remote host
for that, for obvious reasons.

IU> CRAN maintainers are pretty strict with this kind of stuff: if it
IU> works now, it's guaranteed to continue to work.

Well, that's good, but this is a hack so it's not a terrible idea to
inform them that we have to use this kind of thing so that they can
either bless this method or provide a cleaner one.

IU> There are no other formats: every package is tar.gz. But, as I
IU> pointed out above, the immutable URL is a redirection to the
IU> complete URL, so you can still extract the extension.

No, you can't.  Not in the context and under the limitations where we're
running.  Certainly we can't know anything about that in an RPM macro as
we have to provide an extension in a complete vacuum.

But given what you say, certainly defaulting to tar.gz will work for
everything now.

Try dropping the below into /usr/lib/rpm/macros.d/macros.test
(temporarily, make sure to deleted it when you're done experimenting).
See if it gives the results you expect when you use %cran_url and
%cran_source.  Do fedpkg prep or some local builds.  Try spectool -g and
rpmspec -P.

Note that I've snuck a bit of magic in there which I'm not sure should
be kept: If you don't have %packname defined and you call either
%cran_url or %cran_source, then it will be automatically defined for you
by stripping the leading "R-" from the name.

With this, you can just have:

Name: R-webp
Version:  0.4
Release:  3%{?dist}
Summary:  A New Format for Lossless and Lossy Image Compression

License:  MIT
URL:  %cran_url
Source0:  %cran_source

And use %packname in %prep as usual without explicitly defining it.  But
I'm not sure that much magic is a good idea.

(And while we're doing R macros, that package suggests that we should
also have a macro defined to %_libdir/R/library)

- J<

# Macros to replace overly complicated references to CRAN URLs and source files.
# %cran_source -
#   Expands to the CRAN URL for a package
#   Accepts zero to three arguments:
#   1:  The CRAN project name, defaulting to %packname if it is defined.
#   If not, R- will be stripped from %name and %packname defined to that.
#   2:  The CRAN version, defaulting to %version.
#   3:  The file extension, defaulting to %__cran_default_extension (tar.gz).
#   Requires %__cran_package_url_template and %__cran_default_extension to be 
defined.
#   %__cran_package_url_template will undergo substitution (case-sensitive):
#   *  "PACKNAME" will be replaced with the above CRAN project name.
#   *  "PACKVERSION" will be replaced with the above CRAN version.
#   *  "EXTENSION" will be replaced with the above extension.
#
# %cran_url -
#   Expands to the CRAN URL for a package
#   Accepts zero or one arguments:
#   1:  The CRAN project name, defaulting to %packname if it is defined.
#   If not, R- will be stripped from %name and %packname defined to that.
#   Requires %__cran_project_url_template to be defined.
#   %__cran_project_url_template will undergo substitution (case-sensitive):
#   *  "PACKNAME" will be replaced with the above CRAN project name.

%__cran_project_url_template https://cran.r-project.org/package=PACKNAME
%__cran_package_url_template 
%{__cran_project_url_template}&version=PACKVERSION#/PACKNAME_PACKVERSION.EXTENSION
%__cran_default_extension tar.gz

%cran_source() %{lua:
local src = rpm.expand('%1')
local ver = rpm.expand('%2')
local ext = rpm.expand('%3')
local url = rpm.expand('%__cran_package_url_template')
\
-- If no first argument, try %packname, then %name with 'R-' stripped.
-- Note that rpm leaves macros unchanged if they are not defined.
if src == '%1' then
src = rpm.expand('%packname')
end
if src == '%packname' then
src = string.gsub(rpm.expand('%name'), "^R%-", "")
-- Since packname wasn't defined, define it for convenience.
rpm.define("packname " .. src)
end
\
-- If no second argument, use %version
if ver == '%2' then
ver = rpm.expand('%version')
end
\
-- If no third argument, use the preset default extension
if ext == '%3' then
ext = rpm.expand('%__cran_default_extension')
end
\
-- Now substitute in all the values
url = string.gsub(url, "PACKNAME", src)
url = string.gsub(url, "PACKVERSION", ver)
url = string.gsub(url, "EXTENSION", ext)
\
print(url)
}

%cran_url() %{lua:
local src = rpm.expand('%1')
local url = rpm.expand('%__cran_p

Re: Use immutable CRAN URLs

[Iñaki Ucar]

On Wed, 31 Oct 2018 at 19:52, Jason L Tibbitts III  wrote:
>
> > "IU" == Iñaki Ucar  writes:
>
> IU> https://cran.r-project.org/package=simmer&version=3.0.0
>
> IU> returns a redirection (303) to the complete URL, with file
> IU> extension.
>
> 303 is actually "See Other".  Which is odd as that's usually sent in
> response to a PUT or POST, not a GET.  Maybe you can get the files via
> POST as well; I'm not sure.

Why is this odd? It's not "moved", either permanently or temporarily
(301, 302). It clearly matches the "see other" case. 303 was
*primarily* motivated by the POST use case, but I think this is a
pretty fair use.

> In any case, none of that has any effect on the filename that spectool
> (really curl) will use.  It can't use data supplied by the remote host
> for that, for obvious reasons.
>
> IU> CRAN maintainers are pretty strict with this kind of stuff: if it
> IU> works now, it's guaranteed to continue to work.
>
> Well, that's good, but this is a hack so it's not a terrible idea to
> inform them that we have to use this kind of thing so that they can
> either bless this method or provide a cleaner one.

I'll raise the issue in the R-devel mailing list and report back.

> IU> There are no other formats: every package is tar.gz. But, as I
> IU> pointed out above, the immutable URL is a redirection to the
> IU> complete URL, so you can still extract the extension.
>
> No, you can't.  Not in the context and under the limitations where we're
> running.  Certainly we can't know anything about that in an RPM macro as
> we have to provide an extension in a complete vacuum.
>
> But given what you say, certainly defaulting to tar.gz will work for
> everything now.

For what it's worth, this (the extension) is clearly specified in the
"Writing R Extensions" and the "R Installation and Administration"
manuals. It always has been the same, and I'd say it's *extremely*
unlikely to change.

> Try dropping the below into /usr/lib/rpm/macros.d/macros.test
> (temporarily, make sure to deleted it when you're done experimenting).
> See if it gives the results you expect when you use %cran_url and
> %cran_source.  Do fedpkg prep or some local builds.  Try spectool -g and
> rpmspec -P.

Thanks, I'll give it a try and report back.

> Note that I've snuck a bit of magic in there which I'm not sure should
> be kept: If you don't have %packname defined and you call either
> %cran_url or %cran_source, then it will be automatically defined for you
> by stripping the leading "R-" from the name.

This is great. However, in theory, given the naming guidelines, by
stripping the leading "R-" you should get the package name. In
practice, at least one package doesn't adhere to this: R-TH-data,
while the R package name is TH.data, not TH-data. I see that the SPEC
says "# Cannot use . in name", but this is clearly not true (maybe it
was true long ago?).

> With this, you can just have:
>
> Name: R-webp
> Version:  0.4
> Release:  3%{?dist}
> Summary:  A New Format for Lossless and Lossy Image Compression
>
> License:  MIT
> URL:  %cran_url
> Source0:  %cran_source
>
> And use %packname in %prep as usual without explicitly defining it.  But
> I'm not sure that much magic is a good idea.
>
> (And while we're doing R macros, that package suggests that we should
> also have a macro defined to %_libdir/R/library)

That would require a good ton of magic. You have seen something like this:

%global rlibdir   %{_libdir}/R/library

The thing is, this is the path for R packages *with* compiled code,
while R packages *without* compiled code must go to
%_datadir/R/library. That's why every R package has this global on top
of the SPEC. Are you able to detect that and set the path
appropriately with an RPM macro? :) That would certainly be very
convenient for us, packagers.

>
> - J<
>
> # Macros to replace overly complicated references to CRAN URLs and source 
> files.
> # %cran_source -
> #   Expands to the CRAN URL for a package
> #   Accepts zero to three arguments:
> #   1:  The CRAN project name, defaulting to %packname if it is defined.
> #   If not, R- will be stripped from %name and %packname defined to that.
> #   2:  The CRAN version, defaulting to %version.
> #   3:  The file extension, defaulting to %__cran_default_extension (tar.gz).
> #   Requires %__cran_package_url_template and %__cran_default_extension to be 
> defined.
> #   %__cran_package_url_template will undergo substitution (case-sensitive):
> #   *  "PACKNAME" will be replaced with the above CRAN project name.
> #   *  "PACKVERSION" will be replaced with the above CRAN version.
> #   *  "EXTENSION" will be replaced with the above extension.
> #
> # %cran_url -
> #   Expands to the CRAN URL for a package
> #   Accepts zero or one arguments:
> #   1:  The CRAN project name, defaulting to %packname if it is defined.
> #   If not, R- will be stripped from %name and %packname defined to that.

Re: Use immutable CRAN URLs

[Iñaki Ucar]

On Wed, 31 Oct 2018 at 21:22, Iñaki Ucar  wrote:
>
> while the R package name is TH.data, not TH-data. I see that the SPEC
> says "# Cannot use . in name", but this is clearly not true (maybe it
> was true long ago?).

Well... the guidelines for Python state: 'Note that when a module that
has a dot in its name, the usual rule about changing "." to "-"
applies.' But the guidelines for R say nothing about that, and as a
result, most packages with a dot don't change it. Maybe R-TH-data is
the only one that is compliant after all? :)

-- 
Iñaki Ucar
___
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: Use immutable CRAN URLs

[Jason L Tibbitts III]

> "IU" == Iñaki Ucar  writes:


IU> This is great. However, in theory, given the naming guidelines, by
IU> stripping the leading "R-" you should get the package name. In
IU> practice, at least one package doesn't adhere to this: R-TH-data,
IU> while the R package name is TH.data, not TH-data. I see that the SPEC
IU> says "# Cannot use . in name", but this is clearly not true (maybe it
IU> was true long ago?).

Why is that a problem?  You would just define %packname in that case and
nothing changes.

Look for the 50% case.  Does it simplify at least half of the packages
while not making things harder for the rest?  I don't know the answer
but I would be surprised if it wasn't 'yes' even if you change 50% to
90%.

IU> That would require a good ton of magic. You have seen something like
IU> this:

IU> %global rlibdir %{_libdir}/R/library

IU> The thing is, this is the path for R packages *with* compiled code,
IU> while R packages *without* compiled code must go to
IU> %_datadir/R/library. That's why every R package has this global on
IU> top of the SPEC.

Well, what you'd generally do is simply use a different macro for the
noarch location and the arch-specific location.  So you'd one defined
macro for things under libdir, another macro for things under
datadir.  Like Perl and Python and such do.

If you really wanted to get down into it, it's tough to magically define
a macro depending on BuildArch (though I could be missing a trick) but
ou could conceivably have macros like %r_archful_package and
%r_noarch_package.

They could some macro like your %rlibdir and also take care of adding
the build dependencies and (where needed) the BuildArch: line and the
R-core dependency.  There's really a whole lot you could do, down to
having macros used in %install, adding that annoying empty %build
section, even generating a file list so you don't have to manually list
so much in %files.

It depends on how far you want to go, and how specific you can be before
you're not actually simplifying a majority of the R packages we have.

 - J<
___
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: Use immutable CRAN URLs

[Iñaki Ucar]

On Wed, 31 Oct 2018 at 21:48, Jason L Tibbitts III  wrote:
>
> > "IU" == Iñaki Ucar  writes:
>
>
> IU> This is great. However, in theory, given the naming guidelines, by
> IU> stripping the leading "R-" you should get the package name. In
> IU> practice, at least one package doesn't adhere to this: R-TH-data,
> IU> while the R package name is TH.data, not TH-data. I see that the SPEC
> IU> says "# Cannot use . in name", but this is clearly not true (maybe it
> IU> was true long ago?).
>
> Why is that a problem?  You would just define %packname in that case and
> nothing changes.
>
> Look for the 50% case.  Does it simplify at least half of the packages
> while not making things harder for the rest?  I don't know the answer
> but I would be surprised if it wasn't 'yes' even if you change 50% to
> 90%.

Don't get me wrong: I'm totally in with this change. I was just
putting all the information on the table. And I'd be surprised if it
wasn't "yes" for less than 95%. :)

> IU> That would require a good ton of magic. You have seen something like
> IU> this:
>
> IU> %global rlibdir %{_libdir}/R/library
>
> IU> The thing is, this is the path for R packages *with* compiled code,
> IU> while R packages *without* compiled code must go to
> IU> %_datadir/R/library. That's why every R package has this global on
> IU> top of the SPEC.
>
> Well, what you'd generally do is simply use a different macro for the
> noarch location and the arch-specific location.  So you'd one defined
> macro for things under libdir, another macro for things under
> datadir.  Like Perl and Python and such do.
>
> If you really wanted to get down into it, it's tough to magically define
> a macro depending on BuildArch (though I could be missing a trick) but
> ou could conceivably have macros like %r_archful_package and
> %r_noarch_package.
>
> They could some macro like your %rlibdir and also take care of adding
> the build dependencies and (where needed) the BuildArch: line and the
> R-core dependency.  There's really a whole lot you could do, down to
> having macros used in %install, adding that annoying empty %build

That is quite annoying, yes. :)

> section, even generating a file list so you don't have to manually list
> so much in %files.
>
> It depends on how far you want to go, and how specific you can be before
> you're not actually simplifying a majority of the R packages we have.
>
>  - J<

-- 
Iñaki Ucar
___
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

Latest RHEL7 release v Xorg

[Bojan Smojver]

With RHEL 7.6 out, a new version of Xorg has been delivered, which made 
xorgxrdp package that I maintain binary incompatible. Given that build 
overrides are not possible with EPEL (AFAIK), could someone with enough 
privileges please update the build environment for rhel7.

Thanks,
-- 
Bojan
___
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

Schedule for Thursday's FPC Meeting (2018-11-01 16:00 UTC)

[James Antill]

  Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-11-01 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.


  Local time information (via. uitime):

= Day: Thursday ==
2018-11-01 09:00 PDT  US/Pacific
2018-11-01 12:00 EDT  --> US/Eastern <--
2018-11-01 16:00 GMT  Europe/London 
2018-11-01 16:00 UTC  UTC   
2018-11-01 17:00 CET  Europe/Berlin 
2018-11-01 17:00 CET  Europe/Paris  
2018-11-01 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2018-11-02 00:00 HKT  Asia/Hong_Kong
2018-11-02 00:00 +08  Asia/Singapore
2018-11-02 01:00 JST  Asia/Tokyo
2018-11-02 02:00 AEST Australia/Brisbane


  Links to all tickets below can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting


= Followups =

#topic #719 Simplify packaging of forge-hosted projects
.fpc 719
https://pagure.io/packaging-committee/issue/719

= Open Floor =

  For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

  If you would like to add something to this agenda, you can:
   * Reply to this e-mail
   * File a new ticket at: https://pagure.io/packaging-committee
   * E-mail me directly
   * Bring it up at the end of the meeting, during the open floor topic.
 Note that added topics may be deferred until the following meeting.
___
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 updates-20181031.0 compose check report

[Adam Williamson]

On Wed, 2018-10-31 at 18:33 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 2/2 (x86_64)
> 
> New failures (same test did not fail in updates-20181030.0):
> 
> ID: 303943Test: x86_64 AtomicHost-dvd_ostree-iso install_default
> URL: https://openqa.fedoraproject.org/tests/303943
> ID: 303944Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/303944

This seems to be the same failure Rawhide is running into - installer
image booting to a cursor on a black background, but no anaconda. Might
help figure out what's causing it, now we have two releases to compare.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Enabling powerline theme system wide by default

[Luya Tshimbalanga]

It will be nice to enable powerline theme by default system and user
wide. Simple reason is refresh the look of terminal while also providing
useful information especially for git branch. Since powerline does not
impact the performance, it will be great to set for Fedora 30.

Comments welcome.

Luya




signature.asc
Description: OpenPGP digital signature
___
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: Use immutable CRAN URLs

[Jason L Tibbitts III]

> "JLT" == Jason L Tibbitts  writes:

JLT> It depends on how far you want to go, and how specific you can be
JLT> before you're not actually simplifying a majority of the R packages
JLT> we have.

Just for fun I took the R-webp package and constructed a macro that
generates most of the package.  Obviously it's somewhat bound to this
specific package, but it appears that most R packages have rather
similar boilerplate so it might be more generally useful.  It's just a
hack but it seems like it might be interesting to explore this a bit.
The technique should still apply to package sets which have significant
uniformity.

The spec looks like:
-
Name: R-webp
Version:  0.4
Release:  3%{?dist}
Summary:  A New Format for Lossless and Lossy Image Compression

License:  MIT
URL:  %cran_url
Source0:  %cran_source

Suggests: R-jpeg R-png

BuildRequires:libwebp-devel
BuildRequires:R-jpeg R-png

%description
Lossless webp images are 26% smaller in size compared to PNG. Lossy webp
images are 25-34% smaller in size compared to JPEG. This package reads and
writes webp images into a 3 (rgb) or 4 (rgba) channel bitmap array using
conventions from the 'jpeg' and 'png' packages.

%r_simple_archful_package

%files -f %packname.files

%changelog
-

This builds fine and produces the same output as the current spec in
git.  I could go even further and not have the %files section at all,
really.

I don't really know how useful this would be.  I know (from another
package I glanced at) that applying patches seems to be a bit weird
because of the directory structure, so maybe using %autosetup isn't the
right way to go.  But I could still easily duplicate the patch
application part of %autosetup.  And the auto file-list generation
stuff could easily grow smarts to handle other cases.

The macros, which you can drop temporarily in /usr/lib/rpm/macros.d for
testing, follow.  These aren't "complete" and you still need the other
macros I posted earlier.  You can cram them together in one file if you
like.

 - J<

# The basic sections
%r_prep %{lua:\
local packname = rpm.expand('%packname')
local autosetup = rpm.expand("%{autosetup -c -n " .. packname .. "}")
\
print(autosetup .. "\\\n")
}

%r_install %{lua:\
local rlibdir = rpm.expand('%rlibdir')
local bindir = rpm.expand('%_bindir')
local packname = rpm.expand('%packname')
local buildroot = rpm.expand('%buildroot')
\
-- A function to simplify adding to the file list
local function add_file(file, type)
print("echo '")
if (type ~= nil) then
print("%" .. type .. " ")
end
print(rlibdir .. "/" .. packname)
if (file ~= nil) then
print("/" .. file)
end
print("' >> " .. packname .. ".files\\\n")
end
\
print("mkdir -p " .. buildroot .. rlibdir .. "\\\n")
print(bindir .. "/R CMD INSTALL -l " .. buildroot .. rlibdir .. " " .. 
packname .. "\\\n")
print("test -d " .. packname .. "/src && (cd " .. packname .. "/src; rm -f 
*.o *.so)\\\n")
print("rm -f " .. buildroot .. rlibdir .. "/R.css\\\n")
\
-- R packages have a somewhat regularlized file structure
-- This could be pushed out to a shell script and called like %find_lang is
-- called.  But for now we'll just inline the code.
print("\\\n# Generate a default file list\\\n")
add_file(nil, "dir")
add_file("html/", "doc")
add_file("libs", "dir")
add_file("libs/" .. packname .. ".so")
add_file("DESCRIPTION")
add_file("LICENSE", "license")
add_file("NEWS", "doc")
add_file("INDEX")
add_file("NAMESPACE")
add_file("Meta/")
add_file("R/")
add_file("help/")
\
print("ls -lR " .. buildroot .. "\\\n")
}

%r_check %{lua:\
local bindir = rpm.expand('%_bindir')
local packname = rpm.expand('%packname')
\
print(bindir .. "/R CMD check " .. packname .. "\\\n")
}

# For noarch packages
%r_noarch_package %{lua:\
print("BuildArch: noarch\\\n")
print("Requires: R-core\\\n")
print("BuildRequires: R-devel tex(latex)\\\n")
rpm.define("rlibdir  %{_datadir}/R/library")
print("%build\\\n\\\n")
}

%r_archful_package %{lua:\
print("BuildRequires: R-devel tex(latex)\\\n")
rpm.define("rlibdir  %{_libdir}/R/library")
print("%build\\\n\\\n")
}

%r_simple_archful_package %{lua:\
print(rpm.expand("%r_archful_package"))
\
local prep = rpm.expand("%r_prep")
print("%prep\\\n")
print(prep .. "\\\n\\\n")
\
-- Hack around bizarre redefinition of %install.
local pre_install = 
rpm.expand('%{?_enable_debug_packages:%{debug_package}}')
print(pre_install .. "\\\n")
\
local install = rpm.expand('%r_install')
print("%install\\\n")
print(install .. "\\\n\\\n")
\
local check = rpm.expand('%r_check')
print("%check\\\n")
print(check .. "\\\n\\\n")
\
-- We could even add the files section here, but this needs mag

Re: Latest RHEL7 release v Xorg

[Orion Poplawski]

On 10/31/2018 04:13 PM, Bojan Smojver wrote:

With RHEL 7.6 out, a new version of Xorg has been delivered, which made 
xorgxrdp package that I maintain binary incompatible. Given that build 
overrides are not possible with EPEL (AFAIK), could someone with enough 
privileges please update the build environment for rhel7.

Thanks,



First off, EPEL development questions should go to epel-devel.  Second, 
buildroot overrides are possible, but I don't think you need one. 
RHEL7.6 has been imported into the epel7 buildroots so you just need to 
rebuild your package - unless there are other dependencies that need to 
get rebuilt first.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
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: Use immutable CRAN URLs

[Jason L Tibbitts III]

And with some tweaks to the macro file (current version at
https://www.math.uh.edu/~tibbs/fedora/macros.test) and the R-uuid
package is reduced to the following.  Not quite as simple, but it shows
how you can still split out the individual sections when you need to add
something, and also cope with a difficult version number.  (I switched
the argument order around for %cran_source.)

Sadly you still need %build if not using %r_simple_archful_package.  I
could explain why but

Name: R-uuid
Version:  0.1.2
Release:  6%{?dist}
Summary:  Tools for generating and handling of UUIDs

License:  MIT
URL:  %cran_url
Source0:  %cran_source 0.1-2

BuildRequires:libuuid-devel

%description
Tools for generating and handling of UUIDs (Universally Unique
Identifiers).

%r_archful_package

%prep
%r_prep

pushd %{packname}
rm configure.ac configure src/Makevars.in src/[a-z]*.[ch]
sed -i -e '/configure/d' -e '/Makevars/d' -e '/src\/[a-z].*.[ch]/d' MD5
rm -r src/config.h.in src/win32
sed -i -e '/config.h/d' MD5
cat > src/Makevars << EOF
PKG_CFLAGS = \$(shell pkg-config --cflags uuid)
PKG_LIBS = \$(shell pkg-config --libs uuid)
EOF
popd

%build

%install
%r_install

%check
%r_check

%files -f %packname.files

%changelog
___
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: Latest RHEL7 release v Xorg

[Bojan Smojver]

Noted and thanks.

-- 
Bojan


 Original Message 
From: Orion Poplawski 
Sent: 1 November 2018 1:17:11 pm AEDT
To: Development discussions related to Fedora , 
Bojan Smojver 
Subject: Re: Latest RHEL7 release v Xorg

On 10/31/2018 04:13 PM, Bojan Smojver wrote:
> With RHEL 7.6 out, a new version of Xorg has been delivered, which made 
> xorgxrdp package that I maintain binary incompatible. Given that build 
> overrides are not possible with EPEL (AFAIK), could someone with enough 
> privileges please update the build environment for rhel7.
> 
> Thanks,
> 

First off, EPEL development questions should go to epel-devel.  Second, 
buildroot overrides are possible, but I don't think you need one. 
RHEL7.6 has been imported into the epel7 buildroots so you just need to 
rebuild your package - unless there are other dependencies that need to 
get rebuilt first.

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
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: Use immutable CRAN URLs

[Elliott Sales de Andrade]

On Wed, Oct 31, 2018, 5:01 PM Iñaki Ucar  On Wed, 31 Oct 2018 at 21:48, Jason L Tibbitts III 
> wrote:
> >
> > > "IU" == Iñaki Ucar  writes:
> >
> >
> > IU> This is great. However, in theory, given the naming guidelines, by
> > IU> stripping the leading "R-" you should get the package name. In
> > IU> practice, at least one package doesn't adhere to this: R-TH-data,
> > IU> while the R package name is TH.data, not TH-data. I see that the SPEC
> > IU> says "# Cannot use . in name", but this is clearly not true (maybe it
> > IU> was true long ago?).
> >
> > Why is that a problem?  You would just define %packname in that case and
> > nothing changes.
> >
> > Look for the 50% case.  Does it simplify at least half of the packages
> > while not making things harder for the rest?  I don't know the answer
> > but I would be surprised if it wasn't 'yes' even if you change 50% to
> > 90%.
>
> Don't get me wrong: I'm totally in with this change. I was just
> putting all the information on the table. And I'd be surprised if it
> wasn't "yes" for less than 95%. :)
>

All my packages were created using R2spec, so they would all use
%{packname}. I would guess that most packages used the generator as well.

> IU> That would require a good ton of magic. You have seen something like
> > IU> this:
> >
> > IU> %global rlibdir %{_libdir}/R/library
> >
> > IU> The thing is, this is the path for R packages *with* compiled code,
> > IU> while R packages *without* compiled code must go to
> > IU> %_datadir/R/library. That's why every R package has this global on
> > IU> top of the SPEC.
> >
>

This can be determined from the NeedsCompilation key in the DESCRIPTION
file, which is what (my fork of) R2spec does.

> Well, what you'd generally do is simply use a different macro for the
> > noarch location and the arch-specific location.  So you'd one defined
> > macro for things under libdir, another macro for things under
> > datadir.  Like Perl and Python and such do.
> >
> > If you really wanted to get down into it, it's tough to magically define
> > a macro depending on BuildArch (though I could be missing a trick) but
> > ou could conceivably have macros like %r_archful_package and
> > %r_noarch_package.
> >
> > They could some macro like your %rlibdir and also take care of adding
> > the build dependencies and (where needed) the BuildArch: line and the
> > R-core dependency.  There's really a whole lot you could do, down to
> > having macros used in %install, adding that annoying empty %build
>
> That is quite annoying, yes. :)
>
> > section, even generating a file list so you don't have to manually list
> > so much in %files.
> >
>

Basically anything under %{rlibdir}%{packname} is needed and nothing
appears elsewhere. If we didn't need to mark doc and license files, we
could have just specified that top-level directory. The hard part about
that is the naming is pretty inconsistent. Because CRAN disallows providing
the full license text in LICENSE, upstreams that want to follow the terms
of the license will put it in a separate file and the name is never the
same.

> It depends on how far you want to go, and how specific you can be before
> > you're not actually simplifying a majority of the R packages we have.
>

In the same way Go has moved to mostly generated, I think R can mostly get
away with this as well. We can get most of the information from the
DESCRIPTION file or re-write R2spec to output what we need. I don't really
know how macros work or I might have attempted this earlier.


> >  - J<
>
> --
> Iñaki Ucar
>
___
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: Nonresponsive maintainer: Björn Esser (besser82)

[Jan Pokorný]

On 27/08/18 08:41 +0200, Matthias Runge wrote:
> On Fri, Aug 17, 2018 at 03:48:12PM +0200, Bob Mauchin wrote:
>> On Fri, Aug 17, 2018, 12:53 Leigh Scott 
>> wrote:
>> 
>>> Besser82 hasn't answered  any of my emails for months.
>>> 
>> 
>> I saw him back in May for a couple of reviews, maybe he's in holidays.
>> 
> 
> I briefly contacted Björn, and he promised to get back here.

Any signs of his activity, yet?

I'd be interested in (co)maintenance of one of his packages,
tried contacting him over email (less than a day ago), then 
realized I could check this ML.

-- 
Jan (Poki)


pgprFqIZRBLio.pgp
Description: PGP signature
___
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