Heads-up: Updating python-markdown to 3.6 in F41/Rawhide

[Thomas Moschny]

Dear all,

Just a heads up that python-markdown has just been updated in
rawhide/f41 to 3.6.

See here for the list of changes:
https://python-markdown.github.io/changelog/#36-2024-03-14

This will not be pushed to released Fedora branches.

Best regards
-- 
Thomas Moschny 
--
___
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Thomas Moschny]

Hi,

sorry for the late response, have been a bit busy recently...

Yes, we should remove botan (1) from Fedora - that has also been a request
by upstream. The point is, I want to keep monotone, and it needs a bit of
work to switch it over to botan2. There exists a branch that should have
the necessary changes, but no released version.

Anyway, the monotone switch will not make it in time for F40 I guess, but
I'll look into it.

Regarding botan3, I guess no one has volunteered yet to maintain it.

Regards,
Thomas


Am Do., 4. Apr. 2024 um 20:28 Uhr schrieb Jens-Ulrik Petersen <
peter...@redhat.com>:

> https://botan.randombit.net/handbook/support.html#branch-support-status
> can be referenced in the retirement commit:
>
> Branch
>
> First Release
>
> End of Active Development
>
> End of Life
>
> Botan 1.8
>
> 2008-12-08
>
> 2010-08-31
>
> 2016-02-13
>
> Botan 1.10
>
> 2011-06-20
>
> 2012-07-10
>
> 2018-12-31
> (Though 1.11.x also exists, or was that a devel series for botan2?)
> --
> ___
> 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/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Thomas Moschny 
--
___
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[Thomas Moschny]

> dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo 
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync

 Problem 1: problem with installed package mkdocs-1.2.3-2.fc36.noarch
  - mkdocs-1.2.3-2.fc36.noarch does not belong to a distupgrade repository
  - nothing provides (python3.11dist(markdown) < 3.4~~ with
python3.11dist(markdown) >= 3.2.1) needed by
mkdocs-1.3.1-2.fc37.noarch
 Problem 2: package openjfx-devel-3:11.0.9.2-10.fc36.x86_64 requires
openjfx(x86-64) = 3:11.0.9.2-10.fc36, but none of the providers can be
installed
  - openjfx-3:11.0.9.2-10.fc36.x86_64 does not belong to a distupgrade
repository
  - problem with installed package openjfx-devel-3:11.0.9.2-10.fc36.x86_64
 Problem 3: problem with installed package
seahorse-nautilus-3.11.92-20.fc36.x86_64
  - package seahorse-nautilus-3.11.92-20.fc36.x86_64 requires
libnautilus-extension.so.1()(64bit), but none of the providers can be
installed
  - nautilus-extensions-42.2-1.fc36.x86_64 does not belong to a
distupgrade repository
 Problem 4: problem with installed package gtkhash-nautilus-1.4-4.fc35.x86_64
  - package gtkhash-nautilus-1.4-4.fc35.x86_64 requires
libnautilus-extension.so.1()(64bit), but none of the providers can be
installed
  - package nautilus-python-4.0~alpha-1.fc37.x86_64 requires
nautilus-extensions(x86-64) >= 43~beta, but none of the providers can
be installed
  - package nautilus-python-4.0~alpha-1.fc37.x86_64 requires
libnautilus-extension.so.4()(64bit), but none of the providers can be
installed
  - cannot install both nautilus-extensions-43~rc-1.fc37.x86_64 and
nautilus-extensions-42.2-1.fc36.x86_64
  - problem with installed package nautilus-python-1.2.3-10.fc36.x86_64
  - nautilus-python-1.2.3-10.fc36.x86_64 does not belong to a
distupgrade repository
___
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal to deprecated `fedpkg local`

[Thomas Moschny]

> 3) The argument of mock being slow can't stand, because in one of my examples 
> I posted elsewhere in this thread, I picked up the simplest package I could 
> and the build took 7 seconds. This is certainly not slow, in this time you 
> can't even switch to your email client to check your emails.

To add some data points: I roughly see a factor of 2 (with already
populated caches). For one of the smaller packages (xml2) it's ~6
seconds for `fedpkg local` vs ~15-20 seconds for `fedpkg mockbuild`.
For one of the larger packages (shotwell) it's ~1 minute vs. ~2
minutes. So, from my POV, the argument of mock being slow still
stands.

- Thomas
___
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

stk update and soname change

[Thomas Moschny]

The Synthesis ToolKit in C++ (STK) package has been updated to 4.6.1,
which includes an SONAME change from "libstk.so.4" to "libstk-4.6.1.so".

The stk package has been built in side tag f34-build-side-29971, which
will be merged to f34 in about a week.

Packages that need to be rebuilt:

csound-0:6.15.0-1.fc34.src
lmms-0:1.1.3-19.fc33.src
lv2-newtonator-0:0.6.0-20.fc33.src

I will take care of lmms, other package maintainers cc'ed.

- Thomas
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: Lua 5.4.0

[Thomas Moschny]

Am Mi., 1. Juli 2020 um 00:52 Uhr schrieb Jerry James :
> On Tue, Jun 30, 2020 at 4:01 PM Tom Callaway  wrote:
> > lua-event seems to be broken because of broken deps unrelated to Lua 5.4: 
> > nothing provides perl(:MODULE_COMPAT_5.30.1) needed by 
> > perl-Monotone-1.1-34.fc32.x86_64, so I left it alone.
>
> I opened this pull request against monotone to try to unblock lua-event:
>
> https://src.fedoraproject.org/rpms/monotone/pull-request/1

Merged and rebuilt. Thanks!

- Thomas
___
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Generate list of my packages

[Thomas Moschny]

Something like this should work:

$ curl -o result.json
'https://src.fedoraproject.org/api/0/projects?owner=orion_page=100'
$ jq :
>
> On Fri, 28 Feb 2020, Orion Poplawski wrote:
>
> > Can someone point me to a way to generate a list of non-retired packages 
> > that
> > I am a maintainer on?  Thanks.
> >
> > Hunting around for a "pagure cli" doesn't bring up much that seems active.
>
> You could probably scrape it from here?
>
> https://src.fedoraproject.org/dashboard/projects
>

- Thomas
___
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Test-Announce] New Release Freeze Times

[Thomas Moschny]

Am Di., 25. Feb. 2020 um 20:37 Uhr schrieb Matthew Miller
:
> > Whereas with 12h clocks, I think midnight is 12:00 PM, and noon is 12:00
> > AM? Which is still confusing me after having known about it for decades.
>
> It's the opposite, which furthers your point. :)

That does not seem to be very clear:
https://www.npl.co.uk/resources/q-a/is-midnight-12am-or-12pm
https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight

- Thomas
___
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Final fedora distribution Was: How to reuild wdune ?

[Thomas Moschny]

The correct bug would be this, I think:
https://bugzilla.redhat.com/show_bug.cgi?id=1658153

