Re: [packman] New packages for packman (Walter Fey) (Walter Fey)

[Richard Brown]

On 3 August 2017 at 09:47, Luigi Baldoni  wrote:
> Sent: Thursday, August 03, 2017 at 12:23 AM
> From: "Walter Fey" 
>>
>> I agreed to this and informed him, that due to serious legal concerns,
>> I cannot publish the copyright remark that is pointing to SUSE LINUX GmbH,
>> Nuernberg, Germany without a  written approval from this company.
>
> This is the part I understand the least.
> What would be the legal ramifications or even just the risks in
> attributing copyright to a third party? Or is mentioning a trademark that
> concerns you?

I also don't understand this part - especially as most FOSS licenses
require a copyright attribution for involved authors and require them
to be preserved when redistributing

eg: from https://opensource.org/licenses/MIT

"The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software."

eg. https://www.gnu.org/licenses/gpl-howto.en.html

"Whichever license you plan to use, the process involves adding two
elements to each source file of your program: a copyright notice (such
as “Copyright 1999 Terry Jones”), and a statement of copying
permission, saying that the program is distributed under the terms of
the GNU General Public License (or the Lesser GPL)."

"If you have copied code from other programs covered by the same
license, copy their copyright notices too. Put all the copyright
notices together, right near the top of each file."

In addition to many licenses requiring an explicit copyright notice
and the preservation of it, Germany, UK and the US (as the three most
relevant legal authorities which OBS operates under) are all
signatories to the Berne convention which gives "automatic protection"
to copyrightable works under their jurisdiction.

This complicates matters with FOSS licenses which consider copyright
attribution as 'optional' but require it's preservation when source is
being redistributed. An 'implied' copyright assignment might not be
enforceable in all countries, and yet openSUSE's OBS can, and does,
redistribute software & source in all countries.

It's the openSUSE's projects opinion that to ensure the software's
free distributability the best approach is to require the explicit
declaration of copyright attribution in all specfiles. That copyright
attribution should include all of the involved parties who authored
that specfile.

> Furthermore, you wouldn't even have to use the "Copyright SUSE GmbH" line.
> Several other packagers just put in their name, current year and everyone
> who adds something to it would add his own.

Exactly, and the openSUSE Project is _perfectly_ happy with that. We
encourage our contributors to share their copyright attributions when
there is more than one party that wants to be recognised as a
copyright holder on the work they have contributed to the openSUSE
Project.

> Also, I understand the principle of wanting one's work to be recognised,
> but is it worth the trouble for something that can be trivially reimplemented
> and it's MIT licensed so anyone could reuse it in the first place?

And as linked above, the MIT license already requires an explicit
copyright declaration in order to be MIT licensed. Without a copyright
declaration, a file claiming to be MIT licensed is breaching the terms
of it's own license, and therefore is not legally redistributable.

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] New packages for packman (Walter Fey)

[Richard Brown]

On Thu 3. Aug 2017 at 02:01, Pascal Bleser <pascal.ble...@opensuse.org>
wrote:

> 2017-08-01 18:02 GMT+02:00 Richard Brown <rbrown...@opensuse.org>:
> > On Tue 1. Aug 2017 at 15:33, Luigi Baldoni <aloi...@gmx.com> wrote:
> [...]
> >> If so I suspect it's related to the missing header with copyright
> >> attribution to SUSE AG.
> >>
> >> Now, the question is: would Packman be ok with that?
> >
> > I would hope the answer is "no"
>
> It seems to me that the conflict here comes from a different
> interpretation of how things happened.
> I might be wrong but from what I've read, I'm under the impression that
> - Walter says that he has maintained those spec files since years and,
> hence, he is the copyright holder on the spec files, and in that case,
> there would be no problem building and hosting them at Packman (*)
> - Richard says that he took bits of spec files that were not his
> copyright and/or had the copyright attribution to SUSE, and removed
> those in the process
> Maybe Walter means that he solely wants to base his packages in
> Packman on his very own spec files.
>
> (*) that being said...
> I'm in no position to influence anything as I've pretty much retired
> from everything, but as probably everyone knows, I have maintained a
> lot of packages at Packman in the past, for quite a while.
> Based on that experience, my personal opinion is that hamradio
> packages have absolutely nothing to do on Packman.
> MPlayer yes, hamradio? no. That is really not the purpose of Packman.
> It's not a dissidence from the openSUSE project (even though it was a
> bit of that in the olden days, before the openSUSE project started
> :)), it's a complementary (and important) service to its community.
>
> Is there maybe a way to resolve what seems to be a misunderstanding
> (or misrepresentation of events), and keep those packages on the
> openSUSE OBS ? (even though the tone of discourse makes it seem as if
> it's already too late for that..)


Walter is totally free to host whatever he wants on OBS as long as he
complies with the documented rules, which require copyright headers. He has
received extensive guidance that clarifies that, for those specfiles 100%
of his own work, he could/should assert his own copyright in that header.
For those where the specfiles contains lines taken from the collaboration
with hardware/sdr, the copyright header should include attribution to the
copyright holder of the hardware/sdr specfiles.

At no point was Walter banned, forbidden, or otherwise censored from OBS,
but we try to make it very clear what the acceptable behaviour is in
regards to software licenses and copyright.

The fact that he seems to want to move his work to Packman therefore
concerns me that he intends to do so in a way that OBS would deem
unacceptable. I consider this as much of a risk to Packman as it was to
OBS, and think it's important to highlight the problems associated with
that. I did not intend to come off as "threatening" and wish to apologise
for that - I thought my choice of language made it clear that I respect
Packmans independence as a project, but at the same time I feel the
responsible thing is to show the legal risks involved.


> > If Packman receives packages which clearly remove the legal copyright
> > attribution of previous authors, Packman would need to be prepared for
> > serious conversations with the copyright holder who's attributions are
> > being removed.
> > This is a very serious situation which fundamentally undermines the legal
> > basis under which free and open source licenses operate, so is taken very
> > seriously by corporations that run their business in compliance with
> those
> > licenses.
>
> Richard, seriously, those gratuitous threats...
> Nothing happened, why are you throwing those around ? (including the
> bit in a latter post you made..)


Nothing happened with Packman, but they did in OBS. It was a long drawn out
discussion with Walter that took a lot of the Boards time and SUSEs legals
team time. As I already said above, I didn't intend for what I wrote to be
read as a threat, but it most certainly was intended as a warning, because
I wouldn't wish on any other human being a repeat of the work I've already
gone through on this issue.


>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] New packages for packman (Walter Fey)

