[F29 only] Dropping requirements for initscripts package from specfiles
Hello people, I'm working on making Fedora being able to function completely without the 'initscripts' package (hopefully) some day in the future. I have done some cleanup in initscripts recently, and I would like to ask maintainers of packages listed below to check if their package(s) still really need the initscripts package to function properly (for any reason). It seems that for many packages the requirement of initscripts is just a leftover from past. If the package does not need the initscripts any longer, please remove the requirement in Rawhide (F29) and forward. (Do not backport this change into F28 or F27, it would break things.) NOTE: In case you are depending on initscripts because of networking scripts (ifup/ifdown, etc.), then you will need to update your specfile to depend directly on new package 'network-scripts' (instead of 'initscripts'). I've opened bug reports for each of the packages listed here, and created a tracking BZ for it: https://bugzilla.redhat.com/show_bug.cgi?id=1592330 List of packages still depending on initscripts (some of them were already fixed): 3proxy barry boomaga-selinux Canna clamsmtp conmux crossfire-selinux cyphesis device-mapper-multipath dpm-xrootd ebnetd-common exim exim-clamav foghorn freeipa-client glpi groonga-munin-plugins groonga-server-gqtp iipsrv isdn4k-utils kbd libstoragemgmt mailman-3 nightview-server node ntop numad omniORB openslp-server os-net-config pcp pcsc-cyberjack pgbouncer plymouth ppp pure-ftpd-selinux ratbox-services sagator-core spacewalk-config spamassassin spawn-fcgi sslogger systemtap-initscript systemtap-server tigervnc-server-minimal torque-mom torque-scheduler torque-server trafficserver varnish vdsm vhostmd vpnc vte vte291 vte3 wine-desktop xboxdrv Thank you, and best regards! :) David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ 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/MRI2HG2WTDJ2BGZTZMZ3JLUMKGEFWM6P/
Re: What services / tools still require NIS domain?
Thank you all for you replies, it helped a lot! :) On Thu, May 17, 2018 at 1:54 AM, Ian Kent wrote: > On 16/05/18 23:17, David Kaspar [Dee'Kej] wrote: > > On Wed, May 16, 2018 at 5:07 PM, Stephen Gallagher <mailto:sgall...@redhat.com>> wrote: > > > > I don't think SSSD or FreeIPA *require* it. They offer netgroup > functionality that can be used with it. Maybe I misunderstood your > question? Are you just asking which things in the distro interact with NIS > domains at all? > > > > Perhaps it would be better if you explained the rationale for the > question. For example, are you trying to figure out if we can remove all of > NIS from the distro? > > > > > > Sorry, I don't know much about NIS. I was coming out from what I've > been told. > > I think you'll find NIS is still quite widely used. > > NIS Plus was an attempt to improve NIS but (AFAIK) it never became widely > used. > LDAP is another attempt to provide much of the table information provided > by NIS > but it is far more complicated to administer. > > NIS remains the simplest and easiest way to centrally manage (key, value) > stores > such as password, group, netgroup, hosts etc. so it has endured. > > Automount maps are another (key, value) store that can be centrally > managed by > NIS and there are still a surprising number of autofs users that continue > to > use it. > > > > > I'm trying to figure out, which application / tool / service still > actually need the fedora-domainname.service to be present in Fedora in > order to function correctly? > > The question is kind-off ambiguous. > > It's not so much applications that need the service but rather services > that can utilize the (key, value) information stored in NIS tables for the > functionality they provide that need the NIS domain to be set. > > For example autofs can use NIS as an automount map source but it doesn't > depend on NIS, it can also use automount maps stored in files, LDAP, sss > etc. > > Ian > ___ 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/UJQMCAUCS3JSVE7IDSO7OPOUURGWH5XX/
Re: What services / tools still require NIS domain?
On Wed, May 16, 2018 at 5:07 PM, Stephen Gallagher wrote: > I don't think SSSD or FreeIPA *require* it. They offer netgroup > functionality that can be used with it. Maybe I misunderstood your > question? Are you just asking which things in the distro interact with NIS > domains at all? > > Perhaps it would be better if you explained the rationale for the > question. For example, are you trying to figure out if we can remove all of > NIS from the distro? > Sorry, I don't know much about NIS. I was coming out from what I've been told. I'm trying to figure out, which application / tool / service still actually need the fedora-domainname.service to be present in Fedora in order to function correctly? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
What services / tools still require NIS domain?
Hello people, I would like to know if you know about any service / tool / application that still relies on NIS domain to be set in Fedora? So far, I know only about SSSD/FreeIPA relying on it. Does anybody know anything else? All replies are welcome. :) Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /etc/profile.d/lang.sh -- still needed?
On Tue, May 15, 2018 at 3:46 PM, R P Herrold wrote: > If you wish to 'clean out' initscripts, migrate the content > into the relevant bash, and tcsh packages, and be done with it > Yeah, you're right. Good point. Though I would prefer these scripts be moved into 'setup' package instead, so they stay together for easier maintenance, and because the functionality of lang.sh is not used just by bash, but other shells can use it as well. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /etc/profile.d/lang.sh -- still needed?
On Tue, May 15, 2018 at 3:30 PM, Akira TAGOH wrote: > how/what does those scripts "block"? > Right now, it depends on the "/usr/sbin/consoletype", which is also part of initscripts. I hope it will be possible to just switch it to "tty" utility instead, so the dependency on initscripts can be completely broken. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /etc/profile.d/lang.sh -- still needed?
On Tue, May 15, 2018 at 9:45 AM, Akira TAGOH wrote:
> On Tue, May 15, 2018 at 12:41 AM, David Kaspar [Dee'Kej]
> wrote:
> > My question was more meant in a sense "are those files still necessary"?
> :)
> > I expect they were created to deal with some problems with locale
> setting,
> > but from just looking into them it's hard for me to guess what the
> initial
> > purpose of them were... :)
>
> That is used to set up the user specific locale settings. is there any
> alternatives to take care of them instead of
> /etc/profile.d/lang.{sh,csh} ?
>
No that I'm aware of
, unfortunately.
I still get the feeling like we are not totally sure these scripts are
still needed nowadays. Do you think it would be too much dangerous to test
if we need still those files in Fedora via the System-wide Change? (I.e. do
the change in rawhide, see if it breaks something. fallback if necessary.)
It could at least tell us the current state of things, and maybe create a
plan on how to fix things, so they could be eventually removed at some
point.
In any case I would like to find a new home for these scripts, so they
don't "block" other work on initscripts package. And if it would turned out
we can't remove those scripts yet, at least to do some cleanup in those
scripts if possible.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /etc/profile.d/lang.sh -- still needed?
On Mon, May 14, 2018 at 5:27 PM, R P Herrold wrote:
> On Mon, 14 May 2018, David Kaspar [Dee'Kej] wrote:
>
> > does anybody know if the files /etc/profile.d/lang.{csh,sh} are still
> used
> > these days, and what for?
>
> by their terms, they are a collection of I18N and environment
> settings.
>
My question was more meant in a sense "are those files still necessary"?
:) I expect they were created to deal with some problems with locale
setting, but from just looking into them it's hard for me to guess what the
initial purpose of them were... :)
> > Do we still need them in Fedora?
>
> Are you asking if /bin/sh, and /bin/tcsh are still installed
> or used? I certainly install ande use each
>
Let me rephrase - if those files are gone completely, will it break
anything? Isn't the functionality of those scripts obsolete nowadays?
> > Should they be installed by default these days?
>
> One assumes the files could be moved out to 'bash' and 'tcsh'
> packagings, if the (unstated) goal is to eliminate
> 'initscripts' as a standalone package
>
I'd like to remove them completely if possible, but I don't want to break
anything for our users. That's why I would like to know the initial
purpose of those files, and if they are still really needed nowadays... :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
/etc/profile.d/lang.sh -- still needed?
Hello people,
does anybody know if the files /etc/profile.d/lang.{csh,sh} are still used
these days, and what for?
Do we still need them in Fedora?
Should they be installed by default these days?
Any info is appreciated! :)
David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP - Changes to Ghostscript package in F28
Hello guys, and sorry for the delay - I've got caught in my other responsibilites. I have created the Wiki page for this change, as requested: https://fedoraproject.org/wiki/Changes/GhostscriptPackageUpdate28 To comply with the guidelines there, I had to categorize this as a "system-wide change" though. The pull-requests to update specfiles for all the dependant packages have been already submitted. Some of them were already accepted. You can see the progress in this tracking BZ: https://bugzilla.redhat.com/ show_bug.cgi?id=1534638 The mass rebuild of F28 is done, and I'm aware only about one FTBFS related to these changes: https://bugzilla.redhat.com/show_bug.cgi?id=1535860 (upstream is already aware of this issue) Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP - Changes to Ghostscript package in F28
Hello guys! I wanted to let you know I have decided to create additional subpackage 'ghostscript-tools-dvipdf' after some discusssions. It is because the 'dvipdf' tool requires 'dvips' utility to work correctly, which is provided in 'texlive-dvips' subpackage. This resulted in lot of texlive packages being pulled in as a dependency of 'ghostscript' where the 'dvipdf' tool initially was. However, many of our users might not need the 'dvipdf' tool nor the texlive itself. This change might cause some inconvenience to some users, but for most of the people it should save them some disk space when they don't need the texlive installed. Also, the new 'ghostscript-tools-dvipdf' subpackage is not required by 'ghostscript-core' meta subpackage. This will ensure that users doing upgrade to F28 will not get texlive automatically installed in case they didn't have it before. On Wed, Jan 17, 2018 at 4:01 PM, Michael Cronenworth wrote: > On 01/09/2018 04:51 PM, David Kaspar [Dee'Kej] wrote: > >> Initial NOTE: I have made some bigger changes in Ghostscript package >> during the cleanup, which should be self-contained. In my opinion those >> changes are not so significant to create "self-contained change" wiki page >> for it (for F28), but if the consensus of people here will be the opposite, >> then I will create it additionally... >> > > You should create a change request for this. It's very significant, IMHO. > OK, I'll start working on that once I all the necessary packages in the tracking BZ. > I've encountered a problem with this change. ImageMagick tests require the > 'gs_resmp.ps' resource file to be around, but I cannot find where this > file lives now. Where is it now? > The file is generally located in Resource/Init folder of Ghostscript. As I mentioned before, the version of the Ghostscript is no longer part of this path: /usr/share/ghostscript/*9.22*/Resource/Init/gs_resmp.ps ->> /usr/share/ghostscript/Resource/Init/gs_resmp.ps It is part of the 'libgs' package now: https://koji.fedoraproject.org/koji/fileinfo?rpmID=12537549&filename=/usr/share/ghostscript/Resource/Init/gs_resmp.ps ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP - Changes to Ghostscript package in F28
On Wed, Jan 10, 2018 at 7:50 PM, Adam Williamson wrote: > On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote: > > On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote: > > > The new Ghostscript should be available for trying/testing in Rawhide > in a > > > few hours. I will follow up with additional information (e.g. tracking > BZ > > > link) here in this thread. > > > > It would be better to create a Copr for testing purposes to avoid > disruption > > of Fedora development. > > +1 (or a tag). Lots of stuff hangs off of ghostscript. It'd be nice to > have the implications of this at least broadly figured out in advance > rather than "doing it live" in Rawhide. > I was trying to make the F28 planning phase deadline, in case people would require to create System-wide / Self-contained change wiki page for it. In the rush I didn't think of your point, and automatically submitted 'fedpkg build'. But I agree with your point. I will try to be more aware of this in the future, to not repeat this mistake again. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP - Changes to Ghostscript package in F28
On Wed, Jan 10, 2018 at 3:44 PM, Neal Gompa wrote:
> If the content of "ghostscript-core" is now part of "ghostscript", you
> can do the following:
>
> Obsoletes: ghostscript-core < 9.22-5
> Provides: ghostscript-core = %{version}-%{release}
>
> In addition, packages that currently require "ghostscript-core" can
> and should be fixed for Fedora 28. In my view, there's nothing that
> necessitates this metapackage for a development branch.
>
> If this was going into Fedora 27, for example, then sure, it makes sense.
>
Unfortunately in the current situation, it's not that simple... :-/ Let me
try to explain:
In the context of changes mentioned here (package layout change,
software/resources debundling) specifying Obsoletes/Provides as you
mentioned above for 'ghostscript' (or any other subpackage) wasn't enough.
As I said before, the 'ghostscript-core' contained almost everything from
Ghostscript's build, and 'ghostscript' was an empty metapackage, requiring
'ghostscript-core', 'ghostscript-x11'.
If I would specify the Obsoletes/Provides inside 'ghostscript' package as
you suggest, then the 'ghostscript' package would still miss some scripts
that are now in separate subpackages (*-tools-*). It could lead to people
complaining (in BZs, mailing list) about missing scripts after upgrade to
F28 (the scripts would have been uninstalled during upgrade in this way).
I'm trying to avoid any disturbance to our users that could generally lead
to negative feelings about our distribution.
In order to have the scripts kept during the upgrade, then I would have to
specify additional requirements in 'ghostscript' package for the
'ghostscript-tools-*' subpackages. However, this would create again the
problem I was trying to solve in the first place (to have more granular
package layout), and 'ghostscript' package itself would just become "new"
'ghostscript-core'. I.e., the contents would have been moved from
'ghostscript-core' into 'ghostscript', which is not exactly what I wanted.
:)
So right now, none of the (sub)package has Obsoletes/Provides/Requires for
'ghostscript-core'. Instead, I kept the 'ghostscript-core' with
requirements on 'libgs', 'ghostscript', 'ghostscript-tools-*'. This way the
'ghostscript-core' will not be installed automatically on fresh F28
installations, but for users upgrading from previous version to F28, it
will kept the Ghostscript scripts installed.
My plan is to remove the 'ghostscript-core' once F28 has reached EOL. I
realize now that this might influence the users doing the upgrade anyway
(the 'ghostscript-tools-*' might get uninstalled during upgrade and some of
them might be missing them). But before I need to deal with this, I want to
make sure other packages requiring Ghostscript are fixed first. To kind of
grind the huge change into a smaller chunks of changes, if possible. :)
I'm sorry if my explanation does not make sense. :-/ If that's the chase,
then it might be better to look in the specfile at the package layout (and
dependencies) before and after the change. (
https://src.fedoraproject.org/rpms/ghostscript)
> Okay, this makes sense. I'm a bit disappointed that we couldn't have
> the conf.d thing upstreamed, but we'll see how it goes...
>
Generally it's hard to get something upstreamed unless they have any
benefit from it. I had really hard times trying to convince them to create
a new Github repository for 'urw-base35-fonts' and accepting the AppStream
and fontconfig configuration files there.
For upstream accepting something might mean additional maintenance work,
and they are (understandably) trying to avoid it. :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP - Changes to Ghostscript package in F28
On Wed, Jan 10, 2018 at 3:30 PM, David Kaspar [Dee'Kej] wrote: > I hope I didn't forget to mention something important... :D If something > is unclear, lay it on me! ;) > Yeah, I forgot one more small thing to mention... :D For now I'm waiting for 'google-droid-fonts' to be rebased to latest version, to make sure that the upstream's default solution for CJK-based documents missing embedded fonts is up-to-date. (https://bugzilla.redhat.com/show_bug.cgi?id=1532523) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP - Changes to Ghostscript package in F28
On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa wrote:
> Is there a specific bug that forces us to require we have transitional
> packages like this? RPM's Conflicts+Obsoletes logic is powerful enough
> to allow us to avoid this.
>
I'm not aware of any BZ/Fedora wiki page that is requiring this. This
solution was based solely on my best judgment. To clarify on this:
The 'ghostscript-core' is a "main" subpackage in previous subpackage
scheme. It basically contained almost everything from Ghostscript's
compilation, and IIRC few of other packages were requiring this package
directly in their specfiles...
Other packages were not yet updated to requires correct subpackage from new
subpackage layout. Therefore I decided to transform 'ghostscript-core' into
auxiliary subpackage, since it was already there.
This should have allowed new Ghostscript to be rolled out without breaking
build process for them (hopefully completely, or at least it should at
mitigate most of the problems). And the other packages can be then rebuild
immediately once their requirements have been appropriately updated. :)
Why are examples not shipped? For documentation, this seems to be
> fine, especially since it's a separate subpackage anyway.
>
Upstream has decided to drop the examples/ completely from the next
version of Ghostscript release (9.23). According to them those files are
more useful for testing purposes rather than actual examples, and those
files are poorly written PostScript files. They wouldn't help people who
would like to learn how to write PostScript documents. That's why upstream
does not want to ship those files anymore.
Since I was doing changes to contents/layout of Ghostscript, I thought it
was a good time to incorporate this change into the package already.
> > * Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
> > Ghostscript's default choice for rendering of CJK glyphs, which is Google
> > Droid Sans Fallback font. In case this proves insufficient, the conf.d/
> > folder support will be re-established.
> >
> > ->> This change is still being discussed with Peng Wu and Akira Tagoh. So
> > far, we have agreed to this change, but I will be ready to revert it in
> case
> > people depending on printing CJK-based texts will have any problems. In
> case
> > the Ghostscript's default functionality would prove to be sufficent and
> work
> > OK, then the 'ghostscript-chinese' package could be retired as a result.
> > ->> For now, we are also waiting for rebase of 'google-droid-fonts' for
> > Ghostscript to have the latest version of Droid Sans Fallback font and
> thus
> > the latest CJK glyphs coverage.
> >
>
> I'm confused why we would drop support for conf.d directories. Unless
> it's completely unavoidable, I don't see why we would do this. We
> can't possibly know of everyone who might be using them, and generally
> speaking, I'd like to see more software configurable this way, not
> less.
>
The folder /usr/share/ghostscript/conf.d/ actually comes from the package
'ghostscript-chinese'. Ghostscript itself was just configured to check that
folder for configuration before, if there was any.
The folder itself contained mappings for specific locales into
specific CJK-based
fonts. It was used only after 'ghostscript-chinese' was installed. This
solution was introduced into Ghostscript more than a decade ago, and it is
based on this project: https://www.freedesktop.org/wiki/Software/
CJKUnifonts/
If you look at the project, you will that it is basically dead, and the
'ghostscript-chinese' package itself received last update in 2012.
The main purpose of using 'ghostscript-chinese' is to introduce a
workaround for displaying/printing of CJK-based documents which do not have
the correct font embedded (for displaying the glyphs inside the document
text). When document wouldn't have correct CJK font(s) embedded inside it,
then Ghostscript would the closest substitution(s), so the document can be
at least displayed/printed in a readable/legible way. However, the
substitution will never be perfect, and will always be best-effort
workaround.
The above described situation was valid several years ago. Nowadays
upstream has its own solution (i.e. workaround) on doing so, which is based
only on one (different) font - Google Droid Sans Fallback.
I'm still discussing this change with Peng Wu (maintainer of
'ghostscript-chinese') and Akira Tagoh (fontconfig upstream developer)
off-the-list, but for now we have agreed to try use the default upstream's
solution for this scenario.
If it works well, this should mean less maintenance work for Peng
('ghostscript-chinese' could be dropped), and we wouldn't have a downstream
solution that could potentially cause additional issues in the future.
Also, the downstream solutions were really not popular with upstream before
(IMHO they didn't like Fedora at all because of it), and I was working with
them for last half and a year to improve our relationship with the
HEADS UP - Changes to Ghostscript package in F28
* As a result of debundling, 'poppler-data' is no longer a requirement for Ghostscript, and it is no longer necessary to do a rebuild of 'poppler-data' when Ghostscript is rebased. -- These changes shouldn't influence most of the users in any significant way. Some of Fedora developers might need to update their specfiles to require correct new (sub)package names. For that I will create a new tracking BZ for all related packages, and I will create necessary pull-requests on Pagure, or open corresponding BZs if pull-requests are disabled. The new Ghostscript should be available for trying/testing in Rawhide in a few hours. I will follow up with additional information (e.g. tracking BZ link) here in this thread. Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proven packagers - stop messing with other people packages!!
2 Richard: I think we've hit the cause of misunderstanding here. Many people around me (including) me use the word "own", because it's shorter (faster to say/write), even though we mean maintain (in a contributor sense). It's a slang for us. I don't know anyone around ne who would take the word "own" literally. The same applies for me. 2 Reindl: And I actually didn't write anything like this - nor I think anything like this. I thought my follow-up e-mail explained it clearly enough. And trying to discuss the meaning of "own" in Fedora package context is getting us off-topic... So to reiterate - I don't have a problem with proven packagers fixing something in packages that I maintain. My problem is when by doing that they create unnecessary more work (and/or some "hidden work landmine" as nicely stated by Adam), because they do not follow the Proven Packager Policy, which was IMHO create to also address exactly this specific issue... Anyway, I have already apologized to people who follow the Proven Packager Policy and whom I could offend, and I don't see this dicussion progressing anywhere. We're starting to beat a dead-horse here... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proven packagers - stop messing with other people packages!!
On Mon, Dec 4, 2017 at 4:33 PM, Reindl Harald wrote: > > > Am 04.12.2017 um 16:22 schrieb David Kaspar [Dee'Kej]: > >> On Mon, Dec 4, 2017 at 3:54 PM, Richard Hughes > <mailto:hughsi...@gmail.com>> wrote: >> >> On 4 December 2017 at 14:17, David Kaspar [Dee'Kej] >> mailto:dkas...@redhat.com>> wrote: >> > 4) He found a fix for it, created a new patch and added it into the >> package >> > I maintain/own. >> >> Did you say thanks? >> For what? Creating more work for me? :) If you were self-employed, would >> you thank your government for creating more unnecessary work for you? :) >> Hmm. I wouldn't think so... >> > probably nobody told you clear enough that nobody OWNS a fedora package at > all, if you would follow this list over the years you would know that as i > do even without beeing a packager > Well, you probably have time to read (almost) every message on fedora-devel mailing list, but I don't. Nor I have time to discuss pointless nit-picking on wording (no, I'm not a native speaker and "owning" a package has most likely a different meaning to me and to you) that actually don't change a thing in this discussion. :) Have a nice day, Dee'Kej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proven packagers - stop messing with other people packages!!
On Mon, Dec 4, 2017 at 3:54 PM, Richard Hughes wrote: > On 4 December 2017 at 14:17, David Kaspar [Dee'Kej] > wrote: > > 4) He found a fix for it, created a new patch and added it into the > package > > I maintain/own. > > Did you say thanks? For what? Creating more work for me? :) If you were self-employed, would you thank your government for creating more unnecessary work for you? :) Hmm. I wouldn't think so... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proven packagers - stop messing with other people packages!!
Hello Christian, On Mon, Dec 4, 2017 at 2:44 PM, Christian Dersch wrote: > Hi all, > > sorry but I think this mail goes into the completely wrong direction… You > claim that you don't want to point any fingers, but instead you blame *all* > proven packagers, including me. > my intention was not to blame all packagers maintainers, and it definitely went the wrong direction - I can see that. > I claim that I respect the policies for > example. Only reason to use the rights are pure rebuilds for me, in case of > soname bumps and already broken dependencies. So when things are already > broken and a rebuild solves it. For changes in packages I used Bugzilla for > long time. Now we have pagure with its very nice pull request mechanism I > use > in these cases to work with the maintainer. I know many other (proven) > packagers doing the same. > And for that I thank you - this is what I would expect from proven packagers workflow. > So blaming all of them… sorry… NO! > Please accept my apologies (and others as well) if you're following the Proven Packager policies and you have taken my initial e-mail personally. It was not intended to offend people who follow the policies. (Actually it was not intended to offend anyone.) > I know what you want to say though, as I also know that *some* proven > packagers abuse their rights. I also had that situation with few of my > packages, but I managed this with the specific proven packager then. If > some > proven packagers abuses his access again and again, an issue has to be > filed > @FESCo, so they can instruct the packager and maybe remove the proven > packager > rights later in case of another abuse. > This was the first time happening for me so I can't tell if it was actually recurring case or not. It seemed to me too far to take this to FESco straight away. Instead I tried to remind the proven packagers of the policy. However, I must admit that the format of this was based on affection and therefore not ideally chosen. Best regards, Dee'Kej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proven packagers - stop messing with other people packages!!
So, to clarify - I'm OK with proven packagers to make changes to package I (actively) maintain in case I'm unavailable for some longer period of time (weekend, vacation, etc.), and the changes needed to be done fall into one of these categories: * my package received some high/critical CVE that needs to be patched ASAP * my package is causing Fedora not to boot properly/at all * my package is causing some serious problems to Fedora infrastructure (e.g. causing builds to fail, causing Pagure not to work, etc.) * my package is causing some other significant problem When there's no such pressing issue, I would expect the packager to follow the Fedora policy about proven packagers I mentioned before. To be specific: * contact me via IRC first if it is something trivial not worth creating BZ and I'm available at IRC * write me an e-mail if it is something trivial not worth creating BZ and I'm not available at IRC * create a new BZ if it something non-trivial, causing problems to any users of Fedora What happened in the case that lead me to write my initial e-mail was this: 1) Proven packager received a BZ report for his own package. 2) Proven packager discovered the issue was actually caused by package I maintain/own. 3) Instead of switching that BZ to correct component, the proven packager decided to use his power to fix it himself. 4) He found a fix for it, created a new patch and added it into the package I maintain/own. NOTES: * The issue itself was not critical at all for Fedora to boot/function, it was not a CVE and it was not affecting the Fedora infrastructure, nor was critical at all IMHO. * I was available on the IRC during my working hours, but was not contacted by the proven packager, either via IRC or e-mail. * The specfile change was not referencing the BZ it was suppose to fix. It was containing only a link to upstream commit, where the commit message was completely irrelevant to the actual BZ. * The dist-git commit didn't contain the BZ number or some actually useful info either. The reason I'm not mentioning the person's name here is that I'm still waiting for his reply (or some kind of justification for this approach), but I really don't think that this actions would (nor should) fall to "being done according to policy". :) For me, it's more "I don't give a damn about others"-like approach, which IMHO nobody likes. :) Because it will be me (or some other maintainer) who will be (and will have to) deal(ing) with the package in the future, not the proven packager. Generally this "reckless" approach can cause be a pain for other people when they will be trying to find out answers to their questions (like "why was this patch included in the first place?", "can I safely remove it now?", "how long should it stay in the package?", "could this be the patch causing some regression I'm facing now?", etc. etc.) And that's one of the reason why I wrote my initial e-mail to this mailing list - for other proven packagers to be aware of this and for them to try not to make others people life harder... :) In the end, we have that saying in Fedora as well IIRC (when using 'sudo' for the first time): "With great power comes great responsibility" :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Proven packagers - stop messing with other people packages!!
Hello folks, I do not want to point any fingers, so I'll be adressing this to all proven packagers... Stop messing with other people packages without trying to contact them via e-mail/IRC, or openind new BZ! Especially when you see they are actively maintaining the package and your changes are not critical for Fedora to function/boot. THIS IS NOT OKAY, AND YOU ARE ABUSING THE RIGHTS YOU WERE GIVEN! Fedora proven packagers policy ( https://fedoraproject.org/wiki/Provenpackager_policy) explicitly says: "Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes. They should be careful not to change other people's packages needlessly and try to do the minimal changes required to fix problems, ..." Last note to proven packagers: You're not BDFLs - so start acting according to it. Thank you! David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removing ghostscript-fonts package
On Mon, Nov 6, 2017 at 5:12 PM, Zdenek Dohnal wrote: > Based on this thread, I will retire now this package. That's should be save to do IMHO: * https://src.fedoraproject.org/rpms/hylafax+/c/4886f02ec6327a54488750acf4b9e05559a48460?branch=master * https://bodhi.fedoraproject.org/updates/FEDORA-2017-b20e04f6ce Thanks! :) -- Dee'Kej -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Rawhide] gawk API changes heads up
Thanks for the info. In that case there's nothing holding me from doing the rebase (I'm already in contact with gawk extensions developer). My guess is that the new gawk version will land in Rawhide tomorrow then. Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Rawhide] gawk API changes heads up
Hello folks! :)
The new major version of GNU awk (gawk) was released recently, and this
version introduced a new API (version 2.0). I want to give all of you a
heads up that I'm planning to do a rebase in Rawhide next week (probably on
Tuesday, November 7th, if everything goes OK).
If you have any gawk extension (or you somehow depend on gawk internals in
your packages), then you will have to update your packages so they are able
to work properly during runtime (with the new ABI).
On the other hand, I do not think we have so many extensions of gawk in
Fedora. Most of the packages depending on gawk (see below) probably uses
the gawk for its text processing capabilities. :)
In any case, I have recently introduced (in gawk-4.1.4-7) the 'gawk(abi)'
in the gawk's specfile:
> Provides: gawk(abi) = %{gawk_api_major}.%{gawk_api_minor}
If your package requires a specific API version, then you can require that
version in your package's specfile as you need. Once you have this in
place, the users shouldn't be able to update to newer version of gawk, if
it would break the ABI compatibility.
-
Last thing I have in my mind regarding the upcoming rebase - should we
schedule a mass-rebuild for the packages listed below, to see if they build
correctly with the latest version of gawk? If they wouldn't, we could file
the new FTBFS BZs for it. Thoughts? Comments? :)
-
List of packages requiring gawk (it might not be complete, it was extracted
from some quick dnf query):
akmods
am-utils
autoconf213
autofs
calamares
ceph-selinux
checksec
cloud-utils
cloud-utils-growpart
copr-backend
ctdb
dhcp-client-12
dkms
docbook-utils
e2fsprogs-devel
execstack
firehol
gt5
guilt
hylafax+
krb5-libs
latex2rtf
lde
libguestfs
libsmi
linuxdoc-tools
lorax
netdump-server
nfs-utils
pcp
phpPgAdmin
pkgdiff
policycoreutils
quilt
ragel
rarian
R-core
rear
rf
rpm-build
rpmdevtools
screenie
seqan
testssl
translate-shell
tuned
tw
txt2man
unity-gtk-module-common
virt-p2v-maker
virt-v2v
vzctl-core
xfce4-dev-tools
ypserv
-----------
Best regards,
David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removing ghostscript-fonts package
Sorry for the delay in reply, vacation... Anyway, back to work! :) On Mon, Oct 9, 2017 at 6:25 PM, wrote: > > > - Mail original - > De: "David Kaspar [Dee'Kej]" > > > * Regarding the font family names and subpackages -- it's another mess. > > Not just in Fedora (the FPG for fonts are really outdated), but generally > > everywhere. > Ah, darn it. Apparently I have oversimplified and didn't express myself correctly. :-/ > > Since I wrote those, I'd like to qualify this: > > 1. Fedora basic packaging principles for fonts are sound, since they are > based around fontconfig capabilities, OpenType capabilities, and the CSS > model (mostly the same thing since fontconfig is architectured around > OpneType and the CSS font model). All of those are pillars of any > font-manipulating app in Fedora currently and in the near future. If > anything they've become stronger requirements since the guidelines were > written. The basic CSS font family is a set of faces that only differ in > width, weight or slant. Because apps can only apply width, weight or slant > attributes to text (not serif or sans-serif or whatever). Since in the past > years some advanced apps have gained the ability to select optional > opentype features such as advanced ligatures, I'd tend to think files that > add those features also belong in the same font family. > To clarify - the FPG for fonts is okay in principles. It just still mentions some things that are no longer used in Fedora's specfiles, or some things are not so clear when reading through them. IMHO, just a regular cleanup/update in the wiki (and maybe unifying all the related wikis into one) should be enough. :) If you wish, we could create a BlueJeans meeting (open for everyone) to go through these guidelines and fix them together. ;) I unfortunately don't have right to edit the wiki, nor I want to mess with something which you maintain(?). > 2. Those principles are much better than the Debian ones of a few years > ago, that reposed on layers of custom Debian-specific metadata that was > supposed to work with every possible font system, working well with none, > all very maintainer-intensive. I haven't checked if Debian managed to sort > this mess since. What I've seen of the Appstream font spec reeks of the > same metadata overlaying, and misunderstanding of the CSS font model. When > you reinvent the wheel you can redefine everything. Contrariwise, when you > reinvent the wheel you need to maintain your wheel ad vitam eternam + deal > with every piece of code not written around your square wheel. Apps are > written around fontconfig and the CSS model, not the appstream abstraction, > even when developers do not realise it (the CSS model is really pervasive, > since it was defined by Microsoft around what monsters like Office did at > the time, and has been adopted by the web and web-derived techs since). > Even TEX that long stood for its own font model has switched to OpenType > lately – gaining access to the vast trove of OpenType fonts trumped being > "better" with a limited font set. > Again, I'm OK with the principles, it's just some small things need update in FPG, that's all. I don't want us to reinvent the wheel (again). I agree that fontconfig is good way to go. The only reason why I created the AppStream files is for the 'urw-base35-font's to be available in Gnome-software if possible, so users can possibly preview them before installing them. That's the only actuall benefit I see from AppStream files for fonts in Fedora. (+1 for moving to OTF/TTF.) > 3. Therefore, I would caution against anything that proposed abandoning > the CSS font model and redefined the font family/font faces split of the > CSS model. A strength of our guidelines is that our package split follows a > logical font family split which is understood both by users and the > application code. > I'm not proposing abandoning what we have in Fedora. I would like to just to have the FPG updated. For example IIRC, there was a suggestion somewhere there, to use fontforge to display the font family, and then to use that font family name for the font subpackage. However, this contradicts what you wrote about the CSS model and the width/weight/slant. That's why I think we should update the FPG and unite them. ;) > 4. However there are many broken fonts out there. The metadata of actual > font files may be suboptimal upstream, requiring font packagers to > understand the limits of ideal (application-wise) font families, and fixing > the metadata of the fonts we ship either by patching the fonts of via > fontconfig directives. This is a major PITA but we can't avoid it if we > want the fonts we
Re: Removing ghostscript-fonts package
So, I have tried to rebuild 'hylafax+' with 'urw-base35-fonts' and it passed: https://koji.fedoraproject.org/koji/taskinfo?taskID=22352204 I suggest we rebase it newer version (5.5 -> 6.0.6 -- the latest stable release is already 5 years old -- http://www.hylafax.org/content/Download), rebuild it against 'urw-base35-fonts', and get it to Rawhide for testing. -- Dee'Kej -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removing ghostscript-fonts package
On Fri, Oct 6, 2017 at 10:51 PM, R P Herrold wrote: > I don't see a urw-base35-fonts SRPM in my RawHide ... has it > been packaged? > Yes, it's in the Rawhide already: https://src.fedoraproject.org/rpms/urw-base35-fonts My mirror only fires weekly, but it seens ... hasty to retire > a package before its successor has 'aged' a bit to let > possible bugs appear. In checking the CTAN site, it seems > pretty likely that font metrics will have changed and so the > appearance of documents will be affecte > d > I understand your concerns, but to clarify - technically, the urw-base35-fonts is a successor to successor of ghostscript-fonts: ghostscript-fonts -> urw-fonts -> urw-base35-fonts I took ownership of urw-fonts sometime in the last year, and I had been working with upstream (Artifex company) to fixing some bugs in the latest release of these fonts [a.k.a. (URW)++ fonts], as well as updating and creating fontconfig and AppStream files (respectively). I really can't tell why the ghostscript-fonts were not killed before, since we had the urw-fonts already. You would have to ask previous maintainers about this. To clarify on what others wrote: * Nicolas is right, the fonts needed a proper cleanup, and that's why we went through this. We were already using an outdated fonts in Fedora 25 (and newer) for Ghostscript and other applications depending on it (like ImageMagick, GraphicsMagick, Evince, ...), and I received some bug reports for it that forced me to "hack" the Ghostscript configuration to temporary fix this situation -- but not completely. Since I hope to do a rebase of Ghostscript-9.22 in F27 (to fix quite few low-level CVEs and some annoying issues, but no API/ABI changes according to upstream, so it should be "safe"), I needed the urw-base35-fonts to be ready first. Ghostscript bundles a lot of stuff, but we're "de-bundling" it in Fedora. However the 'urw-fonts' were already too old now/outdated in F25. In past, any part needed for Ghostscript's "de-bundled" build often resulted in unnecessary bug-reports for upstream, if it was outdated. And it was IMHO mainly because of that why upstream started... to not like use very much. (In last ~1 year I'm working more closely with upstream to improve the relationship again, and to fix all the mess around Ghostscript.) * Right now, we have a problem that some applications (ImageMagick at least, I expect others as well) depend on Type1 fonts, not just Ghostscript, which is not allowing us to completely move to OTF font format. But as Nicolas said, the LibreOffice in F26 no longer supports Type1 fonts. ->> I expect for us to ship both OTF and Type1 together for now (as a transition period), until we can work with upstreams & package maintainers to make complete shift to OTF. * Regarding the font family names and subpackages -- it's another mess. Not just in Fedora (the FPG for fonts are really outdated), but generally everywhere. Currently I'm seeing that every party (group) does something different, and IMHO we should first update the FPG, and to do a general fonts cleanup in Fedora. (For now I will keep the subpackages, until we decide on how to approach this on wide level across Fedora.) * I wouldn't say the upstream is dead, they have just moved fast-forward, and the fonts in ghostscript-fonts are no longer supported by them. However, orphaning the package does not make much sense to me. We need the maintainer/upstream of "hylafax+" to move to 'urw-base35-fonts', which are supposed to receive updates in the future if needed. Once they have moved, then we can kill the ghostscript-fonts. ->> For now the maintainer of 'hylafax+' should try to update the paths (if needed) in 'hylafax+' specfile, and try to build it against 'urw-base35-fonts'. If it succeeds, we can try to let it live in Rawhide for some time. If it does not succeed, we should inform its upstream so they can update their software. 2 Nico: I understand that 'hylafax+' is an extremely stable package, but that shouldn't block us from moving forward in fixing other stuff. Is my suggestion above OK for you as a solution for now? :) -- Dee'Kej -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Removing ghostscript-fonts package
On Fri, Oct 6, 2017 at 4:18 PM, Xose Vazquez Perez wrote: > Zdenek Dohnal wrote: > > > I am going to retire ghostscript-fonts package in F27 because its fonts > > are deprecated and replaced by urw-base35-fonts package. > > NACK. They are _extra_ fonts: > http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f= > Resource/Init/Fontmap.GS > Well, the ghostscript-fonts might be *extra* fonts, but they are only being used by 'hylafax+' package ATM. Ghostscript is *NOT* using these fonts anymore. They are many years old (and outdated). These fonts are completely irrelevant and obsoleted nowadays. The Fontmap.GS you have shared actually uses fonts from urw-base35-fonts package, not ghostscript-fonts. You would see the names mapping there if you look closely. I'm ACKing this request as the maintainer of ghostscript and urw-base35-fonts. -- Dee'Kej -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Pagure] Allow deleting and force-push for auxiliary branches
On Sat, Sep 16, 2017 at 8:38 PM, Christopher wrote: > You don't need to create pull requests at all. git handles multiple remote > repositories (the "origin" and your fork) just as easily as it handles one. > Saving your work in a separate branch is the same whether that branch is in > the main repo or a fork. The only difference is which remote you push to. > Yeah, you're actually right. I don't know I have forgotten about that, when I'm sometimes using for some other repositories we have at Github. *sigh* Sorry for the noise. :-/ -- Dee'Kej -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Pagure] Allow deleting and force-push for auxiliary branches
On Fri, Sep 15, 2017 at 5:28 PM, Pavel Valena wrote: > You can do all you want in your fork[1], which Pagure does support. IMHO > there's no need to use private branches now. > Pagure also supports PRs[2]. > Okay, that's oney way to deal with his. However, making a fork of a repository where only I maintain it, to later create pull-requests and accept them myself... Is too much overkill for this kind of workflow. The only time it would make a sense I guess is when there are multiple admins/committers working on the package simultaneously. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Pagure] Allow deleting and force-push for auxiliary branches
Hello folks, I have stumbled upon this several times before, and today again. And since we have switched to Pagure, I think it's time to discuss this (again?)... :) IMHO, the package maintainers should be allowed to make, delete and force-push into private/auxiliary branches. Disabling completely the deletion & force-pushing on all branches is IMHO PITA for many maintainers, because it distorts the common git workflow... I - as a maintainer - want often to create an auxiliary branch where I will do some changes, do a git rebase/amend/etc. that requires a force-push later - to keep the git commits clean and not messy, and once I think the whole branch is clean enough and ready, then I will merge it into master (or some other main branch). Or I can decide at some point to completely drop all the changes from that private/auxiliary branch, or start again differently in other private/auxiliary branch... In any case this requires for me to have the ability to be able to do force-push and deletion of the auxiliary branches which I create just for that purpose. Currently I don't have this ability in Pagure either, and it is starting to produce a mess in branches in git repositories for my packages. (I often forget that I can't currently delete the already pushed branch, and it will just "hang" in the git repository indefinitely.) Therefore, I want to propose this: 1) Package maintainers (main admin, admin, committer roles in Pagure) will have the right to create private/auxiliary branches in git repository belonging to that package. 2) Each package maintainer will have the ability to only do 'git push --force' into the branch that he/she has created before. (No force-push into private/auxiliary branch of other package maintainers.) 3) Each package maintainer will have the ability to only do 'git push --delete origin ' into the branch that he/she has created before. (No deletion of private/auxiliary branch of other package maintainers.) 4) In case a package maintainer will require a deletion of private/auxiliary branch of other package maintainer, he/she will have to request this (in Pagure?). Only allowed Pagure admins (or somebody else with proper authorization) could do it after the request was approved. (This situation might occur in case some previous maintainer is no longer maintaining the package, but his old private/auxiliary branches are still present in the git repository.) 5) The default branches for Fedora releases (f, like 'f26', and 'master' branch) will still remain protected against force-push and deletion unconditionally. 6) Each main admin and admin of the package will have right to set each private/auxiliary branch as "protected", thus blocking force-push and deletion of that particular branch. This is just a mock-up idea, the details of this would have to be discussed in more details. The main questions about this are: A) Would you guys welcome this option - to do force-push and deletion of private/auxiliary branches? B) Would it be feasible to implement this in our Pagure infrastructure? I do realize that this will become more complicated with Modularity project, but I still think it would be feasible to adapt this approach even to changes which Modularity brings. I welcome any feedback! Thanks for it in advance! ;) Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: urw-fonts: Versioning Mess
OK, I will proceed with Domininik's or Zbigniew's idea. Thanks all to your suggestions. :) David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. On Thu, Dec 1, 2016 at 9:13 AM, Pierre-Yves Chibon wrote: > On Thu, Dec 01, 2016 at 01:37:18AM +, Zbigniew Jędrzejewski-Szmek > wrote: > > On Wed, Nov 30, 2016 at 05:35:19PM +0100, Dominik 'Rathann' Mierzejewski > wrote: > > > On Wednesday, 30 November 2016 at 16:07, David Kaspar [Dee'Kej] wrote: > > > > On Wed, Nov 30, 2016 at 12:38 PM, Dominik 'Rathann' Mierzejewski < > > > > domi...@greysector.net> wrote: > > > [...] > > > > I'm not sure where your Version == 1.0 comes from. If they're > versioned > > > > > only by date now, then you have two options. Use Version: 0 in the > new > > > > > package in anticipation of upstream eventually reintroducing > semantic > > > > > versioning. Or, Version: MMDD. Admittedly, the latter looks > nicer > > > > > and upstream already said they'll stick to it. > > > > > > > > > The Version == 1.0 comes from the source code of the fonts > themselves. > > > > Running 'grep "Version" *.afm' tells me that there are all files with > > > > Version == 1.0, except two of them (which have Version > > > > > > If they don't have the same version then it doesn't make sense to use > > > the version of *some* of them as base. > > > > > > > > If you worry about upstream versioning sanity, then stick with > > > > > Version: 0 > > > > > and follow the snapshot versioning guidelines. > > > > > > > > > > > There's also one more option, and that is to base the package on > > > > > > upstream's git repository and the snapshot scheme, because we > > > > > > would be using snapshot string in the package name anyway. And it > > > > > > would also solve one more issue that upstream is not shipping > > > > > > license files in the archive. (I have already contacted to > correct > > > > > > this.) > > > > > > > > > > The exact location of the source doesn't matter too much as long > as it's > > > > > official and pristine. I agree it might be better to use the git > repo > > > > > directly since it contains both the licence indication and its full > > > > > text. > > > > > > > > > Upstream has heard to my request and fixed it. ( > > > > http://bugs.ghostscript.com/show_bug.cgi?id=697390) > > > > > > > > And yes, what Douhlas wrote is correct (about the 35 fonts), and I > will > > > > have that noted in the %description section. > > > > > > > > Anyway, since determining the Version field is still unclear, I > think the > > > > most sense to me right now is to proceed with option 2) - IOW - to > bypass > > > > the versioning from URW++ completely, and have Version field based on > > > > snapshot string, in a way: > > > > X.Y.Z == .MM.DD > > > > > > > > Or do you some problem with this approach? > > > > > > As I said, please do not invent the version on your own. Please apply > > > the existing snapshot guidelines instead, i.e.: > > > Version: 0 > > > > > > Release: 0.N.MMDD > > > or > > > Release: 0.N.MMDDgitHASH > > > > Or even better, as you proposed in the other e-mail, Version: MMDD. > > This is much nicer for users, and actually easier for the maintainer > > of the package. David seems to ignore this option for some reason, > > but it really seems the best one. > > > > (If upstream does something crazy and it is necessary to change the > > versioning scheme again in the future, adding an epoch is always an > > option.) > > Since I guess the idea of this thread is to avoid using epoch, I think the > better approach is to stick with the Dominik's suggestions. It is what > gives the > most flexibility for future changes. > > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: urw-fonts: Versioning Mess
On Wed, Nov 30, 2016 at 12:38 PM, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > I also found this: > http://git.ghostscript.com/?p=urw-core35-fonts.git;a=summary > and they're called urw-core35-fonts here. It might be wise to ask > upstream to clarify before choosing the new package name. > OK, will do. I'm not sure where your Version == 1.0 comes from. If they're versioned > only by date now, then you have two options. Use Version: 0 in the new > package in anticipation of upstream eventually reintroducing semantic > versioning. Or, Version: MMDD. Admittedly, the latter looks nicer > and upstream already said they'll stick to it. > The Version == 1.0 comes from the source code of the fonts themselves. Running 'grep "Version" *.afm' tells me that there are all files with Version == 1.0, except two of them (which have Version > If you worry about upstream versioning sanity, then stick with > Version: 0 > and follow the snapshot versioning guidelines. > > > There's also one more option, and that is to base the package on > upstream's > > git repository and the snapshot scheme, because we would be using > snapshot > > string in the package name anyway. And it would also solve one more issue > > that upstream is not shipping license files in the archive. (I have > already > > contacted to correct this.) > > The exact location of the source doesn't matter too much as long as it's > official and pristine. I agree it might be better to use the git repo > directly since it contains both the licence indication and its full > text. > Upstream has heard to my request and fixed it. ( http://bugs.ghostscript.com/show_bug.cgi?id=697390) And yes, what Douhlas wrote is correct (about the 35 fonts), and I will have that noted in the %description section. Anyway, since determining the Version field is still unclear, I think the most sense to me right now is to proceed with option 2) - IOW - to bypass the versioning from URW++ completely, and have Version field based on snapshot string, in a way: X.Y.Z == .MM.DD Or do you some problem with this approach? Thanks! :) David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
urw-fonts: Versioning Mess
Hello guys, I took over the maintenance of urw-fonts to update them to the latest version (ghostscript and other packages needs them). However, there are several problems in versioning of it, and I would like to discuss future steps for the package. The current problems: * our urw-fonts are kind of old (~2 years), and ghostscript is unable to build without latest version correctly (unless I patch it, and it would still cause ghostscript crashes for some instances AFAIK) * according to git log the urw-fonts in Fedora should be based on version 1.10, but the source code archive indicates version 1.07 pre-release (1.06 in fact, if we check the source code) * the NVR of urw-fonts does not correlate to this at all - urw-fonts-2.4-22.fc24.noarch * we obtain the source archive from Artifex (aka upstream responsible for ghostscript), nowadays they are no longer using the X.Y.Z versioning system. Instead, they have created a separate git repository for it, and are doing "snapshot based" releases... Their latest release is: urw-base35-20160926.zip * I asked them if they could go back to X.Y.Z versioning system, here's what Chris Liddell replied: "If you check the versions in the font files, you'll see why I switched to the release dates. For several releases they never changed from 1.10, and with the latest release, they're back to 1.00. Since this is how URW++ release them to us, there's not a huge amount we can do." * and as you can see above, they also changed the name from 'urw-fonts' to 'urw-base35' because of this As you can see, the versioning of urw-fonts is total mess right now, and I would like to bring back some order to it, but I don't want it to backfire on me because of how URW++ tends to version their fonts... Here's my proposed solution to this: - create a new package for urw-fonts which would obsolete the current urw-fonts - choose a similar name to the new package - 'urw-base35-fonts' or similar And either... 1) stick to URW++ based versioning - this would mean (at the moment) Version == 1.0 and adding snapshot == 20160926 (MMDD as described in https://fedoraproject.org/wiki/Packaging:Versioning#Snapshot_packages) 2) or map the X.Y.Z versioning to MMDD from upstream - IOW - X == Year, Y == Month, Z == Day (based on the snapshot date in the name of the source archive) 3) or set the Version to some constant (35 for example) and just use the snapshot to distinguish between older and newer releases. I am affraid that I would pick option 1) it could pose problems in the future again, because there's not guarantee that URW++ will follow sane versioning. So, personally, I would choose 2) or 3). There's also one more option, and that is to base the package on upstream's git repository and the snapshot scheme, because we would be using snapshot string in the package name anyway. And it would also solve one more issue that upstream is not shipping license files in the archive. (I have already contacted to correct this.) What are you thoughts, guys? Anyone has a better idea how to solve this mess? Or which option would you recommend? Thank you in advance for all your ideas. Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: remote: sh: ./hooks/post-receive-chained.d/post-receive-alternativearch: No such file or directory
Thank you guys for the reply, I'm just glad it's not something critical... :) David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. On Tue, Nov 1, 2016 at 3:05 PM, Pierre-Yves Chibon wrote: > On Tue, Nov 01, 2016 at 08:41:55AM -0500, Jon Ciesla wrote: > >On Tue, Nov 1, 2016 at 8:34 AM, David Kaspar [Dee'Kej] > > wrote: > > > > Hello folks, > > > > when I was pushing new commit to ghostscript, I received the line in > > $SUBJ during the push, for all the currently used Fedora branches. > > > > Did anybody else stumble upon this? Any idea where should I report > this > > bug since this is apparently problem of our Fedora infrastracture? > > > >I'm seeing it too. > > So the proper place to report this is on the fedora-infrastructure project > on > pagure: https://pagure.io/fedora-infrastructure/ > > This error is something that got pushed accidentally, that I have fixed > this > morning but not on all git repos yet as I wanted to be around when I do > (fix all > git repos) in case something came up but I'm not much around today. > > Worst case this error will be gone by tomorrow and can be safely ignored > in the > mean time. > > > Sorry for the inconvenience :s > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
remote: sh: ./hooks/post-receive-chained.d/post-receive-alternativearch: No such file or directory
Hello folks, when I was pushing new commit to ghostscript, I received the line in $SUBJ during the push, for all the currently used Fedora branches. Did anybody else stumble upon this? Any idea where should I report this bug since this is apparently problem of our Fedora infrastracture? Thanks, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [security fix] ghostscript rebased to 9-20 for all releases
Thank you, Solomon for that info, actually gutenprint maintainer is my colleague, but he is sick today. I'm adding him into CC, so he's aware of it when he returns. ;) 2 Zdenek: Please, look at the whole thread here - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WZYPIRENDRAT3XZLTOVUVNOCJDZQIW3M/ - we have discussed a little on Thursday, so you should know what's going on. :) Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. On Fri, Oct 7, 2016 at 5:28 PM, Solomon Peachy wrote: > On Fri, Oct 07, 2016 at 03:14:57PM -, David Kaspar wrote: > > Right now, I think only packages that depend on ghostscript-devel > subpackage *might* be affected by this change. List of those packages: > > > ariamaestosa > > > ImageMagick > > > wfdb > > Add gutenprint to that list. I don't expect the existing package will > malfunction in any way with the ghostscript bump, but it's not > rebuildable without ijs-config. There's an already-upstreamed patch > that switches over to using pkg-config: > > https://sourceforge.net/p/gimp-print/source/ci/ > 233a909a77dd4c18d359bf32cd8ef99ed1b7b459/ > > (For the life of me I can't figure out how to get sourceforge to display > a raw diff. I can supply one out of my local repo if need be..) > > - Solomon > -- > Solomon Peachy pizza at shaftnet dot org > Delray Beach, FL ^^ (email/xmpp) ^^ > Quidquid latine dictum sit, altum viditur. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [critpath] bash - Security fix for CVE-2016-0634 ready for testing.
Hello Matthes, thank you for the heads up, I was fixing the issue because I'm "backup" maintainer of bash, and the main contact (Siteshwar) was not avaiable. I've put him in CC, so if he wishes he can create the test plan. Unfortunately, I personally do not have time for it now. :( Best regards, David Kaspar [Dee'Kej] *Associate Software Engineer* *Brno, Czech Republic* RED HAT | TRIED. TESTED. TRUSTED. Every airline in the Fortune 500 relies on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>. On Thu, Sep 22, 2016 at 6:24 PM, Matthew Miller wrote: > On Thu, Sep 22, 2016 at 09:21:22AM -, David Kaspar wrote: > > Hello guys, > > > > I backported the upstream patch for CVE-2016-0634 [1] into bash for > Rawhide, F25, F24, and F23. If you have some spare time, feel free to help > verifying the issue / testing the stability of bash [2][3][4]. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1377614 > > [2] https://bodhi.fedoraproject.org/updates/bash-4.3.43-3.fc25 > > [3] https://bodhi.fedoraproject.org/updates/bash-4.3.42-6.fc24 > > [4] https://bodhi.fedoraproject.org/updates/bash-4.3.42-4.fc23 > > Hi David! Bash is relatively important. It'd be awesome to have a test > plan for this. See > https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation if > you'd like to write one... or, if you have a series of basic things > you think people should test, maybe you could just list those here or > on the test list and someone else will be inspired to help. :) > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