> $ fedpkg request-repo wdune
> Could not execute request_repo: A Bugzilla bug is required on new
> repository requests
> $
>
> I adeded it a dummy bug
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1786307
>
> but no effect 8-(
>

- Thomas
___
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/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Tagging commit hashes of Koji builds in dist-git

[Thomas Moschny]

Am Do., 6. Juni 2019 um 14:12 Uhr schrieb Pierre-Yves Chibon
:
>
> On Thu, Jun 06, 2019 at 01:52:20PM +0200, Florian Weimer wrote:
> > Is there a reason why we do not tag dist-git commits, using a name which
> > is derived from the NEVR from a Koji build?
>
> One of the issue is that currently tags are not immutable, ei packagers could
> override them.

Tags could be signed, and also pagure could reject removal of tags.
Immutability is a feature of the repository, not the tags themselves,
I think.

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

[EPEL-devel] Re: missing -devel packages in 8 beta

[Thomas Moschny]

>   Failed to synchronize cache for repo 
> 'codeready-builder-beta-for-rhel-8-x86_64-rpms', ignoring this repo.
>
> whereas the base and appstream repo work.  Does anyone have that
> working, and, if so, how?

The codeready-builder repo is not part of the public beta I think.

- Thomas
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Source tarballs are being placed in git?

[Thomas Moschny]

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
> another entry.

My impression was that this is actually implemented in current fedpkg.
I have /foo-*.tgz patterns in many of the packages I maintain, and
fedpkg new-sources seems to respect that.

- Thomas
___
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/UJB4YJCRLEHGPKBPWTGSDGZCCU5TOV3P/

Re: Build failures of packages which use waf as build system

[Thomas Moschny]

Please note that we have two different issues here, with different solutions:

- Packages using an embedded waf: as the upstream waf script uses a
shebang like '#! /usr/bin/env python', these packages fail due to the
removal of the unversioned Python binary and should call their waf
copy using one of the %{__python2} or %{__python3} macros, and BR on
python2-devel or python3-devel to get the macros.

- Packages using the system-wide waf script in the Python3 variant
(note that waf is using alternatives, so /usr/bin/waf can be either
using Python2 or Python3, depending on the declared BRs): these will
currently fail in rawhide, as the version in rawhide is not fully
Python3-compatible, which will be fixed soon.

(Of course packages using embedded waf, and calling it via
%{__python3} will likely also see the second issue, and should simply
update their embedded waf script.)


2018-07-23 12:55 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> Please don't recommend that. Instead of munging all packages that use
> waf, waf should be fixed. In the other thread the maintainer said they
> can do it next week. If more speed is needed, prepare a PR in src.fp.o
> and maybe have a provenpackager push the build.
___
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/SONWVTWZTYIINDPK33IQ6MLVX6227PHF/

Re: diorite: FTBFS in Fedora rawhide

[Thomas Moschny]

I think we need to update system waf, version 2.0.7 improves Python
3.7 compatibility.

I'm currently on vacation though, so I might not be able to update waf
before next week. In the meantime you could try to use a local copy of
waf.

2018-07-22 18:40 GMT+02:00 Martin Gansser :
> I changed the spec file [1] but it still fails on rawhide
>
> [1] https://martinkg.fedorapeople.org/Packages/nuvolaruntime/diorite.spec
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=28522155
___
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/MSJMZRMWL7QKJXSHZYCVMZGVQV6ENQSE/

Re: Fedora 28 Final status is GO

[Thomas Moschny]

2018-04-26 22:02 GMT+02:00 Adam Williamson :
> On that basis, I'm gonna say FC1 was at least a day late from the
> schedule in place a week before it came out,

It even slipped 'officially':
https://www.redhat.com/archives/fedora-devel-list/2003-October/msg01178.html
:)

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass Rebuild for Fedora 28

[Thomas Moschny]

2018-02-13 0:06 GMT+01:00 Dennis Gilmore :
> [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-need-rebuild.html

Among those are a lot of packages for which it seems the rebuild has
not been tried at all, for whatever reason.
Instead of asking every maintainer to go manually through his or her
packages and verify whether they have been rebuilt, would it make
sense to try to automatically rebuild those ~4.6k packages?

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Thomas Moschny]

2017-10-13 16:26 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> Sure, that's what everybody knows. But without going from generalities
> to details of a specific extension, we're just speculating idly.

Here's another one:
https://addons.mozilla.org/en-US/firefox/addon/advanced-locationbar/

"Warning! This extension will stop work in Firefox 57+ since this
version of the browser supports WebExtensions API only. It is not
possible to implement this extension using WebExtensions API."

Same holds for the alternative
https://addons.mozilla.org/en-US/firefox/addon/locationbar²/

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] pytest update in EPEL6

[Thomas Moschny]

Hi,

as this has been requested several times[1], I've created an update of
pytest to 2.4.2 for EPEL6.

Afaik there are no packages in EPEL6 that depend on it at runtime, but
there are packages having a BR on it:

$ repoquery --arch=src --disablerepo='*' --enablerepo=epel-source
--whatrequires pytest
fedfind-0:3.6.1-1.el6.src
future-0:0.16.0-2.el6.src
python-argh-0:0.23.2-1.el6.src
python-cached_property-0:1.3.0-7.el6.src
python-click-0:2.6-1.el6.src
python-copr-0:1.78-1.el6.src
python-docopt-0:0.6.1-3.el6.src
python-execnet-0:1.2.0-4.el6.1.src
python-gunicorn-0:18.0-1.el6.src
python-ivi-0:0.14.9-3.el6.src
python-marshmallow-0:2.0.0-0.6.gita8b3385.el6.src
python-msgpack-0:0.4.6-1.el6.src
python-py-0:1.4.18-1.el6.src
python-structlog-0:0.4.2-5.el6.src
python-vxi11-0:0.8-1.el6.src
python-whitenoise-0:2.0.6-5.el6.src
python-whoosh-0:2.5.7-4.el6.src

Rebuilding those (while unlikely) could fail due to this update.

The package is submitted for testing[2], happy to receive feedback.

Thanks,
Thomas

[1] e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1400254
[2] https://bodhi.fedoraproject.org/updates/pytest-2.4.2-1.el6
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Thomas Moschny]

2017-09-01 11:20 GMT+02:00 Gerd Hoffmann :
> So, what would be really helpful, especially for CI with the option to
> build and test every upstream commit, would be support for *two* git
> repos.  One git repo where the spec-file and other build-related stuff
> lives (distgit like).  One git repo where the unmodified upstream
> source lives.  Updates on either repo triggers a build.  The build runs
> "git archive" on the upstream repo to generate the tarball and tweaks
> the specfile (Source and Release tags probably) before kicking off mock
> for the actual build.

That would indeed be very useful!

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best practices for getting CFLAGS/LDFLAGS etc.

[Thomas Moschny]

2017-01-05 14:01 GMT+01:00 Florian Weimer :
> On 01/05/2017 11:58 AM, Michael Schwendt wrote:
>>
>> On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:
>>
>>> It would also be nice if:
>>>
>>>   PYTHON=/usr/bin/python3 %configure
>>>
>>> didn't (silently) do the wrong thing by default.  For a long time we
>>> shipped a nbdkit-python3 package which was using python2, and that was
>>> found to be the cause.
>>
>>
>> And the configure script didn't accept the external definition of $PYTHON,
>> I guess. What could the %configure macro do about it?
>> If you look at "rpm -E %configure", anything it does wouldn't help, if
>> the parameters are ignore or don't make it into the Makefiles.
>
>
> I suspect the problem is that the PYTHON=… setting is only applied to the
> first shell command in the %configure expansion.  It's not the configure
> invocation, just a plain variable assignment, so PYTHON is set, but not
> exported to subprocesses (such as the future invocation of ./configure).
>
> There is probably some shell hackery we could use to avoid that, but I don't
> think more magic should be the goal.

Wouldn't it suffice to put PYTHON= at the end? autotools' configure
scripts accept such assignments (and even remember them in
config.status etc).

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pytest 3.0 in rawhide

[Thomas Moschny]

Hi,

this is a heads-up about the pytest update to version 3.0.3 that just
hit rawhide.