[Richard Brown]

On Wed 2. Aug 2017 at 09:26, Luigi Baldoni  wrote:

> Sent: Wednesday, August 02, 2017 at 10:08 AM
> From: mar...@pluskal.org
> >
> > On Tue, 2017-08-01 at 21:41 +0200, Luigi Baldoni wrote:
> > > No. I was talking about the copyring attribution for the spec file
> > > itself, with which I seem to recall
> > > from a previous interaction OP has a problem with.
> > >
> > > Now, I assume that a commercial entity like SUSE can't afford to
> > > distribute anything where the IP is not
> > > clearly defined, even for a mere script.
> > >
> > > Would Packman be more lenient in that regard?
> >
> > As Richard explained, this might be a bit dangerous adventure for
> > packman. Apart from that I would say that motivation for moving to
> > packman is a bit weak - my understanding is that move is motivated by
> > hurt feelings after discussion about copyright attribution with OP, and
> > by his opposition against including hamradio/sdr stuff in Factory and
> > Leap.
>
> Before slandering anyone, now I see that packages in home:dl8fcl:hamradio
> have the following header:
>
> #
> # spec file for package foo
> #
> # Copyright (c) 2017 Walter Fey DL8FCL
> #
> # This file is under MIT license
>
> Is this the reeason why OBS doesn't want it? Would packman?
> Can Walter Fey confirm this?


The packages in OBS which the openSUSE Board objected to either

1) had no copyright attribution at all
Or
2) had copyright attribution which removed that claimed by other
contributors in versions of the specfile used by the package.

Your above example clearly would not be a repeat of scenario 1), but I
cannot comment to whether scenario 2) applies without a thorough audit of
the code and commit history involved.

I personally would consider 2) more concerning than 1) as 1) is a state
that all source files go through as they are being originally created. 2)
directly undermines the removed copyright holders ability to enforce the
license of their contributions. This is deeply concerning and toxic to the
smooth and legal operation of any open source project, especially one
distributing software.

If the package had no history (this is clearly not the case in this
situation, as Walter has already stated they're packages he formerly hosted
on OBS) then the above header certainly seems consistent with good
practice. But in this case the history of the package and the attribution
of all of the copyright holders involved in that history is the most
important factor to consider.


>
> > This would basically go against most of recent efforts to move
> > everything that is possible/allowed to OBS/Leap/Factory and would put
> > additional load on packman's resources, which are much more scarce than
> > those of OBS.
>
> And on that I fully agree. It seems to me trying to find a modus vivendi
> with OBS would be a much fruitful employment of everyone's time:)
>
> Regards
>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] New packages for packman (Walter Fey)

[Richard Brown]

On Tue 1. Aug 2017 at 22:29, Luigi Baldoni <aloi...@gmx.com> wrote:

> Sent: Tuesday, August 01, 2017 at 10:30 PM
> From: "Richard Brown" <rbrown...@opensuse.org>
> > > On Tue 1. Aug 2017 at 20:42, Luigi Baldoni <aloi...@gmx.com[mailto:
> aloi...@gmx.com]> wrote:Sent: Tuesday, August 01, 2017 at 6:02 PM
> > >
> > > No. I was talking about the copyring attribution for the spec file
> itself, with which I seem to recall
> > > from a previous interaction OP has a problem with.
> > >
> > > Now, I assume that a commercial entity like SUSE can't afford to
> distribute anything where the IP is not
> > > clearly defined, even for a mere script.
> > >
> > > Would Packman be more lenient in that regard?
> >
> > I don't know if Packman would be lenient or not in the scenario you
> pose, but that isn't relevant to the actual risk with Mr. Feys proposed
> comtributions.
> >
> > The behaviour with Walter alludes to in his post was a clear,
> demonstrable case of Mr. Fey taking sources (in this case spec files) and
> reusing the spec file, in whole
> > or in part, while simultaneously removing the copyright header from
> those spec files.
> >
> > The spec files were all licensed under licenses such as the GPL and MIT
> which require all copyright attribution to be preserved as part of the
> license for reuse and
> > redistribution.
> >
> > Mr. Feys insistence to remove the copyright attribution while reusing
> source which clearly derived from clearly attributed specfiles is a clear
> breach of the licenses
> > involved and in the interest of the copyright holders, the upstream
> projects who chose the licenses in use, and all open source projects the
> openSUSE Board requested
> > Mr Fey cease that behaviour.
> >
> > Mr Fey now seems to seek to use Packman and his posts imply he might
> intend to do so in the same manner in which he chose to use the openSUSE
> Build service.
> >
> > If that is the case, this could be a serious issue for the Packman build
> service. If the sources involved include files derived from those
> copyrighted to SUSE Linux
> > GmbH it is likely that SUSE will notice (after all, I have read this
> thread) and it is certainly likely we will be compelled to take action to
> protect our copyright
> > and the redistribution license of the packages in question.
>
> > And that's a situation I really, sincerely hope we can avoid so hope
> that Packman has suitable processes and options in place to ensure the
> licenses and copyrights of
> > their contributions are as checked as they reasonably can be before
> hosting and redistributing the resulting binaries.
>
> I didn't say anything of the sort and I'm sorry if I gave that impression.


Nothing to apologise for, this is a polite conversation between curious
parties


>
> In my understanding (and I could be wrong), Walter Fey opposes copyright
> headers for spec files even
> when he's the original author.


Such an approach is inconsistent with the openSUSE Project where we clearly
state all spec files must have a license header including a copyright
attribution

https://en.opensuse.org/openSUSE:Specfile_guidelines#Specfile_Licensing

We do not require copyright attribution transfer and fully support our
contributors to assert their own copyright if they are the sole author, or
share attribution with multiple parties if the specfile includes the work
of multiple parties.

In the case of the openSUSE Project we consider all of our specifies to
have the same license as the associated source, unless it is not an open
source license in which case the specfile is MIT.

As all major open source licenses require clear copyright attribution to be
valid, any removal of copyright attribution when reusing openSUSE specfiles
is a breach of the license in question.

This is a common practice that is followed throughout the open source
world, for example the FSF have the following guides even on the topic.

https://www.gnu.org/licenses/why-assign.en.html

So this is not just a question of corporate concern, but the correct, and
secure, way to ensure that the terms and conditions are enforceable for the
software author as intended under their chosen license.

If Packman plays too fast and loose with such good practice I can imagine
some very uncomfortable possibilities.

Given most open source licenses have strict rules regarding redistribution,
I cannot imagine it is a good thing for any service hosting open source
software to turn a blind eye to the terms, conditions and copyrights of the
software they are distributing.

Just my 2c and sharing from my own personal experience


> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] New packages for packman (Walter Fey)

[Richard Brown]

On Tue 1. Aug 2017 at 20:42, Luigi Baldoni <aloi...@gmx.com> wrote:

> Sent: Tuesday, August 01, 2017 at 6:02 PM
> From: "Richard Brown" <rbrown...@opensuse.org>
> > I would hope the answer is "no"
> >
> > If Packman receives packages which clearly remove the legal copyright
> attribution of previous authors, Packman would
> > need to be prepared for serious conversations with the copyright holder
> who's attributions are being removed.
> >
> > This is a very serious situation which fundamentally undermines the
> legal basis under which free and open source
> > licenses operate, so is taken very seriously by corporations that run
> their business in compliance with those
> > licenses.
>
> No. I was talking about the copyring attribution for the spec file itself,
> with which I seem to recall
> from a previous interaction OP has a problem with.
>
> Now, I assume that a commercial entity like SUSE can't afford to
> distribute anything where the IP is not
> clearly defined, even for a mere script.
>
> Would Packman be more lenient in that regard?
>
> Regard
>
>
I don't know if Packman would be lenient or not in the scenario you pose,
but that isn't relevant to the actual risk with Mr. Feys proposed
comtributions.

The behaviour with Walter alludes to in his post was a clear, demonstrable
case of Mr. Fey taking sources (in this case spec files) and reusing the
spec file, in whole or in part, while simultaneously removing the copyright
header from those spec files.

The spec files were all licensed under licenses such as the GPL and MIT
which require all copyright attribution to be preserved as part of the
license for reuse and redistribution.

Mr. Feys insistence to remove the copyright attribution while reusing
source which clearly derived from clearly attributed specfiles is a clear
breach of the licenses involved and in the interest of the copyright
holders, the upstream projects who chose the licenses in use, and all open
source projects the openSUSE Board requested Mr Fey cease that behaviour.

Mr Fey now seems to seek to use Packman and his posts imply he might intend
to do so in the same manner in which he chose to use the openSUSE Build
service.

If that is the case, this could be a serious issue for the Packman build
service. If the sources involved include files derived from those
copyrighted to SUSE Linux GmbH it is likely that SUSE will notice (after
all, I have read this thread) and it is certainly likely we will be
compelled to take action to protect our copyright and the redistribution
license of the packages in question.

And that's a situation I really, sincerely hope we can avoid so hope that
Packman has suitable processes and options in place to ensure the licenses
and copyrights of their contributions are as checked as they reasonably can
be before hosting and redistributing the resulting binaries.

Regards,

- R

>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] New packages for packman (Walter Fey)

[Richard Brown]

On Tue 1. Aug 2017 at 15:33, Luigi Baldoni <aloi...@gmx.com> wrote:

> Sent: Tuesday, August 01, 2017 at 2:22 PM
> From: Malcolm <malcolmle...@cableone.net>
> >
> > >A few weeks ago I was informed by somebody, who is member of the
> > >openSUSE Board and employee of the SUSE GmbH, that the form as this
> > >was done for more than ten years is not welcome anymore.
> > 
> > Hi
> > You mean the spec file, changes file etc when you refer to 'form'?
>
> If so I suspect it's related to the missing header with copyright
> attribution
> to SUSE AG.
>
> Now, the question is: would Packman be ok with that?


I would hope the answer is "no"

If Packman receives packages which clearly remove the legal copyright
attribution of previous authors, Packman would need to be prepared for
serious conversations with the copyright holder who's attributions are
being removed.

This is a very serious situation which fundamentally undermines the legal
basis under which free and open source licenses operate, so is taken very
seriously by corporations that run their business in compliance with those
licenses.

Regards,
Richard Brown
openSUSE Chairman
SUSE Linux GmbH


>
> Regards
>
>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] removal of Leap 42.1

[Richard Brown]

On 22 May 2017 at 08:48, Markus Kohm  wrote:
> Am Montag, 22. Mai 2017, 08:37:51 CEST schrieb Olaf Hering:
>> Since Leap 42.1 will receive no further updates via OBS I think it is time
>> to remove it also from PMBS. The existing binaries will (hopefully) remain
>> on the mirrors. This will free resources for Leap 42.3.
>
> Please don't be so quick! Current release is still 42.2. 42.3 is still marked
> as alpha on  . IMHO 42.1 shouldn't be
> removed before release of 42.3.

I agree with Olaf - I would like to see Packman reflect the actual
support lifecycle of openSUSE Leap releases and not to encourage users
to remain on unsupported (and therefore insecure) versions of openSUSE
Leap.

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] PMBS - quo vadis?

[Richard Brown]

On 24 February 2017 at 10:29, Stefan Botter  wrote:

> And here again is the misunderstanding. Packman is not just there to
> provide the same packages as openSUSE, only fully working ones. Packman
> is a repository to host interesting software, which is elsewhere not
> found. Or crippled. Or old.

I do not want to comment too broadly on the discussion going on here -
there's a fair bit of quotation of me already.

But I have to pick out this sentence and point something out.

Every time Packman provides a package which COULD be in the
distribution(s) it's providing the package for, it is missing an
opportunity to help the upstream distribution it's meant to be working
with.

This is not a good sustainable model for Packman, and is not what I
would consider a friendly or healthy relationship between projects.
I consider it akin to openSUSE carrying patches without submitting
them to their respective upstreams, something which is seriously
frowned upon within the openSUSE project, and I do not apologise for
carrying forward that distaste when I see it in contexts like this.

It's not good open source practice, and it's really sad to see it
anywhere, but especially in a project that is close to one I care
about.

Putting that aside, every time Packman diverges from the distribution,
either in the above example of additional packages or in the form of
changes to overlapping packages, it's introducing scope for users to
experience broken behaviour, unexpected behaviour, or even benign
usability changes, which users still have to deal with.

To do this properly, you need to have solid quality controls and
processes, robust documentation, and multiple channels to keep a broad
userbase informed what's going on in your broad-based repository.
These are standards which not only distributions but any broad-based
repository provider adheres to, not just for the sake of their users
but to reduce the maintenance workload long term.

I feel Packman has little or no capability in any of these areas. I
think this is a recipe for repeated disappointment in the eyes of your
users, and as a package provider I think failing to address these
basics of software distribution is irresponsible.

With the current size of the Packman community & the hardware
available, I do not think it's feasible to suggest that Packman
invests a large amount of time, effort, hardware into the tooling and
processes to address those problems head on. Therefore I think it
would be the responsible thing to seriously and wholeheartedly adopt
any effort to reduce the scope of Packman to something much narrower
than "Packman is a repository to host interesting software".
This would at least mean you'd be in a position to at least limit the
breadth of risk to users by limiting the number of packages that are
provided without robust review, QC, QA, and active documentation.

openSUSE would be happy to take everything we can to help reduce that
burden upon Packman, we can work together to solve these problems, we
may not share build servers but almost all of Packmans users are
openSUSE users and I want to see them get the best experience possible
from both of our projects.

Regards,
Richard

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] gstreamer-plugins-libav missing

[Richard Brown]

On 23 August 2016 at 10:01, Olaf Hering  wrote:
> On Mon, Aug 22, Sergey Kondakov wrote:
>
>> Yeah, but how can it be "fixed" if in-OBS ffmpeg doesn't have that
>> code and doesn't even link with appropriate coding libraries ?
>
> By changing the code to offer the stuff ffmpeg may provide
> unconditionally. In the meantime the pkg is now reenabled in packman.
>
> Olaf

Thank you Olaf, always a pleasure :)

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] gstreamer-plugins-libav missing

[Richard Brown]

or to rephrase - "how the heck is gstreamer meant to decode h264 media now?"

On 22 August 2016 at 17:11, Richard Brown <rbrown...@opensuse.org> wrote:
> gstreamer-plugins-libav is missing from Packman - where'd it go? ;)

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

[packman] gstreamer-plugins-libav missing

[Richard Brown]

gstreamer-plugins-libav is missing from Packman - where'd it go? ;)

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] dropping support for SLE_11

[Richard Brown]

On 16 August 2016 at 15:07, Bruno Friedmann  wrote:
> On mardi, 16 août 2016 10.51:53 h CEST Luigi Baldoni wrote:
>> Sent: Monday, August 15, 2016 at 9:38 PM
>> From: "Olaf Hering" 
>>
>> > Does anyone still care about SLE_11 in packman? I think its time to
>> > retire it to free resources. The binary packages will remain on the
>> > mirrors.
>>
>> I seriously doubt anyone using SLE11 at this point is interested in
>> multimedia packages.
>
> Perhaps not easy as it sounds, but did you check stats to see if there's any
> hits on the repodata of this repository ?
> (Yeah yeah I know mirrors :-))

Multimedia packages are primarily for Desktop distributions

SUSE Linux Enterprise Desktop 11 support ended on 31st March 2016

https://www.suse.com/lifecycle/

If SUSE is no longer providing infrastructure or updates for it's
paying-for-SLED-11 customers, instead expecting them to be using SLED
12, then I believe this would be a logical approach for Packman to
follow


>
> --
>
> Bruno Friedmann
>  Ioda-Net Sàrl www.ioda-net.ch
>  Bareos Partner, openSUSE Member, fsfe fellowship
>  GPG KEY : D5C9B751C4653227
>  irc: tigerfoot
>
>
>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] Packman for Tumbleweed

[Richard Brown]

On 20 June 2016 at 12:02, Olaf Hering <o...@aepfle.de> wrote:
> On Mon, Jun 20, Richard Brown wrote:
>
>> Packman's current model for Tumbleweed, building against
>> multimedia:libs and not Tumbleweed, means that Packman users get
>> packages of the NEXT version of ffmpeg, gstreamer, etc, BEFORE it is
>> ready for Tumbleweed
>
> Regarding gstreamer, I wonder what kind of testing is done. Can it do
> anything useful in the variant from OBS? Looking at the spec files, only
> -bad and -ugly rely on packman.

openQA is fully capable of loading a video, going to a specific frame
and confirming it renders properly, and listening to audio and
ensuring the output from the sound card spectrographically matches a
reference audience sample.

So in short, we test if it works, not whether it's got a pretty spec file.

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

[packman] Packman for Tumbleweed

[Richard Brown]

On 20 June 2016 at 10:03, Dave Plater  wrote:
> This thread has the wrong subject.
> I think this is a proposal for a new Packman model.
> Rolling release Packman and stable Packman,

While I support this idea, I still think packman needs to stop rolling
faster than Tumbleweed

Therefore for rolling packman, I still recommend it should be built
against Tumbleweed, and not an untested devel project.

So while the discussions about Leap go on in the other thread, this
new thread is to discuss the situation specific to Tumbleweed

Tumbleweed is a tested rolling distribution. While it can change
anything at any time, it only changes stuff once they are tested and
integrated.

Packman's current model for Tumbleweed, building against
multimedia:libs and not Tumbleweed, means that Packman users get
packages of the NEXT version of ffmpeg, gstreamer, etc, BEFORE it is
ready for Tumbleweed

This causes disruption, pain, heartache, and I've now lost track of
the amount of times it's broken GNOME applications that used
gstreamer.

Packman is effectively treating it's users like guineapigs for the
unreleased packages in multimedia:libs. I'd rather Packman be a
reliable source of packages that can be trusted.

Please build Packman for Tumbleweed using linked packages from Tumbleweed.
Also, Bjorn's advice about =direct is still good ;)

- Richard

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] rebuilding gstreamer every day?

[Richard Brown]

On 19 June 2016 at 16:41, Dave Plater  wrote:
>> The pkg in multimedia:libs is about one hundred, thousand, million
>> times more at risk of being broken than the pkg in Factory
>
> Not if it's well maintained

There is _NO SUCH THING_ as a well maintained Devel Project.

https://en.opensuse.org/openSUSE:Factory_development_model

They EXIST to be where things are put together, broken and ultimately
fixed before being submitted to Factory for testing into Tumbleweed

A Devel Project which doesn't break from time to time is not doing
it's job properly.

>>
>> Because it's a devel project, where packages are MEANT to be broken
>> from time to time, meanwhile we KNOW the ffmpeg packages in Factory
>> work as they get tested in openQA as part of the VLC testing.
>>
>> I've said it before and I'll say it again Packman building against
>> multimedia:libs has always been silly
>
> Once Packman packages weren't linked and that resulted in many
> problems with incompatible libraries and out of sync maintenance.

I have no problem with linking, but link to the right thing for petes sake

ffmpeg in Packman is linked to openSUSE.org:multimedia:libs

This means it is version 3.0.2

In Tumbleweed ffmpeg is 2.8.6

In Leap ffmpeg is 2.8.6

In Leap 42.2 ffmpeg is 2.8.6

End result: Any Packman user is now forced to upgrade ffmpeg and
potentially ffmpeg related packages, including many multimedia
applications, to the versions in packman to a version of ffmpeg which
is UNTESTED and NOT SUPPORTED by the openSUSE Project (yet)

In short, this is dangerous, wrong, stupid and downright idiotic.. and
I'm being polite and holding back what i really think about it.

At the very LEAST ffmpeg in Packman should be linked to Factory/Tumbleweed

Packman for Leap should be linked to the version in Leap, so that
users do not have to suffer needless risk upgrading their packages.

> Packman is a safe way for users to get the newest packages, especially
> Leap users because it rarely gets new packages. It's a pity somebody
> doesn't donate some extra server power to Packman to speed up the
> build cycle. Maintaining the Packman packages in multimedia apps and
> libs has taken away the old volatility that used to come from Packman.
> It's a far better option to enabling multiple obs repositories for Leap.

No, Packman is not a safe way and this thread is sadly yet another
example of packman maintainers ignoring sound advice from seasoned
packagers who know what they're talking about.

And I'm not really talking about myself, you can ignore me all you
want, but Bjorn is an expert on all things packaging and OBS,
especially when it comes to large projects, it's downright crazy that
his good advice appears to be ignored.

Just as Tomas Chvatal's has been ignored on this list repeatedly.

Please guys, I've been a long supporter of Packman, even running
several servers for pmbs before I changed employer, so not erode my
goodwill and poison my soft spot for your efforts by stubbornly
sticking to your guns and risking the smooth operation of Tumbleweed
and Leap users in the process.

Please link your packages more appropriately.
Please do whatever you can to avoid unnecessary drift between Packman
and the distributions for which you are building Packman for.
Please rebuild="direct"

and Please listen to guys like Bjorn and Tomas when they give advice,
they know what they're talking about

- Richard
  http://rootco.de

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] rebuilding gstreamer every day?

[Richard Brown]

On 19 June 2016 at 11:53, Olaf Hering  wrote:
> On Thu, Jun 16, Bjørn Lie wrote:
>
>> Packman would be better of with link to the factory sources instead of
>> straight from the devel one in m:l.
>
> This does not help much. If the pkg in Factory gets broken for whatever
> reason it will take weeks until the error is resolved.
>
> Olaf

The pkg in multimedia:libs is about one hundred, thousand, million
times more at risk of being broken than the pkg in Factory

Because it's a devel project, where packages are MEANT to be broken
from time to time, meanwhile we KNOW the ffmpeg packages in Factory
work as they get tested in openQA as part of the VLC testing.

I've said it before and I'll say it again Packman building against
multimedia:libs has always been silly

In fact, for Leap, Packman should build against the packages in Leap
which would even further reduce the needless, pointless, load on pmbs
and on packman users constantly having to update packages for no
benefit.

But right now I would just take removing m:l out of the equation, it
has no place being used in this way.

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

[packman] Why is fdupes in Packman?

[Richard Brown]

As subject

Why is fdupes in Packman, and especially why is it in Essentials?

It's already in Tumbleweed, I don't see why it needs to be in Packman

I really don't like it when Packman replaces packages from openSUSE
without good reason...

Regards,

Richard

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] Unable to install w32codec-all for Tumbleweed

[Richard Brown]

Never mind..glitch in my salt state.. would have helped if I could
spell 'ugly' properly...

*hides in shame*

On 28 March 2016 at 22:22, Richard Brown <rbrown...@opensuse.org> wrote:
> On 28 March 2016 at 19:20, Olaf Hering <o...@aepfle.de> wrote:
>> On Mon, Mar 28, Richard Brown wrote:
>>
>>> Problem: nothing provides libstdc++.so.5 needed by 
>>> w32codec-all-20110131-1.9.i586
>>>  Solution 1: do not install w32codec-all-20110131-1.9.i586
>>>  Solution 2: break w32codec-all-20110131-1.9.i586 by ignoring some of its 
>>> dependencies
>>
>> I wiped the binaries and disabled the pkg.
>> What package requires w32codec?
>
>
> I dont know, but I wanted it because I thought it was the only way of
> getting wmv decoded..
>
> I have gstreamer bad, ugly, and libav from Packman, what more do I
> need to get wmv working?

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] Unable to install w32codec-all for Tumbleweed

[Richard Brown]

On 28 March 2016 at 19:20, Olaf Hering <o...@aepfle.de> wrote:
> On Mon, Mar 28, Richard Brown wrote:
>
>> Problem: nothing provides libstdc++.so.5 needed by 
>> w32codec-all-20110131-1.9.i586
>>  Solution 1: do not install w32codec-all-20110131-1.9.i586
>>  Solution 2: break w32codec-all-20110131-1.9.i586 by ignoring some of its 
>> dependencies
>
> I wiped the binaries and disabled the pkg.
> What package requires w32codec?


I dont know, but I wanted it because I thought it was the only way of
getting wmv decoded..

I have gstreamer bad, ugly, and libav from Packman, what more do I
need to get wmv working?

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

[packman] Unable to install w32codec-all for Tumbleweed

[Richard Brown]

Problem: nothing provides libstdc++.so.5 needed by
w32codec-all-20110131-1.9.i586
 Solution 1: do not install w32codec-all-20110131-1.9.i586
 Solution 2: break w32codec-all-20110131-1.9.i586 by ignoring some of
its dependencies

Looks like it's asking for the wrong libstdc, Tumbleweed is at 6

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] retiring 11.4 in packman

[Richard Brown]

Please save your build power and stop building packman for 11.4

11.4 has been out of offical support since November 2012

11.4 Evergreen support ceased in July 2015

Anyone who thinks the trickle of patches that volunteers are still pushing
out gives them any semblance of security is sorely mistaken

11.4 is unmaintained, insecure, and should be migrated from as soon as
possible

Ceasing pmbs support for 11.4 might help people realise how important it is
they move to a system which is still actively maintained
On 23 Mar 2016 8:54 am, "Olaf Hering"  wrote:
>
> On Wed, Mar 23, k...@wijatmoko.name wrote:
>
> > .. don't drop it from packman.
>
> The existing binaries wont go away from the mirrors.
>
> Olaf
>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] Only Sync Tumbleweed on Fridays?

[Richard Brown]

On 7 July 2015 at 13:27, Olaf Hering o...@aepfle.de wrote:

 At least the building starts right after OBS indicates changes.
 Dont know about publishing schedules.


Thats what I thought and what I thought I saw in PMBS. Glad to hear
it. Hopefully publishing is the typical publish after it's built -
at least, it seems to

Stupid rumours...

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] Account setup

[Richard Brown]

On 27/07/14 08:45, openSUSE user wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi. Can someone confirm my account (openSUSE-user), please ?
I need this, so I can have the access to the API for local custom
build tasks against Packman project.

Cheers.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJT1J/8AAoJEHRzCo0swmJSEREP/i7BAlRgijlaJb49KXRuIeZn
DtgtbY7SCjIUk1/wyXzb4vq1QqqzgpTJEINKsqYbni2NXPF2Cx1LVY1/MSgPdsbQ
7Xp9h9J74ZrZ4yCovEZchstULyFJI2kzpMi10veaSS0qD+yIKbHcuKG3to4bYiq0
4ZcfPiRr3CKYpvtsacG81PS+oT7v/Ry/OtuTVTeD1sgyZaVltVwLrzLt9y9/ZvkY
KMM0Og8IgxE6+BN40v+rhR4vQUsbQMOPEfvPBYFYvaAVlXuUmuJ84w9lwKTJRqpV
BwPHFeL15DB+r8aEWkbxOTqcYKnct4tDoKQY19Wt/nZDyNxEslnb44Xrs36J1CjM
1SpcrUjk0ZVR1J6Qo3+uIPm95glMaocq1j9qzM6aU2dL32snG5NKHjmPMxExTeB4
14qB20SPfq1mPF//ibIN7/WdJxh43+yAJuTL5Zkd/UWuxdnVJSQsPQlHbnht54yH
E/WFTLseZJUaWaZ4fhutYxiy4DtQHOFZawU5dZtSTCLuQLgp2T5U3NkLffMumJqe
s0nwsSXSFrezQ2vBvflxhRw4pdWW43khgFbEm7crhoujZNDicptJC+EiiF8WXpKE
gMxZ4Eby1U2pxLMe6WsundInSNLfxp4doUIgjEClZhcW+usPwrN59UYnN+KijkM/
TVwRtwNoKbdb2vgsltcF
=I/nI
-END PGP SIGNATURE-

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman



Hello Packman Maintainers,

I don't mean to meddle, but despite this persons email address 
(devel.opensuse@gmail.com) I do not believe this request is coming 
from anyone 'officially' affiliated with the openSUSE project.


Given the potentially 'suspicious' choice of mail address and the nature 
of the request, I think it might be an idea to investigate further to 
understand who this person is and why they desire this access before 
accepting this request.


Regards,

Richard Brown
openSUSE Board Chair



___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] GStreamer on 13.1

[Richard Brown]

Thanks for the followup :) I'll take a look at it in the morning
On 14 Nov 2013 00:59, Cristian Morales Vega reddw...@opensuse.org wrote:

 On 11 November 2013 20:41, Cristian Morales Vega 
 christian.morales.v...@gmail.com wrote:

 On 11 November 2013 15:53, Cristian Morales Vega
 cristian.morales.v...@gmail.com wrote:
  On 11 November 2013 15:24, Richard Brown rbrown...@opensuse.org
 wrote:
  On Mon, 2013-11-11 at 15:10 +, Cristian Morales Vega wrote:
  On 11 November 2013 15:02, Richard Brown rbrown...@opensuse.org
 wrote:
  I already *have* all the GStreamer 1.2 packages from Packman manually
  installed, but Totem/GStreamer+PackageKit clearly wants the 1.0 (from
  13.1 oss repo) as well.
 
  I think Dominique/Dimstar is the openSUSE person who better
  understands it, you may ask him. But AFAIK
  Totem/GStreamer+PackageKit should not want the 1.0 as well. The
  1.2 packages *are* enough, and it should be happy with them. Asking
  for the 1.0 one is IMHO a bug.

 I just checked in my 12.3, which is in *exactly* the same situation:
 Totem from openSUSE, compiled against GStreamer 1.0 from openSUSE,
 works just fine with GStreamer 1.2 from Packman.
 When I uninstall gstreamer-plugins-libav the video fails to play, but
 Totem doesn't ask me to install it. I guess there is something broken
 in 12.3 that was fixed in 13.1. Perhaps when fixing that a new problem
 appeared?


 And it also works in my new 13.1 installation.

 Something is broken in your system. You may want to run:
 rm -rf ~/.cache/gstreamer-1.0


___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] GStreamer on 13.1

[Richard Brown]

On 11 November 2013 15:57, Cristian Morales Vega reddw...@opensuse.org wrote:
 You shouldn't try to install both, only 1.2. Can I see that auto
 solver pop up?

Here it is: http://i2.minus.com/iVUjY1o1xdg4S.png



 Can we get all the packages for 13.1 set to gstreamer 1.0.x, or find out
 what's really going on?

 From http://gstreamer.freedesktop.org/news/
 The GStreamer team is pleased to announce the first release of the
 stable 1.2 release series. The 1.2 release series is adding new
 features on top of the 1.0 series and is part of the API and
 ABI-stable 1.x release series of the GStreamer multimedia framework
 that contains new features.

 I didn't have time (or a proper computer) to check. But AFAIKT
 GStreamer 1.2 is 100% compatible with GStreamer 1.0. What's the
 problem?
 If the problem is that the Totem package is hardcoding a dependency to
 GStreamer == 1.0 then what must be fixed is the Totem package. But
 looking at https://build.opensuse.org/package/show/openSUSE:13.1/totem
 I can't see such a thing.

I can understand where you're coming from, but if that was the case,
then I shouldn't be having any problem playing media on my 13.1
laptop. Can you get it working fine?

Unless I'm doing something awfully stupid, but given I've been using
oS+Packman for 7 years, I'd like to think I know what I'm doing by now
:)

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] GStreamer on 13.1

[Richard Brown]

On Mon, 2013-11-11 at 15:10 +, Cristian Morales Vega wrote:
 On 11 November 2013 15:02, Richard Brown rbrown...@opensuse.org wrote:
  On 11 November 2013 15:57, Cristian Morales Vega reddw...@opensuse.org 
  wrote:
  You shouldn't try to install both, only 1.2. Can I see that auto
  solver pop up?
 
  Here it is: http://i2.minus.com/iVUjY1o1xdg4S.png
 
 I don't use Gnome, but that seems to be the GStreamer-PackageKit 
 integration.
 It appears automatically when you try to play a video for which you
 don't have the decoder?
 If so, trying to install both 1.0 and 1.2 is a bug in the
 GStreamer-PackageKit integration. You should report it at
 https://bugzilla.novell.com/. If you assign it to the Gnome team I am
 sure you will get a reply soon.
 By the way, the fact that gstreamer-plugins-base-1.0.10-2.1.3
 (64-bit) appears twice is clearly an indication that something is
 wrong there.

While I really appreciate your confidence in the GNOME team, as a member
of that team, I can quite comfortably say I don't think it's a problem
with GStreamer-PackageKit integration :) (read on for why I think
this..)

 I don't have a 13.1 system yet.
 But you should be able to use zypper to install the GStreamer (1.2)
 packages from Packman manually and then the GStreamer-PackageKit
 integration will not be needed.

...and that is why I think GStreamer-PackageKit isn't the problem. Your
suggestion to install GStreamer 1.2 is exactly what I've already done.
Sorry for not mentioning it earlier

I already *have* all the GStreamer 1.2 packages from Packman manually
installed, but Totem/GStreamer+PackageKit clearly wants the 1.0 (from
13.1 oss repo) as well. 
As your (Packmans) 1.2 version have the same package name, file
locations, etc, there's no way to install both, so it would seem I'm
either left with using 13.1-oss-repo's 1.0 packages with only open
codecs supported, or Packmans 1.2 version which does not appear to work
properly with Userspace applications, at least, not Totem, the main
Video player in GNOME in 13.1

I think this is where Tomas is coming from with his suggestion to have
Packman better track the versions in a release. I'm reasonably sure that
if Packman built GStreamer 1.0.x for openSUSE 13.1, I'd be having no
problem at all here.

At least that's the theory I'd like to pursue, unless there is an
absolutely compelling reason why Packman must provide GStreamer 1.2 when
13.1 is released? 

I would personally prefer to err on the side of caution and, hopefully,
have a smoother time of playing restricted formats when release day
comes about :)


___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman