Kevin Kofler via devel wrote:
> Dominique Martinet wrote:
>> Before making each of these safer we should make sshd not link with so
>> many things in the first place.
>
> Indeed. E.g., Arch Linux does not transitively link sshd against liblzma.
> Fedora does because of this innocuous-looking
Sérgio Basto wrote:
> On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote:
>> a project
>> where the primary sponsor and downstream no longer provides
>> source code freely and openly
>
> what you are talking about ? all RHEL Source are freely available on
>
Hi,
Michael J Gruber wrote:
> Thank you for all the effort you have put into maintaining these
> packages so far, for the benefit of all of Fedora, and consequently
> its downstream!
Thanks!
> Your reasons resonate with me, though I'm not taking the same
> conclusions. Have you arranged
:
asciidoc
git-filter-repo
rpmlint
Thanks,
--
Todd Zullinger
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US
Carlos O'Donell wrote:
> On 6/26/23 18:47, Jeff Law wrote:
>> What Red Hat has done may be technically legal and perhaps good for
>> its business. However, to me it's ethically unconscionable. Those
>> who know me know I'm not an zealot, but I do have a baseline set of
>> ethical values and Red
Stephen Gallagher wrote:
> On Fri, Jun 16, 2023 at 11:53 AM Miro Hrončok wrote:
>>
>> On 16. 06. 23 15:39, Stephen Gallagher wrote:
>>> This leads me to my next schedule announcement: we will be performing
>>> the initial CentOS Stream 10 branch creation in Gitlab for all
>>> packages in the
Pavel Raiskup wrote:
>> I thought that previous fedpkg or mock releases printed a
>> large banner which explained this a bit and linked to
>> further details? I would have thought that was still in
>> place, but perhaps not.
>
> Mock prints the banner you expect iff the corresponding
> epel-*
bradb...@seanet.com wrote:
> I misspelled centos as contos Now fedpkg mockbuild works with the proper
> links:
>
>>ls -l $HOME/.config/mock
> total 8
> lrwxrwxrwx. 1 bradbell bradbell 41 Jun 3 19:09 epel-8-x86_64.cfg ->
> /etc/mock/centos-stream+epel-8-x86_64.cfg
> lrwxrwxrwx. 1 bradbell
I wrote:
> I may attempt to resolve some of the issues, but if there's
> some documentation on the changes it would make it a lot
> easier. :)
I filed an upstream PR with a couple of commits:
https://github.com/rpm-software-management/rpmlint/pull/1066
This fixes the test suite and works in
Hi,
Michal Domonkos wrote:
> We're currently preparing an update to RPM 4.19 ALPHA for Rawhide in a
> side-tag. The new version features a soname bump:
Is there a porting guide for rpm python users? The rpmlint
package has a number of test failures and quite likely other
breakages which may
Chris Adams wrote:
> Kind of a random thing, but... I would like to write up how to use GRUB2
> to do BIOS-PXE+UEFI-PXE+UEFI-HTTP boot. I asked for the Fedora packages
> to include the needed PXE bit, and it does now (thanks!), so I feel I
> owe a good explanation on how to use it. :)
>
> I
TLDR; I'm in the "please, not a web forum" camp, but I also
feel like this is effectively a foregone conclusion,
unfortunately.
As a maintainer of a small number of packages, I follow
devel to keep up with changes affecting the distribution and
occasionally chime in or find areas where I can help
Laura Flores wrote:
> Link to the thread:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/SN2KUYRQRVPN5YD25LQRCRTOXGH2TUDH/
I think https://pagure.io/fedora-infrastructure/issue/11233
is tracking this. It looks like the problematic system
should be out
Chris Adams wrote:
> Once upon a time, Michael Catanzaro said:
>> On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams
>> wrote:
>>>I wouldn't do that part; that's additional disk I/O for every prompt.
>>>Especially when the system might be having issues, users (especially
>>>root) don't need
Chris Murphy wrote:
> I've implemented the suggested two line change to
> .bash_profile:
>
> # User specific environment and startup programs
> shopt -s histappend
> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
>
[...]
> Any thoughts?
As others have said, enabling this by default has
Florian Festi wrote:
> On 3/29/23 10:31, Michael J Gruber wrote:
>> Has `%patchN` been deprecated in favour of `%patch N`?
>
> Yes, see %patch section on
> https://rpm-software-management.github.io/rpm/manual/spec.html
Quoting that:
%patch is used to apply patches on top of the just
Hi,
Chris Kelley wrote:
> TL;DR dogtag-pki is not installable on F38/Rawhide because
> it fails the GPG check (F37 and prior are fine), even if
> --nogpgcheck is specified, and I don't understand why.
>
> 1) Why does the key not work?
> 2) Why does --nogpgcheck not work?
It seems like it must be
Tomas Korbar wrote:
> Extending the question here.
>
> -- Forwarded message -
> From: Tomas Korbar
> Date: Thu, Mar 9, 2023 at 9:51 AM
> Subject: License: GPL-3.0-or-later AND GPL-2.0-or-later
> To:
>
>
> Hi guys,
> I am doing the conversion of license tags in my projects and
Petr Pisar wrote:
> [...] Either turn that directory into a git repository (git
> init-db . && git add hello.spec && git commit -a) ...
Just a minor, tangential nit, `git init` is the preferred
and documented command. The `git init-db` command is an
ancient name for it. The documentation for
Kenneth Goldman wrote:
> https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
> GNU_Hello/
>
> ~~~
>
> when running that tutorial (Fedora 37, x86), I get this error:
>
> ERROR: Exception(/home/kgold/hello/hello-2.10-1.fc37.src.rpm)
>
Alexander Ploumistos wrote:
> On Mon, Feb 27, 2023 at 4:15 AM Globe Trotter via devel
> wrote:
>> I wonder if anyone has any suggestions on how to get
>> around this problem. I create my local repo using
>>
>> createrepo .
>>
>> inside my RPMS/x86_64 directory.
>
> Is there a specific reason you
Hi,
Globe Trotter via devel wrote:
> I have been trying to package slim again. The package does not come with a
> signature or a gpg key.
>
> From
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification
> I don't see an option of what to do if there is no
Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
>> 'git pull --rebase' is a strange command to suggest. I does the job,
>> but almost by accident, and it's confusing things by mixing in rebasing.
>> Can we make this just say 'git fetch' or 'git fetch -v' ?
>
> The thing is, you
Christopher Klooz wrote:
> A fresh installation of Fedora 37 has by default the "--supervised" option
> active in its gpg-agent systemd file
> (/usr/lib/systemd/user/gpg-agent.service).
>
> According to GnuPG Docs [1], this option is deprecated. Once gpg-agent is
> invoked, the log of "systemctl
Zbigniew Jędrzejewski-Szmek wrote:
> Yes, this is what I was talking about too. Because rpmbuild does not set
> %_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
> versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
> Personally, I have dozens of
Hi,
Luya Tshimbalanga wrote:
> Hello team,
>
> While building opensubdiv, the failure[1] occurred on doc subpackage with
> the following line:
>
> BuildError: The following noarch package built differently on different
> architectures: opensubdiv-doc-3.5.0-1.fc38.noarch.rpm
> rpmdiff output
Hi,
Florian Weimer wrote:
> I don't see what spec file aspect is causing this failure:
>
> $ fedpkg clone -a cups-bjnp
> Cloning into 'cups-bjnp'...
> remote: Enumerating objects: 278, done.
> remote: Counting objects: 100% (278/278), done.
> remote: Compressing objects: 100% (222/222), done.
>
Vitaly Zaitsev via devel wrote:
> On 29/11/2022 09:24, Bob Hepple wrote:
>> "... Arch supports signed git tags. I'm hoping Fedora does too.
>
> On Fedora you must upload source tarball, its signature and public key to
> the Fedora look-aside cache
A minor expansion on that; the public key /
Sérgio Basto wrote:
> I fully agree with this commit, maybe you can go ahead with an official
> PR.
Done, thanks!
EPEL8 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/57
EPEL7 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/58
--
Todd
signature.asc
Sérgio Basto wrote:
> in an effort to do things correctly and without hacks
> I noticed that redhat-rpm-config-202-1.fc35.noarch defines
> %bash_completions_dir and epel-rpm-macros %defines bash_completion_dir
>
> Which one is the correct ? hopefully we have a few case [1] (18) vs [2]
> (14)
>
Neal Gompa wrote:
> On Tue, Nov 15, 2022 at 11:05 AM Todd Zullinger wrote:
>> Am I missing something obvious or does licensecheck not work
>> as expected? This is with licensecheck-3.3.0-2.fc36.noarch.
>
> licensecheck does not follow/use SPDX-License-Identifier
Chris Adams wrote:
> Once upon a time, Todd Zullinger said:
>> Sylvain Jones via epel-devel wrote:
>>> It appears the update to pypolicyd-spf-2.9.3 from pypolicyd-spf-2.0.x
>>> crashes Postfix unexpectedly. Perhaps a missing dependency?
>>
>> It
Neal Gompa wrote:
> On Tue, Nov 15, 2022 at 6:24 AM Miro Hrončok wrote:
>> Do we have a command line tool for this? Does licensecheck support SPDX
>> identifiers?
>>
>> (I find the use of browser extension for this very weird. I have the LICENSE
>> file unpackaged with the sources on my machine,
Hi,
Sylvain Jones via epel-devel wrote:
> It appears the update to pypolicyd-spf-2.9.3 from pypolicyd-spf-2.0.x
> crashes Postfix unexpectedly. Perhaps a missing dependency?
It looks like pypolicyd-spf-2.9.3-2 should be in
epel-testing now. That update will install python3-authres,
so you may
Ian Laurie wrote:
> On 11/2/22 04:22, Dmitry Belyavskiy wrote:
>
> Dear colleagues,
>
> I've just pushed the updates for OpenSSL fixing 2 CVEs evaluated as HIGH.
> Could you please check the freshly pushed builds to get necessary karma
> ASAP?
>
> Are we not fixing Fedora 35?
Hi,
Richard W.M. Jones wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2
> https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
> https://bugzilla.redhat.com/2042099
>
> The RPM database is supposed to move from /var/lib/rpm to
> /usr/lib/sysimage/rpm. This was supposed to
manuel wolfshant wrote:
> On 10/22/22 00:22, Troy Dawson wrote:
>>
>> distribution-gpg-keys-1.78-1.el7 is currently in testing.
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-318362b0c0
>>
>> You can get things moving my using the epel-testing repo
>> yum --enablerepo=epel-testing
Hi,
Sergey Mende wrote:
>> Mildly related, I've been working on getting rpmlint updated
>> to 2.3.0 and now 2.4.0. I filed a PR to get comments from
>> other rpmlint maintainers and (hopefully) catch any bugs I
>> may have introduced:
>>
>>
Miro Hrončok wrote:
> On 03. 10. 22 12:09, Vít Ondruch wrote:
>> And how is this change related to:
>>
>> https://src.fedoraproject.org/rpms/rpmlint/c/2beb19345e6644cb1b5ee8092b8533c8984cd21c?branch=rawhide
>
> I was unaware of this change at all.
>
> Tom, should rpmlint ditch that file instead
Kevin Fenzi wrote:
> On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
>> Isn't peer review much better and easier solution over all? We could also
>> require signed commits I guess.
>
> I think it would slow things down quite a lot to require peer review of
> every commit.
>
> I'd
Kevin Fenzi wrote:
> Lest it sound like everyone just wants it to behave this way, I
> personally _do_ like getting emails for actions I did myself.
> I find that later when I am looking back to see what changed by who I
> can (sometimes surprisingly) find out it was me. :)
>
> So, I would
Hi,
Ron Olson wrote:
> Sorry if I missed something, but under Rawhide I
> discovered when I tried to “more somefile.txt” I got
> “less” behavior, while Fedora 35 still runs more like, uh,
> more.
I'm not quite sure what "less" behavior you mean, so I'm
only guessing.
If you mean that more
Fabio Valentini wrote:
> Fri, Nov 26, 2021 at 8:37 PM Susi Lehtola
>> I am experiencing problems updating packages employing GitHub source
>> URLs. For instance,
[...]
>> https://github.com/pyscf/pyscf/archive/v2.0.1/pyscf-2.0.1.tar.gz
>> Download failed:
>> 404 Client Error: Not Found for url:
>>
Miro Hrončok wrote:
> On 03. 06. 21 21:51, Tom Callaway wrote:
>> I have landed rpmlint 2.0.0 in rawhide, along with Mirek Suchý's toml
>> configs (with updates for the licenses.toml). PRs, bug reports, and
>> suggestions welcome.
>
> Thanks, spot!
>
> I'm looking at the stuck Python 3.10
Tony Breeds wrote:
> One annoying gotcha I hit after adding the new key to my agent was that
> many places now failed to auth as it tried each key in my agent and
> exceeded the MaxAuthTries in sshd
The IdentitiesOnly option to ssh is useful for that. From
ssh_config(1):
Specifies that
Pierre-Yves Chibon wrote:
> On Fri, Feb 05, 2021 at 12:11:45PM +0100, Florian Weimer wrote:
>> Would it be possible to add the sequence of commands to the proposal to
>> convert an existing clone with unpushed changes?
>>
>> I think it is something along the lines of (for src.fedoraproject.org):
[re-sending to devel instead of devel-announce, apologies if
this arrives twice.]
Kevin Fenzi wrote:
> Greetings everyone and thanks for your patience with us today.
Thank you Kevin and all the folks who help make such changes
happen relatively seamlessly. :)
> You will want to re-clone any
Hi,
Ian McInerney wrote:
> Why not split the cvs package like git and create a cvs-core package that
> actually contains the cvs executables/files and then only BR/require that
> from git/git-cvs? That would be the more immediate solution that prunes the
> affected packages from the xinetd
Hi,
Sérgio Basto wrote:
> Like tftp we may replace xinetd by systemd service files [1] ,
> if we replace cvs-inetd by a systemd service, the problem is solved.
>
> [1]
> https://src.fedoraproject.org/rpms/tftp/c/15a26fcde8a0078766b6bbba183d89f920e51535?branch=master
The cvs package has
Hi,
Richard W.M. Jones wrote:
> On Mon, Nov 09, 2020 at 11:17:38AM -0500, Todd Zullinger wrote:
>> The cvs and cvsps BR's are for the test suite, since we
>> prefer to use the comprehensive test suite that git
>> includes. So dropping those BR's is not a useful option.
>
Hi,
Richard W.M. Jones wrote:
> On Mon, Nov 09, 2020 at 12:09:00PM +0100, Miro Hrončok wrote:
>> rjones: xinetd, numad
>
> Your "packager dashboard"[1] which I found for the first time today is
> very useful!
>
> Turns out the problem for my package is this weird ol' dependency chain:
>
>
Michael J Gruber wrote:
>> = NOTE about xinetd =
>>
>> Many packagers are listed as affected by xinetd. The dependency chain is:
>>
>> cvs (kasal, ppisar)
>> cvs-inetd.noarch requires xinetd
>>
>> git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz)
>>
I wrote:
> Zdenek Dohnal wrote:
>> CCing Git maintainer to see whether it can be implemented or not.
I somehow forgot to say that I'm just one of several
maintainers for the git package. :)
I've Cc'd the git-maintainers alias to include the other
folks.
--
Todd
signature.asc
Description:
Hi,
Zdenek Dohnal wrote:
> To be honest, I'm sad about the change.
It is just a default though, and I'll certainly change it on
my systems. But like many others, I too can still recall
(decades ago) being dumped into vi and having no clue how to
do anything -- including just exiting.
> I'm not
Hi,
E.N. virgo wrote:
>> Why are replying from there instead of using your email client normally?
> I set this list to send digests instead of individual messages;
> so, I was using other means to get to the in-reply-to field.
If you're using the "Plain Text Digests" delivery mode, you
might
Markus Larsson wrote:
> While I'm fine with spending 2500€ of company money on a
> work machine, I'm rather hesitant to spend that kind of
> money on laptops for the kids :)
Isn't that where some good, old-fashioned nepotism comes in?
The kids get a title, a valuable first entry on their CV,
and
I wrote:
> clime wrote:
>> It seems the f32's git-core got many more deps for some reason, even
>> such as dbus-broker or systemd.
[...]
> I'll try to poke a bit in the next few days as I can make
> some time. I had not noticed the inflated depchain. Thank
> you for pointing it out.
I was
Hi,
clime wrote:
> Hello,
>
> I very much appreciate the git-core package but there seems to be some
> change under f32 which makes it download many more deps during
> installation.
>
> This is f32:
>
> $ mock -r fedora-32-x86_64 install git-core
> ...
> =
> Package
>
Hi Ivan.
Ivan Chavero wrote:
> Are there any plans to upgrade the spec file of rubygem-asciidoctor for
> Fedora 31 to the 2.0.10 version?
Unfortunately, I don't think it would be an appropriate
update for Fedora 31. And update from 1.5.6 to 2.0.10 would
cause some package builds to break and
Jakub Jelinek wrote:
> On Sat, Mar 14, 2020 at 11:54:54PM +0100, Dominik 'Rathann' Mierzejewski
> wrote:
>>> Known issue?
>>
>> The above was with gcc-10.0.1-0.9.fc32 and annobin-9.06-1.fc32.
>>
>> Looks like it was fixed in the meantime as another build gets
>> gcc-10.0.1-0.8.fc32 and the same
Andrew C Aitchison wrote:
> On Sun, 9 Feb 2020, Pete Geenhuizen wrote:
>
>> Is this the right list to ask about the status of ClamAV 0.102.1 and
>> when it will be released?
>> If this is not the right list please tell which list I to which I
>> should direct this question.
>
> I don't have
Fabio Valentini wrote:
> On Mon, Dec 23, 2019, 17:45 J. Scheurich wrote:
>> $ git commit
>> error: gpg failed to sign the data
>> fatal: failed to write commit object
>>
>> Same problem 8-(
>>
> Looks like you have the option to sign your git commits turned on globally,
> probably in ~/.gitconfig
Dridi Boukelmoune wrote:
> On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
>>
>> On 11/1/19 1:47 PM, Daniel Walsh wrote:
>>> Flat pack should be doing a requires(post): selinux-policy-base
>>>
>>> To make sure it is installed before flatpack.
>>
>> Thanks. The proper incantation actually
Hi,
I wrote:
> I'm planning to push asciidoctor-2.0.10 to rawhide in the
> next few days.
This has now been built and should show up in the next
rawhide compose.
> This is a major bump from our current 1.5.8, but upstream
> has worked hard to fix regressions found since the initial
> 2.0.0
Hi Fabio,
Fabio Valentini wrote:
> I'm the maintainer of rubygem-jekyll-asciidoc, and I think there
> shouldn't be issues with it when updating rubygem-asciidoctor.
> The Jekyll AsciiDoc plugin is published by the asciidoctor project
> themselves, so I just hope they know what they're doing :)
Hi Robert-André,
Robert-André Mauchin wrote:
> Using Igor's whatrequires script
> (https://gist.github.com/ignatenkobrain/a2b21a4db497a2a4b441e3957fcc8483), we
> get:
Nice. I didn't know about that one either.
> PACKAGE DEPENDENT
>
Hi Miro,
Miro Hrončok wrote:
> On 25. 09. 19 17:10, Todd Zullinger wrote:
>> dnf repoquery -q --qf '%{name}' --archlist=src --releasever=rawhide \
>> --disablerepo='*' --enablerepo=rawhide-source \
>> --whatrequires asciidoctor --whatrequires rubygem-asciidocto
Hi Vit,
Vít Ondruch wrote:
> Dne 24. 09. 19 v 17:47 Todd Zullinger napsal(a):
>> These srpm's require asciidoctor or rubygems-asciidoctor:
>>
>> awesome
>> booth
>> hugo
>> ipmctl
>> js8call
>> mod_auth_mellon
&g
Hi all,
I'm planning to push asciidoctor-2.0.10 to rawhide in the
next few days. This is a major bump from our current 1.5.8,
but upstream has worked hard to fix regressions found since
the initial 2.0.0 release back in March.
The 2.0.0 release notes can be found at:
Miro Hrončok wrote:
> Note that jgit is not (yet) orphaned nor retired, and its dependencies might
> be picked up by somebody. I suggest to remove the dep in rawhide temporarily
> (to make the next weeks reports more readable and shorter to calculate (the
> present one took 2 days)). Once the dust
Hi,
Pavel Cahyna wrote:
> On Mon, Jul 29, 2019 at 12:59:22PM +0200, Miro Hrončok wrote:
>> On 29. 07. 19 12:37, Miro Hrončok wrote:
>>> The following packages are orphaned and will be retired when they
>>> are orphaned for six weeks, unless someone adopts them. If you know for sure
>>> that the
Hi,
Fred Gleason wrote:
> On Wed, 2019-05-01 at 16:17 -0700, Kevin Fenzi wrote:
>> Can you please refile that as two bugs? On python3-pycurl and
>> python3-mysql?
>>
>> The python34 component is only for python34 itself, you will need to
>> get
>> those other two packages to fix things.
>
> I
Neal Gompa wrote:
> If devtoolset is available for EPEL6 (which I think it is?)
I don't believe devtoolset was enabled for el6 in koji.
When it was added to the mock configs for el6/el7, the
consensus on the epel list was that it would be added to el6
if there was sufficient demand. I've only
Antonio Trande wrote:
> On 09/04/19 22:29, Kevin Fenzi wrote:
>> Can any of you folks seeing this:
>>
>> Run this script:
>> https://paste.fedoraproject.org/paste/tWt5LBT13-~d22wBpo38uQ/raw
>>
>> and send me the output?
>
> Sorry,
>
> how this script works?
You can download the script (using
Richard W.M. Jones wrote:
> On Tue, Mar 12, 2019 at 11:38:47AM +0100, Miro Hrončok wrote:
>> rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle,
>> xmvn, plexus-utils
>
> I'm unclear what if anything I could do (apart from maintaining loads
> of Java packages which isn't going to
Hi,
Globe Trotter wrote:
> Thanks, and that takes care of it.
Glad that helped.
> Thanks also for letting me know of preferred options. I am
> quite new to this and so any advice is always helpful.
>
> I will see if the copr maintainer wants to host my build.
> fetchmail 7.0.0 alpha has
Hi,
Globe Trotter wrote:
> Here is my fetchmail.spec:
[...]
> %build
> autoreconf -if
> %configure PYTHON-: --enable-POP3 --enable-IMAP
[...]
You want "PYTHON=:", not "PYTHON-:". The goal is to set the
PYTHON variable. I tend to put such definitions before the
configure call, e.g.:
%build
Hi,
[BTW, something is wrong with your mail client's quoting.
It is very hard to read your replies when your reply and the
text to which you are replying to are at the same quote
level.]
Globe Trotter wrote:
> Thanks! I see. Actually, I am not that keen on packaging
> fetchmailconf. I think that
Orion Poplawski wrote:
> With current koji buildroot I end up with:
>
> + ls -l /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ld.gold /usr/bin/ldd
> --w---. 1 root root 3814880 Feb 27 04:00 /usr/bin/ld
> -rwxr-xr-x. 1 root root 1841608 Feb 26 15:02 /usr/bin/ld.bfd
> -rwxr-xr-x. 1 root root 3814880 Feb
Hi,
Mohan Boddu wrote:
> Fedora 30 has now been branched,
Thanks, to you and the releng team. :)
> please be sure to do a git pull --rebase to pick up the
> new branch
A simple 'git fetch' should suffice to pick up the f30
branch. Depending on the state of one's repository, the
'git pull
Hi,
Richard Shaw wrote:
> Out of curiosity I took a look at abipkgdiff that's provided by the
> libabigail package and it's a python wrapper around abipkgdiff. I'm a
> little rusty on Python but I could probably use that as a very nice
> starting point...
>
> The next question is what package
Kevin Fenzi wrote:
> On 2/3/19 11:48 AM, Stephen John Smoogen wrote:
>> Over the weekend, tmz asked on IRC why their RHEL-6 build was
>> failing when it had not failed previously. The problem was that
>> the expat21 package was being seen in the buildroot and
>> over-riding the RHEL-6 expat.
>>
Stephen Gallagher wrote:
> On Fri, Jan 18, 2019 at 11:18 AM John Harris wrote:
>>
>> On Friday, January 18, 2019 8:14:32 AM EST Stephen Gallagher wrote:
>>> Note: Adding the Signed-off-by: line to a patch should be a conscious
>>> act and means that you certify you have the rights to submit this
Hi Zbigniew,
Zbigniew Jędrzejewski-Szmek wrote:
> I'll do a mass update to use C.UTF-8 for the packages in the list that
> follows, next week. I'll do test builds locally, and I'll only push to
> dist-git if the local builds succeed. Let me know if you want your
> package to be excluded.
> git
Sérgio Basto wrote:
> I had checked mock-core-config [1] , which are in use in copr (I guess)
> and can't enable developer tools .
> But on koji runs well , can you review this ? please .
>
> I could build azureus [4] on koji [2] which need eclipse-swt , but not
> on copr `Error: No Package found
Jonathan Dieter wrote:
> On Fri, 2018-10-19 at 21:37 -0700, Josh Stone wrote:
>> On 10/19/18 6:19 PM, Robert-André Mauchin wrote:
>>> On samedi 20 octobre 2018 00:31:50 CEST Jonathan Dieter wrote:
I'm trying to build duperemove[1] for epel7[2], and it's building on
all the arches except
Máirín Duffy wrote:
> So our Hyperkitty version is old here. I can't reporduce the issue on
> mailman3.org's HK, which is newer. I suspect this is a bug that's been fixed.
Indeed it was. An infrastructure ticket was filed ~7 months
back¹ and the issue was addressed upstream in 7558682 ("Fix
Dave Love wrote:
> I thought devtoolset was now available for building EPEL packages, but
> I've just tried with something that needs a more recent gcc than el6's
> but neither devtoolset-6 nor -7 are found. Should that work?
I don't think devtoolset was added to koji for el6. It's in
the mock
Brian (bex) Exelbierd wrote:
> On Mon, Oct 1, 2018 at 11:03 PM Björn Persson wrote:
>
>> Jason L Tibbitts III wrote:
>>> Indeed, asciidoctor works a bit better than asciidoc does but still
>>> converts quickly. It's actually in the "rubygem-asciidoctor" package.
>>
>> Maybe I'll try that next
Hi,
Florian Weimer wrote:
> * Todd Zullinger:
>
>> On the users list we enabled Mailman's DMARC mitigations
>> several months ago. That has allowed posts from users
>> @yahoo and other domains with strict DMARC settings to reach
>> list subscribers @gmail and o
Chris Murphy wrote:
> Semi-related to the "Attention Gmail users, please turn off HTML"
> thread; anyone *not* using gmail (e.g. all Yahoo email users) are
> having their emails put into spam by google mail.
>
>
>>This message has a from address in yahoo.co.uk but has failed yahoo.co.uk's
Daniel P. Berrangé wrote:
> On Fri, Aug 10, 2018 at 11:27:43AM +0200, Pierre-Yves Chibon wrote:
>> On Fri, Aug 10, 2018 at 10:16:13AM +0100, Daniel P. Berrangé wrote:
>>> ability to write to git, but there are a variety of ways to deal with that.
>>
>> I'm pretty sure we used to do this at one
Tim Landscheidt wrote:
> Todd Zullinger wrote:
>
>> […]
>
>> For example, the rpmlint's .gitignore contains the
>> following¹:
>
>> /*.rpm
>> /results_rpmlint/
>> /rpmlint-*/
>> /rpmlint-*.tar.gz
>
>> […]
>
> Apropos: Ma
Thomas Moschny wrote:
> 2018-07-24 20:28 GMT+02:00 Todd Zullinger :
>> Years
>> ago, I submitted a patch to fedpkg/rpkg to have it resepct
>> the existing .gitignore, such that if you have a pattern
>> which matches the source being added, fedpkg won't add
>>
Daniel P. Berrangé wrote:
> On Tue, Jul 24, 2018 at 01:32:45PM -0400, Todd Zullinger wrote:
>> Artur Iwicki wrote:
>>> That section of the guide is a bit poorly worded. You should *not* use "git
>>> add" on source tarballs. These should be added only via mea
Artur Iwicki wrote:
> That section of the guide is a bit poorly worded. You should *not* use "git
> add" on source tarballs. These should be added only via means of "fedpkg
> new-sources $FILES; git add ./sources". I believe what the guide means under
> "new source files" is e.g. when upstream
Jan Kratochvil wrote:
> On Wed, 04 Jul 2018 12:18:00 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>> What about just doing a mass specfile update now? I think asking
>> individual maintainers to fix their packages isn't worth their
>> time. It's a safe change,
>
> Is it? I haven't found whether this
Miro Hrončok wrote:
> We have 170 packages with blocked dependencies.
> We also have 176 packages that fail to build from source (+ ~10 more that
> are being handled).
>
> I need your help, I cannot possibly fix 178 packages.
>
> I've opened bugzillas for some, but let me ask you via e-mail
Miro Hrončok wrote:
> We have 170 packages with blocked dependencies.
> We also have 176 packages that fail to build from source (+ ~10 more that
> are being handled).
>
> I need your help, I cannot possibly fix 178 packages.
>
> I've opened bugzillas for some, but let me ask you via e-mail
I wrote:
> It should be possible to manually override the resolv.conf
> now by bind mounting an empty file on /etc/resolv.conf in
> the chroot. I've been meaning to play with this, but have
> not made time to do it until just now.
>
> I thought something like this would work:
>
> touch
1 - 100 of 162 matches
Mail list logo