A number of incompatible changes were made in 3.0.0 compared to 2.9.2.
See http://doc.pytest.org/en/latest/changelog.html for the full list of
changes and new features.

If you got this email directly, then your package (SRPM) depends on
pytest. Please check, whether it builds and works with the new pytest
release. This especially holds for the pytest plugins, some of which
definitively need to be updated to support pytest 3.0.

Here's the list of packages that (according to dnf repoquery)
build-depend on pytest:

  copr-frontend
  copr-keygen
  freeipa
  python-astropy
  python-coveralls
  python-django-pytest
  python-docopt
  python-gabbi
  python-lib389
  python-pytest-cache
  python-pytest-capturelog
  python-pytest-cov
  python-pytest-mock
  python-pytest-multihost
  python-pytest-pep8
  python-pytest-runner
  python-pytest-sourceorder
  python-pytest-spec
  python-pytest-testmon
  python-pytest-timeout
  python-pytest-watch
  python-pytest-xdist
  python3-pytest-asyncio

Thanks,
Thomas
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

pytest 3.0 in rawhide

[Thomas Moschny]

Hi,

this is a heads-up about the pytest update to version 3.0.3 that just
hit rawhide.

A number of incompatible changes were made in 3.0.0 compared to 2.9.2.
See http://doc.pytest.org/en/latest/changelog.html for the full list of
changes and new features.

If you got this email directly, then your package (SRPM) depends on
pytest. Please check, whether it builds and works with the new pytest
release. This especially holds for the pytest plugins, some of which
definitively need to be updated to support pytest 3.0.

Here's the list of packages that (according to dnf repoquery)
build-depend on pytest:

  copr-frontend
  copr-keygen
  freeipa
  python-astropy
  python-coveralls
  python-django-pytest
  python-docopt
  python-gabbi
  python-lib389
  python-pytest-cache
  python-pytest-capturelog
  python-pytest-cov
  python-pytest-mock
  python-pytest-multihost
  python-pytest-pep8
  python-pytest-runner
  python-pytest-sourceorder
  python-pytest-spec
  python-pytest-testmon
  python-pytest-timeout
  python-pytest-watch
  python-pytest-xdist
  python3-pytest-asyncio

Thanks,
Thomas
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Thomas Moschny]

2016-09-29 16:58 GMT+02:00 Stephen John Smoogen :
> https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46

This is titled
  "All shells referenced in /etc/passwd must be listed in the
/etc/shells file, except any shells specified for the purpose of
preventing logins."
and *doesn't* require /sbin/nologin to be in /etc/shells, or am I misreading it?

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Upstream Release Monitoring builds for EL7 instead of Rawhide

[Thomas Moschny]

2016-09-21 15:21 GMT+02:00 Avram Lubkin :
> Anyone else seeing similar? I this something I can fix or is there a problem
> with rebase helper?

This is a known issue. the-new-hotness looks for rpms, not for srpms:
See https://github.com/fedora-infra/the-new-hotness/issues/98

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Bodhi takes days to get something pushed to testing

[Thomas Moschny]

2016-07-18 23:57 GMT+02:00 Kevin Fenzi :
> I could tell you more about your specific updates if you list them...

This one took a bit more than 6 days from submission to testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-e5b5fbfa86

- Thomas
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

bash completion dirs

[Thomas Moschny]

Hi,

the "old" bash completion dir /etc/bash_completion.d is now owned by
the filesystem package, so packages don't need (actually: are
forbidden) to own that dir and also don't have to depend on the
bash-completion package. This perfectly makes sense.

However, for the same reasons, shouldn't the filesystem package also
own the "new" /usr/share/bash-completion/completions location?

- Thomas
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Copr routinely swamped by nightly builds

[Thomas Moschny]

2015-02-17 5:34 GMT+01:00 Kevin Kofler kevin.kof...@chello.at:
 IMHO, one of 2 things needs to happen:
 a) Copr gets a massive increase of resources (builders) to handle the load,
 OR
 b) we disallow nightly builds of huge packages such as python3 in Copr,
 because the infrastructure does not scale to that kind of load.

 Kevin Kofler


Wouldn't it be better to (c) implement some sort of 'fair' scheduling
instead of a pure first-come-first-serve system?

Because (a) sounds unlikely, and (b) seems hard to define properly
(what is a 'huge' package? when is 'night'? and when are people
allowed to do these builds?) and also hard to enforce.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] EPEL-5 packages to be removed

[Thomas Moschny]

2015-01-23 19:36 GMT+01:00 Stephen John Smoogen smo...@gmail.com:
 python-jinja2

Huh? In what way is it unmaintained?

- Thomas
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Unpackaged files checking - oddities

[Thomas Moschny]

2015-01-10 13:04 GMT+01:00 Michael Schwendt mschwe...@gmail.com:
 %exclude is global per spec file, or else you would need to %exclude
 a file in _all_ subpackages (in the case when deleting it in %install
 would be more convenient anyway). That would cause some pain in some
 packages.

Is that really true? But  a file %excluded in the main package can be
explicitly named and thus included in a subpackage, right? At least I
am doing that in one of my packages...

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Multiple directory ownership including filesystem package

[Thomas Moschny]

2014-09-24 22:50 GMT+02:00 Michael Schwendt mschwe...@gmail.com:
 https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership

   | Packages must own all directories they put files in, except for:
   |
   |   any directories owned by the filesystem, man, or other explicitly
   |   created -filesystem packages

 Should it be fixed?

 Yes.

 It isn't necessary to include the directory in the package anymore, since
 the filesystem package owns that dir already nowadays.

... for all active Fedora branches and EPEL=7.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Intent to retire postler

[Thomas Moschny]

Hi,

I intend to retire postler. It FTBFS in the last mass rebuild and
upstream recommends to switch to geary instead.

Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: $HOME/.local/bin in $PATH

[Thomas Moschny]

2013/11/1 Reindl Harald h.rei...@thelounge.net:
 The attacker needs to be able to write to your home directory to take
 advantage of it.
 And if he can do that (you lost) he has numerous other ways of doing it

 so the people decided not put the current directory in the
 PATH on Unix *for security reasons* decades ago must be
 fools

Not having cwd in the path is a protection against malicious (or at
least joking) users on the same system: Otherwise they could easily
fool you to execute e.g. a file named 'ls' in their home doing
something evil.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Intent to retire python-jinja

[Thomas Moschny]

2013/9/23 Daniel Drake d...@laptop.org:
 olpc-library just got obsoleted (nothing uses it now, the
 functionality got moved elsewhere), so if you could point me at how to
 drop this package from rawhide I will get it out of your way.

See https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Thanks,
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Intent to retire python-jinja

[Thomas Moschny]

Hi,

I'd like to retire the python-jinja package, containing the Jinja1
template engine, which has been superseded by Jinja2 for a very long
time. Jinja2 is packaged as python-jinja2 in Fedora.

However, there's one package left that depends on it: olpc-library.
Can anyone comment on the status of that package, and if it would be
possible to switch over to Jinja2?

Regards,
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: An even closer look: Obsolete but still included packages

[Thomas Moschny]

2013/8/20 Michael Schwendt mschwe...@gmail.com:
 Undead and all builds obsoleted:

Seems this misses cases like pexpect, which is undead, but obsoleted
by python-pexpect. Maybe because the latter failed in the latest mass
rebuild?

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 20 v2

[Thomas Moschny]

2013/8/16 Bill Nottingham nott...@redhat.com

  $ koji list-tagged --latest f20 | grep fc1[4-8]

 Actually, now that I re-read what we did before, for F-20 we'd block things
 that have failed to build since *before* F-18, i.e., those with fc17 or
 earlier dist tags.

 Which shortens the list to:
 ...

This misses packages that don't use %dist, like tiobench, which has
not been built in the F18, F19 and F20 mass rebuilds it seems.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rebuild of Boost dependees

[Thomas Moschny]

2013/7/31 Petr Machata pmach...@redhat.com:
 monotone5678043 'LUA_GLOBALSINDEX' was not declared in this 
 scope

For Lua 5.2 and newer Boost it has to be updated to latest head from
MTN. As I am on vacation now, that will likely have to wait until next
week.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rpmconf and new feature to configure application

[Thomas Moschny]

In my opinion, the best solution would be to automatically keep a copy
of the original configuration file (maybe RPM could do that - always
wondered why it doesn't, or one could use a tool like etckeeper).

For files in /etc that have to be changed, I usually make a backup
copy, enabling me to do a simple three-way file merge (see merge(1))
after an update:

$ cp -av foo foo.orig
$ vi foo # initial config

$ yum upgrade # this creates a foo.rpmnew

$ merge foo foo.orig foo.rpmnew
$ vi foo # in case there were conflicts
$ mv foo.rpmnew foo.orig

It would be supercool if rpmconf could aid in doing this workflow - or
maybe that's what the updated rpmconf in rawhide already does? ;)

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Grepping through all Fedora specfiles?

[Thomas Moschny]

2013/7/22 Ville Skyttä ville.sky...@iki.fi:
 I'd like to grep through all specfiles (and preferably also patches and
 sources in git) for rawhide, this time related to the unversioned docdirs
 F20 feature, and sometimes for other reasons. Hopefully there's a better way
 than to fedpkg clone all packages one at a time... does anyone know of one?

Maybe you could use searchco.de in some creative way?
  http://searchcode.com/?q=url%3Afedora+ext%3Aspec+docdir

They also have an API.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: EPEL Updating git in -5 to 1.8.2.1

[Thomas Moschny]

Hi Todd,

we are missing /usr/libexec/git-core/git-http-backend in the new
package. Has this been intentionally removed, or is this an accident?

Best regards
Thomas

2013/4/22 Todd Zullinger t...@pobox.com:
 This is a heads up and a request for testing of git-1.8.2.1 on el5 (if
 anyone here is still using git from EPEL there).

 https://admin.fedoraproject.org/updates/git-1.8.2.1-1.el5

 This update obsoletes an ealier 1.8.1.4 update that didn't get announced
 here.  I don't believe there are any changes from the current 1.7.4.1
 release that would make this unacceptable for EPEL, but I could always be
 wrong.



--
Thomas Moschny thomas.mosc...@gmail.com
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Login to Koji

[Thomas Moschny]

2013/4/18 Kevin Fenzi ke...@scrye.com:
 There's no reason you ever need to login to the web interface, so just
 don't bother and move on. ;)

Almost everything can be done using the koji command line, but one
thing I couldn't find: Koji's web interface let me create a
notification, so I get notified whenever a selected package is build
(optionally selecting a tag, and optionally on success only).

How can I add/modify/remove such notification subscriptions without
the web interface?

-- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Login to Koji

[Thomas Moschny]

2013/4/19 Kevin Fenzi ke...@scrye.com:
 It's true that you cannot do that from the command line interface.

 However, there's a bunch of other ways to get that info:

 - Subscribe to the koji recent builds rss feed:
 http://koji.fedoraproject.org/koji/recentbuilds
 and alert on whatever builds you care about.

 - Join the #fedora-fedmsg channel on irc and setup notify for whatever
   packages you care about and what part of the build (since it will
   send a message on build start, build end, success or failure, tagging
   into tag, etc).

 - Setup fedmsg-notify on your desktop and set it to look for the same
   above messages.

 - Setup your own fedmsg consumer to look for the messages and do
   whatever you want on getting them. email you?

 IMHO we should really move to using fedmsg for these things instead of
 a non standard difficult interface in a specific app. ;)

Agreed in principle. On the other hand, all these possible solutions
require something running on my side permanently :(

-- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedora release name problem

[Thomas Moschny]

2013/3/19 Richard W.M. Jones rjo...@redhat.com

 I'm voting for ☃.


What about  ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

update of python-markdown

[Thomas Moschny]

Hi,

python-markdown has been updated in rawhide to the latest version 2.3,
please check whether your package still works as expected.

There are a some backward-incompatible changes, see
https://github.com/waylan/Python-Markdown/blob/2.3.final/docs/release-2.3.txt.

Affected packages:
bodhi-server
lastuser
python-cheetah
ReviewBoard
sshuttle
timeline
transifex

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for Fedora 19

[Thomas Moschny]

2013/3/11 Bill Nottingham nott...@redhat.com

 Package email2trac (fails to build)


Added myself to the package, waiting for approval.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: is it possible to download a spec file only using yum?

[Thomas Moschny]

If all you want is the spec file, then this probably the easiest way:

$ wget http://pkgs.fedoraproject.org/cgit/firefox.git/plain/firefox.spec

However, this way you miss patches, and other auxiliary files.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg: Change in git push method?

[Thomas Moschny]

2013/2/8 Josh Boyer jwbo...@gmail.com:
 Yes, but fedpkg is currently relying on the existing git default, which
 is matching.  That is changing upstream in git, so fedpkg needs to set
 a default when it clones.

And this default should probably be push.default=upstream.

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: nc replaced by nmap ncat

[Thomas Moschny]

2012/7/19 Daniel P. Berrange berra...@redhat.com:
 Libvirt needs to be able to run the following command

   # nc -U /var/run/libvirt/libvirt-sock

It could use socat:

# socat stdio /var/run/libvirt/libvirt-sock

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Couldn't we enable 256 colors by default on TERM?

[Thomas Moschny]

2012/6/26 Chris Adams cmad...@hiwaay.net:
 The newer terminal
 programs have configuration menus for various things; do any of them set
 it there?  If they don't, I would think it would be relatively easy to
 add (and hopefully upstreams would accept such patches).

Tried with XFCE's Terminal, which has a $TERM option in its
configuration dialog (under advanced options), but it simply doesn't
work. I set it to xterm-256color, but within the shell, TERM is
still xterm.

Not sure whether that is an XFCE (or vte) bug, or whether some
system-wide profile script overrides it. Afaict, none of my user
profile scripts overrides it.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg(1) completion for zsh

[Thomas Moschny]

2012/6/6 Alexey I. Froloff ra...@raorn.name:
 Just sharing my fedpkg(1) completion for zsh :-)  Put this file
 somewhere in your $fpath as usual.

You might want to add it here:
https://fedorahosted.org/fedora-packager/ticket/81

Regards,
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Evolving standards for unpacked sources

[Thomas Moschny]

2012/5/29 Richard W.M. Jones rjo...@redhat.com:
 Has anyone written any tools for converting git repos into patches?
 Currently I use 'git format-patch' and then I copy the patches.

Have a look at topgit [1], also packaged for Fedora.

 - Thomas

[1] http://repo.or.cz/w/topgit.git?a=blob;f=README
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Stop the git abuse

[Thomas Moschny]

2012/5/21 Simo Sorce s...@redhat.com:
 Except we do not allow to rewrite history and push -f so you will never
 be able to squash everything.

If koji/bodhi were able to tag successful builds within git, we would
be able to allow rewrites, squash commits and the like at least for
commits that never have been successfully build (or tagged).

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging Guidelines - creating tarball from VCS with script

[Thomas Moschny]

2012/5/14 Toshio Kuratomi a.bad...@gmail.com:
 Automating of the package's checksum won't work for many VCS's .  git, for
 instance, does not preserve timestamps.  So the tarball created from a git
 snapshot will have a different checksum for each checkout.

While files' modification times in a checkout may be different,
archives created with 'git archive' are stable, because git uses the
datetime of the commit for each file in the archive.

So instead of cloning the repository and creating the archive locally,
the preferred method would imho be to use a download link (if present)
of the used git hosting service for directly preparing an archive, and
to file bugs for the respective hosting service if they do not
properly use this git functionality.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Logwatch - looking for testers

[Thomas Moschny]

2012/5/4 Reindl Harald h.rei...@thelounge.net:
 dear maintainers: please take a tighter look for which
 release bugs are reported and consider that the reporter
 has exactly this and only this version installed and is
 not very happy about a has been submitted as an update
 for Fedora 17 notify without finding any build for the
 reported release on koji

See https://fedorahosted.org/bodhi/ticket/613 .

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: compile shotwell 0.12

[Thomas Moschny]

Gerry Reno gr...@verizon.net:
 Has anybody managed to compile Shotwell 0.12 on F16 successfully?

You can try the shotwell RPMs from here (12.1 available only for F16 so far):
http://repos.fedorapeople.org/repos/thm/shotwell/

Please note that these are _not_ official builds. Please send feedback
about these packages to me first.

Regards
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Automating the NonResponsiveMaintainers policy

[Thomas Moschny]

Am 2. März 2012 16:56 schrieb Reindl Harald h.rei...@thelounge.net:
 what are all these maintainers doing?

 it takes exactly 5 minutes to write a systemd-unit for most
 services

Some packages need a bit more love, especially when the sysv init
scripts did more than just starting / stopping a service., e.g.
creating / migrating databases.

You need to convert that functionality to separate scripts, put those
somewhere (/usr/sbin? /usr/libexec/package?), decide whether to let
the user start them manually (which is a big step back in user
experience), or let systemd run them e.g. via ExecStartPre, and test
the whole thing. And then debug and test again. Not a 5 minute job.

Just my 2ct
- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PCRE 8.30 will break API

[Thomas Moschny]

2012/2/13 Petr Pisar ppi...@redhat.com:
 Currently there is 17 packages linked against the old PCRE:

 monotone

Fixed in monotone-1.0-7.fc18.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The question of rolling release?

[Thomas Moschny]

2012/1/24 Josh Boyer jwbo...@gmail.com:
 How is rawhide not a rolling release?  Or perhaps better asked, what
 about rawhide makes it
 unsuitable for use as a rolling Fedora release?

This has been discussed several times on this list: Technically,
rawhide is a rolling release, sure. But rawhide is not near as stable
as it needed to be to be seriously considered for productive use.
There is no testing repo acting as a filter for example.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: orphaning lxc

[Thomas Moschny]

Hi Haïkel,

2012/1/14 Haïkel Guémar karlthe...@gmail.com:
 thank you for having maintained it for some time. Since i still use it
 (at least as long as libvirt isn't able to generate LXC rootfs), i took
 ownership.
 As always, co-maintainers are welcome.

I am comaintaining lxc for a while and was already working on an
update to 0.7.5 (but got distracted somehow...).

Regards,
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: update of python-markdown

[Thomas Moschny]

Hi,

2011/12/13 I wrote:
 this is a heads up that I plan on updating python-markdown to the
 latest version 2.1.0 in rawhide within the next days; please test
 whether your package still works as expected after the update.

python-markdown-2.1.0-1.fc17 has been built for rawhide.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Native systemd unit for tsm client

[Thomas Moschny]

Why are you starting dsmc explicitly - isn't it started by dsmcad?
Here's what we've been using:

[Unit]
Description=DSM Client Acceptor
After=network.target

[Service]
Type=forking
ExecStart=-/usr/bin/dsmcad -errorlogname=/var/log/dsmerror.log
Environment=LANG=en_US
StandardOutput=syslog
GuessMainPID=no

[Install]
WantedBy=multi-user.target

For some reason the PID guessing does not work, so we force it to use cgroups.

- Thomas


2011/12/15 Jóhann B. Guðmundsson johan...@gmail.com:
 Here's an native tsm client service for your fedora running
 workstation/server since it's probably going to be awhile before IBM catches
 up to systemd...

 ### tsm-client.service ###

 [Unit]
 Description=Tivoly Storage Manager Client
 After=network.target

 [Service]
 Type=oneshot
 Environment=DSM_LOG=/var/log/tsm
 ExecStart=/usr/bin/dsmcad
 ExecStart=/bin/bash -c exec /usr/bin/dsmc sched  /dev/null 21 
 RemainAfterExit=yes

 [Install]
 WantedBy=multi-user.target

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Native systemd unit for tsm client

[Thomas Moschny]

2011/12/15 Jóhann B. Guðmundsson johan...@gmail.com:
 Hum that unit file looks a bit odd to me and does not work with TSM 6.3 on
 F16 atleast not here

Not sure what you mean by a bit odd. Isn't specifying oneshot
together with RemainAfterExit more odd in this case, where a deamon
(dsmcad) in fact keeps running? Is it possible to stop it with your
unit file?

The one I posted works with 6.2.2 on Fedora 16 x86_64. The only odd
thing might be  that it doesn't use the pid file but cgroups to
control the daemon - which is a good thing anyway.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

update of python-markdown

[Thomas Moschny]

Hi,

this is a heads up that I plan on updating python-markdown to the
latest version 2.1.0 in rawhide within the next days; please test
whether your package still works as expected after the update.

There are some backward-incompatible changes, see
https://github.com/waylan/Python-Markdown/blob/2.1.0.final/docs/release-2.1.0.md
.

Affected packages:

% repoquery --repoid=rawhide-source --archlist=src --whatrequires
python-markdown
lastuser-0:0.1-3.20110724gitf41a49.fc17.src
python-cheetah-0:2.4.4-2.fc15.src
transifex-0:1.1.0-4.fc17.src

% repoquery --repoid=rawhide --whatrequires python-markdown
bodhi-server-0:0.8.5-1.fc17.noarch
python-cheetah-0:2.4.4-2.fc15.x86_64
timeline-0:0.14.0-3.fc17.noarch
transifex-0:1.1.0-4.fc17.noarch

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changing kernel API / Breaking VirtualBox - update criteria violation?

[Thomas Moschny]

2011/11/22 Dave Jones da...@redhat.com:
 On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote:
 Consideration implies that the following thought process will occur

 This update will break out of tree modules, perhaps we shouldn't push it.

 That isn't going to happen.

To me, this sounds like knowingly violating the Updates Policy, which
states: Updates should aim to fix bugs, and not introduce features,
particularly when those features would materially affect the user or
developer experience.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changing kernel API / Breaking VirtualBox - update criteria violation?

[Thomas Moschny]

2011/11/22 Matthew Garrett m...@redhat.com:
 If you interpret The ABI as Any property of the binary that another
 package could conceivably depend on then your position makes sense. But
 since nobody would interpret it that way, the obvious conclusion is that
 The ABI means The supported ABI. Attempting to codify this more
 precisely would just encourage language lawyering, which is exactly what
 we were trying to avoid when we generated this policy. Use common sense.

If you replace conveivably by commonly or reasonably than I'd
say more people than nobody would expect the updates policy to
prevent such changes.

Of course I buy the argument that we as the Fedora community don't
have enough resources to backport each and every kernel bugfix. That
is a completely valid point, and if the outcome is that under these
constraints things are how they are and the ABI changes, than this is
ok.

That said, you are still obliged by the updates policy to think about
the effects of an update (of each update) and weigh pros and cons like
every other packager. Saying yes we did that long time ago occurs a
bit rude to me.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upstream Release Monitor

[Thomas Moschny]

2011/10/12 Till Maas opensou...@till.name:
 On Wed, Oct 12, 2011 at 03:06:46PM +1000, Peter Hutterer wrote:
 out of interest - are there any plans to auto-close bugs once the new
 version hits rawhide?

 No, this is not planned. But you do not need to close bugs, because old
 bugs are re-used unless they changed status.

Or someone else being overly tidy closing it for you.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rm --no-traverse-mount-points [Re: stop rm at same-dev bind mounts

[Thomas Moschny]

2011/9/10 Jim Meyering j...@meyering.net:
 Thanks for the example, but I don't see how that option name is
 misleading.  A file system is the thing you create with mkfs.
 Even though normally there is only one mount point per file system,
 the fact that with bind mounts there can be many doesn't change
 the name of the thing occupying the underlying device: a file system.

 I think you want a new option, say --no-traverse-mount-points.

The term file system can of course have different meaning to
different people - you could also argue it means file system type,
with unexpected results for the interpretation of --one-file-system.
Anyway, that is nitpicking on my side; obviously it was clear what I
meant: An option to make rm walk the tree, ignoring (=not following)
mount points. Thanks for opening the ticket.

As a side note: I am not sure whether that also means it should remove
stuff normally hidden by such a mountpoint?

As long as such a --no-traverse-mount-points option is not available
yet for rm, I am still looking for suggestions on how to achieve the
same effect in a shell script.

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

stop rm at same-dev bind mounts

[Thomas Moschny]

Hi,

having a rm command accidentally removing 3/4 of my system yesterday,
I am starting to wonder whether it is possible to have rm reliably
stop at bind mounts. I know there is a --one-file-system option, but
it is not working when the bind mount points to the same device:

% cd /tmp
% mkdir -p a/b c/d ; touch c/d/file ; mount --bind c a/b
% find a
a
a/b
a/b/d
a/b/d/file
% rm -rf --one-file-system a
rm: cannot remove `a/b': Device or resource busy
% find a
a
a/b

`file' has been removed. Imho the name of the --one-file-system option
is misleading as it only compares st_dev fields. Besides filing a
bug/enhancement ticket for coreutils, does someone know a reliable way
to stop rm in such cases?


-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning dnsmasq

[Thomas Moschny]

2011/8/25 Paul Wouters p...@xelerance.com:
 Again, this is based on f14, not f15/f16. I am not sure how much this has been
 addressed. But if we want DNSSEC validation on the endnode, at the very least
 127.0.0.1:53 needs to be left free.

Are you sure the dnsmasq instance started by libvirt is really
grabbing 127.0.0.1:53?

In my experiments it did not, and the issue instead was that the other
DNS server [1] wanted to grab port 53 on *all* interfaces.

- Thomas

[1] In my case that was a second instance of dnsmasq, and I had to set
--interface=lo and --bind-interfaces.


-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to ignore LD_LIBRARY_PATH

[Thomas Moschny]

2011/8/23 Orion Poplawski or...@cora.nwra.com:
 See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation

 The environment module system allows users to modify their environment in a
 predictable way, including setting LD_LIBRARY_PATH.  However, this makes it
 possible to break the modulecmd binary by putting an incompatible TCL (or
 other) library earlier in the path.  It would be great if modulecmd were made
 impervious to such things, but I don't know the best or acceptable method to
 do this.  I'm guessing using rpaths would be the easiest.

 Thoughts/suggestions?

Would something like this work?

module ()
{
eval `/lib64/ld-linux-x86-64.so.2 --library-path ''
/usr/bin/modulecmd bash $*`
}

(on a 64bit system; on a 32bit system it would need to use /lib/ld-linux.so.2).

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to read /proc/locks in safe mode?

[Thomas Moschny]

2011/7/12 Dario Lesca d.le...@solinos.it:
 Hi, how to I can read in safe mode, from bash, the content
 of /proc/locks?

 On my system I have more than 7000/9000 line into /proc/locks and if I
 read it with awk (or cat or grep or cp) the file change during the read
 and my input is undefined and is not processable (see attach).

Interesting, because afaiu, in recent kernels reading /proc/locks
line-wise should not yield broken records, as the code in fs/locks.c
uses the seq_file abstraction. See
http://stackoverflow.com/questions/5713451/is-it-safe-to-parse-a-proc-file/5880485#5880485.
What is the kernel version you are seeing that on?

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20110619 changes

[Thomas Moschny]

2011/6/19 Rawhide Report rawh...@fedoraproject.org:
 Compose started at Sun Jun 19 08:15:25 UTC 2011

 Broken deps for x86_64
 --
 ...
        postler-0.1.1-4.fc16.i686 requires libdb-5.1.so
 ...

Just fyi, a simple rebuild against the newer libdb is not enough;
newer vala gives a compile error:
https://bugs.launchpad.net/postler/+bug/797033.

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: What is the status of Features/YumLangpackPlugin?

[Thomas Moschny]

2011/6/14 Itamar Reis Peixoto ita...@ispbrasil.com.br:
 where I can get a list of internal identifiers

yum grouplist -v shows them.


-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: tomboy orphaned

[Thomas Moschny]

Hi,

took it, as I use it everyday. Will update to 1.6.0 when koji is back.

- Thomas


2011/4/27 Ray Strode halfl...@gmail.com:
 Hey guys,

 A long, long time ago (before the extras/core merge in fact i think) i
 was given tomboy to help spread the influx of mono packages across
 desktop team.

 IIt's a neat program, but I don't really use it. I'm more of a
 send-myself-email/scribble-on-whiteboard kind of guy.  I'm also not
 very good about maintaining it.

 I've orphaned it now.  If anyone is interested in it, feel free to take it.

 --Ray

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git repository with Fedora kernel(s) sources

[Thomas Moschny]

2011/2/27 Kyle McMartin k...@mcmartin.ca:
 Our workflow is an SRPM of patches, so that's what we work with.

You really do that by hand, without some sort of patch manager?

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git repository with Fedora kernel(s) sources

[Thomas Moschny]

2011/2/25 Garrett Holmstrom gho...@fedoraproject.org:
 While I can see how this might make things a bit easier, it can obscure
 what commits are Fedora-specific as they are lost in the sea of the
 upstream kernel's commits, making me firmly against the proposal.

Using topgit to control the Fedora patches would be an option,
essentially creating a topic branch for each of these patches (and
recording their dependencies).

I have no clue however if that scales well to ~90 patches.

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updating waf to 1.6

[Thomas Moschny]

2011/1/24 Kevin Kofler kevin.kof...@chello.at:
 Simo Sorce wrote:
 You are free to volunteer to do that, I am not going to do it for
 samba4, I simply do not have the time to waste on such a thing.
 (Samba4 people are in strict contact with the waf author and use
 regularly the svn version du jour to fix build bugs they found, good
 luck trying to make samba4 build right with months old releases that do
 not include all necessary fixes).

 I think the cleaner approach would actually be to aggressively update waf
 and to fix projects to build with a newer waf, not an older one.

Simo was talking about samba4 using trunk versions instead of released
versions iiuc, so: no, it is not a matter of more aggressively
updating waf. Normally we ship released versions of our software, not
devel aka trunk versions.

That said I'm always open to adding single patches to the waf package
if that helps any other package, preferredly from svn (as that shows
that upstream knows and already approved these patches). Of course
someone has to file bz tickets, so I get to know.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updating waf to 1.6

[Thomas Moschny]

2011/1/18 Toshio Kuratomi a.bad...@gmail.com:
 +1 to FPC blessing.  Like I said, we can probably carve up something that
 explains both the waf POV and configure scripts here... but it'll need
 someone who knows waf to be able to explain, for instance, how waf differs
 from autoconf which has both a non-bundled and non-bundled component.

In theory, it's not complicated at all: you have a binary (+ its
library) and you have rule files describing the build process, build
options and variants, checking prerequisites, etc... within your
project.

So in theory, no need to bundle waf and the lib together with your project [*].

In practice however waf versions seem to differ enough to cause build
problems if not done with the exact same waf version the wscripts are
developed against.

So, it's neither waf is a copylib, nor is it like autotools (in that
it generates scripts).

The exception FPC to ask for is simply because it makes things easier.
Multiple waf packages would be needed in parallel, and extensive
testing for each package that BRs it. Much effort for no real gain.

- Thomas

[*] There is a small possibility projects use a patched version of
waf. Not sure if that's really the case for any package in Fedora.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updating waf to 1.6

[Thomas Moschny]

2011/1/17 Simo Sorce sso...@redhat.com:
 The best thing is to not package waf on and in itself, and let package
 embed the right version. At least until waf becomes mature enough that
 the rate of change slows down to the point that option 1 becomes
 feasible.

 Option 2 is just begging for maintenance nightmares.

Seems most people agree on that pov. But it would be good to also get
FPC's blessing. One of the affected package maintainers should file a
trac ticket.

- Thomas


-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updating waf to 1.6

[Thomas Moschny]

2011/1/16 Jon Ciesla l...@jcomserv.net:
 Would you be so kind as to file BZs against midori and xiphos indicating
 that they either need to switch to using system waf or file a Trac with
 FPC for an exception if there's a really good reason to bundle?

Could do that, but I think we should ask FPC for a general exception.

waf is intended to be bundled, and its api changes from time to time.
waf's upstream even officially discourages installing it system-wide
(and has removed the installation routine in later releases). Some
people might find an rpm handy nevertheless, that's why we still
package it, while e.g. Debian has stopped packaging it. Forcing our
package maintainers to use system's waf (which might be a on different
version than that embedded in their source tars) might put extra
burden on them and is probably not worth the effort - we are talking
about a build system, not a run-time lib.

- Thomas


-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Thomas Moschny]

2010/12/10 Orcan Ogetbil oget.fed...@gmail.com:
 [...]
 the problem is just the dependencies added by executable %doc files,
 then rpmbuild can be taught to not scan the %doc files for generating
 dependencies.

That seems by far the cleanest solution to me. Especially
development-oriented packages often contain example directories;
removing x-bits there only puts extra-burden on someone trying to play
with the examples.

On a related note, rpmlint also warns (don't know if we have a
corresponding guideline) about empty files, even when in %doc, but in
some cases these might indeed be wanted.

Thomas

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: hosted reproducible package building with multiple developers?

[Thomas Moschny]

2010/12/10 Matt McCutchen m...@mattmccutchen.net:
 On Fri, 2010-12-10 at 15:06 +, Daniel P. Berrange wrote:
 Adding CLONE_NEWPID would be worthwhile to stop the
 mock process seeing any other PIDs on the machine.

 It's critical, or mock could ptrace some process running as root on the
 host and inject arbitrary code.

Wouldn't a properly set-up LXC container be a better solution here?
See http://lxc.sourceforge.net/ . LXC is already packaged for Fedora,
and also in RHEL6 iiuc.

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git usage question

[Thomas Moschny]

2010/9/8 Daniel P. Berrange berra...@redhat.com:
 When maintaining a proper GIT branch against upstream and cherry picking
 patches, the fact that you might end up with 100's of patches is not
 really a burden anymore. GIT does all the hardwork for you. You can
 automate patchfile creation with git format-patch, and a simple script
 can munge the RPM spec to add the neccessary Patch:  %patch lines
 and %changelogs based off the GIT commit summary line for each patch.

You could also use topgit [1], which really eases the process of
maintaining a set of patches (which might depend on each other)
against some upstream branches.
Btw, topgit is awaiting review [2] ;)

Regards,
Thomas


[1] http://repo.or.cz/w/topgit.git
[2] https://bugzilla.redhat.com/show_bug.cgi?id=619593
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedora mission (was Re: systemd and changes)

[Thomas Moschny]

2010/8/31 Jesse Keating jkeat...@j2solutions.net:
 An update that changes behavior for the end user would never be
 acceptable as an update to a stable release.  Only severe exceptions
 should be made to this rule, where the time/effort to backport the
 important fixes from a new upstream release are cost prohibitive and too
 complicated to do on our own.

An update that does not change behavior for the end user is ... not meaningful.

Any update changes something, otherwise it would not have been issued.
And sometimes it is not at all clear if that change is welcome or not.
A bug fix might be in most cases, but could also mean some work to the
end user as well, like removing a workaround.

We should accept that people have different expectations, and draw
different lines in the trade of getting new bug fixes and new features
vs. coping with breakage and changed behavior. People might even have
different expectations from package to package. If we decide to draw
that line at a fixed point, distribution-wide, we'll lose people,
inevitably. So lets try to come up with ideas how to satisfy both (or
even more than two) needs. Making categories (critical packages vs.
non-critical packages) is a good step in the right direction, as well
as more than one repository. If there are issues the build system or
the packaging tools cannot handle, good, that is a technical problem
and can be solved. We're not here for politics, are we?

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd and changes

[Thomas Moschny]

2010/8/27 Jesse Keating jkeat...@j2solutions.net:
 That's strange.  I use it on my laptop, which has a caching local DNS
 server (dnsmasq) and it works just fine.  I do have a script in
 /etc/NetworkManager/dispatcher.d/ that waits for bringup and vpn bring
 up to make adjustments to the running local DNS server (which seems
 easier with NM than it would be with the old scripts).

How can it be easier than this line in /etc/dhcp/dhclient-eth0-up-hooks:
new_domain_name_servers=127.0.0.1 $new_domain_name_servers

This doesn't work with NM anymore however, so care to share your NM script?

(Imho NM should offer a configuration option for this, seems a common case.)

Thanks
Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: 1 more git problem

[Thomas Moschny]

2010/8/26 Till Maas opensou...@till.name:
 On Thu, Aug 26, 2010 at 03:16:14PM -0400, Neal Becker wrote:

 But, I hope this doesn't mean f12 is out of sync with f13, f14, master.
 They should all be identical.

 I usually  gitk --all to check this. The green labels need all to
 point to the same commit for all to be equal.

Strictly speaking, the trees can be equal even if the commits differ
(because the metadata, which is also part of the hash, differs).

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Partial mass rebuild for Python 2.7 coming soon (I hope)

[Thomas Moschny]

2010/7/21 David Malcolm dmalc...@redhat.com:
 Some notes can be seen at:
 https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild
 TODO: do we need a compat-python-2.6 temporarily to resolve loops in the dep 
 graph?

Wouldn't such a compat package also make yum upgrades from f13-f14 or
rawhide-with-py2.6-rawhide-with-py2.7 easier, and thus should not
only provided temporarily, but for a longer time?

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: pidgin obsoleting itself

[Thomas Moschny]

2010/6/11 Stu Tomlinson s...@nosnilmot.com:
 At least it causes package-manager to display an irritating (and
 somehow bogus) warning box that it's going to remove pidgin, and needs
 confirmation for that.

 I'm not sure which package-manager this is, but I suggest the fix is
 to make package-manager not display this warning if it is not really
 removing pidgin.

Meant to write PackageKit. And this is surely a PackageKit bug.

Today this happened again, for the awn-extras-applets package, which
also self-obsoletes: % rpm -q --obsoletes awn-extras-applets
awn-extras-applets-devel  0.4.0-14.fc13
awn-extras-applets  0.4.0-14.fc13
for whatever reason).

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

pidgin obsoleting itself

[Thomas Moschny]

Hi,

pidgin-2.7.1-2.fc13 obsoletes pidgin = 2.7.1-1.fc13, is that meaningful?

At least it causes package-manager to display an irritating (and
somehow bogus) warning box that it's going to remove pidgin, and needs
confirmation for that.

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: pidgin obsoleting itself

[Thomas Moschny]

2010/6/9 Chen Lei supercyp...@gmail.com:
 Yes, the obsoletes is necessary, if you don't add it, yum will only
 pull in pidgin-evolution.

For which operation? Can you elaborate a bit?

-- 
Thomas Moschny thomas.mosc...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: sources file audit - 2010-05-31

[Thomas Moschny]

2010/6/3 Kevin Fenzi ke...@scrye.com:
 thm:BADSOURCE:httperf-0.9.0.tar.gz:httperf

why's that?

% cd devel
% wget -N http://httperf.googlecode.com/files/httperf-0.9.0.tar.gz
% md5sum -c sources
httperf-0.9.0.tar.gz: OK

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: sources file audit - 2010-05-31

[Thomas Moschny]

2010/6/4 Christoph Wickert christoph.wick...@googlemail.com:
 Am Freitag, den 04.06.2010, 15:12 +0200 schrieb Thomas Moschny:
 2010/6/3 Kevin Fenzi ke...@scrye.com:
  thm:BADSOURCE:httperf-0.9.0.tar.gz:httperf

 why's that?

 % cd devel
 % wget -N http://httperf.googlecode.com/files/httperf-0.9.0.tar.gz

 Not sure how the source file audit script works, but you will see the
 same for all googlecode adresses when using spectool. I suggest to
 ignore it.

Then it was BADURL, not BADSOURCE.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to make things better(tm)

[Thomas Moschny]

2010/3/5 Adam Williamson awill...@redhat.com:
 On Fri, 2010-03-05 at 11:15 +0100, Kevin Kofler wrote:
 Rahul Sundaram wrote:
  We have a written down policy that specifically recommends that our
  maintainers consider the issue of regressions seriously and not push
  every upstream release into the updates repository
 
  http://fedoraproject.org/wiki/Package_update_guidelines

 1. That policy is not mandatory, just indicative:
 These are not intended to be prescriptive rules. Package maintainers are
 expected to to exercise their own common sense and good judgement.
 2. That policy doesn't say that no new versions or even no feature upates
 should be pushed. Quite the opposite

 So I don't see that policy as backing your claims at all.

 That's because you're misreading Rahul's claims. Rahul was replying to a
 post which claimed Fedora has a 'policy' of being 'bleeding edge'.
 Rahul's point is that we don't, and the only policy we do have - even
 though, as he specifically notes, it's a weak one (he says 'specifically
 recommends', not 'requires') - is rather the opposite. If you'd left in
 the context from the post Rahul was replying to, this would have been
 clear.

Although when it was approved by fesco, it was discussed under the
term Update description guidelines, and from the short discussion
archived on http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html
it is not at all clear that the main intention was to discourage
updates to stable releases. Instead the main focus was on the update
descriptions.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

[Thomas Moschny]

2010/3/3 Josh Boyer jwbo...@gmail.com:
 On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote:
On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:

 We've made a mess and as a member of fesco I'd expect you to be helping in
 cleaning up the mess, not making it worse b/c fesco HAS to be about the
 long term growth and sustainability of fedora.

I'm starting to think this thread needs a hall monitor. Unfortunately
half of them seem to be in it, swinging away.

 Why?  Other than one instance, which was my own, there hasn't been anything in
 this thread that I would consider hall monitor worthy.

Wording starts to get near to unacceptable imho. People not sharing
the view that there are to many updates to so-called stable releases
(a 'fire-hose' of a 'horrendous' and 'insane' amount of updates) are
denoted not being normal.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

[Thomas Moschny]

2010/3/2 Adam Williamson awill...@redhat.com:
 On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote:

 Doesn't just not running random/unrestricted yum update exactly
 encode that option?

 If you're happy to live with unsecure software, certainly =)

 you can try and cherry-pick security updates, but then you get the
 problem where initial release has Foobar 1.0, then Foobar 3.5 gets
 shipped in updates, then a security problem emerges and Foobar 3.5-2
 with the security fix gets shipped in updates. You now have a choice of
 unsecure Foobar 1.0, or completely new version Foobar 3.6.

Yes, and that will always be the case unless you are hiring a lot of
developers to backport security fixes. Oh wait ... isn't that what
RHEL is about?

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

[Thomas Moschny]

2010/2/26 Bill Nottingham nott...@redhat.com:
 Till Maas (opensou...@till.name) said:
 I just have another idea: Add the karma value to the repository
 metadata and write a yum plugin to only install packages with a certain
 amount of karma. I just checked that stable packages may still receive
 karma, so then everyone can pre-select packages based on the karma. And
 people for whom the current system works good enough, can disable it.
 And security updates could still be installed using the yum-security
 plugin.

 Given the interdependencies between updates, I'm not sure that's really
 practical. What happens when (theoretically) new thunderbird is +3
 but the new xulrunner it depends on is -3?

Use both, karma and package selection not for individual packages, but
for groups of packages.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

stk soname change

[Thomas Moschny]

Hi!

Just a small heads up that I'm going to update stk (Synthesis ToolKit
in C++) to version 4.4.2 and thereby change the soname from
libstk.so.4 to libstk.so.0. This will, as far as I can see, only
affect lmms, which I also maintain and take care of the rebuild
myself. The rebuild seems necessary anyway: lmms build against 4.3.1
crashes when run with 4.4.2, which is an indicator that the soname
should have been changed. Upstream unfortunately doesn't seem to have
a consistent scheme yet, maybe we should work something out together
with them.

The new soname also would bring us in-line with Debian who used major
.0 for some time now.

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning Candidate packages for removal due to FTBFS, implications

[Thomas Moschny]

2010/1/18 Seth Vidal skvi...@fedoraproject.org:
 1. extraordinarily stable
 [...]
 in ANY of those cases I'd want to start thinking about nuking the pkg from
 fedora.

Are you serious?

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ABRT frustrating for users and developers

[Thomas Moschny]

2010/1/18 Jiri Moskovcak jmosk...@redhat.com:
 Plus abrt should run `rpm -V' on any rpm involved in the transaction (=if
 user
 does not have replaced the binary by some non-rpm make install).

 ABRT used to do this (and still can, it's just disabled), but rpm -V uses
 prelink to un-prelink the binaries to check the MD5 sum and security guys
 don't like it.

Can you explain what's the security problem here?
The outcome would be a boolean and a reject to send the report (or at
least a big warning).

- Thomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel