Re: Please fix your bugzilla.redhat.com account
by Christopher
Can anybody tell me what this is all about? I'm using my @fedoraproject.org
address in Bugzilla, and was previously told that was okay. I don't want to
use my forwarding address to authenticate to Bugzilla, because that can
change. Yet, I'm getting the following errors now as a result of that. I
seem to recall addressing this before, but it seems to be happening again.
Anybody know why?
On Thu, Aug 10, 2017 at 2:21 AM <accounts(a)fedoraproject.org> wrote:
> Greetings.
>
> You are receiving this email because there's a problem with your
> bugzilla.redhat.com account.
>
> If you recently changed the email address associated with your
> Fedora account in the Fedora Account System, it is now out of sync
> with your bugzilla.redhat.com account. This leads to problems
> with Fedora packages you own or are CC'ed on bug reports for.
>
> Please take one of the following actions:
>
> a) login to your old bugzilla.redhat.com account and change the email
> address to match your current email in the Fedora account system.
> https://bugzilla.redhat.com login, click preferences, account
> information and enter new email address.
>
> b) Create a new account in bugzilla.redhat.com to match your
> email listed in your Fedora account system account.
> https://bugzilla.redhat.com/ click 'new account' and enter email
> address.
>
> c) Change your Fedora Account System email to match your existing
> bugzilla.redhat.com account.
> https://admin.fedoraproject.org/accounts login, click on 'my account',
> then 'edit' and change your email address.
>
> If you have questions or concerns, please let us know.
>
> Your prompt attention in this matter is appreciated.
>
> The Fedora admins.
>
6 years, 8 months
openjpeg-2.2.0
by Sandro Mani
Hi
openjpeg-2.2.0 was just release, carrying a large number of security
fixes. I'd also like to update it for F25 and F26, since it is ABI and
API compatible with 2.1.x, there is however the problem that openjpeg2
installs its headers under /usr/include/openjpeg-$major.$minor, so this
would mean that the location of headers changes, potentially leading to
compilation failures in the unlikely event users have hardcoded the path
to said headers (instead of using the pkgconfig file). I'd say however
that this risk is worth the update.
Any objections to updating?
Thanks
Sandro
6 years, 8 months
Debuginfo/debugsource: mingw package with mixed host and target
debuginfos
by Sandro Mani
Hi
mingw-qt5-qtbase and mingw-qt5-qttools are currently FTBFS [1] due to
errors like
error: Could not open %files file /builddir/build/BUILD/qtbase-opensource-src-5.9.1/debugsourcefiles.list: No such file or directory
Duplicate build-ids /builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/i686-w64-mingw32/lib/libQt5Bootstrap.so.5.9.1 and /builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/x86_64-w64-mingw32/lib/libQt5Bootstrap.so.5.9.1
Duplicate build-ids /builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/i686-w64-mingw32/lib/libQt5BootstrapDBus.so.5.9.1 and /builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/x86_64-w64-mingw32/lib/libQt5BootstrapDBus.so.5.9.1
Could not open %files file /builddir/build/BUILD/qtbase-opensource-src-5.9.1/debugsourcefiles.list: No such file or directory
Indeed, these packages need special logic to deal with debuginfo files because both host as well as target binaries are produced by the package, the result up to now being
mingw-qt5-qtbase-debuginfo -> host
mingw32-qt5-qtbase-debuginfo -> target
mingw64-qt5-qtbase-debuginfo -> target
This was handled in the spec file [2] as
# Override the __debug_install_post argument as this package
# contains both native as well as cross compiled binaries
%global __debug_install_post %%{mingw_debug_install_post}; %{_rpmconfigdir}/find-debuginfo.sh %{?_missing_build_ids_terminate_build:--strict-build-id} %{?_find_debuginfo_opts} "%{_builddir}/%%{?buildsubdir}" %{nil}
Long text short question: can someone help me adapt this logic for the new debuginfo/debugsource mechanism?
Thanks
Sandro
[1] https://koji.fedoraproject.org/koji/getfile?taskID=21030286&volume=DEFAUL...
[2] https://src.fedoraproject.org/rpms/mingw-qt5-qtbase/blob/master/f/mingw-q...
6 years, 8 months
mock's dual bootstrapping enabled by default for existing copr projects
by Michal Novotny
Hello,
while working on another thing, I noticed that when use_bootstrap_container
project option was introduced (Wed Jun 14 this year), it was introduced as
enabled for existing COPR projects at that time. That was not exactly
intended as this feature is experimental.
Enabling this option makes mock setup two chroots during build:
- "bootstrap" one with the latest dnf, rpm (and other build tools) for the
given build chroot (e.g. fedora-26-x86_64)
- the one where the build is actually run (which is of the same os,
version, and arch as the bootstrap one) and that is initially setup by the
tools from the bootstrap one
This makes build last a bit longer (in order of minutes depending on
package download speed) and it might cause a build to fail unexpectedly in
case there is e.g. bug in rawhide dnf (or in experimental dnf that is built
in your copr chroot).
If this option is disabled, host (builder) system dnf is used to setup the
build chroot. There is no bootstrap chroot setup and hence it is faster.
The longer running time might be a problem so, please, if you are a long
term users of COPR and you don't want the feature enabled, check your
project settings and disable it.
Sorry for accidentally enabling it
clime
6 years, 8 months
Self Introduction: David J Battaglia
by djb djb
Hello,
I am just starting out with fedora packaging. My background is mostly
working in NOCs, infrastructure support roles and working as sys admin.
Look for forward to learning as much as possible with the hopes of getting
sponsored.
Regards,
David J Battaglia
6 years, 8 months
Arbitrary Branching and solving the "Change Checkpoint? Better hit
the gas!" problem
by Matthew Miller
Our Change process has the basic assumption that if a Change isn't
working, we will be able to back out. But, in practice, when there are
problems, we often find it that it's easiest to shrug and go forward,
scrambling to fix problems in the change itself as well as any fallout.
I won't say this is a _failure_ exactly — with the Change process, at
least, we do have that checkpoint where we know the scramble is needed
rather than waiting until the very last minute. But, especially if we
are serious about a six-month schedule, it'd be _better_ if we could
simply decide at the Change Checkpoints whether to include the feature
at all.
Arbitrary branching and Modularity give us a way to do this. We can, at
any time, say "this release includes this set of modules" (see
https://docs.pagure.org/modularity/design/constructing/compose-distributi...
and
https://docs.pagure.org/modularity/design/constructing/back-together.html).
I'm really liking what I'm seeing from the Boltron demo, questions
about how to actually manage modules as an end user notwithstanding. If
we can deliver this with minimal end-user disruption and yet give
ourselves capabilities like this, it's a huge success.
(Aside: This possibly involves what the Boltron walkthrough calls
"system profiles". Modularity team! This isn't in the docs yet. Can you
clarify?)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 8 months
Modularity Working Group IRC Meeting Minutes (2017-08-08)
by Nils Philippsen
=================================================================================
#fedora-meeting-3: Meeting of the Modularity Working Group (once every two weeks)
=================================================================================
Meeting started by nils at 14:00:21 UTC.
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-3/2017-08-08/modularity_...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-3/2017-08-08/modularity_...
Log: https://meetbot.fedoraproject.org/fedora-meeting-3/2017-08-08/modularity_...
Meeting summary
---------------
* Roll Call (nils, 14:00:29)
* Agenda (nils, 14:03:56)
* Module naming policies (nils, 14:03:56)
* Host & Platform availability (nils, 14:03:56)
* Fedora 27 modular design (nils, 14:03:56)
* Modular Atomic Host (nils, 14:03:56)
* Modular Guidelines and Review Process (nils, 14:04:37)
* Module naming policies (nils, 14:05:05)
* LINK: https://pagure.io/modularity/pull-request/43 Module naming
policy proposal (contyk, 14:06:40)
* Host & Platform availability (nils, 14:08:14)
* The very first builds of Host & Platform are now available and the
initial test composes should be ready later today. (contyk,
14:14:56)
* Images will be available once we have the new installer module
available. The current Platform is messy and will be sanitized over
the next week or two. (contyk, 14:15:29)
* Fedora 27 modular design (nils, 14:15:42)
* We will be going through the list of required modules for Fedora 27,
their built-time and runtime dependencies and deciding what buckets
they should go into. (contyk, 14:25:44)
* We will also generate module templates for upstream maintainers
willing to help us with implementation, to guide them (contyk,
14:26:11)
* LINK: https://github.com/fedora-modularity/dependency-report A
helper module dependency reporting tool. WIP. (contyk, 14:26:27)
* ACTION: langdon to file a ticket in pungi(?) backlog to create a
modulemd -> pungi config generator (langdon, 14:44:57)
* Modular Atomic Host (nils, 14:46:03)
* LINK: https://pagure.io/atomic-wg/issue/312 Experiment with building
Atomic Host out of a module (contyk, 14:46:36)
* Expect a modular Atomic Host prototype within the next two weeks!
(contyk, 14:50:51)
* Modular Guidelines and Review Process (nils, 14:52:50)
* fedora council approved fesco approving the initial guidelines and
process, after that this group will be responsible for maintaining
them (langdon, 15:00:05)
* contyk, nils and geppetto are updating the spec (based on a couple
missing items from the last week or so) and associated guidelines to
be as close as possible (langdon, 15:00:23)
* ACTION: langdon shooting to file a ticket with fesco by the end of
the week to review it at the next fesco meeting next friday
(langdon, 15:00:40)
* ACTION: needs to get the bz product created to file review
requests.. which I don't think we have done or assigned anyone too
(langdon, 15:00:50)
* ACTION: needs to identify any other gaps in the process that I am
not thinking of (langdon, 15:01:03)
Meeting ended at 15:04:11 UTC.
Action Items
------------
* langdon to file a ticket in pungi(?) backlog to create a modulemd ->
pungi config generator
* langdon shooting to file a ticket with fesco by the end of the week to
review it at the next fesco meeting next friday
* needs to get the bz product created to file review requests.. which I
don't think we have done or assigned anyone too
* needs to identify any other gaps in the process that I am not thinking
of
Action Items, by person
-----------------------
* langdon
* langdon to file a ticket in pungi(?) backlog to create a modulemd ->
pungi config generator
* langdon shooting to file a ticket with fesco by the end of the week
to review it at the next fesco meeting next friday
* **UNASSIGNED**
* needs to get the bz product created to file review requests.. which
I don't think we have done or assigned anyone too
* needs to identify any other gaps in the process that I am not
thinking of
People Present (lines said)
---------------------------
* contyk (100)
* langdon (57)
* nils (57)
* asamalik (29)
* jkaluza (29)
* threebean (26)
* zodbot (15)
* ttomecek (14)
* tflink (3)
* geppetto (2)
* sgallagh (1)
* jkurik (1)
* dgilmore (1)
* mikedep333tflink (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
6 years, 8 months