Re: Broken dependencies: vim-syntastic
by Pavel Raiskup
On Wednesday, September 21, 2016 12:16:39 PM CEST buildsys(a)fedoraproject.org wrote:
> vim-syntastic has broken dependencies in the rawhide tree:
> On aarch64:
> vim-syntastic-lisp-3.7.0-6.fc26.noarch requires clisp
> On aarch64:
> vim-syntastic-cs-3.7.0-6.fc26.noarch requires mono-core
> On aarch64:
> vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc
> On armhfp:
> vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc
> Please resolve this as soon as possible.
What's should packager do in such case? Recap: noarch package depends on
arch-dependant package, which is not available everywhere.
Pavel
7 years, 4 months
[Fwd: Re: [Fedora-packaging] Re: why the Group tag is obsolete ?]
by Sérgio Basto
Hello, I'd like understand how groups of package are now detect ,
specially in 3rd repo packages which can't use comps.xml.
Thanks !
-------- Forwarded Message --------
From: Sérgio Basto <sergio(a)serjux.com>
To: packaging(a)lists.fedoraproject.org
Subject: Re: [Fedora-packaging] Re: why the Group tag is obsolete ?
Date: Sun, 28 Aug 2016 07:24:58 +0100
On Seg, 2016-08-01 at 09:17 -0600, Dave Johansen wrote:
>
> On Sun, Jul 31, 2016 at 9:23 PM, Sérgio Basto <sergio(a)serjux.com>
> wrote:
> >
> > Hi,
> > A year ago, I learned that Group tag is obsolete [1] I remember ask
> > the
> > reason and is something about comps.xml that I don't remember
> > neither
> > find on google , but for projects that still use repoview, Group
> > tag is
> > needed. So the questions are, have we any replacement for repoview
> > ? or
> > another way to show one repo content ? and why the Group tag is
> > obsolete ? can someone remind me why. And how we now the group of
> > one
> > package ? .
> >
> > Thanks.
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1239067#c1
> Here's the FPC ticket about it:
> https://fedorahosted.org/fpc/ticket/199
Thanks I was able to find the reason:
RPM in Fedora 18 does not require the presence of the Group tag in the
spec file. If the tag is defined, it will be ignored. The package
groups of the yum application are used on a Fedora 18 system as the
relevant source of information on which group is the package a part
of.
I remembered in one thread of devel mailing list on create hawaii group
and bingo found the link:
https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_...
So now, how I know the group of the package (via yum or dnf) ? seems to
me many packages will not have group ... and 3rd-part software ?
Also /usr/bin/gnome-software how find the group of the package ?
Well this is not a very important matter , but I'd like try organize
packages in groups , via repoview.
Thanks.
--
Sérgio M. B.
--
Sérgio M. B.
7 years, 4 months
ATTN: OCaml 4.03 in Rawhide, could affect POWER, s/390, RHEL 7.4,
CentOS 7.4
by Richard W.M. Jones
OCaml 4.03 has been out for a while.
I'm intending to add it to Fedora Rawhide once a side tag has been
created: https://fedorahosted.org/rel-eng/ticket/6486
This will require rebuilding every OCaml package, which I normally do
using a script, but probably there will be manual rebuilds necessary
too.
A few issues that may affect people:
(1) There is a new ppc backend upstream, and I intend to switch to this.
For years we have maintained our own out-of-tree ppc64 & ppc64le
backends. I want to switch to the upstream ppc backend (which
supports, in theory, ppc 32 bit, ppc64 and ppc64le). However when I
actually tried this I found it to be rather buggy, it couldn't even
compile many basic OCaml packages. This time I intend to switch, and
we'll deal with the bugs.
(2) There is a new s/390x backend upstream. This should enable us to
compile all s/390x packages as native code.
It also means that all supported architectures (yes, even riscv64)
will support native compilation for OCaml.
(3) The real reason I'm doing this now is because partners have asked
us to update the OCaml compiler in RHEL 7.4. This will be a binary
ABI break -- it's unfortunately unavoidable -- and will require all
OCaml-using programs to be recompiled, and of course that will affect
CentOS and any other RHEL derivatives.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
7 years, 4 months
DNF and PackageKit background data usage
by Adam Williamson
Hi folks!
I kinda hate kicking off discussions like this without having a solid
solution to propose or being able to promise to work on one, but this
really seems important. Unfortunately I can't claim I'm gonna have time
to do any concrete work on it, though I'd really *like* to. But I
thought it would be worthwhile to kick around still; perhaps someone
else will be inspired.
I just read Hedayat's review of Fedora 25 Beta:
https://hedayatvk.wordpress.com/2016/10/30/fedora-25-beta
and this really jumped out at me:
"And, if you care about your internet usage, make sure that you disable
both dnf makecache timer, and stop PackageKit from downloading updates
automatically. I don’t allow a new Fedora installation to access
internet before doing these, as it might just eat a considerable amount
of data."
There's two things I think are somewhat unfortunate here:
1) Both dnf and GNOME Software / PackageKit default to performing
fairly data-hungry transactions in the background, out of the box,
without telling you about it. GNOME's is particularly bad, as it will
happily download available updates in the background, which can be
gigabytes worth of data. DNF only updates its metadata caches (on a
systemd timer), but even that could be behaviour that users in certain
circumstances really really do not want.
2) There is no particularly obvious or visible mechanism for a 'typical
user' (or, if you prefer, many of the target 'personas' for our
flavors) to configure this behaviour...and you have to figure out two
completely *different* configuration mechanisms in order to shut off
both.
I think this is kind of poor behaviour on our part and we should make
it better. Do I have a specific concrete proposal? No. But I do have
some vague ideas.
* We could have some kind of configuration interface appear on install
/ first boot. This would require integration with anaconda and/or
initial-setup and gnome-initial-setup.
* We could invert the defaults and have the apps ask the user if they
want to enable data-hungry background operations on first interaction:
the first time you use dnf (without -y) it could say 'hey, do you want
to turn on background cache refreshes?' Similarly, the first time you
run GNOME Software or click on an update notification, it could say
'hey, do you want to turn on background update downloads'?
* We could at least make both of them respect one single config setting
for 'do data hungry background operations' (this is kinda one small
part of the bigger issue that is 'dnf and PK-based stuff don't share
any configuration aside from repo definitions').
Anyone have thoughts on this? Any DNF or Software devs want to say I'm
totally wrong and an idiot? Anyone inspired to do something more
concrete than a mailing list post? :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years, 4 months
Private Bugzilla bugs
by Florian Weimer
Why does Bugzilla allow filing private Fedora bugs?
I'm not sure who has the capability (it may be tied to specific
accounts). It is not all that helpful because accounts on the Cc: list
still receive notifications and can access the bug. Recipients of the
notifications may include public mailing lists. This is probably not
what people make bugs private expect.
The other problem is that I keep having to ask people filing private
bugs if it is okay with them to make them public, and then to open the
bugs again if they accidentally turn it private afterwards.
Surely it's best to remove this capability from Bugzilla?
(In case anyone wonders: We do not file Fedora bugs for embargoed
security issues at all, so a Bugzilla permissions change would have zero
impact on that front.)
Thanks,
Florian
7 years, 4 months
Bodhi For Rawhide?
by Vít Ondruch
Hi all,
I am thinking, why we don't have enabled Bodhi for Rawhide? I know that
you might think now that I went nut and it is bureaucracy, but let me
explain.
If I understand it correctly, during several past years, our build
process was more streamlined and we are trying to do the Rawhide
composes in a similar fashion we are doing stable releases. But for some
reason, we are still not using Bodhi for Rawhide and I see no reasons
not to use it. Here are some benefits if we were using Bodhi:
* One of the nice things which Bodhi does is running several check, such
as depcheck, rpmlint (actually question if we are using rpmlint for
Fedora builds was what triggered this email), etc. On one hand, I'd love
to see these checks running in Koji, but there is no support for them
and I don't even see the support coming. So enabling Bodhi for Rawhide
would give us this opportunity.
It is actually quite interesting, that while most of the development
happens in Rawhide, there is less sanity checks then for the Rawhide, so
if you screw up something in Rawhide, it will get into stable version
and you might not notice until you submit some stable update.
* From time to time, there is necessary to build some framework, which
consist of several components which must be released together.
Currently, we either temporarily break Rawhide or we are asking for side
tag. But why not use koji for that? Users of stable releases are not
affected by incomplete builds, since the don't reach even the
update-testing without pushing via Bodhi.
* And probably last think, why the Rawhide should be really exception?
Why we should not use Bodhi if we are using it anywhere else?
Lets use Bodhi for Rawhide, where the submitted update would immediately
go into Rawhide, unless maintainer wishes some testing period.
Any comments on this topic?
V.
7 years, 4 months
Many directories without owning packages
by Dridi Boukelmoune
Hello,
I was surprised to see /usr/share/texlive on my system although I
remembered very well removing it months ago. It turned out to be
caused by two rpmsave files, although some *empty* directories weren't
removed:
$ find /usr/share/texlive/
/usr/share/texlive/
/usr/share/texlive/texmf-dist
/usr/share/texlive/texmf-dist/web2c
/usr/share/texlive/texmf-dist/web2c/fmtutil.cnf.rpmsave
/usr/share/texlive/texmf-dist/web2c/updmap.cfg.rpmsave
/usr/share/texlive/texmf-dist/tex
/usr/share/texlive/texmf-dist/tex/latex
/usr/share/texlive/texmf-dist/tex/latex/misc
/usr/share/texlive/tlpkg
/usr/share/texlive/tlpkg/TeXLive
/usr/share/texlive/tlpkg/tlpostcode
/usr/share/texlive/tlpkg/translations
But then I decided to check my whole /usr tree and found more orphans
than I expected.
My crude data gathering:
$ find /usr/ -type d -exec rpm -qf {} \; |
grep 'not owned' |
tee not_owned.txt
And the results on my current fc24 laptop:
$ wc -l <not_owned.txt
828
$ sort not_owned.txt | awk '{print $2}' | head
/usr/include/at-spi2-atk/2.0
/usr/include/at-spi2-atk
/usr/include/mono-2.0
/usr/include/mono-2.0/mono/cil
/usr/include/mono-2.0/mono
/usr/include/mono-2.0/mono/jit
/usr/include/mono-2.0/mono/metadata
/usr/include/mono-2.0/mono/utils
/usr/include/nss3/templates
/usr/lib64/akonadi/contact/editorpageplugins
Most directories contain files that are owned by packages, although I
could find an interesting number of actual orphan files on my /usr
tree! Upon quick inspection it looks like remains from old packages
after they got upgraded. Some of the remains date fc22. There's an
insignificant bunch of files I installed in /usr/local too.
$ find $(awk '{print $2}' <not_owned.txt) -type f |
grep -v ' ' | # I don't want to deal with spaces in file names
xargs rpm -qf |
grep 'not owned' |
wc -l
find: ‘/usr/lost+found’: Permission denied
find: ‘/usr/share/rhel/secrets’: Permission denied
1191
Sparing you more shell soup, under /usr I currently have 10738 files
owned by a package whose parent directories are *not all* owned,
belonging to 290 packages.
Once my /usr is clean I will try to monitor it after each upgrade. It
should be easy enough to script, although scanning 18GB of /usr
against the whole RPM database takes some time.
I don't know whether we have tools checking this automatically, and if
DNF/RPM tells you about paths that weren't removed along with their
packages during a transaction, I'm interested in having this
information on every `dnf update`.
Cheers,
Dridi
7 years, 4 months
[OT] Best Practices: Populating RPM SPEC %defines in basic Ant build management
by Bryan Smith
PREFACE: My apologies as this may be off-topic. But I figured this
might be the best set of SMEs to ask this question, especially since
I'm drawing a blank from when I had to do this a few years ago.
Environment:
- Disconnected systems (no or very limited Internet access)
- Apache Ant build management
Best Practice Sought:
- Solution to populate %defines at the top of RPM SPEC files
Feel free to tell me to RTFM with a link or anything else. I just
haven't kept up with the latest set of 'Best Practices' and/or tools
to manage many of the common %defines at the top of RPM SPEC files in
an Ant build management solution.
I.e., I assume there is a way to manage this better than just some
scripts called as part of the buildfile that does direct file
manipulation (e.g., via sed) and/or populates via environmental
variables
Side Note: We were looking at introducing Maven-Nexus as well, but
we're sticking with just our Git repos and Ant to match our
traditional software development and its build process. This would be
for packaging things into RPM atop of all that.
Again, likely off-topic and/or remedial for this list, but I'd figure
I'd ask as I'm several years out-of-date.
-- bjs
--
Bryan J Smith - http://www.linkedin.com/in/bjsmith
E-mail: b.j.smith at ieee.org or me at bjsmith.me
7 years, 4 months
PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.
by Matthew Miller
I've talked about this before, but maybe the F26 cycle is time to make
it happen. Right now, we have only one way of saying "this bug is
important to the project as a whole; could we please get resources
focused on it?" — and that way is to stop the whole vehicle until
someone does something about it. This has always been kind of
problematic, even though it has served well enough so far... but as we
move to more deliverables and add things with different lifecycles, I
think we need something else.
We have the Accepted Blockers
<https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist>
list. The process is nicely documented at
<https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process>; please
read that if you're not familiar.
I propose we create a parallel "Critical Issues" list, using basically
the same procedures. Issues eligible for this status would be those
which do not necessarily fail a release criterion but which have
critical impact on a Fedora Edition or on a council-approved Fedora
Objective.
Since Fedora is a volunteer process, this can't be backed by a hard
mandate (like the "block the release!" emergency brake), but if we
agree together to take it seriously, I think it will still provide a
useful list. Anyone with a package or component involved in the issue
will be able to see the impact, and take that into account when
prioritizing. As FPL, it'd give me a nice overview of issues that might
need extra resources or coordination.
We could either implement this by extending the existing blocker bug
process — adding a new tracker bug, add a new category in the
blockerbug app, and review candidate issues at the normal blocker
review meetings. Or, it could be done in parallel, with a
separately-configured instance of the blockerbug app and with review
in a separate meeting called as needed (or maybe just FESCo?)
As with the existing Blocker or Freeze Exception levels, we could also
introduce a second tier "Important Issues", which could have a wider
net than the rules for "Critical Issues". I'm not sure about that.
In any case, what do you all think?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7 years, 4 months
Pondering security update time frames
by Andrew Lutomirski
It seems to me that Fedora has three severe distribution wide issues
relating to security updates:
1. Updates, even critical security updates, are very slow. Getting an
update out involves creating a build and an update (which is
reasonably fast for most packages), pushing the update to
updates-testing, getting karma, and pushing to updates. The latter
three can happen in parallel in the best case. The big problem as I
see it is that pushing updates is painfully slow. For reasons that
I'm sure make a lot of internal sense, updates seem to get stuck
behind broken composes and such all the time. Can this be made
better?
IMO it should be possible for a security update to be checked,
incrementally, for sanity with respect to the rest of the package
repository, and then pushed out, without needing to do whatever
expensive work a compose does. If some other update breaks the
compose, I don't think this should cause security updates to get
stuck.
2. There doesn't appear to be a working process to get updates out
quickly. As a current and pressing example, there is no build for
Firefox 49.0.2.
3. AFAIK Fedora has no means by which it can participate in embargoed
updates. For this to work, I think there ought to be private git
branches, a way to get Koji to make a private build from a private git
branch, and a way to get private karma on a private update. Then,
when an embargo is lifted, the packager could merge the private branch
in, the various infrastructure bits could notice that the very same
git commit is now public and permit all of the private builds,
updates, and karma to become public and allow an immediate push to
updates.
7 years, 4 months