AW: lede.eu nachricht
Guten Tag geehrte Frau / Herr, Es ist amtlich das der DomainName lede.eu für Sie zur möglichen Abgabe steht. Würden Sie mir bitte eine kurze Rückmeldung geben ob es für Sie von Interesse ist? Mit besten Grüßen aus Wien Angela Müllner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
On 10/08/2020 10:08, Adrian Schmutzler wrote: -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Mauro Mozzarelli Sent: Montag, 10. August 2020 10:36 To: openwrt-devel@lists.openwrt.org Subject: Re: Policy on BUILD_PATENTED On 09/08/2020 12:44, Bjørn Mork wrote: Mauro Mozzarelli writes: On 09/08/2020 03:35, Henrique de Moraes Holschuh wrote: I believe OpenWrt should not even *consider* placing its umbrella organization(s) -- which are based on the U.S. -- in legal risk without at least contacting them first and getting their approval. Has anyone asked SPI about it yet? Who/What are these "umbrella" organizations? What is their relationship with OpenWrt? This is answered by the FAQ: https://openwrt.org/faq/general And what is the "legal risk"? I guess that's the question you should ask the SPI. This is not a technical or a political discussion. It's about not putting your friends at unnecessary risk, even if they happen to live under some regime you don't like or respect. Bjørn Although I respect other's opinions and rules, I do not think it is right to limit everyone's freedom, just to appease some. That's why we allow you to use BUILD_PATENTED and not just remove that stuff entirely. If there is a minority who is unable to use parts of this software, we can make it easy for that minority to be able to strip those software components (or they can propose and implement changes that achieve that themselves), but in no way limit or prevent everyone from making use of it. But still, OpenWrt as a project/organization in embedded in an environment it has to care about. And that of course includes caring about the interests of important stakeholders (or at least ask them about those), and not make our decisions based on how we would like the world to be. I think Bjørn put that in a nutshell nicely. Best Adrian Citizens of the European Union are major contributors to OpenWrt and other Open Source projects, The European Union, after several years of debate. listened to its citizens, not corporations, and has put into law that freedom from software patents that allows us all to contribute to the community without fear of litigation nor constraints imposed from monopolistic organizations. The EU and its citizens are too important stakeholders. EU law, and EU citizens' will must too be respected. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] binutils: fix build after upgrade to 2.34
On 8/10/20 6:51 AM, W. Michael Petullo wrote: > From: "W. Michael Petullo" > > Building the binutils package produced the following error: > > Package binutils is missing dependencies for the following libraries: > libctf-nobfd.so.0 > > This changes the glob for the libctf subpackage so that it catches > libctf-nobfd.so.0. > > Signed-off-by: W. Michael Petullo > --- > package/devel/binutils/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/devel/binutils/Makefile b/package/devel/binutils/Makefile > index 6ad326efa0..fada8009be 100644 > --- a/package/devel/binutils/Makefile > +++ b/package/devel/binutils/Makefile > @@ -106,7 +106,7 @@ endef > > define Package/libctf/install > $(INSTALL_DIR) $(1)/usr/lib > - $(CP) $(PKG_INSTALL_DIR)/usr/lib/libctf.so* $(1)/usr/lib/ > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libctf*.so* $(1)/usr/lib/ > endef > > define Package/libopcodes/install > I already send this patch some hours before: https://patchwork.ozlabs.org/project/openwrt/patch/20200809160216.23697-1-ha...@hauke-m.de/ It fixes the same problem. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Fwd: Re: Policy on BUILD_PATENTED
On 10/08/2020 06:08, Adrian Schmutzler wrote: But still, OpenWrt as a project/organization in embedded in an environment it has to care about. And that of course includes caring about the interests of important stakeholders (or at least ask them about those), and not make our decisions based on how we would like the world to be. Well said ! +1 I think Bjørn put that in a nutshell nicely. Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: missing email header
On 09/08/2020 17:17, Fabian Bläse wrote: please keep the current configuration. The Subject header ist typcially configured to be included in dkim signatures. Therefore mangling the subject breaks the signature, which might lead to rejected mails or higher spam scores. Agreed. HOWEVER, anything that is being relayed due to too-strict SPF is being relayed with an *EMPTY* subject, and *THAT* is extremely annoying. -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
On Mon, Aug 10, 2020 at 09:36:08AM +0100, Mauro Mozzarelli wrote: > If there is a minority who is unable to use parts of this software, Worth considering: do we know for sure that it's a minority? And is it even relevant whether it is a minority or a majority, as long as we know that some developers and some users do live or work in jurisdictions where software patents are litigiously upheld? > we can make it easy for that minority to be able to strip those > software components (or they can propose and implement changes that > achieve that themselves), but in no way limit or prevent everyone from > making use of it. IIUC, you are suggesting the creation of a new package repository through which OpenWRT devs who are based in countries (e.g. EU countries) that don't uphold software patents could distribute patent-encumbered software. Users would then be able to decide whether or not to enable that repo. This would be a *little* like Debian's "non-free" repository, insofar as it separates some packages into a different repository than usual (Debian's default repo is called "main") based on their legal status: https://www.debian.org/doc/debian-policy/ch-archive#s-non-free . I emphasised "little" in the previous sentence because Debian's non-free repo was based on copyright (not patents), whereas your proposal AIUI is based on patents (not copyright). See, e.g.: On Mon, Jul 11, 2005 at 11:10:57AM +0100, Daniel James wrote: > [..] As a short-term measure, I suggest that the xmms package in > Debian is split into xmms and xmms-mpg123 with the latter package > moving to non-free. I have cc'd the maintainers of the xmms > package in Debian. This is generally not regarded as an appropriate use of non-free; patent-encumbered works cause problems whether they're shipped in non-free or in main. [..] Steve Langasek Source: https://lists.debian.org/debian-legal/2005/07/msg00082.html To me, as an OpenWRT user, your proposal seems reasonable, but IANAL. It would seem wise for OpenWRT devs to seek advice on the proposal, from SPI and/or SFC. Best wishes, Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
On Sun, Aug 09, 2020 at 01:21:26PM -0700, Rosen Penev wrote: > On Sun, Aug 9, 2020 at 6:09 AM Sam Kuper wrote: >> On Sun, Aug 09, 2020 at 10:55:37AM +0100, Sam Kuper wrote: >>> On Mon, Aug 03, 2020 at 07:11:13PM +0300, Etienne Champetier wrote: Le lun. 3 août 2020 à 00:04, Rosen Penev a écrit : > Whenever discussion about patents arise, I usually point to > Fedora whose parent company is Red Hat, which is based in the US. > There are many things that they do not distribute that OpenWrt > does for legal reasons. Should Fedora's practices be mirrored or > should a more liberal policy regarding patented functionality be > taken? >>> >>> For OpenWRT at least, might Debian be a more appropriate exemplar >>> than Fedora? Unlike Fedora AFAIK, but like OpenWRT, Debian is >>> represented in some sense by SPI: >>> https://www.spi-inc.org/projects/debian/ . >>> >>> The debian-legal mailing list archives can be searched for the >>> decisions taken by the debian-legal team, and the reasoning behind >>> those decisions: https://lists.debian.org/debian-legal/ . >> >> Here is an example of discussion on that list, that is on a similar >> topic to the original question in this thread: patent-encumbered >> software. It also speaks to differences between the Debian and Red >> Hat policies. >> >> (The example is 15 years old, so perhaps not representative of >> current policy. I'm just giving it as an example.) >> >> [The] reason Debian continues to include the mp3 decoder library >> is that this patent, like so many other software patents, does >> not appear to be actively enforced. This is the standard Debian >> uses in deciding whether to distribute the software; Red Hat >> evidently uses a different standard. > > Yep. And this is the issue. Which standard is to be followed, Red > Hat's or Debian? [..] > > I'd like a decision on this issue. [..] Yes; that's why I suggested contacting SPI and/or SFC.* Those organisations exist to help libre software projects to thrive. They might be able to provide suitable legal advice to ensure that if OpenWRT adopts a policy on how to deal with patented software, that policy would be a well-informed one that provides the maximum benefit to OpenWRT's users, within the OpenWRT devs' risk appetite. I'm not an OpenWRT dev, so I don't think it would be appropriate for me to contact SPI or SFC on behalf of OpenWRT; but you seem to be, so perhaps you should? Maybe CC, into that message, any other devs who are interested in formulating an OpenWRT patent policy (and at least CC the SPI OpenWRT liaisons, Imre Kaloz and John Crispin)? And if you get any useful info from SPI or SFC, then maybe use it to help formulate an OpenWRT patent policy RFC and post it to this mailing list (e.g. as a follow-up to this thread)? (For an example of a recent OpenWRT RFC thread, see Paul Spooren's thread on PKG_RELEASE policy. To find the latter in your inbox, search for Message-ID 5ee96304-afff-c527-4c52-a9704bb9b...@aparcar.org .) Good luck, Sam * Note 1: SFC is not to be confused with SFLC. They are different organisations run by different people. Note 2: I would not recommend contacting SFLC, for the reasons given by Matthew Garrett: https://mjg59.dreamwidth.org/49370.html . This creates a possible difficulty, insofar as SPI currently lists SFLC as its legal advisor: https://www.spi-inc.org/corporate/board/ . A reasonable solution to that difficulty would be that if you do contact SPI, you could say in that message that you would prefer SPI not to contact SFLC on your behalf without first checking with you. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Policy on BUILD_PATENTED
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Mauro Mozzarelli > Sent: Montag, 10. August 2020 10:36 > To: openwrt-devel@lists.openwrt.org > Subject: Re: Policy on BUILD_PATENTED > > On 09/08/2020 12:44, Bjørn Mork wrote: > > Mauro Mozzarelli writes: > >> On 09/08/2020 03:35, Henrique de Moraes Holschuh wrote: > >> > >>> I believe OpenWrt should not even *consider* placing its umbrella > >>> organization(s) -- which are based on the U.S. -- in legal risk > >>> without at least contacting them first and getting their approval. > >>> > >>> Has anyone asked SPI about it yet? > >> Who/What are these "umbrella" organizations? What is their > >> relationship with OpenWrt? > > This is answered by the FAQ: > > https://openwrt.org/faq/general > > > >> And what is the "legal risk"? > > I guess that's the question you should ask the SPI. > > > > This is not a technical or a political discussion. It's about not > > putting your friends at unnecessary risk, even if they happen to live > > under some regime you don't like or respect. > > > > > > Bjørn > > Although I respect other's opinions and rules, I do not think it is right to > limit > everyone's freedom, just to appease some. That's why we allow you to use BUILD_PATENTED and not just remove that stuff entirely. > > If there is a minority who is unable to use parts of this software, we can > make > it easy for that minority to be able to strip those software components (or > they can propose and implement changes that achieve that themselves), but > in no way limit or prevent everyone from making use of it. But still, OpenWrt as a project/organization in embedded in an environment it has to care about. And that of course includes caring about the interests of important stakeholders (or at least ask them about those), and not make our decisions based on how we would like the world to be. I think Bjørn put that in a nutshell nicely. Best Adrian > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH procd] initd/init: add minimal SELinux policy loading support
Hi,
Sun, Aug 09, 2020 at 03:15:20PM -1000, Paul Spooren wrote:
> From: Thomas Petazzoni
>
> In order to support SELinux in OpenWrt, this commit introduces minimal
> support for loading the SELinux policy in the init code. The logic is
> very much inspired from what Busybox is doing: call
> selinux_init_load_policy() from libselinux, and then re-execute init
> so that it runs with the SELinux policy in place and enforced.
>
> Signed-off-by: Thomas Petazzoni
> [fix spelling of OpenWrt]
> Signed-off-by: Paul Spooren
> ---
> This is part of a bigger PR on GitHub[1], however this patch should be
> added directly to `procd` rather than as a patch in openwrt.git.
>
> As some core devs avoid GitHubs heavy frontend, I send this particular
> patch here again.
>
> I've tested the patch series and it compiles and runs as (I) expected.
I've applied this to move forward, however, there will be a problem
once we got libselinux packaged, as buildbots will then ALWAYS build
procd with libselinux. What we would need now is packaging two
variants of procd (and busybox and maybe other packages): One without
selinux support and one seliux-enabled which depends on libselinux.
(assuming we are heading for SELinux support in our binary
distribution -- otherwise we can just mark libselinux as @BROKEN for
buildbot not to consider it and only allow building from source if
user wants support for SELinux)
>
> [1]: https://github.com/openwrt/openwrt/pull/3207
>
> CMakeLists.txt | 9 -
> initd/init.c | 38 ++
> 2 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index c7adfa3..d20e57b 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -46,6 +46,12 @@ IF(ZRAM_TMPFS)
>SET(SOURCES_ZRAM initd/zram.c)
> ENDIF()
>
> +IF(SELINUX)
> + include(FindPkgConfig)
> + pkg_search_module(SELINUX REQUIRED libselinux)
> + add_compile_definitions(WITH_SELINUX)
> +ENDIF()
> +
> add_subdirectory(upgraded)
>
> ADD_EXECUTABLE(procd ${SOURCES})
> @@ -62,7 +68,8 @@ ADD_DEFINITIONS(-DDISABLE_INIT)
> ELSE()
> ADD_EXECUTABLE(init initd/init.c initd/early.c initd/preinit.c initd/mkdev.c
> sysupgrade.c watchdog.c
> utils/utils.c ${SOURCES_ZRAM})
> -TARGET_LINK_LIBRARIES(init ${LIBS})
> +TARGET_INCLUDE_DIRECTORIES(init PUBLIC ${SELINUX_INCLUDE_DIRS})
> +TARGET_LINK_LIBRARIES(init ${LIBS} ${SELINUX_LIBRARIES})
> INSTALL(TARGETS init
> RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
> )
> diff --git a/initd/init.c b/initd/init.c
> index 9b47826..2eb6ead 100644
> --- a/initd/init.c
> +++ b/initd/init.c
> @@ -29,6 +29,10 @@
> #include
> #include
>
> +#if defined(WITH_SELINUX)
> +#include
> +#endif
> +
> #include "../utils/utils.h"
> #include "init.h"
> #include "../watchdog.h"
> @@ -67,6 +71,38 @@ cmdline(void)
> }
> }
>
> +#if defined(WITH_SELINUX)
> +static int
> +selinux(char **argv)
> +{
> + int enforce = 0;
> + int ret;
> +
> + /* SELinux already initialized */
> + if (getenv("SELINUX_INIT"))
> + return 0;
> +
> + putenv("SELINUX_INIT=1");
> +
> + ret = selinux_init_load_policy(&enforce);
> + if (ret == 0)
> + execv(argv[0], argv);
> +
> + if (enforce > 0) {
> + fprintf(stderr, "Cannot load SELinux policy, but system in
> enforcing mode. Halting.\n");
> + return 1;
> + }
> +
> + return 0;
> +}
> +#else
> +static int
> +selinux(char **argv)
> +{
> + return 0;
> +}
> +#endif
> +
> int
> main(int argc, char **argv)
> {
> @@ -79,6 +115,8 @@ main(int argc, char **argv)
> sigaction(SIGUSR2, &sa_shutdown, NULL);
> sigaction(SIGPWR, &sa_shutdown, NULL);
>
> + if (selinux(argv))
> + exit(-1);
> early();
> cmdline();
> watchdog_init(1);
> --
> 2.25.1
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC] Policy for PKG_RELEASE bumps
Hi, > Looking at other distros (Debian [1], Fedora [2]), it appears to be common to > reset the equivalent of PGK_RELEASE for every upstream version bump. In > OpenWrt it appears to mean [3] "our version since the dawn of times" > instead of "our version of this upstream release". that's a misunderstanding. PKG_RELEASE _is_ (/should be) reset for every upstream version bump, i.e. when PKG_VERSION or PKG_SOURCE_DATE are changed. However, in that ref [3] I removed PKG_VERSION for those cases where _there is no upstream_, i.e. no PKG_SOURCE_URL was set. The past has shown that "inventing" an upstream version where there is none is rather detrimental, as nobody will know which variable to bump. So, in this case, and this case only, I removed the PKG_VERSION. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Policy on BUILD_PATENTED
On 09/08/2020 12:44, Bjørn Mork wrote: Mauro Mozzarelli writes: On 09/08/2020 03:35, Henrique de Moraes Holschuh wrote: I believe OpenWrt should not even *consider* placing its umbrella organization(s) -- which are based on the U.S. -- in legal risk without at least contacting them first and getting their approval. Has anyone asked SPI about it yet? Who/What are these "umbrella" organizations? What is their relationship with OpenWrt? This is answered by the FAQ: https://openwrt.org/faq/general And what is the "legal risk"? I guess that's the question you should ask the SPI. This is not a technical or a political discussion. It's about not putting your friends at unnecessary risk, even if they happen to live under some regime you don't like or respect. Bjørn Although I respect other's opinions and rules, I do not think it is right to limit everyone's freedom, just to appease some. If there is a minority who is unable to use parts of this software, we can make it easy for that minority to be able to strip those software components (or they can propose and implement changes that achieve that themselves), but in no way limit or prevent everyone from making use of it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
